SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsto-tasks

to-tasks

General & other

View repository

Updated 10-15 20:09

About this skill

to-tasks

Do not write code.

Pre-checks

Follow the "Pre-checks" section of common.md .

Parameters

For identifiers and matching rules, see common.md。

  • Matched identifier: break down that unit. If tasks/ already exists, only use the "incremental phase addition" mode: the text after the identifier is a regression / gap-filling description, not a new requirement.
  • Parameter is empty: if there are 0 cookings with a spec (whose overview "Next step" is not to-spec / explore / archive), stop and tell the user to first to-spec; if there is 1, use it; if there are multiple, ask. When a unit with an existing tasks/ is selected, likewise only use "incremental phase addition".
  • No match and parameter is non-empty: list existing identifiers and stop. Do not treat the sentence as a new requirement to break down.

Run node .agents/scripts/cooking.mjs status <feature>, do not read goal.md to judge: spec.md：无 → stop, tell the user to first execute to-spec。 goal.md：未确认 → stop, currently exploring, do not break down tasks based on a possibly outdated spec. spec.md"Architecture impact" is not 无: check whether ARCHITECTURE.md / CODE-MAP.md already includes these paths (those marked "planned" count too); if not included, stop and have the user first run sync-docs before coming back to break down. Do not modify architecture documents here.

How to split phases

  • Filename:P1.md、P2.md、P3.md… Pn is the phase id,nota sequence number that must be serial.
  • Each phase has "prerequisite tasks": list the other that must have been implemented and passed review . Write Pnfor none. 无。
  • Parallelism: phases whose prerequisites have all passed can be parallel with each other (based on the "can do" behavior of cooking.mjs status ); those with prerequisites of "none" can be parallel right from the start. Do not force phases that can be parallel into a serial chain.
  • Long-running verification: long-running verification such as real-device / browser smoke tests and full regression should be a separate phase; as long as it is not semantically a prerequisite for the implementation of other phases, do not set it as their prerequisite, let it run in parallel with implementation phases, and have the closing phase depend on it for wrap-up.
  • One phase = one implement + one review. A phase must be able to complete its implementation within a single sub-agent context and leave room to run commands: if the checklist is about 5 items or the changes are about 10 files or more, split off another Pn.
  • Checklist items should be specific enough to code (which type of files to change, what the behavior is); do not write "handle related logic".
  • Write the initial value of "Status" according to the template; afterward only cooking.mjs changes it.

Workflow

  1. Determine <feature>. Read spec.md(acceptance criteria are the basis for splitting). For code-related work, search CODE-MAP.mdand read DEV-STANDARDS.mdwhen needed; for non-code work, refer to PROJECT.md, do not open ARCHITECTURE / DEV-STANDARDS / CODE-MAP.
  2. Draw dependencies: what can be done first, what can be parallel, what must be wrapped up.
  3. Write each task-template.md . Do not add or remove headings. Do not write tasks/Pn.mdaccording to README.md or other index files. When .agents/docs/ACCEPTANCE.md exists, append each of its completion criteria into Pn.md"Completion criteria": Only acceptance items belonging to a single phase are appended to the phase that implements it; cross-phase global commands are appended only to the closing phase (the phase that no other phase has as a prerequisite; if there are multiple closings, only append to the one with the largest number). Items marked "skip" are copied verbatim as skip markers. If none exist, nothing is appended.
  4. Run node .agents/scripts/cooking.mjs status <feature>: it validates prerequisite references and cycles; if it reports an error, fix it until it passes.

Incremental phase addition

The unit already has tasks/ The only mode when present: add a new phase for regressions or omissions of already-passed phases, without re-splitting existing tasks. The input is the regression / gap-filling description provided by the caller (symptom, root cause, phase to fix); if there is no description, stop and ask the user for one; do not look for regressions yourself. To change requirements or rearrange existing phases: do not follow this section; have the user first explore(this will rebuild spec and tasks).

  1. New file tasks/P<n+1>.md(existing maximum number +1), write the initial state according to task-template.md .
  2. For "prerequisite tasks", write the phase being fixed; also include phases that depend on it and have not yet passed review, to ensure the fix occurs before they close out. Using an already-passed phase as a prerequisite is legal (the state machine passes it directly).
  3. The list contains only fix items and regression test cases;ACCEPTANCE.md The append rules for completion criteria are the same as item 3 of "Workflow".
  4. Do not modify spec, do not touch existing P*.md。
  5. Run node .agents/scripts/cooking.mjs status <feature>: validate prerequisite references and cycles; if it reports an error, fix it until it passes.

End

Use the "can do" lines output in the previous step to indicate which phases can be implemented right now. Next step: have the user explicitly invoke implement <feature>(or include Pn); do not continue automatically.