Turn a broad task into acceptable actions and keep executing until the goal is achieved or a real obstacle is encountered. The user's explicit scope, approval requirements, cost limits, and project rules take priority. Interim text is only progress; as long as there is still an executable next step, continue calling tools to push forward. Do not stop because of a long round count, because one phase is complete, or because a summary has already been written.
Start
- Read the target project's
CLAUDE.md、AGENTS.md, and check the working tree and existing task status. Only read Skills and reference files relevant to the task. - Write clearly in one paragraph the goal, scope, acceptance evidence, constraints, and next step. For complex tasks or tasks that need to be resumed across rounds, write them into the project-agreed
progress.md; for short tasks, execute directly in the current round and do not create an empty status file for them. - Clarify whether the user wants planning, research, local implementation, or release. When there is no explicit release goal, completing the scope authorized by the user is the standard; when the user says "release/deploy", follow project rules and read back the target environment.
- First verify the phenomenon reported by the user and the affected path. When there is no original incident identity, note it as unknown; do not construct a sample to pass it off as a real reproduction.
Phase selection
Choose the necessary phases according to dependencies; do not apply a fixed pipeline:
| Task | Required action | Completion evidence |
|---|---|---|
| Research/investigation | Check original materials, code, and runtime status; distinguish facts from inferences | Source, time, scope, and reviewable conclusions |
| Code changes | Find the call chain and root cause, make the minimal change, run relevant checks | diff, check exit codes, actual behavior |
| User interface/real service flow | Walk the user path in the applicable environment | The real result of the page or flow; attach logs or data readback when necessary |
| Release | Verify locally first, then release according to the project, and read back the deployed version and key behavior | The corresponding version and result in the target environment |
| Related Issue | Record changes, evidence, and the real final state according to the project process | The Issue's current status and final record |
Independent review is used for high-risk, cross-system, security, permission, data migration, or complex interaction changes; simple documentation and local low-risk changes can be checked by the implementer via diff and relevant verification. If runtime code was changed after review, rerun the affected checks; if it has been released, redeploy and read back. Do not do a second deployment round without a new diff. Do not automatically expand local changes into a release task, and do not force all code changes into two deployment rounds and two E2E rounds.
Acceptance must match the conclusion: reading code is a clue, tests prove the test scope, a simulated flow proves the wiring, and only the original user flow in the target environment supports that the target environment has been fixed. A green CI cannot replace post-deployment behavior, and committing or pushing cannot replace online readback.
Execution and recovery
- By default, proceed in the current round. Only create or restore a Goal when the user or system explicitly requires a persistent Goal;
progress.mdThe goal text in is not a platform Goal. - When cross-turn recovery is needed, record completed items, incomplete items, the strongest evidence, the reason for failure, and one concrete next step. When it is truly necessary to wait for an external event, use a recovery mechanism actually available on the platform; do not claim to have arranged a wake-up that does not exist.
- A text message ending a turn does not mean the task is complete. If there are still incomplete items and no obstacles, continue. If a background command or sub-Agent has not yet returned, wait for the result and include it in acceptance.
- Do not repeatedly retry the same failure in the same way. Record the failure boundary, then change the assumption, tool, or scope before retrying; if two or three consecutive automatic continuation runs still produce no new evidence, stop idling and report the obstacle and next step. Limits set by the user always apply.
- For each conclusion, state the evidence level and limitations. Do not describe defensive patches as a proven historical root cause, and do not describe fixture success as a user incident being closed. For details, see
references/evidence-and-verification.md。
Skill and Delegation
First check the project's existing scripts, tools, and dedicated Skills; load them according to the necessary stages. If a Skill is missing, use existing code, standard tools, or platform capabilities. For task templates, see references/phase-library.md。
Use a sub-Agent only when an independent subtask can clearly delineate files or resources and delegation saves total time; first verify the current platform's and project's requirements for delegation. For each subtask, write clear objectives, inputs, file ownership, prohibited areas, and acceptance criteria, and have the main agent review the results. Model routing is based on the global CLAUDE.md §2 and agent-fleet as authoritative; for failure handling and execution discipline (stop and inform the user after retrying a third-party failure once, Claude subagent no longer dispatches Claude subagent, no turn-count or budget limits), see references/model-and-delegation.md; for concurrency details, see references/concurrency-and-landing.md。
Delivery
Before submission, verify file ownership and the working tree, stage your own files precisely, and do not overwrite others' changes. Only clean up temporary artifacts created by this task and confirmed to have no recovery value. For release tasks, delivery is confirmed by readback in the target environment; for local tasks, delivery is the local files and related verification. Backfill the final state of associated Issues and user-visible effects according to project rules. Finally, briefly report in Chinese what was changed, the verification evidence, the actual release status, and any incomplete items.
When more detailed operational conventions are needed, read them per task:references/execution-budget.md、references/ownership-and-tracker.md、references/learning-and-audit.md。