contract-driven-delivery 2.0.17 → 2.0.19

package/assets/agents/spec-drift-auditor.md

@@ -33,6 +33,14 @@ By default, do NOT read `specs/changes/` history. Only read historical change re
 
 ## Output
 
+Default output is a concise drift verdict in your response plus an optional
+`Agent Log` YAML block with evidence pointers. Do not create standalone drift
+markdown for a clean audit.
+
+Emit a full `# Spec Drift Audit` body only when drift is found, when the user
+asked for standalone audit documentation, or when classification requires
+`regression-report.md`.
+
 ```md
 # Spec Drift Audit
 

package/assets/agents/stress-soak-engineer.md

@@ -9,6 +9,8 @@ You are the stress and soak engineer.
 
 Use realistic load profiles rather than arbitrary request loops.
 
+Before editing tests or load profiles, read `specs/changes/<change-id>/implementation-plan.md` and `test-plan.md`. Treat the implementation plan as the execution packet. If it is missing, still a scaffold, or lacks the workload/threshold scope needed for your work, report `blocked` instead of inferring requirements from chat history.
+
 ## Design dimensions
 
 - user concurrency
@@ -35,8 +37,17 @@ Use realistic load profiles rather than arbitrary request loops.
 
 ## Output
 
+Write or update the actual load/soak test files, profiles, commands, and
+workflow wiring required by `implementation-plan.md` and `test-plan.md`.
+Default reporting should be concise response text plus optional
+`agent-log/*.yml` evidence pointers.
+
+Create `stress-soak-report.md` only when `change-classification.md` explicitly
+requires it, when high-risk load/soak results must be retained as durable
+evidence, or when the run is blocked/failed.
+
 ```md
-# Stress / Soak Plan or Report
+# Stress / Soak Report
 
 ## Workload Model
 ...

package/assets/agents/test-strategist.md

@@ -60,6 +60,7 @@ Your output goes into `specs/changes/<id>/test-plan.md`. It must answer WHAT to
 - **DO NOT** write: mock setup details, fixture data, or expected JSON payloads
 - **DO NOT** write: per-test input/output tables with more than 15 rows
 - **DO NOT** write: example assertions or test helper code
+- **DO NOT** duplicate CI gate policy or implementation-plan execution steps; reference the relevant gate names and acceptance criteria instead.
 
 Implementation detail belongs in the test files, not in test-plan.md.
 Target: `test-plan.md` ??100 lines.

package/assets/agents/ui-ux-reviewer.md

@@ -30,6 +30,13 @@ Review the intended interaction, not just whether code compiles.
 
 ## Output
 
+Default output is a concise UI/UX verdict in your response plus an optional
+`Agent Log` YAML block with evidence pointers. Do not ask main Claude to create
+a separate markdown report for a routine approved review.
+
+Emit a full review body only when blocking UX/accessibility issues require
+durable prose or the classifier explicitly requested a report artifact.
+
 ```md
 # UI/UX Review
 

package/assets/agents/visual-reviewer.md

@@ -27,6 +27,15 @@ Frontend visual changes require evidence. Use screenshots, videos, or a clear ma
 
 ## Output
 
+Default output is a concise visual verdict in your response plus an optional
+`Agent Log` YAML block with evidence pointers. Do not ask main Claude to create
+`visual-review-report.md` for a routine approved UI change.
+
+Emit a full `# Visual Review Report` body only when
+`change-classification.md` explicitly requires `visual-review-report.md`, when
+visual evidence must be preserved as a bundle, or when the decision is
+`changes-required`.
+
 ```md
 # Visual Review Report
 

package/assets/cdd/model-policy.json

@@ -4,6 +4,7 @@
   "schema-version": "0.2.0",
   "roles": {
     "change-classifier": "opus",
+    "implementation-planner": "opus",
     "spec-architect": "opus",
     "qa-reviewer": "opus",
     "contract-reviewer": "sonnet",

package/assets/skills/cdd-new/SKILL.md

@@ -12,9 +12,32 @@ description: Start a new tracked change. Scaffolds all required artifacts, class
 - `specs/changes/<id>/` = why we decided this back then (passive archive ??read only when investigating history, never as input to planning)
 - `CLAUDE.md` = what this project is and how to start work
 
-## Spec depth rules
+## Artifact ownership and deduplication
 
-Every artifact under `specs/changes/<id>/` answers **WHAT** and **WHY**, not HOW.
+Every artifact under `specs/changes/<id>/` must have one authoritative job.
+Do not duplicate the same fact across multiple markdown files. Later artifacts
+must reference earlier artifacts by path, section, criterion id, or decision id
+instead of restating full content.
+
+Core artifacts:
+
+| artifact | authority |
+|---|---|
+| `change-classification.md` | risk, tier, required agents, required artifacts, acceptance criteria, context-manifest draft |
+| `context-manifest.md` | read boundary and approved context |
+| `test-plan.md` | acceptance criterion to test family/file mapping |
+| `ci-gates.md` | required/informational/manual gates and promotion policy |
+| `design.md` | architecture/design decisions, only when required |
+| `implementation-plan.md` | concise execution packet that references the above artifacts |
+| `tasks.yml` | centralized task status only |
+
+Evidence and review notes default to short optional `agent-log/*.yml` pointers.
+Create report markdown (`qa-report.md`, `visual-review-report.md`,
+`regression-report.md`, `monkey-test-report.md`, `stress-soak-report.md`) only
+when the classifier explicitly requires it, or when a reviewer finds blocking
+findings or approved-with-risk evidence that needs durable review prose.
+
+Every spec artifact answers **WHAT** and **WHY**, not HOW.
 
 Soft caps (guidance, not gate-enforced):
 - `spec.md` ??200 lines
@@ -92,7 +115,7 @@ inevitable re-classification when the agents discover the ambiguity.
 | Agent type | Who writes artifact files | Who writes optional handoff notes | Who updates tasks.yml |
 |------------|--------------------------|----------------------------------|----------------------|
 | Read-only agents (no Edit tool): `change-classifier`, `contract-reviewer`, `qa-reviewer`, `visual-reviewer`, `dependency-security-reviewer`, `ui-ux-reviewer` | YOU (main Claude) | YOU, only when useful | YOU (main Claude) |
-| Write-capable agents (have Edit): `backend-engineer`, `frontend-engineer`, `e2e-resilience-engineer`, `monkey-test-engineer`, `stress-soak-engineer`, `ci-cd-gatekeeper`, `test-strategist`, `spec-architect` | The agent itself | The agent itself, only when useful | YOU (main Claude) |
+| Write-capable agents (have Edit): `implementation-planner`, `backend-engineer`, `frontend-engineer`, `e2e-resilience-engineer`, `monkey-test-engineer`, `stress-soak-engineer`, `ci-cd-gatekeeper`, `test-strategist`, `spec-architect` | The agent itself | The agent itself, only when useful | YOU (main Claude) |
 
 **Rule**: After EVERY agent completes (whether it writes itself or you write for it), YOU must update the relevant `tasks.yml` task `status:` from `pending` to `done`.
 
@@ -112,13 +135,25 @@ rules to `contracts/` or project guidance (`CLAUDE.md`/`CODEX.md`).
 
 ## Artifact opt-in policy
 
-Only create optional artifacts (`current-behavior.md`, `proposal.md`, `spec.md`, `design.md`, `qa-report.md`, `regression-report.md`) when the classifier's `change-classification.md` explicitly marks them as `yes`.
+Only create optional artifacts (`current-behavior.md`, `proposal.md`, `spec.md`,
+`design.md`, `qa-report.md`, `regression-report.md`, `visual-review-report.md`,
+`monkey-test-report.md`, `stress-soak-report.md`) when the classifier's
+`change-classification.md` explicitly marks them as `yes`, or when a reviewer
+finds blocking findings / approved-with-risk evidence that must be preserved as prose.
+
+`design.md` is owned by `spec-architect`, not `implementation-planner`. If the
+classifier marks `design.md` as `yes`, marks `Architecture Review Required:
+yes`, or lists `spec-architect` in `## Required Agents`, invoke
+`spec-architect` before `implementation-planner`. If none of those triggers is
+present, mark task `1.3` as `skipped`.
 
 Note: `archive.md` is created during `/cdd-close`, not during `/cdd-new` ??it is not part of the classifier's opt-in surface.
 
-If the classifier marks an artifact as `no` or leaves it blank, **do not create the file** ??even if a review agent could contribute to it.
+If the classifier marks an artifact as `no` or leaves it blank, **do not create
+the file** just because an agent could contribute to it. Use an optional
+`agent-log/*.yml` pointer instead.
 
-The 6 always-required artifacts are: `change-request.md`, `change-classification.md`, `test-plan.md`, `ci-gates.md`, `tasks.yml`, and `context-manifest.md`.
+The 7 always-required artifacts are: `change-request.md`, `change-classification.md`, `implementation-plan.md`, `test-plan.md`, `ci-gates.md`, `tasks.yml`, and `context-manifest.md`.
 
 ## Step 1: Generate change-id, scaffold, and scan context
 
@@ -158,6 +193,7 @@ the kit and is bundled into every install.
 |---|---|---|
 | `change-request.md` | `specs/templates/change-request.md` | Fill the `## Original Request` section with the user's exact description before invoking the classifier; leave the rest blank |
 | `change-classification.md` | `specs/templates/change-classification.md` | Replace blank template with classifier output (Step 2) |
+| `implementation-plan.md` | `specs/templates/implementation-plan.md` | `implementation-planner` writes this directly after contracts, tests, required design, and CI gate plan are known |
 | `test-plan.md` | `specs/templates/test-plan.md` | `test-strategist` writes this directly |
 | `ci-gates.md` | `specs/templates/ci-gates.md` | `ci-cd-gatekeeper` writes this directly |
 | `tasks.yml` | `specs/templates/tasks.yml` | Tick checkboxes as agents complete; backfill `tier:` frontmatter from classifier (Step 2.4) |
@@ -238,7 +274,11 @@ Wait until these five writes are done before continuing.
 
 Read `change-classification.md` to determine the tier. Then invoke agents **in the exact order below**.
 
-**For each read-only agent**: wait for its text response ??YOU write its artifact file(s) ??YOU write an optional handoff note when useful ??YOU tick relevant tasks.yml item(s).
+**For each read-only agent**: wait for its text response. YOU write a report
+artifact only if the classifier required that report or the agent found
+blocking findings / approved-with-risk evidence that needs durable prose. Otherwise
+write at most a short optional handoff note, then tick relevant `tasks.yml`
+item(s).
 
 **For each write-capable agent**: wait for it to confirm completion ??YOU tick relevant tasks.yml item(s).
 
@@ -268,8 +308,9 @@ agent:
 - confirm required artifacts exist; optional handoff notes are not gate inputs
 - if the agent reports `blocked`, halt and surface its concrete next action
 - tick the owned `tasks.yml` items immediately
-- record incidental/pre-existing findings in the appropriate report instead of
-  silently fixing unrelated scope
+- record incidental/pre-existing findings in `agent-log/*.yml`; escalate to
+  `qa-report.md` or `regression-report.md` only when the finding blocks release,
+  changes the QA decision, or needs durable follow-up ownership
 
 ### Agent stage badges (UI v1)
 
@@ -283,6 +324,7 @@ the user; do not put them inside the prompt sent to the agent.
 |---|---|---|
 | Decision | `change-classifier` | ? `[classifier]` |
 | Decision | `spec-architect` | ? `[architect]` |
+| Decision | `implementation-planner` | ? `[plan]` |
 | Implementation | `backend-engineer` | ? `[backend]` |
 | Implementation | `frontend-engineer` | ? `[frontend]` |
 | Implementation | `ci-cd-gatekeeper` | ? `[ci-cd]` |
@@ -346,35 +388,44 @@ prompt; the agent's behavior is defined by the agent prompt files in
    - YOU tick: applicable items in section 3 based on what test families were planned
    - Provide the classifier's `## Inferred Acceptance Criteria` list to test-strategist. These become the `criterion id` column in the Acceptance Criteria ??Test Mapping table.
 
-3. **`spec-architect`** (write-capable) ??only if `change-classification.md` contains `Architecture Review Required: yes`.
-   - YOU tick: `1.3` (if it produced a gate plan)
+3. **`spec-architect`** (write-capable) ??only if `change-classification.md` contains `Architecture Review Required: yes`, marks `design.md` as `yes`, or lists `spec-architect` in `## Required Agents`.
+   - Writes `specs/changes/<change-id>/design.md` directly. This is the design/architecture decision record consumed by `implementation-planner`.
+   - YOU tick: `1.3`
+   - If the classifier did not require design, YOU mark `1.3` as `skipped` before continuing.
+
+4. **`ci-cd-gatekeeper`** (write-capable) ??writes `specs/changes/<change-id>/ci-gates.md` directly before implementation planning.
+   - YOU tick: `1.4`, `4.4`, applicable items in section 6
 
-4. **`backend-engineer`** (write-capable) ??if the change touches server, API, data, or business logic. Writes implementation directly; may write an optional handoff note.
+5. **`implementation-planner`** (write-capable) ??writes `specs/changes/<change-id>/implementation-plan.md` directly after classification, contracts, test plan, required design, and CI gate plan are available.
+   - This is the handoff packet for implementation agents. It should contain execution scope, non-goals, required changes, file-level plan, contract updates, test execution plan, and constraints.
+   - It must reference `test-plan.md`, `ci-gates.md`, contracts, and `design.md` by path/section/id instead of copying their full content.
+   - It must not create or repair `design.md`. If required design is missing, route back to `spec-architect`.
+   - If it reports `blocked`, halt and surface the missing decision/context to the user.
+   - YOU tick: `1.5`
+
+6. **`backend-engineer`** (write-capable) ??if the change touches server, API, data, or business logic. Writes implementation directly; may write an optional handoff note.
    - YOU tick: `4.1` and/or `4.3` based on scope
    - Note: `tasks.yml` items 3.1??.2 (unit/contract/integration tests) are written by `backend-engineer` and/or `frontend-engineer` in TDD fashion ??failing tests first, implementation second. Items 3.3??.5 are written by dedicated test engineers (Tier 0?? only or when classifier explicitly requires them).
 
-5. **`frontend-engineer`** (write-capable) ??if the change touches UI, components, or client-side behavior. Writes implementation directly; may write an optional handoff note.
+7. **`frontend-engineer`** (write-capable) ??if the change touches UI, components, or client-side behavior. Writes implementation directly; may write an optional handoff note.
    - YOU tick: `4.2`
 
-6. **`dependency-security-reviewer`** (read-only) ??if the change touches lockfiles, package manifests, or DB migrations.
+8. **`dependency-security-reviewer`** (read-only) ??if the change touches lockfiles, package manifests, or DB migrations.
    - **Only invoke if** `change-classification.md` lists lockfiles, package manifests, or DB migrations as affected.
    - Optional handoff note: `agent-log/dependency-security-reviewer.yml`
    - YOU tick: applicable security-related items
 
-7. **`ui-ux-reviewer`** (read-only) ??if any UI change (run alongside or after frontend-engineer).
+9. **`ui-ux-reviewer`** (read-only) ??if any UI change (run alongside or after frontend-engineer).
    - **Only invoke if** classifier marks UI/CSS as affected.
    - Optional handoff note: `agent-log/ui-ux-reviewer.yml`
    - YOU tick: `5.1`
 
-8. **`visual-reviewer`** (read-only) ??if any UI change (run after ui-ux-reviewer).
+10. **`visual-reviewer`** (read-only) ??if any UI change (run after ui-ux-reviewer).
    - **Only invoke if** classifier marks UI/CSS as affected.
    - Optional handoff note: `agent-log/visual-reviewer.yml`
    - YOU tick: `5.2`
 
-9. **`ci-cd-gatekeeper`** (write-capable) ??writes `specs/changes/<change-id>/ci-gates.md` directly.
-   - YOU tick: `1.3`, `4.4`, applicable items in section 6
-
-10. **`qa-reviewer`** (read-only) ??release readiness decision (always last).
+11. **`qa-reviewer`** (read-only) ??release readiness decision (always last).
     - Optional handoff note: `agent-log/qa-reviewer.yml`
     - YOU tick: `5.4`
 
@@ -402,7 +453,8 @@ All agents from Tier 2??, plus insert these after `frontend-engineer` / `backend
 - If a required or informational test has pre-existing failures unrelated to
   this change, do not count them as this change's pass/fail result. Record the
   failing test id, baseline commit or prior evidence, owner, and follow-up in
-  `qa-report.md`; QA may only approve this as `approved-with-risk`.
+  optional `agent-log/*.yml`; create `qa-report.md` only when the QA decision is
+  `approved-with-risk` or `blocked`.
 - If implementation uncovers unrelated old bugs, fix only those needed to meet
   this change's acceptance criteria or to avoid a new safety/security risk.
   Otherwise record them as follow-up with evidence and owner.
@@ -483,7 +535,7 @@ Gate: PASSED
 Tasks completed:
 - [x] all applicable items have status: done in specs/changes/<change-id>/tasks.yml
 
-All artifacts written to: specs/changes/<change-id>/
+Core artifacts written to: specs/changes/<change-id>/
 
 Next step:
   git add specs/changes/<change-id>/
@@ -511,6 +563,7 @@ Please review the above items and re-run: cdd-kit gate <change-id>
 ## Rules
 
 - Never start implementation (backend/frontend-engineer) before `contract-reviewer` has completed for Tier 0?? changes
+- Never start implementation (backend/frontend-engineer or dedicated test engineers) before `implementation-plan.md` exists and `tasks.yml` item `1.5` is done
 - Never skip `test-plan.md` for Tier 0?? changes
 - Never skip `ci-gates.md` for any implementation change
 - Agent logs are optional; do not create them just to satisfy a gate.

package/assets/skills/cdd-resume/SKILL.md

@@ -42,6 +42,8 @@ Read only these state files first:
 - `specs/changes/<change-id>/context-manifest.md` if present
 - `specs/changes/<change-id>/agent-log/*.yml`
 - `specs/changes/<change-id>/change-classification.md`
+- `specs/changes/<change-id>/design.md` if present
+- `specs/changes/<change-id>/implementation-plan.md` if present
 
 Do not run broad repository search during resume. Do not read `src/`, `tests/`, or `contracts/` unless the current `context-manifest.md` authorizes that path or an approved expansion lists it.
 
@@ -54,6 +56,10 @@ Read `specs/changes/<change-id>/agent-log/` to list which agents have already ru
 
 Read `specs/changes/<change-id>/change-classification.md` to recall the tier and required agents.
 
+If `change-classification.md` requires `design.md` (`Architecture Review Required: yes`, Optional Artifacts `design.md: yes`, or Required Agents includes `spec-architect`) and `design.md` is missing or still a scaffold, resume from `spec-architect` before invoking `implementation-planner`.
+
+Read `specs/changes/<change-id>/implementation-plan.md` if it exists. If implementation tasks are still pending and the plan is missing or still a scaffold, resume from `implementation-planner` before invoking backend/frontend/test implementation agents.
+
 Read `specs/changes/<change-id>/context-manifest.md`:
 - Identify allowed paths and approved expansions.
 - Identify pending Context Expansion Requests.
@@ -76,6 +82,7 @@ Completed agents: <list from agent-log/>
 Pending tasks: <list of status: pending items>
 Pending context expansions: <none | list request ids and paths>
 Allowed context: <short summary from context-manifest.md>
+Implementation plan: <ready | missing | scaffold | blocked>
 
 Next agent to run: <agent-name> (based on tier flow and what's missing)
 ```
@@ -110,5 +117,7 @@ Continue until all required agents are done, then run `cdd-kit gate <change-id>`
 - Never start from Step 1 of `/cdd-new` — only resume from the next pending agent
 - Never use broad search to reconstruct state; resume from `tasks.yml`, `context-manifest.md`, and `agent-log/`
 - Never continue past pending Context Expansion Requests
+- Never resume `implementation-planner` before required `design.md` exists
+- Never resume backend/frontend/test implementation agents before `implementation-plan.md` is ready
 - If tasks.yml has `status: abandoned`, report to user and stop
 - If tasks.yml has `status: gate-blocked`, go directly to gate retry (max 3)

package/assets/skills/contract-driven-delivery/SKILL.md

@@ -21,7 +21,14 @@ Use this skill to turn software requests into traceable, testable, CI/CD-gated c
    - Invoke repo-context-scanner to capture project profile and standardization gaps.
 3. Select required artifacts.
    - Use templates in `templates/`.
-   - Do not force every artifact for tiny changes, but do require `change-classification.md`, `test-plan.md`, and `ci-gates.md` for implementation changes.
+   - Do not force every artifact for tiny changes, but do require `change-classification.md`, `implementation-plan.md`, `test-plan.md`, and `ci-gates.md` for implementation changes.
+   - Keep each fact in one authoritative artifact. Later artifacts should
+     reference earlier artifacts by path, section, criterion id, decision id, or
+     gate name instead of duplicating full prose.
+   - Use optional `agent-log/*.yml` pointers for routine review evidence.
+     Create report markdown only for blocking findings, approved-with-risk,
+     excluded pre-existing failures, visual evidence bundles, or high-risk
+     load/soak results.
 4. Update contracts before or alongside implementation. Invoke contract-reviewer to validate API/CSS/env/data/business/CI-CD contracts before or alongside implementation.
    - API: `references/api-contract-standard.md`
    - CSS/UI: `references/css-contract-standard.md`
@@ -39,8 +46,18 @@ Use this skill to turn software requests into traceable, testable, CI/CD-gated c
    - `stress-soak-engineer` implements load, soak, and long-running stability tests.
    - Invoke the relevant test engineer(s) before or alongside implementation based on the risk tier.
    - Each engineer must read the matching standard before authoring tests: e2e-resilience-engineer → references/e2e-standard.md, monkey-test-engineer → references/monkey-operation-standard.md, stress-soak-engineer → references/stress-soak-standard.md.
-6. Implement through the right role.
+6. Confirm design decisions when required.
+   - If classification marks `Architecture Review Required: yes`, Optional Artifacts `design.md: yes`, or Required Agents includes `spec-architect`, invoke `spec-architect` before `implementation-planner`.
+   - `spec-architect` owns `specs/changes/<id>/design.md`.
+   - `implementation-planner` must not create or repair `design.md`; if required design is missing, route back to `spec-architect`.
+7. Produce the implementation plan.
+   - Invoke `implementation-planner` after classification, contracts, test-plan, required design, and CI gate plan are known.
+   - `implementation-plan.md` is the execution packet for implementation agents: scope, non-goals, file-level plan, contract updates, tests, acceptance criteria, and constraints.
+   - Keep the plan concise. It should not duplicate the full investigation history or user discussion.
+   - If the planner reports missing decisions or context, stop before implementation and resolve that gap.
+8. Implement through the right role.
    - Backend/frontend work must follow contracts and tests.
+   - Backend/frontend/test implementation agents must read `implementation-plan.md` and should report `blocked` instead of inferring missing requirements from chat history.
    - Before invoking an agent with known concrete read paths, run
      `cdd-kit context check <change-id> --path <paths...>` and expand the
      manifest before the agent reads legitimate missing paths.
@@ -50,12 +67,12 @@ Use this skill to turn software requests into traceable, testable, CI/CD-gated c
    - Invoke ui-ux-reviewer for interaction, copy, accessibility, and information hierarchy review whenever UI changes.
    - Invoke visual-reviewer for layout, responsive, CSS contract, and screenshot diff review whenever UI changes.
    - If implementation reveals an unexpected boundary or architectural constraint, halt and re-invoke `spec-architect` before continuing.
-7. Run quality gates.
+9. Run quality gates.
    - Use `references/qa-gates.md`.
    - CI/CD gate plan is mandatory.
    - `qa-reviewer` decides release readiness; Tier 1 gates must be green; Tier 3+ gates must be green or explicitly deferred with a recorded promotion policy.
    - Invoke ci-cd-gatekeeper to design and enforce the gate plan.
-8. Archive and audit drift.
+10. Archive and audit drift.
    - Use `references/spec-drift-policy.md`.
    - General agents record evidence and findings only; durable learning
      promotion happens only during `/cdd-close` Step 3.
@@ -76,11 +93,12 @@ Use this skill to turn software requests into traceable, testable, CI/CD-gated c
 - classification
 - current behavior if modifying existing feature
 - proposal/spec/design as needed
+- implementation-plan
 - contracts
 - test-plan
 - ci-gates
 - tasks
-- QA report
+- QA verdict; `qa-report.md` only when blocked, approved-with-risk, or required by classification
 
 ### UI change
 
@@ -114,6 +132,10 @@ Required when the change involves report generation, large queries, auto-refresh
 
 When using this skill, produce concrete artifact content instead of vague recommendations. Include exact files to create/update, exact gates to run, exact commands if detectable, and exact acceptance criteria.
 
+Avoid artifact sprawl: do not create optional markdown when a concise verdict
+or `agent-log/*.yml` pointer is enough. Do not duplicate full test strategy,
+CI policy, design rationale, or contract prose across artifacts.
+
 ## Scripts
 
 - `scripts/detect_project_profile.py`: inspect a repository and emit a Markdown project profile.
@@ -129,4 +151,7 @@ Run scripts with Python 3 from the repository root.
 
 - `tasks.yml`: structured YAML, validated by `src/schemas/tasks.schema.ts`.
 - `agent-log/<agent>.yml`: optional structured handoff note per `references/agent-log-protocol.md`.
-- All other change artifacts remain markdown prose.
+- `implementation-plan.md`: required execution handoff for implementation agents.
+- Report markdown is optional and reserved for durable review evidence. Routine
+  pass/fail evidence belongs in short `agent-log/*.yml` pointers or the final
+  assistant summary.

package/assets/skills/contract-driven-delivery/references/qa-gates.md

@@ -20,7 +20,11 @@
 
 ## QA rule
 
-QA approval requires evidence. Evidence may be command output, CI links, logs, screenshots, videos, traces, metrics, or artifact files.
+QA approval requires evidence. Evidence may be command output, CI links, logs,
+screenshots, videos, traces, metrics, or artifact files. Routine approvals
+should use concise verdict text plus optional `agent-log/*.yml` pointers.
+Create `qa-report.md` only for blocked, approved-with-risk, or excluded
+pre-existing failure decisions.
 
 ## Fixback rule
 

package/assets/skills/contract-driven-delivery/references/spec-drift-policy.md

@@ -25,4 +25,7 @@ Run a drift audit when:
 
 ## Output
 
-Use `templates/regression-report.md` or create `spec-drift-audit.md` when the audit is standalone.
+Use concise verdict text plus optional `agent-log/*.yml` evidence pointers for
+clean audits. Use `templates/regression-report.md` or create
+`spec-drift-audit.md` only when drift is found, the user asked for standalone
+audit documentation, or the change needs durable follow-up prose.

package/assets/skills/contract-driven-delivery/references/stress-soak-standard.md

@@ -40,3 +40,7 @@ Define:
 - raw logs or metrics
 - pass/fail conclusion
 - follow-up issues for degraded but non-blocking findings
+
+Routine results may be captured as concise response text plus optional
+`agent-log/*.yml` pointers. Create `stress-soak-report.md` only for required
+high-risk evidence, failed/blocked runs, or approved-with-risk decisions.

package/assets/skills/contract-driven-delivery/references/visual-review-standard.md

@@ -24,4 +24,7 @@ Visual review is required when frontend output changes.
 
 ## Review output
 
-Use `templates/visual-review-report.md`.
+Use concise verdict text plus optional `agent-log/*.yml` evidence pointers for
+routine approvals. Use `templates/visual-review-report.md` only for blocking
+visual findings, approved-with-risk decisions, or evidence bundles that need
+durable review prose.

package/assets/skills/contract-driven-delivery/references/workflow-router.md

@@ -6,8 +6,8 @@ Classify every request before implementation. A request may have more than one t
 
 | Change type | Required path |
 |---|---|
-| new-feature | proposal, spec, design, contracts, test-plan, ci-gates, tasks |
-| feature-enhancement | current-behavior, diff spec, regression scope, contracts, test-plan, ci-gates |
+| new-feature | proposal, spec, design, contracts, test-plan, ci-gates, implementation-plan, tasks |
+| feature-enhancement | current-behavior, diff spec, regression scope, contracts, test-plan, ci-gates, implementation-plan |
 | business-logic-change | current rule, new rule, decision table, examples, edge cases, regression tests |
 | bug-fix | reproduction, root cause, failing test, fix, regression test, QA evidence |
 | regression-fix | broken prior behavior, regression source, failing test, rollback or forward fix |
@@ -28,6 +28,7 @@ Do not create heavyweight artifacts when a tiny change does not need them. Howev
 - which contracts are affected
 - which tests prove it
 - which CI/CD gates must run
+- what execution packet implementation agents should follow
 
 ## Iteration rule
 

package/assets/skills/contract-driven-delivery/scripts/generate_change_scaffold.py

@@ -9,26 +9,36 @@ def main():
     ap.add_argument('change_id')
     ap.add_argument('--root', default='.')
     ap.add_argument('--templates', default=None)
+    ap.add_argument('--all', action='store_true', help='also copy optional report/spec templates')
     args=ap.parse_args()
     root=Path(args.root).resolve()
     templates=Path(args.templates).resolve() if args.templates else Path(__file__).resolve().parents[1]/'templates'
     dest=root/'specs'/'changes'/args.change_id
     dest.mkdir(parents=True, exist_ok=False)
-    mapping={
+    required={
         'change-request.md':'change-request.md',
         'change-classification.md':'change-classification.md',
+        'implementation-plan.md':'implementation-plan.md',
+        'test-plan.md':'test-plan.md',
+        'ci-gates.md':'ci-gates.md',
+        'tasks.yml':'tasks.yml',
+    }
+    optional={
         'current-behavior.md':'current-behavior.md',
         'proposal.md':'proposal.md',
         'spec.md':'spec.md',
         'design.md':'design.md',
         'contracts.md':'contracts.md',
-        'test-plan.md':'test-plan.md',
-        'ci-gates.md':'ci-gates.md',
-        'tasks.yml':'tasks.yml',
         'qa-report.md':'qa-report.md',
         'regression-report.md':'regression-report.md',
+        'visual-review-report.md':'visual-review-report.md',
+        'monkey-test-report.md':'monkey-test-report.md',
+        'stress-soak-report.md':'stress-soak-report.md',
         'archive.md':'archive.md',
     }
+    mapping=dict(required)
+    if args.all:
+        mapping.update(optional)
     for src,dst in mapping.items():
         s=templates/src
         if s.exists():

package/assets/skills/contract-driven-delivery/scripts/validate_spec_traceability.py

@@ -2,7 +2,7 @@
 """Coarse traceability check for a change folder."""
 from pathlib import Path
 import argparse, sys
-REQUIRED=['change-classification.md','test-plan.md','ci-gates.md','tasks.yml']
+REQUIRED=['change-classification.md','implementation-plan.md','test-plan.md','ci-gates.md','tasks.yml']
 def check_change_dir(d):
     """Check one change directory. Returns list of error strings (empty = pass)."""
     errors=[]

package/assets/skills/contract-driven-delivery/templates/change-classification.md

@@ -16,9 +16,10 @@
 ## Architecture Review Required
 - yes / no
 - reason: (fill only if yes)
+<!-- If yes, Optional Artifacts must set design.md to yes and Required Agents must include spec-architect. -->
 
 ## Required Artifacts
-Always required: change-request.md, change-classification.md, test-plan.md, ci-gates.md, tasks.yml
+Always required: change-request.md, change-classification.md, implementation-plan.md, test-plan.md, ci-gates.md, tasks.yml, context-manifest.md
 
 ## Optional Artifacts (default: no — set yes only with explicit reason)
 | artifact | create? | reason |
@@ -29,6 +30,14 @@ Always required: change-request.md, change-classification.md, test-plan.md, ci-g
 | design.md | no | |
 | qa-report.md | no | |
 | regression-report.md | no | |
+| visual-review-report.md | no | |
+| monkey-test-report.md | no | |
+| stress-soak-report.md | no | |
+
+Artifact minimization:
+- Prefer optional `agent-log/*.yml` pointers for routine review evidence.
+- Create report markdown only for blocking findings, approved-with-risk, excluded pre-existing failures, visual evidence bundles, or high-risk load/soak results.
+- Later artifacts should reference earlier artifacts by path/section/id instead of duplicating full content.
 
 ## Required Contracts
 - API:
@@ -61,7 +70,8 @@ Always required: change-request.md, change-classification.md, test-plan.md, ci-g
 
 ## Tasks Not Applicable
 <!-- Comma-separated task IDs from tasks.yml that do NOT apply to this change.
-     /cdd-new SKILL marks these as `status: skipped` in tasks.yml. -->
+     /cdd-new SKILL marks these as `status: skipped` in tasks.yml.
+     Include 1.3 when design.md is not required. -->
 - not-applicable:
 
 ## Clarifications or Assumptions

package/assets/skills/contract-driven-delivery/templates/ci-gates.md

@@ -29,3 +29,7 @@
 ## Artifact Retention
 
 ## Merge Eligibility Decision
+
+## Notes
+
+Reference test-plan.md rows or gate names instead of duplicating full test strategy.

package/assets/skills/contract-driven-delivery/templates/implementation-plan.md

@@ -0,0 +1,65 @@
+---
+change-id: <id>
+schema-version: 0.1.0
+last-changed: <date>
+---
+
+# Implementation Plan: <change-id>
+
+## Objective
+
+(Concrete outcome the implementation agents must deliver.)
+
+## Execution Scope
+
+### In Scope
+- 
+
+### Out of Scope
+- 
+
+## Required Changes
+
+| id | area | required action | owner agent |
+|---|---|---|---|
+| IP-1 |  |  |  |
+
+## Source Artifact Pointers
+
+| source | relevant pointer | used for |
+|---|---|---|
+| test-plan.md | AC-1 | tests to run/write |
+| ci-gates.md | required gates table | verification commands |
+| design.md | Decision:  | implementation constraint |
+
+## File-Level Plan
+
+| path or glob | action | notes |
+|---|---|---|
+|  |  |  |
+
+## Contract Updates
+
+- API:
+- CSS/UI:
+- Env:
+- Data shape:
+- Business logic:
+- CI/CD:
+
+## Test Execution Plan
+
+| acceptance criterion | test file / command | expected signal |
+|---|---|---|
+| AC-1 |  |  |
+
+## Handoff Constraints
+
+- Implementation agents must not infer missing requirements from chat history.
+- Do not re-copy full design, test strategy, CI policy, or contract prose into this plan; follow the source pointers above.
+- If this plan omits a required file, behavior, contract, or test, stop and report `blocked`.
+- Keep implementation within the file-level plan unless a Context Expansion Request is approved.
+
+## Known Risks
+
+-