一键导入
code-plan
Use only when autopilot-code dispatches the planning and plan-check stage. Not for top-level user requests or primary capability routing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use only when autopilot-code dispatches the planning and plan-check stage. Not for top-level user requests or primary capability routing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Use when source code must be implemented, debugged, refactored, or code-audited through a plan, execution, test, and report loop. Not for requirements-only changes, new empirical experiments, or document-only editing.
Use when persistent analysis of code, a paper, or a document must be created or refreshed because it is absent, stale, or explicitly requested. Not for read-only project orientation, context recovery, or status reporting.
Use when durable cross-project user preferences must be inferred from coding, writing, or analysis evidence and stored as a profile. Not for one-project context recovery, casual preference acknowledgment, or ordinary task execution.
Use when a visual product surface needs references, design tokens, components or mockups, review, and development handoff. Not for implementing an already-approved design in code or for document prose work.
Use when a new paper, presentation, report, proposal, or other user-facing document must be produced from evidence. Not for correcting only an existing document or for source-code implementation.
Use only when autopilot-draft dispatches document strategy and evidence-plan creation. Not for top-level user requests or primary capability routing.
基于 SOC 职业分类
| name | code-plan |
| description | Use only when autopilot-code dispatches the planning and plan-check stage. Not for top-level user requests or primary capability routing. |
| argument-hint | <task description> [--intensity direct|quick|standard|strong|thorough|adversarial] |
| metadata | {"group":"sub","fam":"sub","invocation_class":"parent-invoked","modes":[],"blurb":"Analyze code, write a detailed implementation plan, and run the plan-check gate at the rigor derived from intensity.","use_when":"Use only when autopilot-code dispatches the planning and plan-check stage.","not_for":"Not for top-level user requests or primary capability routing."} |
Use the deepest eligible planning profile selected by the active adapter when cross-file reasoning or call-site analysis would benefit from it.
Stage-session entry (
standard+dispatch, spec/stage-dispatch SD-2): Run in-session or as an isolated dispatch-depth-2 stage worker dispatched by theautopilot-codeconductor. Inputs are the task description and<artifact-root>/plans/; never depend on prior-stage conversation. The write class isplan/plan.md, an existing or explicitly requested audience-language companion such as legacyplan/plan_ko.md, and_internal/plan_reviews/. The stage runs as theplan/plan-authorunit (the node's unit); independent plan review is the siblingplan-checknode dispatched by the conductor, not an in-stage delegation.
Language rule: Follow the audience and artifact language contract in arguments-and-decisions.md#language-rule. Write the canonical plan in the selected artifact language; do not generate a language mirror merely because the skill source is English or the conversation uses a particular language.
Search <artifact-root>/plans/ for a similar plan and branch on its frontmatter status:
active: Ask whether to continue the active plan or create a new one. Do not proceed until that genuine choice is resolved.done or failed: Note it as a reference and create a new plan without pausing.partial: Read failed_steps and create a new plan covering only those failed or dependent steps without pausing.Record any user-facing pause for pipeline_summary.md Decision Points.
Run the plan/plan-author unit with this task, adapted only for the selected artifact language and known prior-plan state:
Plan mode. Create a new implementation plan.
Task: {$ARGUMENTS}
Save canonical plan to: <artifact-root>/plans/{YYYY-MM-DD}_{short-task-name}/plan/plan.md
Artifact language: {selected audience or conversation language}
Date: {YYYY-MM-DD}
{If a done/failed/partial plan exists: "Reference previous plan: [path], status: [status]"}
{If partial: "Failed steps from previous execution: [list from plan frontmatter failed_steps]"}
Plan procedure, plan structure, and the single-line return contract are owned by the plan/plan-author unit persona; do not restate them in the prompt. The stage orchestrator receives only the unit's return line ({path} -- {verdict}); plan content stays in the file.
Derive verification rigor from the caller's --intensity and plan risk under CONVENTIONS §1.1. Rigor does not select this stage: code-plan runs only after the caller chooses a durable standard+ graph. direct skips it; quick uses a one-shot worker with an inline micro-plan and plan-check-lite.
Set {log_dir} to the task root above plan/; for example, <artifact-root>/plans/2026-03-18_task/plan/plan.md resolves to <artifact-root>/plans/2026-03-18_task/. Run mkdir -p {log_dir}/_internal/plan_reviews before independent review.
| Rigor | Plan-check action | Correction budget |
|---|---|---|
quick | Normally unreachable; if invoked directly, run one fast sanity review or self-check | Record residual concerns; no repeated loop |
light | One focused fast review or equivalent self-check | One pass only when an issue blocks execution |
standard | One independent review for feasibility, missing steps, and concrete verification commands | At most one correction |
thorough | Deeper or multi-axis review when explicitly selected by the graph | Up to two corrections after synthesizing reviews |
adversarial | Thorough review plus failure-mode, security, and adversarial critique when the adapter proves availability | Explicit unavailable requests fail loudly; automatic escalation falls back to thorough |
After the plan/plan-author unit returns:
plan-check sibling node (unit qa/plan-review), which writes {log_dir}/_internal/plan_reviews/round_{N}.md. Use bounded separate reviewers only when the owner-worker graph and rigor select them.Record any user-facing pause, including active-plan ambiguity, for the pipeline summary.
The canonical plan.md should normally be sufficient because its prose already follows the selected artifact language while code identifiers and paths remain unchanged. Create or update a companion only when the user explicitly requests a second language, an external audience contract requires it, or an existing workflow depends on a legacy companion such as plan_ko.md.
When a companion is required, dispatch the editorial/translate unit (a conditional companion node appended at compile) to translate from canonical plan.md while preserving code identifiers, file paths, library names, step numbering, and semantics. Use the existing project naming convention for the output. Consult memory for writing preferences only when the acting agent judges the retrieved preference relevant; project and explicit audience requirements take precedence.
Report the canonical plan path, any requested companion path, a compact summary, and the QA verdict in the conversation language.
$ARGUMENTS