@rasensio/aidlc-content 1.5.0 → 1.6.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rasensio/aidlc-content",
-  "version": "1.5.0",
+  "version": "1.6.0",
   "type": "module",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/skills/30-design.md

@@ -29,11 +29,22 @@ Produce a technical design that satisfies the requirements. Define architecture,
 6. **Design decisions.** Record each significant decision with rationale and alternatives considered. Persist accepted decisions as `decision` entities: `aidlc knowledge add --type decision --id <slug> --name "<title>" --description "<rationale>"`.
 7. **Address non-functional concerns.** Map performance, security, and accessibility requirements to design choices.
 8. **Identify risks.** Note technical risks and mitigation strategies.
+9. **Produce the task breakdown.** For templates that require it (full-feature, quick-feature), write `tasks.md` in the instance state directory as the final design step — the design is not done until it is actionable. Decompose the design into commit-sized tasks: each one reviewable in one sitting and independently verifiable. One task per line, in this exact grammar:
+
+   ```
+   - [ ] T<n>: <title>
+   - [ ] T<n>: <title> (AC-1, AC-2)
+   - [x] T<n>: <title> (AC-3)
+   - [>] T<n>: <title> (AC-4) (deferred YYYY-MM-DD: <reason>)
+   ```
+
+   Number tasks sequentially (`T1`, `T2`, ...) — IDs are never renumbered or reused; a task overtaken by events is deferred with a reason, never deleted. Reference the acceptance criteria each task satisfies where any apply; chore or infrastructure tasks may legitimately have none (the implementation gate surfaces them as warnings, never failures).
 
 ## Exit Criteria
 
 - `design.md` exists with architecture, interfaces, and at least one design decision with rationale
 - The design addresses all acceptance criteria from `requirements.md`
+- For templates requiring it: `tasks.md` exists and every active acceptance criterion is claimed by at least one task, or the gap is deliberate
 - The user has confirmed the design direction
 
 ## Guidance

package/skills/40-implementation.md

@@ -24,7 +24,7 @@ Produce working code that satisfies the design and requirements. Follow project
 
 1. **Load context.** Read `.aidlc/context/style-guide.md` and `.aidlc/context/architecture.md` if they exist. Match the project's established patterns. If the project has a knowledge graph (`.aidlc/knowledge/` exists), also run `aidlc knowledge context --scope phase --phase implementation` and query it (`aidlc knowledge query <term>`) before re-exploring code it already describes.
 2. **Load guidance.** Read all active Guidance_Layers from `.aidlc/guidance/index.yaml`. Apply their rules during implementation.
-3. **Plan the work.** Break the implementation into discrete steps. For Micro scope, reference the task description and acceptance criteria directly.
+3. **Execute the task breakdown.** When the instance has a `tasks.md` (produced in Design for full/quick-feature scope), read it and execute tasks in order: complete a task, then mark its checkbox `[x]` as part of the same work unit — never batch checkbox updates for later. A task that should not be done is deferred in place (`- [>] T<n>: <title> (deferred YYYY-MM-DD: <reason>)`) with a dated reason, never skipped silently or deleted; the implementation→testing gate blocks on open tasks. For bugfix scope, create the optional `tasks.md` at implementation start when the fix spans more than one commit-sized unit. For Micro scope, reference the task description and acceptance criteria directly — no task file.
 4. **Write code.** Follow the design interfaces. Match existing code style (naming, formatting, error handling patterns).
 5. **Handle sensitive operations.** Before executing any of the following, describe the action and wait for explicit user confirmation:
    - File deletions or destructive operations

package/skills/80-review.md

@@ -27,6 +27,7 @@ You MUST perform this review with fresh eyes. If you authored the artifact being
 ## Instructions
 
 1. **Read the target artifact completely.** Do not skim.
+   - When reviewing a design artifact and the instance has a `tasks.md`, review it together with the design: breakdown completeness (every design section covered by a task), task sizing (commit-sized units), and AC linkage (tasks reference the criteria they satisfy). Record its findings in the design review's findings file — no separate `tasks.review.md`.
 2. **Examine for each dimension:**
    - **Ambiguities** — Vague terms, undefined behavior, unclear scope
    - **Contradictions** — Requirements that conflict with each other

package/skills/81-continue.md

@@ -23,6 +23,7 @@ Resume an in-progress lifecycle instance efficiently. Determine where work left
 3. **Claim the instance.** Prefer `aidlc claim <instance>` — it writes the claim and appends the claim event to `sessions.ndjson` (the durable session↔instance record cost attribution depends on). Without the CLI, do both: write the claim file (or `claim:` field in the fallback case), then append the claim event to `.aidlc/state/<instance>/sessions.ndjson` (append-only; see the state protocol in **aidlc-overview**). Renew (`aidlc claim --renew`) at every phase transition. Release the same way when you stop (`aidlc release <instance>`).
 4. **Determine next step.** Apply this priority:
    - If current phase has incomplete required artifacts → produce the next artifact
+   - If the current phase is implementation and a task-bearing `tasks.md` exists → resume at the lowest-numbered open (`[ ]`) task; do NOT re-derive the plan from design.md
    - If current phase is complete but not transitioned → evaluate transition (check gates)
    - If transition is allowed → move to next pending phase
    - If all phases complete → report instance complete and fire `on-instance-complete`

package/templates/bugfix.yaml

@@ -10,5 +10,8 @@ override:
     required_artifacts:
       - name: reproduction.md
       - name: requirements.md
+  implementation:
+    optional_artifacts:
+      - name: tasks.md
 gates:
   adversarial-review: []

package/templates/full-feature.yaml

@@ -16,6 +16,7 @@ phases:
   - name: design
     required_artifacts:
       - name: design.md
+      - name: tasks.md
     optional_artifacts:
       - name: architecture-diagram.md
   - name: implementation

package/templates/quick-feature.yaml

@@ -9,6 +9,7 @@ phases:
   - name: design
     required_artifacts:
       - name: design.md
+      - name: tasks.md
   - name: implementation
     required_artifacts:
       - name: code-complete.md