Community编程与开发github.com

BuilderIO/plow-ahead

Use when the user explicitly wants autonomous progress without routine clarification stops: "plow ahead", "do not stop", "use your best judgment", "keep going until done", "finish while I am away", "do not ask questions unless truly blocked", or similar. Convert ordinary ambiguity into stated assumptions, proceed through implementation and validation, stop only for true blockers, and end with a clear recap of decisions, changes, verification, and residual risk.

plow-ahead 是什么?

plow-ahead is a Claude Code agent skill that use when the user explicitly wants autonomous progress without routine clarification stops: "plow ahead", "do not stop", "use your best judgment", "keep going until done", "finish while I am away", "do not ask questions unless truly blocked", or similar. Convert ordinary ambiguity into stated assumptions, proceed through implementation and validation, stop only for true blockers, and end with a clear recap of decisions, changes, verification, and residual risk.

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/BuilderIO/skills/tree/main/skills/plow-ahead

Installed? Explore more 编程与开发 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

Plow Ahead

Proceed through ordinary ambiguity. Make reasonable assumptions, keep momentum, validate as you go, and make the final recap strong enough that the user can see what decisions were made while they were away.

Autonomy Contract

Treat the user's instruction as permission to continue through normal uncertainty:

  • Turn routine questions into explicit assumptions.
  • Prefer the smallest reversible choice that satisfies the request.
  • Use repo conventions, nearby patterns, local docs, tests, and existing product behavior as the decision source.
  • Keep working through normal test failures, missing context, implementation choices, and minor ambiguity.
  • Use subagents for independent research, implementation, or verification when parallel work can reduce idle time or improve coverage.
  • Do not pause merely to ask which reasonable option the user prefers. Pick one, record why, and keep going.

Stop Conditions

Stop and ask only for true blockers:

  • Required credentials, secrets, accounts, paid services, or private data are unavailable.
  • The next step would be destructive, irreversible, or production-mutating.
  • The task requires an explicit branch operation, history rewrite, force push, or deletion that the user did not directly request.
  • Legal, safety, privacy, or security risk is high and cannot be reduced by a conservative local choice.
  • The user explicitly reserved a decision for themselves.
  • A verification failure repeats after reasonable investigation and the next fix would be speculative or broad.

If blocked, leave a self-contained handoff: what was done, what blocks progress, what exact input is needed, and the next command or file to inspect.

Decision Rules

When choosing without the user:

  1. Reuse existing patterns before inventing new ones.
  2. Prefer local, reversible, low-blast-radius changes.
  3. Keep scope tight to the user's request.
  4. Choose correctness and maintainability over cleverness.
  5. Validate with the smallest meaningful test first, then broaden only when the risk justifies it.
  6. If two options are close, choose the one that is easier for the user or a reviewer to understand later.

Maintain a lightweight decision log while working. It can live in notes, the plan, or your final answer, but do not create a new repo artifact unless the task needs one.

Work Loop

  1. Restate the goal internally and identify likely acceptance criteria.
  2. Inspect the real files, docs, issue, PR, screenshots, or runtime behavior before editing.
  3. Make assumptions explicit, then act on them.
  4. Implement in small coherent steps.
  5. Run targeted validation and fix issues found by validation.
  6. Repeat until the requested work is complete or a stop condition applies.
  7. Before final response, review the diff and verification evidence against the original request.

Final Recap

End with a recap that makes autonomous decisions auditable:

Goal
- What you completed.

Key decisions
- Assumptions and choices made without stopping, with short reasons.

Changes
- Files, behavior, docs, or configuration changed.

Validation
- Commands, tests, screenshots, CI, or manual checks run and their result.

Remaining risk
- Anything not verified, deferred, or blocked.

Keep the recap factual. Do not hide uncertainty, skipped validation, or judgment calls.

Individual skills in this repo

This repo contains 10 individual skills — each has its own dedicated page.

BuilderIO/adding-a-skill

Use in the BuilderIO/skills repo whenever adding, updating, publishing, documenting, validating, or wiring a public skill. Covers the repo-local skill files, root catalog docs, plugin metadata, @agent-native/skills dynamic install path, optional managed AGENTS/CLAUDE instruction blocks in ../agent-native/framework, and generated/synced Plan skill gotchas.

BuilderIO/agent-watchdog

Use when asked to watch, babysit, audit, review, compare, or fix another agent's work from a Codex session ID, Claude Code session/transcript, chat/thread link, PR, branch, log, or pasted run summary. Monitor until the other agent is done or blocked, reconstruct what the user asked, inspect what the agent actually changed and verified, report gaps, and optionally make scoped fixes when the user authorizes repair.

BuilderIO/efficient-fable

Use when running Claude Fable on codebase-heavy or token-heavy work and the user wants Fable to orchestrate research, coding, and testing while cheaper subagents do bounded heavy lifting.

BuilderIO/efficient-frontier

Apply the same orchestration as `/efficient-fable` to any high-cost frontier model: delegate research, coding, and testing to cheaper subagents while keeping planning, synthesis, and final review with the expensive model.

BuilderIO/plan-arbiter

Use when asked to compare, cross-review, merge, judge, choose, or arbitrate competing plans from multiple agents such as Codex and Claude Code; when given two or more proposed plans, session IDs, transcripts, plan documents, PR descriptions, or pasted strategies; or when the user wants one recommended execution plan after agents review each other's proposals.

BuilderIO/quick-recap

Use when adding or following the red/yellow/green final status block convention for agent responses, especially by installing managed AGENTS.md or CLAUDE.md instructions.

BuilderIO/read-the-damn-docs

Use when implementing, integrating, upgrading, debugging, or answering anything involving third-party APIs, libraries, frameworks, CLIs, cloud services, model/provider SDKs, fast-moving product behavior, user requests for latest/current/official behavior, unfamiliar repo docs/specs, errors that may indicate API drift, or high-stakes auth, security, billing, data, migration, deployment, compliance, or privacy behavior. Forces Codex to web-search for current official docs and read primary docs before assuming from memory.

BuilderIO/stay-within-limits

Use when long-running or parallel agent work must respect 5-hour and weekly usage limits by checking usage between waves, pausing near the cap, and resuming only when the window is clear.

BuilderIO/visual-plan

Turn ordinary text plans into rich interactive visual plans with diagrams, file maps, annotated code, open questions, and UI/prototype review when useful.

BuilderIO/visual-recap

Turn a PR, branch, commit, or git diff into an interactive visual recap with diagrams, file maps, API/schema summaries, annotated diffs, and focused review notes.

相关技能