Create Tasks

Skill: create-tasks

Purpose: Decompose every Accepted User Story into developer-sized, codebase-agnostic implementation Tasks at artifacts/07-implementation-tasks/. Each Task describes intent + contract (Inputs, Outputs, Technical Context, Definition of Done) that the Dev-Team's AI coding agent consumes — never source-code locations, framework names, or library versions. Tasks are derived deterministically from a published heuristic over Acceptance-Criterion count, Story Implementation Notes, NFR exposure on the parent Epic, and SRS Section 4 component coverage. The skill cross-references the Accepted SRS for stable NFR / CON / component context, raises OQs when the heuristic produces unusual outputs (e.g., a Story decomposes into 7+ Tasks), and audits every Task for codebase-specific content before writing. Re-runs are idempotent: Pending Tasks are refined in place, Accepted Tasks are immutable, and TASK-### IDs are never reused. Cross-cutting Tasks (e.g., a foundational Auth Task driven by a cross-cutting NFR) are minted once and linked to every Story they serve.

Invocation:

• Claude Code: /create-tasks
• GitHub Copilot: "Run the create-tasks skill" or "Follow skills/create-tasks/skill.md"

Inputs:

• artifacts/04-srs/srs.md (status: Accepted) — required; provides Section 4 (logical components), Section 5 (NFRs and Measurable Targets), Section 6 (CONs), Section 8 (canonical AC list)
• artifacts/03-user-stories/story-*.md — Accepted Story subset is in scope; Pending Stories listed in index.md as Deferred
• artifacts/02-epics/epic-*.md — for cross-cutting NFR identification (each Epic's Cross-cutting NFRs table)
• artifacts/01-elicitation/elicitation-document.md — Section 4 component diagrams (logical components only)
• artifacts/05-test-concept/test-case-*.md — to map TC-### per AC into each Task's parent-tcs field
• artifacts/07-implementation-tasks/task-*.md and index.md (existing, if any)

Outputs:

• artifacts/07-implementation-tasks/task-NNN.md — one file per Task, NNN = zero-padded TASK-### sequence
• artifacts/07-implementation-tasks/index.md — always rebuilt every run (Task Map, Story / AC Coverage Matrices, Effort Distribution, Cross-Cutting table, OQ aggregation, Boundary Audit Summary)

Step 0 — Approval gate (SRS strict + Story incremental)

Implementation Tasks bind to two upstream layers: the SRS for stable NFR / CON / component context, and the Story set for unit-of-work decomposition. The gate is strict on the SRS and incremental on Stories — Tasks run as soon as at least one Story is Accepted under an Accepted Epic, while letting Pending Stories defer to a future re-run.

Read artifacts/04-srs/srs.md.

• If the file does not exist: stop. "Run /create-srs first to compile the Software Requirements Specification."
• If frontmatter status is not Accepted: stop and tell the user the current status. "The SRS is <current status>, not Accepted. Have the human reviewer review and accept the SRS in /create-srs before invoking /create-tasks."

Read every artifacts/03-user-stories/story-*.md.

• If the directory does not exist or contains no Story files: stop. "Run /create-stories first to derive User Stories."
• If no Story has status: Accepted whose parent-epic references an Accepted Epic: stop. "No Accepted Story under an Accepted Epic yet. Re-run /create-tasks once at least one Story is Accepted."

Defensive checks (the upstream gates have held but verify):

• The Elicitation Document at artifacts/01-elicitation/elicitation-document.md exists with status: Approved.
• No Critical OQ from any earlier phase is still Open in the SRS, the elicit doc, any Epic file, any Story file, or any Test Case file.

Step 1 — Read every upstream artefact

Extract structural fields from each input. Build the canonical Story subset (all Stories with status: Accepted whose parent-epic references an Accepted Epic) — this is the source of truth for what Tasks must exist.

The skill uses IDs and structural fields, not full prose. Drift is detected by /trace at Phase 6 and is not re-checked here.

Step 2 — Read existing Task artefacts

Walk every artifacts/07-implementation-tasks/task-*.md. For each Task: capture TASK-ID, parent-story, parent-acs, parent-tcs, cross-cutting flag, status, owner, effort, OQs referenced.

Compute counters:

• next_TASK_id = max(existing TASK-### across all task-*.md files) + 1
• next_OQ_id = max(OQ-### across the elicit doc, every Epic file, every Story file, the SRS, every Test Case file, and every existing Task file) + 1

TASK-### IDs and OQ-### IDs are never reused even after deletion or rejection.

Step 3 — Apply the decomposition heuristic

The heuristic is published, not hidden. The team may override during sprint planning, but the skill always produces a deterministic seed list.

For each Story in the canonical Story subset:

1. Per-AC base Tasks — for every AC referenced in the Story's Section 4: mint one base Task with that AC in parent-acs. A Story with N ACs produces N base Tasks. (Exception: when the heuristic detects a tight pair of ACs that read as positive/negative paths of the same observable behaviour — e.g., AC-FR-###-01 happy + AC-FR-###-02 invalid-input — they MAY be combined into one Task with both ACs listed. The skill picks the conservative default — one Task per AC — and never auto-combines without explicit human direction.)
2. NFR-threshold Tasks — for each NFR with a measurable threshold (Category ∈ Performance / Security / Reliability) whose parent BUC is in the Story's parent Epic's BUC scope: mint one extra Task whose parent-acs is the matching AC-NFR-###-NN and whose Title is "Verify NFR-### threshold: <Measurable Target excerpt>". Skip if the AC-NFR is already covered by an existing Task.
3. Cross-cutting Tasks — for each NFR marked Cross-cutting: Yes in any Epic and referenced by ≥2 Stories in the canonical Story subset: mint one cross-cutting Task with cross-cutting: Yes in frontmatter. Section 2 lists the primary Story (lowest US-### in the linked set) under "Parent Story" and the rest under "Additional Stories". The Task's parent-acs is the cross-cutting NFR's AC.
4. Component scaffolding Tasks — for each logical component in SRS Section 4 that is touched by a Story but has not yet been targeted by any earlier Task in the canonical seed list: mint one scaffolding Task with Title "Scaffold logical component <COMP-###>". Intent describes the component's role per SRS §4; no implementation prescription. Skip if the component is implicitly delivered by a base Task (e.g., the only Story touching the component has only one AC — the base Task subsumes scaffolding).

Effort flag (AI-provisional, applied per Task):

• S — 1 AC, no Performance/Security/Reliability NFR exposure on the parent Epic
• M — 2–3 ACs OR 1 AC plus a Performance/Security/Reliability NFR threshold
• L — 4+ ACs OR cross-cutting NFR with multi-Story scope

The flag is AI-provisional and every Task carries the note **AI estimate — confirm with team.** A Story whose total Task count is ≥7 triggers OQ Severity=High: "US-### produced N Tasks. Consider re-running /create-stories with an AC split — Stories of this size are difficult to deliver as a single sprint commitment."

Output of this step: the canonical Task seed list — [(parent-story, parent-acs, parent-tcs, cross-cutting, title-class, effort), ...].

Step 4 — Mint or refine Tasks (idempotent contract)

For every tuple in the canonical Task seed list:

• No matching Task in store (no task-*.md file with the same (parent-story, parent-acs, cross-cutting) signature): mint new. Assign next_TASK_id. Increment counter. Create artifacts/07-implementation-tasks/task-NNN.md from skills/create-tasks/templates/task.md.
• Matching Pending Task exists: refine fields (per Step 5) in place. Preserve TASK-###. Update last-updated frontmatter.
• Matching Accepted Task exists: immutable. Do not modify any field. Append a review note to Section 13 (Revision History): Note YYYY-MM-DD: re-run on upstream update — human review of this Task recommended.
• Matching Rejected Task exists: same as Accepted. The TASK-### is permanently retired but the file persists for audit.
• An Accepted Task references an AC no longer in the SRS canonical list: append review note + raise OQ Severity=High: "TASK-### references AC-### which is no longer in the SRS. The AC was dropped, deferred, or renamed. Reconcile manually."
• An Accepted Task references a parent Story that has been Rejected upstream: append review note + raise OQ Severity=Critical: "TASK-### references US-### which is now Rejected. The Task is orphaned — Reject TASK-### or restore US-###."

The skill never restructures: it does not split or merge Tasks, and it does not change a Task's parent-story or parent-acs on re-run. Restructuring requires explicit human action (Reject the existing Task, edit upstream, re-run).

Step 5 — Populate Task fields

For every Pending Task (do not modify Accepted/Rejected), populate every field. Lift content verbatim from upstream where possible; never invent codebase specifics.

5.1 — Title and frontmatter

Title format depends on Task class:

Frontmatter: artifact: implementation-task, task-id, parent-story, parent-acs (list), parent-fr OR parent-nfr (whichever applies), parent-epic, parent-tcs (list), cross-cutting (Yes/No), status: Pending, owner (inherited from parent Story Owner — defaults to the Story's owner field), priority (inherited from parent FR/NFR Priority), effort (per Step 3 heuristic), created, last-updated.

5.2 — Parent Traceability table

Forward chain rendered as a table: Parent Story → Additional Stories (cross-cutting only) → Parent ACs → Parent FR / NFR → Source BUC → Parent Epic → Parent TCs → Stakeholder. Lifted from upstream artefacts; never authored.

5.3 — Intent paragraph

One paragraph synthesised from parent Story Description + parent AC Then clause. Plain language, observable-outcome framing. No code, no file paths, no framework names, no library versions, no class/function/handler/schema/endpoint nouns. When upstream Story Description leans implementation-prescriptive, rewrite as intent (e.g., upstream "add a /signup endpoint" → Task Intent "deliver signup behaviour that accepts a new user's email, password, and display name").

5.4 — Inputs and Outputs

• Inputs (Section 3): bullets lifted from the Given clauses of every parent AC. Describe shape in plain language (e.g., "a user identifier (uniquely identifies the actor)"). If the parent ACs imply no specific inputs beyond baseline state: write (none beyond the system's baseline state).
• Outputs (Section 4): bullets lifted from the Then clauses. Express as state changes or observable behaviour. If no observable outputs beyond a successful invocation: write (success indication only).

5.5 — Technical Context

Bullets lifted from upstream artefacts ONLY. Sources permitted:

• Parent Story Section 8 (Implementation Notes)
• SRS Section 4 (logical component(s) this Task touches, via the SRS Traceability Matrix mapping FR → component)
• SRS Section 5 (NFRs the parent Epic exposes — Performance, Security, Reliability, Compliance, etc.)
• SRS Section 6 (CONs that bind this Task — Regulatory / Technology constraints recorded in the SRS)

The skill never adds new technical assumptions. New constraints must originate upstream in /elicit or /create-srs. If no upstream context applies: write (none — this Task is unconstrained beyond the project-wide CONs).

5.6 — Definition of Done (per-Task)

Seed the mandatory items:

• One [ ] AC-FR-###-NN verified by TC-### (TC result: pass) line per parent AC, naming the parent TC from the Task's parent-tcs list.
• [ ] No regression in tests for related Stories
• [ ] Cross-cutting NFR thresholds (if any) measured per SRS §5 Measurable Target

Add the delimiter comment <!-- TEAM-ADDITIONS-BELOW: ... --> — the skill never touches the region below this comment on re-run. The delivery team adds task-specific DoD items there during sprint planning.

5.7 — Dependencies

Populate ONLY when upstream artefacts state a dependency explicitly:

• Parent Story Section 7 (Dependencies) names another Story whose Task this Task depends on — propagate the Story-level dependency to the corresponding Task pair.
• Cross-cutting NFR Tasks block per-Story integration Tasks for the same NFR — the cross-cutting Task is a Depends on target for every linked Story's relevant Task.

The skill never invents dependencies. Cycles between Pending Tasks generate OQ Severity=Critical.

5.8 — Effort, Coverage Notes, Owner, Acceptance

• Effort (Section 8): per Step 3 heuristic. Carry **AI estimate — confirm with team.** Rationale: one sentence naming the driver factor (e.g., "Single AC, no NFR threshold → S").
• Coverage Notes (Section 9): which ACs this Task contributes to and which TCs verify it. Cross-reference siblings — e.g., "Covers AC-FR-001-01 (happy path). The negative-path AC-FR-001-02 is covered by TASK-NNN."
• Owner: parent Story owner field (SH-###). Default Accepted By to the same.
• Status: Pending. Accepted Date: —.
• Source: parent Story US-###; AC list AC-FR-###-NN, ...; TC list TC-###, ....

Step 6 — Boundary audit (codebase-awareness validator)

After populating fields, scan every Pending Task's Sections 1, 3, 4, 5, 6, 7, 9 (the body sections the skill authored or lifted into — not Section 2 Parent Traceability, which is structural). This is the rule that holds the framework's boundary.

Forbidden patterns (denylist; case-insensitive; matched against the rendered Section text):

Suppression rules (do not flag):

• Matches inside Section 2 (Parent Traceability) — that's structural ID references.
• Matches inside lifted AC text (Given/When/Then) — the SRS authored the language and the Task quotes it verbatim. If a Section legitimately quotes an AC that contains a route path like /signup, that is allowed; routes alone are AC content, not codebase specifics.
• Matches inside lifted SRS Constraints quotations (e.g., the SRS records "Technology Constraint: PostgreSQL 14" — the Task may legitimately echo this in Technical Context).

For each unsuppressed hit: raise OQ Severity=High:

TASK-### contains "<excerpt>" in Section <N>, which looks codebase-specific. Tasks describe intent + contract, not codebase locations. Rewrite as intent — e.g., "deliver signup behaviour that accepts {email, password, displayName}" instead of "add a POST handler in src/api/auth.ts". Suppression: if this content was legitimately lifted from upstream (SRS Constraint, AC text), confirm in the review gate.

Record the OQ-### in the Task's Section 11 (Boundary Audit). The skill does not auto-rewrite the violation — flag it and let the human reviewer decide.

If the Task has no hits: Section 11 reads "No codebase-specific assumptions detected by /create-tasks Step 6 validation."

Step 7 — Validation (Pending Tasks only)

Run every check; add OQs at the indicated severity.

1. Story coverage: every Accepted Story in the canonical subset has ≥1 Task. Orphan → Critical.
2. AC coverage within a Story: every AC of every Accepted Story has ≥1 Task contributing to it via parent-acs. Orphan → High.
3. Task Owner: every Pending Task has Owner = SH-###. Missing → Critical.
4. TC linkage: every Pending Task's parent-tcs list is non-empty and every TC-### exists in artifacts/05-test-concept/. Missing or dangling → High.
5. Definition of Done seeding: every Pending Task's Section 6 includes one [ ] AC-### verified by TC-### (TC result: pass) line per parent AC. Missing → High.
6. Cross-cutting integrity: every Task with cross-cutting: Yes lists ≥2 Stories in Section 2's "Additional Stories" row and every linked Story is Accepted. Violation → High.
7. Boundary audit: all Step 6 hits resolved or accepted by the human reviewer. Open Step 6 OQs → High.
8. Effort sanity: any Story producing ≥7 Tasks → High (per Step 3).
9. Over-decomposition: two non-cross-cutting Tasks sharing (parent-story, parent-acs) → Medium: "US-### may be over-decomposed; consider merging TASK-### and TASK-###."

Add a one-line summary to index.md Section 9: "Validation: [N] OQs added across coverage / owner / TC-linkage / boundary / effort / decomposition checks."

Step 8 — Build index.md

Always rebuilt from the current state of all task-*.md files. Never merged.

Sections (per skills/create-tasks/templates/index.md):

1. Project Overview — counts (Pending / Accepted / Rejected / Cross-cutting), source SRS version + Accepted date, total Stories in Accepted subset, total Deferred Stories, coverage stats
2. Task Map — Mermaid flowchart LR with one subgraph per Accepted Story and one separate subgraph for Cross-cutting Tasks (with edges to every linked Story). Numeric-only node IDs (US001, TASK001). %%{init: {'theme': 'neutral'}}%% first line. Short single-phrase labels per vault rules.
3. Task List — table with TASK-ID, Title, Parent Story, Parent ACs, Parent TCs, Owner, Priority, Effort, Cross-cutting, Status, file path
4. Story Coverage Matrix — every Accepted Story with AC count, Task count, Status (Covered / Deferred / Orphan), Notes
5. AC Coverage Matrix — every AC under every Accepted Story with its contributing Task(s) and Status (Covered / Orphan)
6. Effort Distribution — count of Tasks per effort flag (S / M / L) with heuristic reminder
7. Cross-Cutting Tasks — table: TASK-ID, Title, Linked Stories, Origin NFR, Effort. If none: "No cross-cutting Tasks in this Story subset."
8. Open Questions — aggregated from every task-*.md + boundary-audit OQs, sorted by Severity
9. Boundary Audit Summary — Tasks scanned / Tasks flagged / Flagged Task-OQ pairs. If 0: "Boundary audit clean — no codebase-specific content detected in any Task."
10. Acceptance Status Overview — TASK-ID, Title, Owner, Status, Accepted Date
11. Revision History — append-only; one row per run with summary

Step 9 — Write outputs

1. For each Pending Task with changes: rewrite artifacts/07-implementation-tasks/task-NNN.md. Update last-updated frontmatter.
2. For each Accepted/Rejected Task with appended review notes: write only Section 13; leave Sections 1–12 untouched.
3. For each newly-minted Task: create from skills/create-tasks/templates/task.md.
4. Always rewrite artifacts/07-implementation-tasks/index.md from scratch using Step 8 data.

Do not delete files — even Rejected Tasks persist so the TASK-### is auditable.

Step 10 — Review gate

Present to the user:

Changes in this run:

• ADDED: [list new TASK-IDs with parent-story / parent-acs]
• REFINED: [list Pending Tasks updated, with reason]
• UNCHANGED: [list Pending Tasks with no new info, or omit if long]
• PROTECTED: [list Accepted/Rejected Tasks that received review notes only]
• BOUNDARY FLAGS: [list TASK-### / OQ-### pairs from Step 6 validation]
• COVERAGE: [N Accepted Stories in canonical subset; M Tasks minted or refined; orphans: list Story-IDs]
• DEFERRED: [list of Pending Stories whose Tasks are deferred to a future run after they are Accepted]
• EFFORT DISTRIBUTION: [S: N; M: M; L: K]
• CROSS-CUTTING: [list cross-cutting Task IDs with their origin NFR and linked Stories]

If any OQs remain Open:

Warning — Unresolved Open Questions: [table with Severity column]

Then give your Professional Assessment — cite specific element IDs:

Blocking — APPROVED is invalid until resolved:

• Critical OQs Open: list OQ-### IDs.
• Pending Tasks with no Owner: list TASK-### IDs.
• Pending Tasks with empty parent-tcs list: list TASK-### IDs.
• Pending Tasks missing the [ ] AC-### verified by TC-### Definition-of-Done line: list TASK-### IDs.
• Orphaned Accepted Stories (no Task): list US-### IDs.
• Open Boundary Audit OQs (Step 6 hits): list TASK-### / OQ-### pairs.

Advisory — flag before approval:

• Stories producing ≥7 Tasks (Step 7.8): list US-### with Task count; recommend re-running /create-stories after AC split.
• Over-decomposition warnings (Step 7.9): list TASK-### pairs sharing (parent-story, parent-acs).
• Effort distribution heavily skewed L: note it; the heuristic may be flagging Stories that should be split.
• Cross-cutting Tasks whose origin NFR is not marked Cross-cutting: Yes in every linked Story's parent Epic: list with the Epic-side correction needed.

If none of these issues exist: state "No quality concerns — Task set is ready for approval."

Review artifacts/07-implementation-tasks/index.md first, then drill into each task-NNN.md. Type APPROVED to mark the Task set as the final RE handoff artefact (the Dev-Team's coding agent may now consume it), or provide corrections. Approval is invalid if any Critical OQ is Open, any Accepted Story is orphan, any Pending Task lacks Owner / TC linkage / DoD seed, or any Boundary Audit OQ is Open.

On APPROVED: update each Pending Task's frontmatter to status: Accepted only when the human reviewer signals per-Task Acceptance (the default is partial — the human types APPROVED to ratify the entire set, the skill flips Status on whichever Tasks the reviewer named; absent per-Task overrides, the entire Pending set transitions). State "Implementation-Tasks phase complete. The Dev-Team's coding agent may now consume artifacts/07-implementation-tasks/. Re-run /trace to verify the full SH → BUC → FR → EP → US → AC → TC → TASK chain." Do not invoke /trace automatically.

ID Reference

TASK-### IDs are never reused, even after deletion or rejection. OQ-### IDs are never reused across the entire pipeline namespace.

Edge Cases