From de57411cd26cc420aea10df0f93c0526adba0e77 Mon Sep 17 00:00:00 2001
From: one-kash <26795040+one-kash@users.noreply.github.com>
Date: Wed, 27 May 2026 23:11:08 +0000
Subject: [PATCH] v2.0.0: rename /tdd to /implement, simplify Phase 6,
 deprecate side repos
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Breaking changes:
- /tdd renamed to /implement; skill dir skills/tdd -> skills/implement;
  speckit ID speckit.dev-workflow.implement (alias speckit.implement)
- Tracker filename: impl-tracker-<feature>.json (was tdd-tracker-*.json)
- Phase 6 parallel reviewer is /code-review (read-only) instead of
  /simplify (which writes); review pair is now both read-only
- This repo is the only distribution channel; ai-agent-spec-skill and
  ai-agent-tdd-skill are deprecated; sync.sh + sync-skills.yml removed

Process simplification:
- Drop tracker `resume` field; pattern hints/pitfalls move to optional
  `notes`. Required fields (name, files_*, tdd, acceptance_criteria)
  already carry resume context
- Merge Standards into review-impl Criterion 4 (Code Quality +
  Architectural Gaps) and Blindspots into Criterion 6 (Robustness +
  Blindspots); drop the inline self-check that duplicated 6/8 criteria
- Prune 5 duplicate Lessons Learned (constructor cascading, TDD-fix-
  code, extract-UI-logic, dead-code-same-chunk, review-plan-before-
  coding) — each duplicated content from earlier phases. 19 -> 14
- Phase 2.5 verdict block trimmed; tracker plan_review field carries
  the gate forward across session resets

Added:
- UI state-holder vs rendering-only distinction in test-strategy table
  with detection signals (mutableStateOf, useState, LaunchedEffect, etc.)
- Both reviewers verify the "Pure UI — no test" exemption isn't
  misapplied to chunks that introduce hoisted state or branching effects
- Small-feature shortcut keeps both review gates (only chunking and
  Plan Mode collapse for 1-chunk features)
---
 .claude-plugin/plugin.json                    |  12 +-
 .github/workflows/sync-skills.yml             |  95 -----------
 CHANGELOG.md                                  |  24 +++
 PRIVACY.md                                    |   2 +-
 README.md                                     |  59 +++----
 agents/review-impl.md                         |  66 ++++++--
 agents/review-plan.md                         |  21 ++-
 extension.yml                                 |  17 +-
 skills/{tdd => implement}/PROJECT.md          |   4 +-
 skills/{tdd => implement}/SKILL.md            | 152 +++++++++---------
 .../project-configs/android-kotlin.md         |   0
 .../project-configs/python-pytest.md          |   0
 .../project-configs/rust-cargo.md             |   0
 .../project-configs/typescript-node.md        |   0
 .../references/chunk-template.md              |  25 +--
 .../references/quality-checklist.md           |   2 +-
 .../references/tracker-schema.md              |  42 ++---
 skills/spec/PROJECT.md                        |   2 +-
 skills/spec/SKILL.md                          |  18 +--
 skills/spec/references/spec-template.md       |  14 +-
 sync.sh                                       |  82 ----------
 validate.sh                                   |  99 ++++++------
 22 files changed, 300 insertions(+), 436 deletions(-)
 delete mode 100644 .github/workflows/sync-skills.yml
 rename skills/{tdd => implement}/PROJECT.md (95%)
 rename skills/{tdd => implement}/SKILL.md (77%)
 rename skills/{tdd => implement}/project-configs/android-kotlin.md (100%)
 rename skills/{tdd => implement}/project-configs/python-pytest.md (100%)
 rename skills/{tdd => implement}/project-configs/rust-cargo.md (100%)
 rename skills/{tdd => implement}/project-configs/typescript-node.md (100%)
 rename skills/{tdd => implement}/references/chunk-template.md (83%)
 rename skills/{tdd => implement}/references/quality-checklist.md (98%)
 rename skills/{tdd => implement}/references/tracker-schema.md (77%)
 delete mode 100755 sync.sh

diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json
index 7dc1159..5638e39 100644
--- a/.claude-plugin/plugin.json
+++ b/.claude-plugin/plugin.json
@@ -1,8 +1,8 @@
 {
   "name": "dev-workflow",
-  "version": "1.1.0",
-  "description": "Spec, Plan, Review, Implement, Verify — a complete AI development workflow with TDD, structured specifications, and independent review agents.",
-  "keywords": ["tdd", "specification", "code-review", "workflow", "quality"],
+  "version": "2.0.0",
+  "description": "Spec, Plan, Review, Implement, Verify — a complete AI development workflow with test-driven implementation, structured specifications, and independent review agents.",
+  "keywords": ["tdd", "implement", "specification", "code-review", "workflow", "quality"],
   "homepage": "https://github.com/openkash/ai-agent-dev-workflow",
   "author": {
     "name": "openkash"
@@ -14,9 +14,9 @@
       "description": "Structured specification with user stories, acceptance criteria, and interactive clarification"
     },
     {
-      "name": "tdd",
-      "path": "skills/tdd",
-      "description": "Test-driven development with chunk decomposition, JSON tracker, and 8-point quality checklist"
+      "name": "implement",
+      "path": "skills/implement",
+      "description": "Test-driven implementation with chunk decomposition, JSON tracker, and 8-point quality checklist"
     }
   ]
 }
diff --git a/.github/workflows/sync-skills.yml b/.github/workflows/sync-skills.yml
deleted file mode 100644
index d144a57..0000000
--- a/.github/workflows/sync-skills.yml
+++ /dev/null
@@ -1,95 +0,0 @@
-name: Sync skills to standalone repos
-
-on:
-  push:
-    branches: [main]
-    paths:
-      - 'skills/tdd/**'
-      - 'skills/spec/**'
-
-concurrency:
-  group: sync-skills
-  cancel-in-progress: true
-
-jobs:
-  sync-tdd:
-    if: contains(join(github.event.commits.*.modified, ','), 'skills/tdd/') || contains(join(github.event.commits.*.added, ','), 'skills/tdd/')
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout ecosystem repo
-        uses: actions/checkout@v4
-
-      - name: Checkout TDD skill repo
-        uses: actions/checkout@v4
-        with:
-          repository: openkash/ai-agent-tdd-skill
-          token: ${{ secrets.SYNC_TOKEN }}
-          path: target-tdd
-
-      - name: Sync TDD skill files
-        run: |
-          cp skills/tdd/SKILL.md target-tdd/SKILL.md
-          cp skills/tdd/PROJECT.md target-tdd/PROJECT.md
-          cp skills/tdd/references/* target-tdd/references/
-
-      - name: Create PR if changes exist
-        working-directory: target-tdd
-        env:
-          GH_TOKEN: ${{ secrets.SYNC_TOKEN }}
-        run: |
-          git config user.name "github-actions[bot]"
-          git config user.email "github-actions[bot]@users.noreply.github.com"
-          if git diff --quiet; then
-            echo "No changes to sync"
-            exit 0
-          fi
-          BRANCH="sync/from-ecosystem-$(date +%Y%m%d-%H%M%S)"
-          git checkout -b "$BRANCH"
-          git add -A
-          git commit -m "Sync from ai-agent-dev-workflow"
-          git push origin "$BRANCH"
-          gh pr create \
-            --repo openkash/ai-agent-tdd-skill \
-            --title "Sync from ai-agent-dev-workflow" \
-            --body "Automated sync from [ai-agent-dev-workflow](https://github.com/openkash/ai-agent-dev-workflow). Review changes before merging."
-
-  sync-spec:
-    if: contains(join(github.event.commits.*.modified, ','), 'skills/spec/') || contains(join(github.event.commits.*.added, ','), 'skills/spec/')
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout ecosystem repo
-        uses: actions/checkout@v4
-
-      - name: Checkout Spec skill repo
-        uses: actions/checkout@v4
-        with:
-          repository: openkash/ai-agent-spec-skill
-          token: ${{ secrets.SYNC_TOKEN }}
-          path: target-spec
-
-      - name: Sync Spec skill files
-        run: |
-          cp skills/spec/SKILL.md target-spec/SKILL.md
-          cp skills/spec/PROJECT.md target-spec/PROJECT.md
-          cp skills/spec/references/* target-spec/references/
-
-      - name: Create PR if changes exist
-        working-directory: target-spec
-        env:
-          GH_TOKEN: ${{ secrets.SYNC_TOKEN }}
-        run: |
-          git config user.name "github-actions[bot]"
-          git config user.email "github-actions[bot]@users.noreply.github.com"
-          if git diff --quiet; then
-            echo "No changes to sync"
-            exit 0
-          fi
-          BRANCH="sync/from-ecosystem-$(date +%Y%m%d-%H%M%S)"
-          git checkout -b "$BRANCH"
-          git add -A
-          git commit -m "Sync from ai-agent-dev-workflow"
-          git push origin "$BRANCH"
-          gh pr create \
-            --repo openkash/ai-agent-spec-skill \
-            --title "Sync from ai-agent-dev-workflow" \
-            --body "Automated sync from [ai-agent-dev-workflow](https://github.com/openkash/ai-agent-dev-workflow). Review changes before merging."
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 6bb63ac..901347d 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -5,6 +5,29 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [2.0.0] - 2026-05-27
+
+### Changed (breaking)
+
+- Renamed `/tdd` to `/implement`. The slash command is now `/implement <feature>`. Speckit command ID is `speckit.dev-workflow.implement` (alias `speckit.implement`); the previous `speckit.dev-workflow.tdd` ID no longer resolves. Skill directory moved from `skills/tdd/` to `skills/implement/`.
+- Tracker filename convention is now `impl-tracker-<feature>.json`. The previous `tdd-tracker-*.json` prefix is no longer recognized by review-plan / review-impl.
+- Phase 6 parallel reviewer is now `/code-review` (read-only) instead of `/simplify` (which writes to the tree). Running a writer concurrently with review-impl was racy; the review pair is now both read-only.
+- This repo is now the only distribution channel. `openkash/ai-agent-spec-skill` and `openkash/ai-agent-tdd-skill` are deprecated; the spec-sync workflow and `sync.sh` script have been removed. Install via the Claude Code plugin or copy directly from this repo.
+
+### Added
+
+- UI state-holder vs rendering-only distinction in the test-strategy table. UI chunks that introduce `mutableStateOf`, `LaunchedEffect`/`useEffect`, hoisted state, or input transformation must extract a state holder and unit-test its transitions. Pure prop/callback threading with no logic keeps the "no test" exemption.
+- Both review-plan and review-impl now check the state-holder exemption explicitly. A chunk that claims "Pure UI — no test" while introducing a holder is flagged as a FAIL.
+- Small-feature shortcut keeps both review gates. Only Plan Mode (Phase 2.4) and chunk decomposition (Phase 2.1-2.2) collapse for 1-chunk features; review-plan and review-impl + /code-review still run.
+
+### Migration
+
+- Replace any saved `/tdd <feature>` invocations with `/implement <feature>`.
+- Rename existing in-flight tracker files from `tdd-tracker-*.json` to `impl-tracker-*.json` if you want them picked up by the agents on resumption.
+- Update any project-level docs or onboarding notes that reference `skills/tdd/` to `skills/implement/`.
+- If you customised `skills/tdd/PROJECT.md`, copy it to `skills/implement/PROJECT.md` before pulling — the directory rename means the old path will not exist after the update.
+- The `resume` field on tracker chunks has been removed; per-chunk pattern hints and pitfalls now live in the optional `notes` field.
+
 ## [1.1.0] - 2026-04-12
 
 ### Changed
@@ -32,5 +55,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Example configs for Android/Kotlin, TypeScript/Node, Python/Django, Python/pytest, Rust/CLI, Rust/Cargo
 - Session resumption via JSON tracker with per-chunk resume fields
 
+[2.0.0]: https://github.com/openkash/ai-agent-dev-workflow/releases/tag/v2.0.0
 [1.1.0]: https://github.com/openkash/ai-agent-dev-workflow/releases/tag/v1.1.0
 [1.0.0]: https://github.com/openkash/ai-agent-dev-workflow/releases/tag/v1.0.0
diff --git a/PRIVACY.md b/PRIVACY.md
index 6f7b31b..31481c3 100644
--- a/PRIVACY.md
+++ b/PRIVACY.md
@@ -9,7 +9,7 @@ This plugin collects no data. It consists entirely of markdown files (skills, ag
 
 ## What This Plugin Does
 
-- Provides two skills (`/spec`, `/tdd`) that guide Claude Code through structured development workflows
+- Provides two skills (`/spec`, `/implement`) that guide Claude Code through structured development workflows
 - Provides two review agents (`review-plan`, `review-impl`) that evaluate plans and implementations
 - All processing happens locally in your Claude Code session
 
diff --git a/README.md b/README.md
index cd64d2f..8f1af07 100644
--- a/README.md
+++ b/README.md
@@ -11,21 +11,21 @@ specify, plan, review, implement, verify.
 ```
 /spec            Clarify WHAT to build (user stories, acceptance criteria)
     |
-/tdd             Plan HOW to build it (chunks, dependencies, tracker)
+/implement       Plan HOW to build it (chunks, dependencies, tracker)
     |
     |--- GATE: tracker file triggers review-plan automatically
     v
 review-plan      Independent 8-point plan review (blocks implementation)
     |
-/tdd             Implement with TDD (failing test -> code -> pass)
+/implement       Implement test-first (failing test -> code -> pass)
     |
     |--- GATE: all chunks complete triggers parallel review
     v
 review-impl      Verifies implementation matches plan ---+
-/simplify        Reviews code reuse and quality ----------+--- run in parallel
+/code-review     Reviews code reuse and quality ---------+--- run in parallel
 ```
 
-`/tdd` handles both planning and implementation. Reviews are
+`/implement` handles both planning and implementation. Reviews are
 **artifact-triggered gates**, not optional suggestions. The tracker
 file triggers review-plan; chunk completion triggers review-impl.
 Both agents run in isolated context with no memory of writing the
@@ -34,12 +34,12 @@ code, so they evaluate honestly.
 ## Why This Workflow
 
 > [!TIP]
-> - **Reviews are gates, not suggestions.** The tracker file triggers review-plan before coding starts. Chunk completion triggers review-impl + /simplify in parallel. No manual invocation needed, no option to skip.
+> - **Reviews are gates, not suggestions.** The tracker file triggers review-plan before coding starts. Chunk completion triggers review-impl + /code-review in parallel. No manual invocation needed, no option to skip.
 > - **The reviewer didn't write the code.** Review agents spawn in a fresh context, separate from the author. Bias eliminated by architecture, not instruction.
 > - **Scope is checked in both directions.** review-plan verifies every criterion has a chunk (completeness) AND every chunk serves a criterion (containment). Catches scope expansion before it becomes code.
 > - **Design bugs are caught before coding starts.** 8-point plan review before any code is written. Fixing a wrong abstraction in a plan costs minutes. In code, hours.
-> - **Specs are created, not just read.** `/spec` writes user stories with Given/When/Then acceptance criteria, then `/tdd` implements them. From "what should we build?" to passing tests.
-> - **Work survives context resets.** JSON tracker with per-chunk `resume` fields and `plan_review` verdict tells a new session exactly where to pick up.
+> - **Specs are created, not just read.** `/spec` writes user stories with Given/When/Then acceptance criteria, then `/implement` implements them. From "what should we build?" to passing tests.
+> - **Work survives context resets.** JSON tracker with per-chunk `name`, `files_*`, `tdd`, `acceptance_criteria` (plus optional `notes`) and the top-level `plan_review` verdict tells a new session exactly where to pick up.
 > - **One install, complete workflow.** Four pieces that work as a pipeline. No separate tools to discover, install, and wire.
 
 ## What's Included
@@ -47,9 +47,9 @@ code, so they evaluate honestly.
 | Piece | Type | Invocation | Purpose |
 |-------|------|-----------|---------|
 | [spec](skills/spec/SKILL.md) | Skill | `/spec <feature>` | User stories, acceptance criteria, edge cases |
-| [tdd](skills/tdd/SKILL.md) | Skill | `/tdd <feature>` | Chunk decomposition, TDD cycle, quality checklist |
-| [review-plan](agents/review-plan.md) | Agent | Triggered by /tdd | 8-point plan review with scope containment check |
-| [review-impl](agents/review-impl.md) | Agent | Triggered by /tdd | Checks code matches the plan and passes acceptance criteria |
+| [implement](skills/implement/SKILL.md) | Skill | `/implement <feature>` | Chunk decomposition, test-driven cycle, quality checklist |
+| [review-plan](agents/review-plan.md) | Agent | Triggered by /implement | 8-point plan review with scope containment check |
+| [review-impl](agents/review-impl.md) | Agent | Triggered by /implement | Checks code matches the plan and passes acceptance criteria |
 
 ## Installation
 
@@ -69,27 +69,19 @@ and both agents are available to use.
 git clone https://github.com/openkash/ai-agent-dev-workflow.git /tmp/dev-workflow
 
 # Skills
-mkdir -p .claude/skills/spec .claude/skills/tdd
+mkdir -p .claude/skills/spec .claude/skills/implement
 cp /tmp/dev-workflow/skills/spec/SKILL.md .claude/skills/spec/
 cp -r /tmp/dev-workflow/skills/spec/references/ .claude/skills/spec/
 cp -r /tmp/dev-workflow/skills/spec/project-configs/ .claude/skills/spec/
-cp /tmp/dev-workflow/skills/tdd/SKILL.md .claude/skills/tdd/
-cp -r /tmp/dev-workflow/skills/tdd/references/ .claude/skills/tdd/
-cp -r /tmp/dev-workflow/skills/tdd/project-configs/ .claude/skills/tdd/
+cp /tmp/dev-workflow/skills/implement/SKILL.md .claude/skills/implement/
+cp -r /tmp/dev-workflow/skills/implement/references/ .claude/skills/implement/
+cp -r /tmp/dev-workflow/skills/implement/project-configs/ .claude/skills/implement/
 
 # Agents
 mkdir -p .claude/agents
 cp /tmp/dev-workflow/agents/*.md .claude/agents/
 ```
 
-### Individual skills (standalone repos)
-
-If you only want the spec skill without the full workflow:
-
-- **Spec only:** [openkash/ai-agent-spec-skill](https://github.com/openkash/ai-agent-spec-skill)
-
-> **Note:** [ai-agent-tdd-skill](https://github.com/openkash/ai-agent-tdd-skill) is deprecated. This repo is the canonical source for the TDD skill, which depends on the review agents for its gate system.
-
 ## Configuration
 
 Each skill reads a `PROJECT.md` in its directory for project-specific
@@ -97,7 +89,7 @@ settings (build commands, test commands, standards).
 
 ```bash
 # Copy templates and customize
-cp /tmp/dev-workflow/skills/tdd/PROJECT.md .claude/skills/tdd/PROJECT.md
+cp /tmp/dev-workflow/skills/implement/PROJECT.md .claude/skills/implement/PROJECT.md
 cp /tmp/dev-workflow/skills/spec/PROJECT.md .claude/skills/spec/PROJECT.md
 ```
 
@@ -113,11 +105,11 @@ Example configs for common stacks are in `skills/*/project-configs/`.
 Produces `docs/specs/rate-limiting.md` with user stories and acceptance criteria.
 
 ```
-/tdd implement rate limiting (spec: docs/specs/rate-limiting.md)
+/implement rate limiting (spec: docs/specs/rate-limiting.md)
 ```
-The TDD skill decomposes the work into chunks, creates a tracker, and
-asks for approval. The tracker file automatically triggers the
-review-plan gate:
+The /implement skill decomposes the work into chunks, creates a
+tracker, and asks for approval. The tracker file automatically
+triggers the review-plan gate:
 
 ```
 GATE: tracker triggers review-plan agent (blocks Phase 3)
@@ -125,13 +117,13 @@ GATE: tracker triggers review-plan agent (blocks Phase 3)
 -> FAIL: update plan and re-run. PASS: proceed to implementation.
 ```
 
-After all chunks are implemented, the TDD skill triggers the
+After all chunks are implemented, /implement triggers the
 implementation review gate (both run in parallel):
 
 ```
 GATE: all chunks complete triggers parallel review
 -> review-impl agent verifies plan conformance and acceptance criteria
--> /simplify reviews code reuse and quality
+-> /code-review reviews code reuse and quality
 -> Address any FAIL findings before completing.
 ```
 
@@ -141,7 +133,7 @@ The agents work independently of the skills:
 
 ```
 Use the review-plan agent to review my-plan.md
-Use the review-impl agent to check the implementation against docs/tdd-tracker.json
+Use the review-impl agent to check the implementation against docs/impl-tracker.json
 ```
 
 ## File Structure
@@ -156,15 +148,14 @@ ai-agent-dev-workflow/
 │   │   ├── PROJECT.md           # Template - copy and customize
 │   │   ├── references/          # Spec template, taxonomy, validation
 │   │   └── project-configs/     # Example configs per stack
-│   └── tdd/                     # TDD skill
-│       ├── SKILL.md             # Core TDD process
+│   └── implement/               # Implementation skill
+│       ├── SKILL.md             # Core implementation process
 │       ├── PROJECT.md           # Template - copy and customize
 │       ├── references/          # Chunk template, tracker schema, checklist
 │       └── project-configs/     # Example configs per stack
 ├── agents/
 │   ├── review-plan.md           # Plan review agent (8-point)
 │   └── review-impl.md          # Implementation review agent (8-point)
-├── sync.sh                      # Sync to individual repos (maintainer use)
 ├── LICENSE                      # Apache 2.0
 └── README.md
 ```
@@ -179,7 +170,7 @@ The review agents are subagents (not slash-command skills) by design:
 |--------|----------------------|-------------------|
 | **Evaluator independence** | Runs in same context as author, biased toward own work | Fresh context, no memory of writing the plan/code |
 | **Context pollution** | Review details consume main window | Isolated, returns summary only |
-| **Automation** | User must remember to invoke | /tdd gates trigger automatically from artifacts |
+| **Automation** | User must remember to invoke | /implement gates trigger automatically from artifacts |
 | **Parallel execution** | Sequential in main context | Can run both reviews in parallel |
 | **Standalone use** | User invokes via `/review-plan` | User invokes via natural language ("review this plan") |
 
diff --git a/agents/review-impl.md b/agents/review-impl.md
index 3169726..bb326d5 100644
--- a/agents/review-impl.md
+++ b/agents/review-impl.md
@@ -1,6 +1,6 @@
 ---
 name: review-impl
-description: "Reviews implementation against the TDD plan. Checks for plan conformance, drift, missed acceptance criteria, and code quality. Use after implementation chunks are complete, before final commit."
+description: "Reviews implementation against the plan. Checks for plan conformance, drift, missed acceptance criteria, and code quality. Use after implementation chunks are complete, before final commit."
 tools: Read, Grep, Glob, Bash
 model: opus
 effort: high
@@ -16,13 +16,14 @@ you are reviewing someone else's work. Be thorough, specific, and honest.
 ## Inputs
 
 You will receive:
-- A **plan document** path (TDD tracker JSON or plan markdown)
+- A **plan document** path (implementation tracker JSON or plan markdown)
 - The **project root** (for reading implementation and tests)
 - Optionally, a list of **changed files** or a git diff range
 
-If no plan path is given, look for the most recent `tdd-tracker.json`
-in `docs/`. If no changed files are given, derive them from the tracker's
-`files_create` and `files_modify` arrays across all chunks.
+If no plan path is given, look for the most recent
+`impl-tracker-*.json` in `docs/`. If no changed files are given, derive
+them from the tracker's `files_create` and `files_modify` arrays across
+all chunks.
 
 ## Review Process
 
@@ -53,7 +54,7 @@ Does the implementation match what the plan specified?
 **How to check:**
 - For each `files_create` entry: does the file exist?
 - For each `files_modify` entry: was the file actually modified? (read it, check for the planned changes)
-- For each chunk: do the implemented changes match the `resume` and `tdd` descriptions?
+- For each chunk: do the implemented changes match the `tdd` description and any `notes`?
 - Check for **drift**: code that was implemented differently than planned
 - Check for **scope creep**: files modified that aren't in any chunk
 
@@ -101,6 +102,20 @@ Are the tests meaningful, correct, and sufficient?
 - Check test count: does it match expectations from the plan's `tdd` fields?
 - Run the test suite to confirm all pass
 
+**UI "no test" exemption — verify it actually applies.**
+When a chunk's `tdd` field claims "Pure UI — no test" or similar, read
+the modified files and grep for state-holder signals:
+
+```bash
+grep -nE "mutableStateOf|remember \{|LaunchedEffect|useState|useEffect|useRef|@State " [chunk-files]
+```
+
+If any of those appear, the exemption is invalid — the chunk has hoisted
+state, derived state, or branching effects that should be unit-tested by
+extracting a state holder. Rendering-only chunks (pure prop/callback
+threading, no logic, no effects) keep the exemption. When the exemption
+is misapplied, FAIL Criterion 3 and recommend extracting the holder.
+
 **Commands to run:**
 Use the project's test and build commands from `PROJECT.md`:
 ```bash
@@ -118,18 +133,28 @@ Use the project's test and build commands from `PROJECT.md`:
 
 ---
 
-### 4. Code Quality
+### 4. Code Quality (Standards + Architectural Gaps)
 
-Does the implementation follow project patterns and conventions?
+Does the implementation follow project patterns, project standards,
+and architectural layer boundaries?
 
-**How to check:**
+**How to check (standards):**
 - Read each created/modified production file
 - Cross-reference against `CLAUDE.md` design rules and architecture patterns
 - Cross-reference against `PROJECT.md` "Standards to Verify" section
 - Verify each standard listed in PROJECT.md is met by the implementation
 
+**How to check (architectural gaps):**
+- Verify layer boundaries are respected (UI → domain → data, no shortcuts)
+- Check that new capabilities accept dependencies via injection
+- Check that no business logic ended up in the wrong layer
+- Verify no circular dependencies were introduced
+- Use `grep` to confirm forbidden imports do not appear (e.g., UI files
+  importing data layer directly when the project's architecture forbids it)
+
 **Report:**
 - Standards violations with file:line references
+- Architecture violations (layer crossings, missed injection points)
 - Pattern deviations (justified deviations are OK — document them)
 
 ---
@@ -152,11 +177,12 @@ Did the implementation break existing functionality?
 
 ---
 
-### 6. Robustness
+### 6. Robustness + Blindspots
 
-Does the implementation handle errors, empty states, and edge cases?
+Does the implementation handle errors, empty states, edge cases, and
+the platform-specific blindspots automated tests typically miss?
 
-**How to check:**
+**How to check (robustness):**
 - For each new function/capability:
   - What happens with empty input? (grep for early returns, empty checks)
   - What happens on external errors? (grep for error handling, try/catch)
@@ -169,10 +195,20 @@ Does the implementation handle errors, empty states, and edge cases?
   - Are writes atomic where the project requires it?
   - Are reads graceful on missing files?
 
+**How to check (blindspots — see PROJECT.md §Blindspots):**
+- **Security:** input validation, injection, auth boundaries
+- **Concurrency:** race conditions, rapid clicks, parallel ops
+- **Error propagation:** errors surface to user, not swallowed
+- **Resource cleanup:** memory, file handles, connections
+- **Platform-specific concerns:** whatever PROJECT.md flags
+  (web: CORS/CSP/XSS/a11y; mobile: dark theme/RTL/permissions;
+  backend: rate limiting/pagination/idempotency; CLI: signals/exit codes)
+
 **Report:**
 - Error paths covered vs uncovered
 - Resource cleanup gaps
 - Missing edge case handling
+- Blindspot risks: what could go wrong, likelihood, mitigation
 
 ---
 
@@ -204,7 +240,7 @@ grep -n "^[[:space:]]*//" [changed-files] | head -20
 Can a future session understand what was done and why?
 
 **How to check:**
-- Is there a post-implementation document? (required by TDD skill Phase 6)
+- Is there a post-implementation document? (required by /implement Phase 6)
 - Does the tracker have `quality_verification` filled in?
 - Are complex decisions documented in code comments or the plan's notes?
 - Can a new session pick up from the tracker alone?
@@ -234,9 +270,9 @@ Output a structured report in this exact format:
 | 1 | Plan Conformance | PASS/WARN/FAIL | [one-line summary] |
 | 2 | Acceptance Criteria | PASS/WARN/FAIL | [N/M criteria verified] |
 | 3 | Test Quality | PASS/WARN/FAIL | [N tests, all passing/N failing] |
-| 4 | Code Quality | PASS/WARN/FAIL | [one-line summary] |
+| 4 | Code Quality (Standards + Architecture) | PASS/WARN/FAIL | [one-line summary] |
 | 5 | Regression | PASS/WARN/FAIL | [N tests pass, build OK/FAIL] |
-| 6 | Robustness | PASS/WARN/FAIL | [one-line summary] |
+| 6 | Robustness + Blindspots | PASS/WARN/FAIL | [one-line summary] |
 | 7 | Dead Code / Cleanup | PASS/WARN/FAIL | [one-line summary] |
 | 8 | Documentation | PASS/WARN/FAIL | [one-line summary] |
 
diff --git a/agents/review-plan.md b/agents/review-plan.md
index ee417dd..7c31df6 100644
--- a/agents/review-plan.md
+++ b/agents/review-plan.md
@@ -1,6 +1,6 @@
 ---
 name: review-plan
-description: "Reviews TDD implementation plans for completeness, correctness, gaps, standards, regression risk, robustness, blindspots, and TDD quality. Use after creating a plan in Phase 2 and before writing any code."
+description: "Reviews implementation plans for completeness, correctness, gaps, standards, regression risk, robustness, blindspots, and TDD quality. Use after creating a plan in Phase 2 and before writing any code."
 tools: Read, Grep, Glob, Bash
 model: opus
 effort: high
@@ -8,7 +8,7 @@ effort: high
 
 # Plan Review Agent
 
-You are an independent plan reviewer. Your job is to evaluate a TDD
+You are an independent plan reviewer. Your job is to evaluate an
 implementation plan against 8 criteria and produce a structured verdict.
 You did NOT write this plan — you are reviewing someone else's work.
 Be thorough, specific, and honest. Flag real issues, not style preferences.
@@ -16,11 +16,12 @@ Be thorough, specific, and honest. Flag real issues, not style preferences.
 ## Inputs
 
 You will receive:
-- A **plan document** path (the TDD plan or tracker JSON to review)
+- A **plan document** path (the implementation plan or tracker JSON to review)
 - The **project root** (for grepping code, reading architecture docs)
 
 If the user provides a plan path, read it first. If they say "review the
-plan" without a path, look for the most recent `tdd-tracker.json` in `docs/`.
+plan" without a path, look for the most recent `impl-tracker-*.json` in
+`docs/`.
 
 ## Review Process
 
@@ -195,14 +196,20 @@ Does the plan follow proper TDD discipline?
 - Chunks are ordered by dependency — no chunk depends on a later chunk
 - Each chunk is independently testable (or explicitly BATCH)
 - Acceptance criteria are testable — specific enough to write an assertion
-- Resume field is actionable (FILES, WHAT, PATTERN, DO NOT, TDD)
+- `name`, `files_create`/`files_modify`, and `tdd` together describe the chunk concretely; any `notes` entry adds non-obvious context (PATTERN: file:function, DO NOT pitfalls)
 
 **Common fails:**
 - Chunk has logic but no test file
 - `tdd` field says "no test" for a chunk that has testable logic
+- **UI chunk claims "Pure UI — no test" but introduces a state holder.**
+  If the chunk's files contain `mutableStateOf`, `remember { ... }` over
+  derived state, `LaunchedEffect`/`useEffect`, hoisted state, or input
+  transformation, the exemption does not apply. Recommend extracting the
+  holder and unit-testing its transitions. Rendering-only chunks (pure
+  prop/callback threading with no branching effects) keep the exemption
 - Dependent chunks not marked in `depends_on`
 - BATCH needed but not annotated (files won't compile independently)
-- Resume field is vague ("implement the feature")
+- Chunk `name` is vague ("implement the feature") with no `notes` to compensate
 - Acceptance criteria use vague terms ("works correctly", "handles errors")
 
 ---
@@ -257,6 +264,6 @@ Output a structured report in this exact format:
 - **Don't invent problems.** If the plan is solid, say PASS. Don't
   manufacture issues to appear thorough.
 - **Focus on what matters.** A missing error path is a FAIL. A
-  slightly verbose resume field is not worth mentioning.
+  slightly verbose `notes` field is not worth mentioning.
 - **Check the code, not just the plan.** Read the actual source files
   to verify the plan's assumptions about signatures, types, and behavior.
diff --git a/extension.yml b/extension.yml
index b8fcc05..47e075d 100644
--- a/extension.yml
+++ b/extension.yml
@@ -2,9 +2,9 @@ schema_version: "1.0"
 
 extension:
   id: "dev-workflow"
-  name: "Dev Workflow — Spec, TDD & Independent Review Agents"
-  version: "1.1.0"
-  description: "Specify, plan, review, implement, verify — full TDD pipeline with isolated reviewer agents."
+  name: "Dev Workflow — Spec, Implement & Independent Review Agents"
+  version: "2.0.0"
+  description: "Specify, plan, review, implement, verify — full test-driven pipeline with isolated reviewer agents."
   author: "openkash"
   repository: "https://github.com/openkash/ai-agent-dev-workflow"
   license: "Apache-2.0"
@@ -23,10 +23,10 @@ provides:
       description: "Generate structured specifications with user stories, acceptance criteria, interactive clarification, and 8-point validation"
       aliases: ["speckit.spec"]
 
-    - name: "speckit.dev-workflow.tdd"
-      file: "skills/tdd/SKILL.md"
-      description: "TDD implementation with chunk decomposition, dependency graph, JSON tracker, and per-chunk red-green-refactor cycle"
-      aliases: ["speckit.tdd"]
+    - name: "speckit.dev-workflow.implement"
+      file: "skills/implement/SKILL.md"
+      description: "Test-driven implementation with chunk decomposition, dependency graph, JSON tracker, and per-chunk red-green-refactor cycle"
+      aliases: ["speckit.implement"]
 
     - name: "speckit.dev-workflow.review-plan"
       file: "agents/review-plan.md"
@@ -38,7 +38,7 @@ provides:
 
   config:
     - name: "PROJECT.md"
-      template: "skills/tdd/PROJECT.md"
+      template: "skills/implement/PROJECT.md"
       description: "Project-specific settings (build commands, test commands, standards, blindspots)"
       required: false
 
@@ -57,6 +57,7 @@ hooks:
 
 tags:
   - "tdd"
+  - "implement"
   - "specification"
   - "review"
   - "claude-code"
diff --git a/skills/tdd/PROJECT.md b/skills/implement/PROJECT.md
similarity index 95%
rename from skills/tdd/PROJECT.md
rename to skills/implement/PROJECT.md
index 05e673e..ed25df5 100644
--- a/skills/tdd/PROJECT.md
+++ b/skills/implement/PROJECT.md
@@ -1,8 +1,8 @@
 # PROJECT.md - Project-Specific Configuration
 
 Copy this file into your skill directory and fill in the sections
-for your project. The TDD skill references this file for commands,
-patterns, and conventions that vary between projects.
+for your project. The /implement skill references this file for
+commands, patterns, and conventions that vary between projects.
 
 ---
 
diff --git a/skills/tdd/SKILL.md b/skills/implement/SKILL.md
similarity index 77%
rename from skills/tdd/SKILL.md
rename to skills/implement/SKILL.md
index 5effa14..300a1db 100644
--- a/skills/tdd/SKILL.md
+++ b/skills/implement/SKILL.md
@@ -1,11 +1,11 @@
 ---
-name: tdd
-description: "Structured TDD process: explores code, plans with chunk decomposition, writes failing tests first, implements to pass, and runs an 8-point quality checklist. Use when implementing features, fixing bugs, or refactoring with test verification."
+name: implement
+description: "Structured implementation process driven by TDD: explores code, plans with chunk decomposition, writes failing tests first, implements to pass, and runs an 8-point quality checklist. Use after /spec, or when implementing features, fixing bugs, or refactoring with test verification."
 argument-hint: "[description of feature, fix, or refactor]"
 effort: high
 ---
 
-# TDD Implementation Process
+# Implementation Process (Test-Driven)
 
 Implement the following using test-driven development: $ARGUMENTS
 
@@ -15,7 +15,7 @@ This is the highest-leverage pattern for agentic coding.
 
 ## Mapping to Claude Code Workflow
 
-| Claude Code Phase | TDD Phase | What Happens |
+| Claude Code Phase | Implement Phase | What Happens |
 |---|---|---|
 | **Explore** | Phase 1: Analysis | Read files, trace data flow, check standards |
 | **Plan** | Phase 2: Planning | Chunk decomposition, dependency graph, approval |
@@ -32,13 +32,14 @@ This is the highest-leverage pattern for agentic coding.
 | Large (cross-cutting, multi-session) | Full process + session resets between chunks |
 
 **Small feature shortcut:** For single-file or few-file changes
-with no new domain logic (pure UI, config wiring), collapse to:
-Analysis -> Pre-Test (verify existing coverage) -> Implement ->
-Post-Test (regression) -> Quality Verification. Use a 1-chunk
-tracker (see [tracker-schema.md](references/tracker-schema.md)
-§Single-Chunk Features). Skip chunking, plan mode, and Plan
-Review Gate (2.5). Quality Verification (Phase 6) still applies
-— review-impl + /simplify run for all features.
+with no new domain logic, collapse to: Analysis -> Pre-Test (verify
+existing coverage) -> Implement -> Post-Test (regression) -> Quality
+Verification. Use a 1-chunk tracker (see
+[tracker-schema.md](references/tracker-schema.md) §Single-Chunk
+Features). Only Plan Mode (2.4) and chunk decomposition (2.1-2.2)
+collapse — Phase 2.5 (review-plan) and Phase 6 (review-impl +
+/code-review) still run. Small features carry the same regression
+risk as large ones.
 
 ## Supporting Files
 
@@ -60,13 +61,13 @@ Phase 3: Pre-Test (per chunk)
 Phase 4: Implementation (per chunk)
 Phase 5: Post-Test (per chunk)
 Phase 6: Quality Verification
-  └─ Gate: review-impl agent + /simplify (parallel — blocks completion)
+  └─ Gate: review-impl agent + /code-review (parallel — blocks completion)
 ```
 
 Each phase must complete before the next begins.
 For multi-chunk features, Phases 3-5 repeat per chunk.
 Gates are artifact-triggered: the tracker file triggers review-plan
-(2.5), all chunks complete triggers review-impl + /simplify (6).
+(2.5), all chunks complete triggers review-impl + /code-review (6).
 
 ---
 
@@ -79,7 +80,7 @@ Gates are artifact-triggered: the tracker file triggers review-plan
 - Check `docs/specs/` for an existing spec file matching the feature.
   If found, use it as primary input — user stories, acceptance criteria,
   and edge cases become the basis for chunk decomposition in Phase 2.
-  (Specs are created by the [spec skill](https://github.com/openkash/ai-agent-spec-skill), an optional companion.)
+  (Specs are produced by the companion `/spec` skill in this plugin.)
 - Ask clarifying questions if the scope is ambiguous
 
 ### 1.2 Explore Current Code
@@ -141,7 +142,8 @@ Rules:
 - Chunks list files to create and modify
 - Chunks specify test files and TDD instructions
 - Chunks declare dependencies on other chunks
-- Each chunk has a `resume` field for session resumption
+- Optional `notes` field captures pattern hints / pitfalls a resuming
+  session can't infer from `name` + files + `tdd`
 
 ### 2.2 Dependency Graph
 
@@ -190,9 +192,7 @@ before proceeding to implementation.
 **GATE — The tracker artifact from 2.3 triggers this review.
 Do not proceed to Phase 3 until review completes.**
 
-The tracker file is the review input (analogous to the spec
-skill's Phase 4 validation, but delegated to an independent
-agent for deeper code-aware analysis). Spawn the `review-plan`
+The tracker file is the review input. Spawn the `review-plan`
 agent (`.claude/agents/review-plan.md`) as a subagent so the
 reviewer operates in a fresh context without author bias:
 
@@ -204,16 +204,14 @@ The agent evaluates 8 criteria against the plan: completeness,
 correctness, functional gaps, standards, regression risk,
 robustness, architectural gaps, and TDD quality.
 
-**FAIL:** Update the plan and re-run review-plan.
-**WARN:** Proceed with a note.
-**PASS:** Proceed to Phase 3.
-**Agent failure** (timeout, error, inconclusive): Fall back to
-self-check against [quality-checklist.md](references/quality-checklist.md),
-document the failure in the tracker's notes, and proceed.
+**FAIL:** update the plan and re-run review-plan.
+**WARN:** proceed with a note.
+**PASS:** proceed to Phase 3.
+**Agent failure** (timeout, error): fall back to self-check against
+[quality-checklist.md](references/quality-checklist.md) and proceed.
 
 Record the verdict in the tracker's top-level `plan_review` field
-(e.g., `"plan_review": "PASS"`). This makes the gate survive
-session resets — resumption checks this field before Phase 3.
+(e.g., `"plan_review": "PASS"`) so the gate survives session resets.
 
 ---
 
@@ -230,10 +228,19 @@ session resets — resumption checks this field before Phase 3.
 | Configuration / preferences | Defaults, type conversions, round-trips |
 | Composite / aggregating layer | Merge logic, fallbacks, empty states |
 | Interface / trait only | No test (tested via downstream fake) |
-| UI component | No test (build + regression) |
+| UI: state-holder / hoisted state | TEST — extract holder, unit-test transitions |
+| UI: rendering only (no logic) | No test (build + regression) |
 | DI wiring / config | No test (verified by compilation) |
 | Type migration / rename | No test (verified by compilation) |
 
+**State-holder detection:** Hoisted state (`mutableStateOf`,
+`useState`, `ref`, `@State`), branching effects (`LaunchedEffect`,
+`useEffect` with deps), or input transformation = testable logic.
+Extract the holder out of the framework component and unit-test
+the transitions. "UI = no test" is the most-abused row in this
+table; a state machine inside a Composable is still a state
+machine.
+
 ### 3.2 Write Failing Tests (or Verify Existing Coverage)
 
 If the test strategy says "No test," verify existing coverage
@@ -321,8 +328,9 @@ the tracker as handoff preserves more fidelity than compacted
 context, which loses information unpredictably.
 
 **Between chunks (preferred):** Start a new session. The JSON
-tracker + resume fields give the new session everything it needs.
-Use `/rename` to name the session for reference.
+tracker (`name` + `files_*` + `tdd` + `acceptance_criteria` + any
+`notes`) gives the new session everything it needs. Use `/rename`
+to name the session for reference.
 
 **Mid-chunk (fallback only):** If you must compact within a chunk,
 run `/compact Focus on the current chunk, tracker path, and test
@@ -347,29 +355,29 @@ for detailed criteria.
 7. **Gaps (Architectural)** - Abstraction boundaries respected
 8. **Blindspots** - Concurrency, security, edge environments
 
-**GATE — All chunks complete triggers parallel review.**
-
-Spawn both in a single message so they run concurrently:
+**GATE — All chunks complete triggers parallel review.** Both
+reviewers are read-only as long as `/code-review` is invoked
+without `--fix`, so concurrent runs are safe. Spawn both in a
+single message:
 
-1. **`review-impl` agent** — verifies plan conformance, acceptance
-   criteria, test quality, regression, robustness, and dead code
-2. **`/simplify`** — reviews changed files for code reuse, quality,
-   and efficiency
+1. **`review-impl` agent** — covers all 8 quality-checklist criteria
+   (completeness, correctness, gaps, standards + architecture,
+   regression, robustness + blindspots, dead code, documentation)
+2. **`/code-review`** — reports correctness bugs and reuse /
+   simplification cleanups on the diff
 
 ```
 In parallel:
 - Use the review-impl agent to review implementation against [path to tracker]
-- Run /simplify on changed files
+- Run /code-review on changed files
 ```
 
-While the agents run, self-check against the quick reference above.
-Merge findings from all three sources (review-impl, /simplify,
-self-check). Address any FAIL findings before proceeding.
+Merge findings from both sources, address any FAIL findings, then
+re-run the suite.
 
-**Agent failure** (timeout, error): If review-impl fails, fall back
-to self-check against the full quality-checklist.md. If /simplify
-is unavailable, review changed files manually for reuse and
-dead code. Document any agent failures in the tracker.
+**Agent failure** (timeout, error): fall back to self-check against
+the full [quality-checklist.md](references/quality-checklist.md).
+Document any agent failures in the tracker.
 
 ### Post-Implementation Documentation
 
@@ -401,74 +409,57 @@ what was reviewed, what was fixed, and what was intentionally left.
 
 1. **Tracker discipline** -
    Update status to `in_progress` BEFORE starting work
-2. **Constructor/signature cascading** -
-   When adding class dependencies or changing signatures,
-   grep ALL test files that call the affected code
-3. **Batch interconnected type changes** -
+2. **Batch interconnected type changes** -
    Changing a shared type's field? Change all consumers in one chunk
-4. **Platform quirks** -
+3. **Platform quirks** -
    Research boundary values, write tests BEFORE implementing
-5. **Don't over-chunk UI wiring** -
+4. **Don't over-chunk UI wiring** -
    Keep compatible signatures to avoid cascading changes
-6. **Sealed type formatting** -
+5. **Sealed type formatting** -
    Use common properties first; branch only for unique data
-7. **TDD means fix code, not tests** -
-   If test describes correct behavior and code doesn't match,
-   fix the code
-8. **Catch narrow exceptions for skip+continue** -
+6. **Catch narrow exceptions for skip+continue** -
    When converting `throw` to `continue` (resilience fix),
    narrow catch scope. Fatal errors (OOM, stack overflow)
    indicate the runtime is broken - continuing would cause
    cascading failures. Also verify cancellation exceptions
    can't reach the catch site
-9. **Fix sibling components together** -
+7. **Fix sibling components together** -
    If two components share the same bug pattern, fix both
    in one pass. Don't leave one broken for a future session
-10. **Check ALL required constructor params** -
-    When creating instances in tests or extensions, verify
-    no required params are missing
-11. **Extract testable logic from UI** -
-    If inline UI logic is worth testing, extract it as a
-    separate function. Test the function, not the UI
-12. **Adding checks breaks existing tests** -
-    When adding validation/permission checks to production
-    code, existing tests that skip setup for that check
-    will fail. Grep test files and add required setup
-13. **Clean up dead code in the same chunk** -
-    When a fix makes a code path unreachable, remove it
-    immediately. Don't leave dead code for a future pass.
-    The implementer has the best context for what's now dead
-14. **Review the plan before coding** -
-    Apply the 8-point quality checklist to the plan itself
-    (Phase 2.5). This is cheaper than finding design bugs
-    during implementation
-15. **Guard against false positive tests** -
+8. **Check ALL required constructor params** -
+   When creating instances in tests or extensions, verify
+   no required params are missing
+9. **Adding checks breaks existing tests** -
+   When adding validation/permission checks to production
+   code, existing tests that skip setup for that check
+   will fail. Grep test files and add required setup
+10. **Guard against false positive tests** -
     When asserting string/pattern presence, verify the match
     is in the right context - not in a comment, label, or
     unrelated field. Use precise assertions (line-level,
     regex-anchored) instead of broad substring checks.
     A broad check can pass for the wrong reason, hiding
     the real bug
-16. **Pre-written tests skip Phase 3** -
+11. **Pre-written tests skip Phase 3** -
     When failing tests already exist (compliance review, bug
     reproduction, user-provided test case), Phase 3 collapses
     to "verify tests still fail for the right reason." Don't
     rewrite or duplicate them - go straight to Phase 4
-17. **Stress-test your process scaffolding** -
+12. **Stress-test your process scaffolding** -
     Every process step encodes assumptions about model
     limitations. As models improve, re-evaluate whether
     scaffolding (sprint decomposition, heavy chunking,
     frequent resets) is still needed. Remove what no longer
     helps — simpler processes with fewer handoffs are faster
     and lose less context
-18. **Calibrate evaluation criteria over time** -
+13. **Calibrate evaluation criteria over time** -
     After Phase 6, compare your quality assessment to what
     the user actually flagged. If you marked "all criteria
     met" but the user found gaps, tighten the checklist or
     acceptance criteria for next time. This QA tuning loop
     — read evaluator output, find divergences from human
     expectations, refine criteria — compounds over sessions
-19. **Check dependency version changelogs during analysis** -
+14. **Check dependency version changelogs during analysis** -
     APIs can change behavior across minor versions without
     changing their signature. A method that fully re-executes
     in v1.0 may only recompose a subset in v1.1. During
@@ -497,7 +488,8 @@ When resuming work on an in-progress feature:
    before proceeding
 3. Read the plan file for detailed chunk descriptions
 4. Find next `pending` chunk where all `depends_on` are `complete`
-5. Read the chunk's `resume` field for instructions
+5. Read `name`, `files_create`/`files_modify`, `tdd`,
+   `acceptance_criteria`, and any `notes` on that chunk
 6. Follow TDD workflow (Phase 3 -> 4 -> 5)
 7. Update tracker status
 
diff --git a/skills/tdd/project-configs/android-kotlin.md b/skills/implement/project-configs/android-kotlin.md
similarity index 100%
rename from skills/tdd/project-configs/android-kotlin.md
rename to skills/implement/project-configs/android-kotlin.md
diff --git a/skills/tdd/project-configs/python-pytest.md b/skills/implement/project-configs/python-pytest.md
similarity index 100%
rename from skills/tdd/project-configs/python-pytest.md
rename to skills/implement/project-configs/python-pytest.md
diff --git a/skills/tdd/project-configs/rust-cargo.md b/skills/implement/project-configs/rust-cargo.md
similarity index 100%
rename from skills/tdd/project-configs/rust-cargo.md
rename to skills/implement/project-configs/rust-cargo.md
diff --git a/skills/tdd/project-configs/typescript-node.md b/skills/implement/project-configs/typescript-node.md
similarity index 100%
rename from skills/tdd/project-configs/typescript-node.md
rename to skills/implement/project-configs/typescript-node.md
diff --git a/skills/tdd/references/chunk-template.md b/skills/implement/references/chunk-template.md
similarity index 83%
rename from skills/tdd/references/chunk-template.md
rename to skills/implement/references/chunk-template.md
index eccb2b1..496cfb5 100644
--- a/skills/tdd/references/chunk-template.md
+++ b/skills/implement/references/chunk-template.md
@@ -71,7 +71,7 @@ If changing file A requires changing file B to compile:
 Data layer (no deps) -> Domain layer -> UI layer -> Verification
 ```
 
-### Step 5: Write Acceptance Criteria and Resume Instructions
+### Step 5: Write Acceptance Criteria
 
 For each chunk, define **acceptance criteria** — explicit pass/fail
 conditions that determine whether the chunk is done. These are the
@@ -82,12 +82,11 @@ Good acceptance criteria are:
 - **Specific** — "search returns filtered results" not "search works"
 - **Complete** — cover happy path, edge cases, and error cases
 
-Then write compact resume instructions that include:
-- FILES to create/modify
-- WHAT the change does
-- PATTERN to follow (existing code reference)
-- DO NOT pitfalls
-- TDD conditions
+A resuming session reads `files_create`/`files_modify` (where),
+`name` (what), `tdd` (test conditions), and `acceptance_criteria`
+(pass/fail) directly. Use the optional `notes` field only for hints
+those required fields can't carry — typically a `PATTERN: file:function`
+reference or a `DO NOT: ...` pitfall.
 
 ---
 
@@ -124,11 +123,15 @@ Then write compact resume instructions that include:
   "files_create": [],
   "files_modify": ["src/ui/components/QuickView.tsx"],
   "test_files": [],
-  "tdd": "No unit test (UI). Verified by build.",
+  "tdd": "No unit test (UI: rendering only — pure callback threading, no hoisted state or branching effects). Verified by build.",
   "depends_on": [1]
 }
 ```
 
+> If this chunk introduced hoisted state, a `useEffect`/`LaunchedEffect`,
+> or input transformation, it would be a UI: state-holder chunk and need a
+> test on the extracted holder. See SKILL.md §3.1 state-holder detection.
+
 ### Chunk 3: Wiring (depends on chunks 1 and 2)
 ```json
 {
@@ -176,9 +179,9 @@ Then write compact resume instructions that include:
 **Bad**: Chunk A changes shared type, Chunk B changes consumer
 **Good**: Single BATCH chunk that changes both together
 
-### Vague Resume Instructions
-**Bad**: "Implement the feature"
-**Good**: "FILES: Item.ts. Add buildShareText() method matching format in existing formatEvent(). PATTERN: Follow formatEvent() in EventService.ts:42. DO NOT: Change return type of getItems()."
+### Vague Chunk Names
+**Bad**: `name: "Implement the feature"`
+**Good**: `name: "buildShareText and toDuplicate helpers"` — paired with concrete `files_modify`, `tdd`, and (when needed) a `notes: "PATTERN: formatEvent() in EventService.ts:42. DO NOT change return type of getItems()."`
 
 ### Testing UI with Unit Tests
 **Bad**: Writing DOM/render tests for a simple layout change
diff --git a/skills/tdd/references/quality-checklist.md b/skills/implement/references/quality-checklist.md
similarity index 98%
rename from skills/tdd/references/quality-checklist.md
rename to skills/implement/references/quality-checklist.md
index 96760da..c5bb890 100644
--- a/skills/tdd/references/quality-checklist.md
+++ b/skills/implement/references/quality-checklist.md
@@ -176,7 +176,7 @@ Verify edge cases that automated tests may miss.
 
 **Self-evaluation warning:** This is the hardest point to
 self-assess honestly. Generators naturally focus on what they
-built, not what they missed. The `/simplify` skill running in
+built, not what they missed. The `/code-review` skill running in
 parallel (see Phase 6) catches what self-evaluation misses.
 
 **Always check:**
diff --git a/skills/tdd/references/tracker-schema.md b/skills/implement/references/tracker-schema.md
similarity index 77%
rename from skills/tdd/references/tracker-schema.md
rename to skills/implement/references/tracker-schema.md
index ca64454..e7c0fa4 100644
--- a/skills/tdd/references/tracker-schema.md
+++ b/skills/implement/references/tracker-schema.md
@@ -3,6 +3,8 @@
 The tracker file is the single source of truth for feature implementation progress.
 It is a local working file - not committed to version control.
 
+**Filename convention:** Trackers use `impl-tracker-<feature>.json`.
+
 ---
 
 ## Schema
@@ -25,8 +27,7 @@ It is a local working file - not committed to version control.
       "acceptance_criteria": ["Criterion 1", "Criterion 2"],
       "tdd": "Write test for X. Run -> fail -> implement -> pass.",
       "depends_on": [],
-      "resume": "Compact implementation instructions for session resumption.",
-      "notes": "Optional notes about decisions or constraints."
+      "notes": "Optional notes: decisions, constraints, pattern to follow (file:function), and pitfalls to avoid."
     }
   ],
   "quality_verification": {
@@ -71,8 +72,7 @@ It is a local working file - not committed to version control.
 | `acceptance_criteria` | Yes | Array of testable pass/fail conditions for this chunk |
 | `tdd` | Yes | TDD instructions: what to test, expected fail, then pass |
 | `depends_on` | Yes | Array of chunk IDs that must be `complete` first |
-| `resume` | Yes | Compact instructions for resuming this chunk |
-| `notes` | No | Optional notes about decisions or constraints |
+| `notes` | No | Optional decisions, constraints, pattern hints (file:function), and pitfalls. The chunk's `name` + `files_create`/`files_modify` + `tdd` already convey the rest of what a resuming session needs |
 
 ---
 
@@ -92,29 +92,18 @@ Rules:
 
 ---
 
-## Resume Field Format
-
-The `resume` field should be a compact instruction block that enables resuming
-the chunk in a new session without reading the full plan. Structure:
-
-```text
-FILES: List files to create/modify
-WHAT: One-sentence description of the change
-PATTERN: Which existing code to follow (file:function)
-DO NOT: Common pitfalls to avoid
-TDD: Specific test conditions
-```
+## Resuming a Chunk
 
-### Example
+A resuming session reads the chunk's required fields directly:
+`name` (what), `files_create` + `files_modify` (where), `tdd` (test
+conditions), `acceptance_criteria` (pass/fail). Add a `notes` entry
+when there's something a resuming session can't infer from those —
+typically a `PATTERN: file:function` hint or a `DO NOT: ...` pitfall.
 
-```text
-FILES: Add searchItems() to ItemRepository interface.
-Implement in SqlItemRepository using full-text search.
-Extend FakeItemRepository with searchItems().
-WHAT: Add search capability to repository layer.
-PATTERN: Follow existing getItemsByDate() for query pattern.
-DO NOT: Change service return types - wrap result internally.
-TDD: Test empty query returns empty, partial match returns filtered, category filtering works.
+```json
+{
+  "notes": "PATTERN: follow getItemsByDate() in SqlItemRepository. DO NOT change service return types — wrap result internally."
+}
 ```
 
 ---
@@ -126,8 +115,7 @@ When multiple files must change together (won't compile between), prefix the
 
 ```json
 {
-  "tdd": "BATCH - all 3 files must change together. No standalone unit test (UI). Verified by build + full suite regression. Update 16 breaking assertions in ServiceTest.",
-  "resume": "BATCH - all 3 files must change together (won't compile between). FILES: AppState.ts, AppService.ts, AppView.tsx. ..."
+  "tdd": "BATCH - all 3 files must change together. No standalone unit test (UI). Verified by build + full suite regression. Update 16 breaking assertions in ServiceTest."
 }
 ```
 
diff --git a/skills/spec/PROJECT.md b/skills/spec/PROJECT.md
index 65b5784..98cdc04 100644
--- a/skills/spec/PROJECT.md
+++ b/skills/spec/PROJECT.md
@@ -69,7 +69,7 @@ what X already does.
 
 ```text
 # Examples:
-#   Event CRUD follows EventCoordinator pattern (create/update/delete)
+#   Domain CRUD goes through the central Coordinator/Service layer
 #   All API endpoints use the shared error response format in errors.md
 #   New CLI commands follow the 'verb-noun' naming convention
 #   UI forms use the shared validation component with error display
diff --git a/skills/spec/SKILL.md b/skills/spec/SKILL.md
index 4322078..73e444c 100644
--- a/skills/spec/SKILL.md
+++ b/skills/spec/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: spec
-description: "Structured specification process: explores code, generates user stories with testable acceptance criteria, resolves ambiguities through interactive clarification, validates completeness, and outputs a lightweight spec. Use before /tdd to clarify WHAT to build."
+description: "Structured specification process: explores code, generates user stories with testable acceptance criteria, resolves ambiguities through interactive clarification, validates completeness, and outputs a lightweight spec. Use before /implement to clarify WHAT to build."
 argument-hint: "[description of feature, fix, or change]"
 effort: high
 ---
@@ -22,7 +22,7 @@ This is the highest-leverage pattern for complex features.
 | **Plan** | Phase 2: Specify | User stories, acceptance criteria, edge cases |
 | **Plan** | Phase 3: Clarify | Interactive disambiguation (max 5 questions) |
 | **Plan** | Phase 4: Validate | 8-point spec quality checklist |
-| **Plan** | Phase 5: Handoff | Summary report, suggest /tdd |
+| **Plan** | Phase 5: Handoff | Summary report, suggest /implement |
 
 ## When to Use This Process
 
@@ -354,11 +354,11 @@ Output to the user:
 - Validation result (Ready or Ready-with-warnings)
 - Any deferred ambiguities or validation warnings
 
-### 5.2 TDD Integration
+### 5.2 Implementation Integration
 
-Explain how the spec maps to TDD implementation:
+Explain how the spec maps to /implement:
 
-| Spec Section | TDD Phase | How to Use |
+| Spec Section | Implement Phase | How to Use |
 |---|---|---|
 | User Stories | Phase 1: Analysis | Scope of what to explore |
 | Acceptance Criteria | Phase 3: Pre-Test | Write these as failing tests |
@@ -369,19 +369,19 @@ Explain how the spec maps to TDD implementation:
 ### 5.3 Suggest Next Step
 
 ```
-Next: /tdd implement <feature> (spec: docs/specs/<feature>.md)
+Next: /implement <feature> (spec: docs/specs/<feature>.md)
 ```
 
 If the spec has warnings, note them:
 "The spec has N unresolved warnings — review the Notes section
-before starting TDD implementation."
+before starting implementation."
 
 **Non-code projects:** If the spec covers content, configuration,
-or documentation (no executable code), adapt the TDD mapping:
+or documentation (no executable code), adapt the mapping:
 - "Write these as failing tests" → "Write these as validation
   criteria or review checks"
 - "Starting point for chunks" → "Starting point for content chunks"
-- Suggest a structured implementation order rather than `/tdd`
+- Suggest a structured implementation order rather than `/implement`
 
 ---
 
diff --git a/skills/spec/references/spec-template.md b/skills/spec/references/spec-template.md
index 1a74824..c991ff7 100644
--- a/skills/spec/references/spec-template.md
+++ b/skills/spec/references/spec-template.md
@@ -72,9 +72,9 @@ no file paths, no algorithms.>
 | <path/to/file> | <what it does> | <what changes> |
 | <path/to/module> | <what it does> | <what changes> |
 
-## TDD Mapping
+## Implementation Mapping
 
-| Spec Section | TDD Phase | How to Use |
+| Spec Section | Implement Phase | How to Use |
 |---|---|---|
 | User Stories | Phase 1: Analysis | Scope of what to explore |
 | Acceptance Criteria | Phase 3: Pre-Test | Write these as failing tests |
@@ -167,19 +167,19 @@ spec-version: 1                # Bumped when spec is re-run/updated
 ### Affected Components
 
 - File paths and modules from Phase 1 exploration
-- Brief role description so TDD can skip redundant exploration
+- Brief role description so /implement can skip redundant exploration
 - Impact column describes what will change, not how
 
-### TDD Mapping
+### Implementation Mapping
 
 - Always include this section — it's the bridge to implementation
-- Maps each spec section to the TDD phase that consumes it
-- TDD skill can reference this table to know where to look
+- Maps each spec section to the /implement phase that consumes it
+- The /implement skill references this table to know where to look
 - **Non-code projects:** If the deliverable is content, config, or
   documentation rather than executable code, adapt the mapping:
   replace "failing tests" with "validation criteria or review checks"
   and "chunk decomposition" with "content chunking." Suggest a
-  structured build order rather than referencing `/tdd` directly
+  structured build order rather than referencing `/implement` directly
 
 ### Clarifications
 
diff --git a/sync.sh b/sync.sh
deleted file mode 100755
index 375ccff..0000000
--- a/sync.sh
+++ /dev/null
@@ -1,82 +0,0 @@
-#!/usr/bin/env bash
-# sync.sh — Copy skills from this ecosystem repo to individual repos.
-# Run manually before tagging a release.
-#
-# Usage:
-#   ./sync.sh [--dry-run]
-#
-# Assumes individual repos are checked out as siblings:
-#   ../ai-agent-tdd-skill/
-#   ../ai-agent-spec-skill/
-
-set -euo pipefail
-
-DRY_RUN=false
-[[ "${1:-}" == "--dry-run" ]] && DRY_RUN=true
-
-SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-
-# Support both naming conventions for local checkouts
-if [[ -d "${SCRIPT_DIR}/../ai-agent-tdd-skill" ]]; then
-    TDD_REPO="${SCRIPT_DIR}/../ai-agent-tdd-skill"
-elif [[ -d "${SCRIPT_DIR}/../tdd-skill" ]]; then
-    TDD_REPO="${SCRIPT_DIR}/../tdd-skill"
-else
-    TDD_REPO="${SCRIPT_DIR}/../ai-agent-tdd-skill"
-fi
-
-if [[ -d "${SCRIPT_DIR}/../ai-agent-spec-skill" ]]; then
-    SPEC_REPO="${SCRIPT_DIR}/../ai-agent-spec-skill"
-elif [[ -d "${SCRIPT_DIR}/../spec-skill" ]]; then
-    SPEC_REPO="${SCRIPT_DIR}/../spec-skill"
-else
-    SPEC_REPO="${SCRIPT_DIR}/../ai-agent-spec-skill"
-fi
-
-sync_file() {
-  local src="$1" dst="$2"
-  if [[ "$DRY_RUN" == true ]]; then
-    echo "[dry-run] $src -> $dst"
-  else
-    cp "$src" "$dst"
-    echo "  copied: $src -> $dst"
-  fi
-}
-
-sync_dir() {
-  local src="$1" dst="$2"
-  if [[ "$DRY_RUN" == true ]]; then
-    echo "[dry-run] $src/ -> $dst/"
-  else
-    cp -r "$src"/* "$dst"/
-    echo "  copied: $src/ -> $dst/"
-  fi
-}
-
-echo "=== Syncing TDD skill ==="
-if [[ -d "$TDD_REPO" ]]; then
-  sync_file "$SCRIPT_DIR/skills/tdd/SKILL.md" "$TDD_REPO/SKILL.md"
-  sync_file "$SCRIPT_DIR/skills/tdd/PROJECT.md" "$TDD_REPO/PROJECT.md"
-  sync_dir  "$SCRIPT_DIR/skills/tdd/references" "$TDD_REPO/references"
-  echo "  Done. Review changes: cd $TDD_REPO && git diff"
-else
-  echo "  SKIP: $TDD_REPO not found"
-fi
-
-echo ""
-echo "=== Syncing Spec skill ==="
-if [[ -d "$SPEC_REPO" ]]; then
-  sync_file "$SCRIPT_DIR/skills/spec/SKILL.md" "$SPEC_REPO/SKILL.md"
-  sync_file "$SCRIPT_DIR/skills/spec/PROJECT.md" "$SPEC_REPO/PROJECT.md"
-  sync_dir  "$SCRIPT_DIR/skills/spec/references" "$SPEC_REPO/references"
-  echo "  Done. Review changes: cd $SPEC_REPO && git diff"
-else
-  echo "  SKIP: $SPEC_REPO not found"
-fi
-
-echo ""
-if [[ "$DRY_RUN" == true ]]; then
-  echo "Dry run complete. No files were copied."
-else
-  echo "Sync complete. Review diffs in each repo before committing."
-fi
diff --git a/validate.sh b/validate.sh
index d1d4266..5737de5 100755
--- a/validate.sh
+++ b/validate.sh
@@ -36,13 +36,12 @@ required_files=(
     ".claude-plugin/plugin.json"
     "LICENSE"
     "README.md"
-    "sync.sh"
-    # TDD skill
-    "skills/tdd/SKILL.md"
-    "skills/tdd/PROJECT.md"
-    "skills/tdd/references/chunk-template.md"
-    "skills/tdd/references/tracker-schema.md"
-    "skills/tdd/references/quality-checklist.md"
+    # Implement skill
+    "skills/implement/SKILL.md"
+    "skills/implement/PROJECT.md"
+    "skills/implement/references/chunk-template.md"
+    "skills/implement/references/tracker-schema.md"
+    "skills/implement/references/quality-checklist.md"
     # Spec skill
     "skills/spec/SKILL.md"
     "skills/spec/PROJECT.md"
@@ -93,11 +92,11 @@ check_links_in() {
 }
 
 check_links_in "README.md"
-check_links_in "skills/tdd/SKILL.md"
+check_links_in "skills/implement/SKILL.md"
 check_links_in "skills/spec/SKILL.md"
-check_links_in "skills/tdd/references/chunk-template.md"
-check_links_in "skills/tdd/references/tracker-schema.md"
-check_links_in "skills/tdd/references/quality-checklist.md"
+check_links_in "skills/implement/references/chunk-template.md"
+check_links_in "skills/implement/references/tracker-schema.md"
+check_links_in "skills/implement/references/quality-checklist.md"
 check_links_in "skills/spec/references/spec-template.md"
 check_links_in "skills/spec/references/clarification-taxonomy.md"
 check_links_in "skills/spec/references/validation-checklist.md"
@@ -142,8 +141,8 @@ validate_json_blocks() {
     done < "$file"
 }
 
-validate_json_blocks "skills/tdd/references/tracker-schema.md"
-validate_json_blocks "skills/tdd/references/chunk-template.md"
+validate_json_blocks "skills/implement/references/tracker-schema.md"
+validate_json_blocks "skills/implement/references/chunk-template.md"
 
 # ─────────────────────────────────────────────
 section "4. plugin.json has required fields"
@@ -166,26 +165,26 @@ else
 fi
 
 # ─────────────────────────────────────────────
-section "5. TDD SKILL.md phases are sequential (1-6)"
+section "5. Implement SKILL.md phases are sequential (1-6)"
 # ─────────────────────────────────────────────
 
-tdd_skill="skills/tdd/SKILL.md"
+implement_skill="skills/implement/SKILL.md"
 
-phase_count="$(grep -cE '^## Phase [0-9]+:' "$tdd_skill" || true)"
+phase_count="$(grep -cE '^## Phase [0-9]+:' "$implement_skill" || true)"
 if [[ "$phase_count" -eq 6 ]]; then
-    pass "TDD SKILL.md has $phase_count phases"
+    pass "Implement SKILL.md has $phase_count phases"
 else
-    fail "TDD SKILL.md has $phase_count phases (expected 6)"
+    fail "Implement SKILL.md has $phase_count phases (expected 6)"
 fi
 
 expected=1
-phase_nums="$(grep -E '^## Phase [0-9]+:' "$tdd_skill" | sed 's/^## Phase //' | sed 's/:.*//' || true)"
+phase_nums="$(grep -E '^## Phase [0-9]+:' "$implement_skill" | sed 's/^## Phase //' | sed 's/:.*//' || true)"
 while IFS= read -r num; do
     [[ -z "$num" ]] && continue
     if [[ "$num" -eq "$expected" ]]; then
-        pass "TDD Phase $num is sequential"
+        pass "Implement Phase $num is sequential"
     else
-        fail "TDD Phase $num out of order (expected $expected)"
+        fail "Implement Phase $num out of order (expected $expected)"
     fi
     expected=$((expected + 1))
 done <<< "$phase_nums"
@@ -219,7 +218,7 @@ done <<< "$phase_nums"
 section "7. Quality checklist has exactly 8 points"
 # ─────────────────────────────────────────────
 
-checklist="skills/tdd/references/quality-checklist.md"
+checklist="skills/implement/references/quality-checklist.md"
 checklist_count="$(grep -cE '^## [0-9]+\.' "$checklist" || true)"
 if [[ "$checklist_count" -eq 8 ]]; then
     pass "quality-checklist.md has $checklist_count points"
@@ -240,7 +239,7 @@ while IFS= read -r num; do
 done <<< "$checklist_nums"
 
 # ─────────────────────────────────────────────
-section "8. TDD SKILL.md 8-point summaries match checklist"
+section "8. Implement SKILL.md 8-point summaries match checklist"
 # ─────────────────────────────────────────────
 
 # Phase 6 Quick Reference lists criteria 1-7 in bold; Phase 2.5 delegates
@@ -258,23 +257,23 @@ phase6_names=(
 )
 
 for name in "${phase6_names[@]}"; do
-    count="$(grep -c "\*\*$name\*\*" "$tdd_skill" || true)"
+    count="$(grep -c "\*\*$name\*\*" "$implement_skill" || true)"
     if [[ "$count" -ge 1 ]]; then
         pass "\"$name\" in Phase 6 Quick Reference"
     else
-        fail "\"$name\" not found in TDD SKILL.md"
+        fail "\"$name\" not found in Implement SKILL.md"
     fi
 done
 
 # Phase 2.5 is an artifact-triggered gate that delegates to review-plan agent.
 # Verify the gate structure exists.
-if grep -q "GATE.*tracker.*triggers" "$tdd_skill"; then
+if grep -q "GATE.*tracker.*triggers" "$implement_skill"; then
     pass "Phase 2.5 has artifact-triggered gate"
 else
     fail "Phase 2.5 missing artifact-triggered gate pattern"
 fi
 
-if grep -q "plan_review" "$tdd_skill"; then
+if grep -q "plan_review" "$implement_skill"; then
     pass "SKILL.md references plan_review tracker field"
 else
     fail "SKILL.md missing plan_review tracker field reference"
@@ -327,14 +326,14 @@ check_lessons() {
     done
 }
 
-check_lessons "$tdd_skill" "TDD"
+check_lessons "$implement_skill" "Implement"
 check_lessons "$spec_skill" "Spec"
 
 # ─────────────────────────────────────────────
 section "10. PROJECT.md templates have required sections"
 # ─────────────────────────────────────────────
 
-tdd_sections=(
+implement_sections=(
     "Build & Test Commands"
     "Architecture Patterns"
     "Standards to Verify"
@@ -343,11 +342,11 @@ tdd_sections=(
     "Documentation Location"
 )
 
-for section_name in "${tdd_sections[@]}"; do
-    if grep -q "$section_name" "skills/tdd/PROJECT.md"; then
-        pass "TDD PROJECT.md has \"$section_name\""
+for section_name in "${implement_sections[@]}"; do
+    if grep -q "$section_name" "skills/implement/PROJECT.md"; then
+        pass "Implement PROJECT.md has \"$section_name\""
     else
-        fail "TDD PROJECT.md missing \"$section_name\""
+        fail "Implement PROJECT.md missing \"$section_name\""
     fi
 done
 
@@ -372,11 +371,11 @@ section "11. No project-specific leaks in core files"
 # ─────────────────────────────────────────────
 
 core_files=(
-    "skills/tdd/SKILL.md"
+    "skills/implement/SKILL.md"
     "skills/spec/SKILL.md"
-    "skills/tdd/references/chunk-template.md"
-    "skills/tdd/references/tracker-schema.md"
-    "skills/tdd/references/quality-checklist.md"
+    "skills/implement/references/chunk-template.md"
+    "skills/implement/references/tracker-schema.md"
+    "skills/implement/references/quality-checklist.md"
     "skills/spec/references/spec-template.md"
     "skills/spec/references/clarification-taxonomy.md"
     "skills/spec/references/validation-checklist.md"
@@ -414,19 +413,19 @@ for agent in agents/*.md; do
 done
 
 # ─────────────────────────────────────────────
-section "13. TDD SKILL.md references review agents"
+section "13. Implement SKILL.md references review agents"
 # ─────────────────────────────────────────────
 
-if grep -q "review-plan" "$tdd_skill"; then
-    pass "TDD SKILL.md references review-plan agent"
+if grep -q "review-plan" "$implement_skill"; then
+    pass "Implement SKILL.md references review-plan agent"
 else
-    fail "TDD SKILL.md does not reference review-plan agent"
+    fail "Implement SKILL.md does not reference review-plan agent"
 fi
 
-if grep -q "review-impl" "$tdd_skill"; then
-    pass "TDD SKILL.md references review-impl agent"
+if grep -q "review-impl" "$implement_skill"; then
+    pass "Implement SKILL.md references review-impl agent"
 else
-    fail "TDD SKILL.md does not reference review-impl agent"
+    fail "Implement SKILL.md does not reference review-impl agent"
 fi
 
 # ─────────────────────────────────────────────
@@ -463,14 +462,14 @@ check_skill_frontmatter() {
     fi
 }
 
-check_skill_frontmatter "$tdd_skill" "TDD SKILL.md"
+check_skill_frontmatter "$implement_skill" "Implement SKILL.md"
 check_skill_frontmatter "$spec_skill" "Spec SKILL.md"
 
 # ─────────────────────────────────────────────
 section "15. SKILL.md files are under 500 lines"
 # ─────────────────────────────────────────────
 
-for skill_file in "$tdd_skill" "$spec_skill"; do
+for skill_file in "$implement_skill" "$spec_skill"; do
     label="$(basename "$(dirname "$skill_file")")"
     lines="$(wc -l < "$skill_file")"
     if [[ "$lines" -le 510 ]]; then
@@ -484,13 +483,13 @@ done
 section "16. Example project configs are valid"
 # ─────────────────────────────────────────────
 
-for config in skills/tdd/project-configs/*.md; do
+for config in skills/implement/project-configs/*.md; do
     basename="$(basename "$config")"
-    for section_name in "${tdd_sections[@]}"; do
+    for section_name in "${implement_sections[@]}"; do
         if grep -q "$section_name" "$config"; then
-            pass "tdd/$basename has \"$section_name\""
+            pass "implement/$basename has \"$section_name\""
         else
-            fail "tdd/$basename missing \"$section_name\""
+            fail "implement/$basename missing \"$section_name\""
         fi
     done
 done