coding-with-plan

coding-with-plan

Input and Startup

Execute the plan confirmed by the user in a previous session; do not re-plan or re-approve, and do not add extra permission confirmation steps; comply with existing authorization. If the plan path cannot be uniquely determined, ask first; do not choose on your own.

The main Agent first reads the plan and the target project's applicable AGENTS.md and the development, testing documents and module descriptions it points to; if applicable CONTEXT-MAP.md or CONTEXT.md exist, load them as well. Sub-Agents likewise read the original text and do not rely only on summaries. Key decisions, acceptance requirements, and necessary references should be findable in these files.

Before startup, record the workspace, implementation scope, review starting point, and existing uncommitted changes to avoid overwriting user changes or mixing in other tasks. Verify that the collaboration tools required below are actually available; do not judge based only on multi_agent_v2 configuration; when necessary materials or capabilities are missing, handle according to the blocking rules.

Create only coding、review two sub-Agents; do not continue delegating. By default, inherit the main Agent's model configuration; if the user specifies otherwise, follow the specification.

The startup tasks of both include the plan path, workspace, standards entry point, implementation scope, review starting point, description of existing changes, main Agent identifier, and the rules of this skill. For communication, use the complete identifier returned by the tool, for example /root/coding, and do not assemble paths yourself.

1. Use spawn_agent to first create review, have it read the standards, and formally review only after receiving the implementation handoff.
2. Create coding, provide review's complete task identifier, and start implementation directly.
3. Notify review of coding's complete identifier.

Task Flow

主 Agent 读取 plan 和规范，核对工作区及工具
    |
    v
创建 review 等待交付，再创建 coding 开始实现
    |
    v
[A] coding 实现或修复业务代码与测试
    |
    v
coding 自验
    +-- 普通失败 --> 定位并修复 ----------------------> [A]
    |
    | 通过，冻结本轮代码并交接
    v
review 对照 plan、开发规范和测试规范评审
    +-- 必须修复 --> 反馈问题，要求修复后重测 --------> [A]
    |
    | 通过
    v
主 Agent 核对最终实现、验证与评审结果
    +-- 需要补充实现或验证 --------------------------> [A]
    |
    v
满足完成条件，向用户汇报

任一阶段真正阻塞 --> 停止交接 --> 主 Agent 暂停并反馈
    |
    +-- 未解决 --> 保持暂停
    +-- 已解决 --> 主 Agent 明确恢复版本和责任人，恢复对应阶段

Implementation and Review Requirements

Coding is responsible for all business code and test code, and completes implementation and self-verification according to project standards. After each rework, rerun the affected tests and necessary checks; when shared behavior is involved or project standards require it, expand the verification scope. Continue handling failures that can be located and fixed; hand off to review only after self-verification passes, and stop modifying code during review.

Review performs a read-only check of the business implementation, test code, and self-verification records, confirming compliance with the plan, development standards, and testing standards, including acceptance coverage, regression risk, and test effectiveness. It must verify the actual verification commands, results, and their corresponding versions, and must not accept based only on "tests passed". Re-review checks both whether the original problems are resolved and whether the fixes introduce new problems.

Review issues must state the location, plan or standards basis, impact, and acceptance conditions for the fix, distinguishing mandatory fixes from optional suggestions; personal preferences cannot block approval. Issues must not be eliminated by modifying the confirmed plan, lowering testing requirements, or loosening assertions.

Handoff Rules

• Use followup_taskfor dispatching work: after self-verification, coding hands off directly to review; after review finds issues, it hands off directly to coding for fixes and retesting. This tool is also used for review objections that need a response or additional judgment. It starts an idle Agent; if the target is still running, it will receive the task at the message processing node or after the current tool call ends, and it is not guaranteed to wait until the previous round ends.
• Use send_messagefor notifications: each handoff synchronizes a brief status to the main Agent; when review passes, notify the main Agent and coding. This tool does not start an idle Agent, and you cannot just send a notification and then wait for it to execute a new task.
• Unified handoff content: current status, implementation version, next-step owner, change scope, and acceptance items; when delivering an implementation, attach verification commands, results, and unverified items with reasons; when rework is required, attach a problem list and retest requirements.
• Versioning and deduplication: coding increments the implementation version after each change and self-verification, such as r1、r2; review feedback points to the same version. A task is handed off only once, and the main Agent does not dispatch it repeatedly; the recipient ignores already-processed or outdated messages, and reports to the main Agent when the status is unclear.
• Stop the previous round of work after handoff: after synchronizing the status, end the current round; if a valid new task has been delivered, handle it according to the latest handoff and do not continue modifying the previous round's code.
• The main Agent continuously tracks: use wait_agent to wait for updates, and when necessary use list_agents to check the status. A timeout does not equal failure, and dispatch must not be repeated based on it; the end of one round of a sub-Agent also does not mean the entire plan is complete.

Blocking and recovery

For compilation errors, test failures, specification violations, or review disagreements that can be resolved with supporting evidence, continue fixing or verifying according to existing requirements. The following situations require pausing:

• Key materials are missing, requirements conflict, or necessary tools or the test environment are unavailable, and this cannot be resolved within the existing authorization.
• The fix must change an already-confirmed plan or acceptance conditions, or the dispute cannot be resolved based on existing materials.
• The same problem is repeatedly reworked with no substantive progress, and there is no new evidence or feasible repair path. No fixed number of rework attempts is set without user agreement.

1. The discoverer stops the handoff and uses send_message to notify the main Agent and the other party, explaining the version, reason, measures already attempted, current results, and recovery conditions, then stops working.
2. The main Agent uses interrupt_agent to interrupt sub-Agents still running, verify the status of unfinished commands, pause the entire process, and report back to the user. The message itself will not pause other Agents, and interrupting an Agent does not guarantee that background commands have been terminated.
3. Old handoff messages cannot lift the pause. After the blockage is resolved, only the main Agent can explicitly restore the version and next-step owner, and use followup_task to resume the corresponding stage.

Completion conditions

The main Agent checks the actual diff to confirm that the planned acceptance items are covered, the issues that must be fixed are closed, the necessary self-verification and review pass conclusions correspond to the final code, and there are no pending blockages or in-progress tasks; the code must not be judged unchanged based only on version labels.

After completion, briefly report the implementation scope, review and verification results, and impactful unverified items; when blocked, report the current progress, reasons, and recovery conditions, and do not declare completion.