rush

rush

This skill wins for features that are multi-stage, parallelizable, and require per-stage review before submission. Do not use it for simple changes or changes that can be done in one stage; use implement direct-write + git review instead. This skill is an orchestrator, not another workflow: artifacts, templates, stage-parallelism rules, and each skill when invoked separately are exactly the same. The main conversation does not read skill details; it dispatches subagents to execute the corresponding SKILL.md. Only follow the cooking stage path, not implement direct-write, not git review.

Pre-checks

The whole workflow runs only once, in the main conversation: run node .agents/scripts/precheck.mjs; if FAIL, stop and prompt the user to execute setup; do not run it on their behalf; PASS outputs include the project category. Afterward, write it into every subagent task brief 前置检查已通过，项目类别：<类别>; subagents do not run it again; explore executed within the main conversation also does not run it again. Read docs as needed per the root AGENTS.md.

Parameters

For identifiers and matching rules, see common.md. One rush advances only one cooking unit.

• Matching identifier: advance only that unit. If there is still text after the identifier, treat it as a requirement supplement for that unit and handle it per item 9 of "What the main conversation does".
• Parameters empty: if there are 0 cooking units, start a new one per the user's requirement; if 1, use it; if multiple, ask the user.
• No match and parameters non-empty: treat the entire text as a requirement description to start a new unit; do not mistakenly match it to another unit.

What the main conversation does

1. Continue from "Next Step": if a unit already exists, run node .agents/scripts/cooking.mjs status <feature>; follow the output "Next Step" line into the corresponding step: explore / to-spec / to-tasks / implement and review (implementation loop) / archive. Do not check on your own whether goal.md、spec.md、tasks/ exists; do not read goal.md to determine confirmation status. The script cannot judge whether a requirement is ambiguous: when "Next Step" is to-spec and goal.md：无 , explore only if there is an ambiguity where "not asking could lead to doing it wrong" (same criterion as the first sentence of the explore decision tree); otherwise go directly to to-spec. For a newly started unit (directory does not yet exist, do not run the script): judge the same way.
2. explore must stay in the main conversation: read explore/SKILL.md and execute until that feature's goal.md is 已确认. Dispatch subagents to check facts. Stop after confirmation and suggest the user start a new session to execute rush <feature> to continue: the Q&A has already consumed this conversation's context, so do not dispatch further from here.
3. For the remaining steps, dispatch subagents per subagent-prompts.md :to-spec+to-tasks(the same subagent does them consecutively; when the spec's "architecture impact" is not "none", it does only the spec then stops) → implementation loop (see "Parallelism") → after all stages pass review, archive。sync-docs is triggered only per item 4 and the "sync-docs dispatch" section.
4. The architecture gate is after spec, not midway through implementation: when the to-spec+to-tasks subagent reports that "architecture impact" is not "none" (at this point it has already stopped after completing the spec per its task brief) → do not continue; first handle per "sync-docs dispatch", and after passing the gate dispatch separately to-tasks subagent. Do not modify architecture docs in the main conversation. If during implementation a subagent still reports that ARCHITECTURE.md needs updating, likewise go through "sync-docs dispatch", then re-dispatch that stage implement(the rework line should state it is resuming after an interruption).
5. Commit cadence: this conversation acts as the review dispatcher. After intermediate-stage review passes, git-commit auto; the final-stage review carries defer-commit, do not commit; after the archive sub-agent has finished deleting the directory, do it in one go git-commit auto (final-stage code + existing docs changed this round), do not split into two commits.
6. Main conversation reads only:goal.md 's "requirement goals",node .agents/scripts/cooking.mjs status 's output (overview and unit details), and the conclusions and blockers reported by sub-agents. Do not read tasks/P*.md, and do not load the full spec text, task list, orreviews/ body into the main conversation. If the script reports an error (prerequisite cycle, invalid state): stop and give the original text to the user.
7. Review fails: dispatch that stage's implement sub-agent to rework (write a rework line in the task document); after completion dispatch that stage's reviewagain, write a rework line in the task document, and under "changed files" fill in only the paths from the rework report. A single stage can be automatically reworked at most 3 rounds; if it still fails after the limit, or if the sub-agent execution is abnormal: stop and give the blockers to the user.
8. A passed stage is found to have regressed (reported by a later stage's implement / review, or found by long-duration verification or smoke testing): dispatch a sub-agent according to the "to-tasks incremental stage addition" task document in subagent-prompts.md (with the regression description and root cause); after it returns, proceed with the new stage normally per the "parallel" section; do not roll back the passed status or open a new unit. Only if it is a requirement change, follow item 9 and use explore.
9. The user changes or adds requirements during progress: no longer dispatch new implement/review sub-agents; execute explore's "modify existing unit" flow in the main conversation; aftergoal.md re- 已确认 , same as item 2: stop, recommend starting a new session rush <feature>。
10. No sub-agent tool: the main conversation personally executes to-spec / to-tasks / implement / archive in the same order, and when sync-docs is needed also executes it personally (the "sync-docs dispatch" items are used directly as input); parallel stages become serial; at review it must stop and must not perform the evaluation on behalf of the reviewer in the main conversation.

sync-docs dispatch

Trigger points: ① the to-spec+to-tasks sub-agent reports "architecture impact" other than "none"; ② to-tasks stops because "architecture impact" was not included; ③ the implement sub-agent reports an architecture-level change (definition see code-map-update.md); ④ the archive sub-agent reports .agents/docs was wrong or the new directory equals a new layering.

• Within the skill package sync-docs/SKILL.md exists: dispatch a sub-agent according to the sync-docs task document in subagent-prompts.md , and for the named items use the original text of the items reported by the triggering sub-agent; after it returns, git-commit auto-commit the doc changes, then re-dispatch the interrupted step (to-tasks / that stage's implement / archive).
• Does not exist: stop, give the items to the user, and have the user first run sync-docs, then rush <feature> continue running.
• For the same trigger point and the same item, automatically dispatch only once; new items later reported by other stages may each be dispatched once more. If the sync-docs report still has unhandled items, or after re-dispatch the original step still stops: stop and give the items and unhandled items to the user.

Parallel

Run each round node .agents/scripts/cooking.mjs status <feature>, do not compute dependencies yourself:

• For each stage in "can do"one implement sub-agent, start them at the same time. Stages whose dependencies have not passed review will not be listed by the script, and must not be dispatched manually.
• As soon as a stage's implement sub-agent returns, dispatchthat stage's review sub-agent, without waiting for other parallel stages to finish implementation. Before dispatching, run statusonce more: if that stage appears in the "wrap-up" line, write in the task document defer-commit。
• "archivable: yes" → dispatch archive.

End

Report: the feature path, the review conclusion for each stage, whether it has been committed locally, and if it has been archived, state that the cooking directory has been deleted. If stopping midway, specify which step you are stuck at and what is missing.