@leeovery/claude-technical-workflows 2.1.33 → 2.1.35

package/README.md

@@ -110,7 +110,7 @@ Each phase produces documents that feed the next. Here's the journey:
 
 **Implementation** — Executes plans via strict TDD. Tests first, then code, commit after each task. Per-task approval gates keep you in control, with auto-mode available when you trust the flow.
 
-**Review** — Validates the implementation against spec and plan. Catches drift, missing requirements, and quality issues. The spec is the source of truth here — earlier phases may contain rejected ideas that were intentionally filtered out. Produces structured feedback without fixing code directly.
+**Review** — Validates the implementation against spec and plan. Catches drift, missing requirements, and quality issues. Findings can be synthesized into remediation tasks that feed back into implementation, closing the review-implementation loop.
 
 ### Standalone Skills
 
@@ -231,8 +231,11 @@ docs/workflow/
 ├── implementation/                    # Phase 5 — directory per topic
 │   └── {topic}/
 │       └── tracking.md               #   Progress, gates, current task
-└── review/                            # Phase 6 — one file per review
-    └── {topic}.md
+└── review/                            # Phase 6 — versioned per review
+    └── {topic}/
+        └── r1/
+            ├── review.md              #   Review summary and verdict
+            └── qa-task-1.md           #   Per-task QA verification
 ```
 
 Research starts with `exploration.md` and splits into topic files as themes emerge. From specification onwards, each topic gets its own directory. Planning task storage varies by [output format](#output-formats) — the tree above shows local-markdown; Tick and Linear store tasks externally.
@@ -269,12 +272,15 @@ skills/
 
 agents/
 ├── review-task-verifier.md           # Verifies single task implementation for review
+├── review-findings-synthesizer.md   # Synthesizes review findings into remediation tasks
 ├── implementation-task-executor.md  # TDD executor for single plan tasks
 ├── implementation-task-reviewer.md  # Post-task review for spec conformance
 ├── planning-phase-designer.md       # Design phases from specification
 ├── planning-task-designer.md        # Break phases into task lists
 ├── planning-task-author.md          # Write full task detail
-└── planning-dependency-grapher.md   # Analyze task dependencies and priorities
+├── planning-dependency-grapher.md   # Analyze task dependencies and priorities
+├── planning-review-traceability.md  # Spec-to-plan traceability analysis
+└── planning-review-integrity.md     # Plan structural quality review
 
 tests/
 └── scripts/                         # Shell script tests for discovery and migrations
@@ -310,7 +316,7 @@ Sequential skills that expect files from previous phases and pass content to pro
 | [**/start-specification**](skills/start-specification/)                      | Start a specification session from existing discussion(s). Automatically analyses multiple discussions for natural groupings and consolidates them into unified specifications.                            |
 | [**/start-planning**](skills/start-planning/)                                | Start a planning session from an existing specification. Creates implementation plans with phases, tasks, and acceptance criteria. Supports multiple output formats. |
 | [**/start-implementation**](skills/start-implementation/)                    | Start implementing a plan. Executes tasks via strict TDD, committing after each passing test.                                                                                                              |
-| [**/start-review**](skills/start-review/)                                    | Start reviewing completed work. Validates implementation against plan tasks and acceptance criteria.                                                                                                        |
+| [**/start-review**](skills/start-review/)                                    | Start reviewing completed work. Validates implementation against plan tasks and acceptance criteria. Findings can be synthesized into remediation tasks.                                                    |
 
 #### Utility Skills
 
@@ -354,6 +360,9 @@ Subagents that skills can spawn for parallel task execution.
 | [**planning-task-designer**](agents/planning-task-designer.md) | technical-planning | Breaks a single phase into a task list with edge cases. |
 | [**planning-task-author**](agents/planning-task-author.md) | technical-planning | Writes full detail for a single plan task. |
 | [**planning-dependency-grapher**](agents/planning-dependency-grapher.md) | technical-planning | Analyzes authored tasks to establish internal dependencies and priorities. |
+| [**planning-review-traceability**](agents/planning-review-traceability.md) | technical-planning | Spec-to-plan traceability analysis. |
+| [**planning-review-integrity**](agents/planning-review-integrity.md) | technical-planning | Plan structural quality review. |
+| [**review-findings-synthesizer**](agents/review-findings-synthesizer.md) | technical-review | Synthesizes review findings into normalized remediation tasks for plan integration. |
 
 ## Requirements
 

package/agents/implementation-analysis-task-writer.md

@@ -19,6 +19,7 @@ You receive via the orchestrator's prompt:
 4. **Plan format reading adapter path** — how to read tasks from the plan (for determining next phase number)
 5. **Plan format authoring adapter path** — how to create tasks in the plan
 6. **plan-index-schema.md** — Canonical plan index structure
+7. **Phase label** — the label for the new phase (e.g., "Analysis (Cycle 1)", "Review Remediation (Cycle 1)")
 
 ## Your Process
 
@@ -35,10 +36,10 @@ The Plan Index File (`docs/workflow/planning/{topic}/plan.md`) is the single sou
 
 Append at the end of the Plan Index File body, following the **Phase Entry** and **Task Table** templates from plan-index-schema:
 
-- Phase heading: `### Phase {N}: Analysis ({cycle description})`
+- Phase heading: `### Phase {N}: {phase_label}`
 - Phase `status`: `approved` (pre-approved by user in approval gate)
 - Phase `ext_id`: external identifier for the phase from the output format
-- Phase goal: `Address findings from implementation analysis cycle {N}.`
+- Phase goal: `Address findings from {phase_label}.`
 - Omit `approved_at` and acceptance criteria (analysis phases don't use them)
 - Task `Status`: `authored` (task files are fully written)
 - Task `Ext ID`: external identifier for the task from the output format

package/agents/planning-task-author.md

@@ -1,7 +1,7 @@
 ---
 name: planning-task-author
-description: Writes full detail for a single plan task. Invoked by technical-planning skill during plan construction.
-tools: Read, Glob, Grep
+description: Writes full detail for all plan tasks in a phase. Invoked by technical-planning skill during plan construction.
+tools: Read, Glob, Grep, Write
 model: opus
 ---
 
@@ -18,13 +18,12 @@ You receive file paths via the orchestrator's prompt:
 3. **Cross-cutting spec paths** (if any) — Architectural decisions that influence planning
 4. **task-design.md** — Task design principles and template
 5. **All approved phases** — The complete phase structure (from the Plan Index File)
-6. **Task list for current phase** — The approved task table
-7. **Target task** — Which task to author (name, edge cases from the table)
-8. **Output format adapter path** — The output format reference defining the exact file structure
+6. **Task list for current phase** — The approved task table (ALL tasks in the phase)
+7. **Scratch file path** — Where to write authored tasks
 
 On **amendment**, you also receive:
-- **Previous output** — Your prior task detail
-- **User feedback** — What to change
+- **Scratch file path** — Contains previously authored tasks with status markers
+- The scratch file contains `rejected` tasks with feedback blockquotes — rewrite only those
 
 ## Your Process
 
@@ -33,10 +32,40 @@ On **amendment**, you also receive:
 3. Read any cross-cutting specifications
 4. Read `task-design.md` — absorb the task template and quality standards
 5. Read the approved phases and task list — understand context and scope
-6. Read the output format adapter — understand the exact format for task files
-7. Author the target task in the output format's structure
+6. Author all tasks in the phase, writing each to the scratch file incrementally — each task written to disk before starting the next
 
-If this is an **amendment**: read your previous output and the user's feedback, then revise accordingly.
+If this is an **amendment**: read the scratch file, find tasks marked `rejected` (they have a feedback blockquote below the status line). Rewrite the entire scratch file — copy `approved` tasks verbatim, rewrite `rejected` tasks addressing the feedback. Reset rewritten tasks to `pending` status.
+
+## Scratch File Format
+
+Write the scratch file with this structure:
+
+```markdown
+---
+phase: {N}
+phase_name: {Phase Name}
+total: {count}
+---
+
+## {task-id} | pending
+
+### Task {seq}: {Task Name}
+
+**Problem**: ...
+**Solution**: ...
+**Outcome**: ...
+**Do**: ...
+**Acceptance Criteria**: ...
+**Tests**: ...
+**Edge Cases**: ...
+**Context**: ...
+**Spec Reference**: ...
+
+## {task-id} | pending
+
+### Task {seq}: {Task Name}
+...
+```
 
 ## Task Template
 
@@ -48,20 +77,21 @@ Every task must include these fields (from task-design.md):
 - **Do**: Specific implementation steps (file locations, method names where helpful)
 - **Acceptance Criteria**: Pass/fail verifiable criteria
 - **Tests**: Named test cases including edge cases
+- **Edge Cases**: Edge case handling (reference from the task table)
 - **Context**: (when relevant) Specification decisions and constraints that inform implementation
+- **Spec Reference**: Which specification section(s) this task traces to
 
 ## Your Output
 
-Return the complete task detail in the exact format specified by the output format adapter. What you produce is what the orchestrator will write verbatim — the user sees your output before approving, and approved output is logged without modification.
-
-The output format adapter determines the file structure (frontmatter, sections, naming). Follow it precisely.
+Write all tasks to the scratch file path provided. Use the canonical task template format above. Each task is written to disk before starting the next — incremental writes, not a single batch at the end.
 
 ## Rules
 
-1. **Self-contained** — anyone (Claude or human) could pick up this task and execute it without opening another document
+1. **Self-contained** — anyone (Claude or human) could pick up any task and execute it without opening another document
 2. **Specification is source of truth** — pull rationale, decisions, and constraints from the spec
 3. **Cross-cutting specs inform** — apply their architectural decisions where relevant (e.g., caching, rate limiting)
 4. **Every field required** — Problem, Solution, Outcome, Do, Acceptance Criteria, Tests are all mandatory
 5. **Tests include edge cases** — not just happy path; reference the edge cases from the task table
-6. **Match the output format exactly** — follow the adapter's template structure
-7. **No modifications after approval** — what the user sees is what gets logged
+6. **Write tasks to the scratch file incrementally** — each task written to disk before starting the next
+7. **Spec interpretation errors propagate across tasks in a batch** — ground every decision in the specification. When the spec is ambiguous, note the ambiguity in the task's Context section rather than inventing a plausible default.
+8. **No modifications after approval** — what the user sees is what gets logged

package/agents/review-findings-synthesizer.md

@@ -0,0 +1,108 @@
+---
+name: review-findings-synthesizer
+description: Synthesizes review findings into normalized tasks. Reads QA verification files, deduplicates, groups, normalizes using task template, and writes a staging file for orchestrator approval. Invoked by technical-review skill after review actions are initiated.
+tools: Read, Write, Glob, Grep
+model: opus
+---
+
+# Review Findings: Synthesizer
+
+You locate the review findings files using the provided paths, then read them, deduplicate and group findings, normalize into tasks, and write a staging file for user approval.
+
+## Your Input
+
+You receive via the orchestrator's prompt:
+
+1. **Plan topic** — the plan being synthesized
+2. **Review path** — path to `r{N}/` directory containing review summary and QA files
+3. **Specification path** — the validated specification for context
+4. **Cycle number** — which review remediation cycle this is
+
+## Your Process
+
+1. **Read review summary** — extract verdict, required changes, recommendations from `review.md`
+2. **Read all QA files** — read every `qa-task-*.md` in the review path. Extract BLOCKING ISSUES and significant NON-BLOCKING NOTES with their file:line references
+3. **Deduplicate** — same issue found across multiple QA files → one finding, note all sources
+4. **Group related findings** — multiple findings about the same concern become one task (e.g., 3 QA findings about missing error handling in the same module = 1 "add error handling" task)
+5. **Filter** — discard low-severity non-blocking findings unless they cluster into a pattern. Never discard high-severity or blocking findings.
+6. **Normalize** — convert each group into a task using the canonical task template (Problem / Solution / Outcome / Do / Acceptance Criteria / Tests)
+7. **Write report** — output to `docs/workflow/implementation/{topic}/review-report-c{cycle}.md`
+8. **Write staging file** — if actionable tasks exist, write to `docs/workflow/implementation/{topic}/review-tasks-c{cycle}.md` with `status: pending` for each task
+
+## Report Format
+
+Write the report file with this structure:
+
+```markdown
+---
+scope: {scope description}
+cycle: {N}
+source: review
+total_findings: {N}
+deduplicated_findings: {N}
+proposed_tasks: {N}
+---
+# Review Report: {Scope} (Cycle {N})
+
+## Summary
+{2-3 sentence overview of findings}
+
+## Discarded Findings
+- {title} — {reason for discarding}
+```
+
+## Staging File Format
+
+Write the staging file with this structure:
+
+```markdown
+---
+scope: {scope description}
+cycle: {N}
+source: review
+total_proposed: {N}
+gate_mode: gated
+---
+# Review Tasks: {Scope} (Cycle {N})
+
+## Task 1: {title}
+status: pending
+severity: high
+sources: qa-task-3, qa-task-7
+
+**Problem**: {what the review found}
+**Solution**: {what to fix}
+**Outcome**: {what success looks like}
+**Do**: {step-by-step implementation instructions}
+**Acceptance Criteria**:
+- {criterion}
+**Tests**:
+- {test description}
+
+## Task 2: {title}
+status: pending
+...
+```
+
+## Hard Rules
+
+**MANDATORY. No exceptions.**
+
+1. **No new features** — only address issues found in the review. Every proposed task must trace back to a specific review finding.
+2. **Never discard blocking** — blocking issues from QA always become proposed tasks.
+3. **Self-contained tasks** — every proposed task must be independently executable. No task should depend on another proposed task.
+4. **Faithful synthesis** — do not invent findings. Every proposed task must trace back to at least one QA finding.
+5. **No git writes** — do not commit or stage. Writing the report and staging files are your only file writes.
+
+## Your Output
+
+Return a brief status to the orchestrator:
+
+```
+STATUS: tasks_proposed | clean
+TASKS_PROPOSED: {N}
+SUMMARY: {1-2 sentences}
+```
+
+- `tasks_proposed`: tasks written to staging file — orchestrator should present for approval
+- `clean`: no actionable findings — orchestrator should report clean result

package/agents/review-task-verifier.md

@@ -17,8 +17,9 @@ You receive:
 3. **Plan path**: The full plan for additional context
 4. **Project skill paths**: Relevant `.claude/skills/` paths for framework conventions
 5. **Review checklist path**: Path to the review checklist (`skills/technical-review/references/review-checklist.md`) — read this for detailed verification criteria
-6. **Topic name**: The plan topic (used for output file path)
-7. **Task index**: Sequential number for this task (used for output file naming)
+6. **Topic**: The plan topic name (used for output directory)
+7. **Review number**: Version number (e.g., 1 for `r1/`)
+8. **Task index**: Sequential number for this task (used for output file naming)
 
 ## Your Task
 
@@ -86,7 +87,7 @@ Review the implementation as a senior architect would:
 
 ## Output File Format
 
-Write to `docs/workflow/review/{topic}/qa-task-{index}.md`:
+Write to `docs/workflow/review/{topic}/r{N}/qa-task-{index}.md`:
 
 ```
 TASK: [Task name/description]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leeovery/claude-technical-workflows",
-  "version": "2.1.33",
+  "version": "2.1.35",
   "description": "Technical workflow skills & commands for Claude Code",
   "license": "MIT",
   "author": "Lee Overy <me@leeovery.com>",

package/skills/begin-implementation/SKILL.md

@@ -25,12 +25,16 @@ This skill is a **bridge** — it runs pre-flight checks for implementation and
 
 ## Step 1: Run Discovery
 
-Execute the start-implementation discovery script to gather current state:
+!`.claude/skills/start-implementation/scripts/discovery.sh`
+
+If the above shows a script invocation rather than YAML output, the dynamic content preprocessor did not run. Execute the script before continuing:
 
 ```bash
 .claude/skills/start-implementation/scripts/discovery.sh
 ```
 
+If YAML content is already displayed, it has been run on your behalf.
+
 Parse the output to find the plan matching the provided topic. Extract:
 
 - **Plan details**: status, format, plan_id, specification, specification_exists

package/skills/begin-planning/SKILL.md

@@ -25,12 +25,16 @@ This skill is a **bridge** — it runs pre-flight checks for planning and hands
 
 ## Step 1: Run Discovery
 
-Execute the start-planning discovery script to gather current state:
+!`.claude/skills/start-planning/scripts/discovery.sh`
+
+If the above shows a script invocation rather than YAML output, the dynamic content preprocessor did not run. Execute the script before continuing:
 
 ```bash
 .claude/skills/start-planning/scripts/discovery.sh
 ```
 
+If YAML content is already displayed, it has been run on your behalf.
+
 Parse the output to extract:
 
 - **Cross-cutting specifications** from `specifications.crosscutting` (name, status)

package/skills/migrate/SKILL.md

@@ -39,6 +39,7 @@ Return control silently - no user interaction needed.
 ## Notes
 
 - This skill is run automatically at the start of every workflow skill
-- Migrations are tracked in `docs/workflow/.cache/migrations.log`
+- Migrations are tracked in `docs/workflow/.state/migrations` (one migration ID per line)
+- The orchestrator skips entire migrations once recorded — individual scripts don't track
 - To force re-running all migrations, delete the tracking file
 - Each migration is idempotent - safe to run multiple times

package/skills/migrate/scripts/migrate.sh

@@ -9,54 +9,43 @@
 #   ./scripts/migrate.sh
 #
 # Tracking:
-#   Migrations are tracked in docs/workflow/.cache/migrations.log
-#   Format: "filepath: migration_id" (one per line, append-only)
+#   Migrations are tracked in docs/workflow/.state/migrations
+#   Format: "migration_id" per line (e.g., "001", "002")
+#   The orchestrator checks/records migration IDs — individual scripts don't track.
 #   Delete the log file to force re-running all migrations.
 #
 # Adding new migrations:
 #   1. Create scripts/migrations/NNN-description.sh (e.g., 002-spec-frontmatter.sh)
 #   2. The script will be run automatically in numeric order
-#   3. Each migration script receives helper functions via source
+#   3. Each migration script receives helper functions via source: report_update, report_skip
 #
 
 set -eo pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 MIGRATIONS_DIR="$SCRIPT_DIR/migrations"
-TRACKING_FILE="docs/workflow/.cache/migrations.log"
+TRACKING_FILE="docs/workflow/.state/migrations"
 
 # Track counts for final report
 FILES_UPDATED=0
 FILES_SKIPPED=0
 MIGRATIONS_RUN=0
 
-# Ensure cache directory exists
+# Ensure state directory exists
 mkdir -p "$(dirname "$TRACKING_FILE")"
 
+# Self-healing: merge entries from old locations into .state/migrations
+OLD_CACHE_LOG="docs/workflow/.cache/migrations.log"
+OLD_CACHE_FILE="docs/workflow/.cache/migrations"
+if [ -f "$OLD_CACHE_LOG" ] || [ -f "$OLD_CACHE_FILE" ]; then
+    { cat "$OLD_CACHE_LOG" 2>/dev/null; cat "$OLD_CACHE_FILE" 2>/dev/null; cat "$TRACKING_FILE" 2>/dev/null; } | sort -u > "${TRACKING_FILE}.tmp"
+    mv "${TRACKING_FILE}.tmp" "$TRACKING_FILE"
+    rm -f "$OLD_CACHE_LOG" "$OLD_CACHE_FILE"
+fi
+
 # Touch tracking file if it doesn't exist
 touch "$TRACKING_FILE"
 
-#
-# Helper function: Check if a migration has been applied to a file
-# Usage: is_migrated "filepath" "migration_id"
-# Returns: 0 if migrated, 1 if not
-#
-is_migrated() {
-    local filepath="$1"
-    local migration_id="$2"
-    grep -q "^${filepath}: ${migration_id}$" "$TRACKING_FILE" 2>/dev/null
-}
-
-#
-# Helper function: Record that a migration was applied to a file
-# Usage: record_migration "filepath" "migration_id"
-#
-record_migration() {
-    local filepath="$1"
-    local migration_id="$2"
-    echo "${filepath}: ${migration_id}" >> "$TRACKING_FILE"
-}
-
 #
 # Helper function: Report a file update (for migration scripts to call)
 # Usage: report_update "filepath" "description"
@@ -78,7 +67,7 @@ report_skip() {
 }
 
 # Export functions and variables for migration scripts
-export -f is_migrated record_migration report_update report_skip
+export -f report_update report_skip
 export TRACKING_FILE FILES_UPDATED FILES_SKIPPED
 
 #
@@ -99,6 +88,14 @@ if [ ${#MIGRATION_SCRIPTS[@]} -eq 0 ]; then
     exit 0
 fi
 
+# One-time: convert old per-file format to per-migration format
+# Old: "docs/workflow/discussion/auth.md: 001" → extracts "001"
+# New: "001" → already correct
+if grep -q ': [0-9]' "$TRACKING_FILE" 2>/dev/null; then
+    grep -oE '[0-9]+$' "$TRACKING_FILE" | sort -u > "${TRACKING_FILE}.tmp"
+    mv "${TRACKING_FILE}.tmp" "$TRACKING_FILE"
+fi
+
 for script in "${MIGRATION_SCRIPTS[@]}"; do
     # Extract migration ID from filename (e.g., "001" from "001-discussion-frontmatter.sh")
     migration_id=$(basename "$script" .sh | grep -oE '^[0-9]+')
@@ -108,11 +105,17 @@ for script in "${MIGRATION_SCRIPTS[@]}"; do
         continue
     fi
 
+    # Global check — skip entire migration if already recorded
+    if grep -q "^${migration_id}$" "$TRACKING_FILE" 2>/dev/null; then
+        continue
+    fi
+
     # Source and run the migration script
-    # The script has access to: is_migrated, record_migration, report_update, report_skip
+    # The script has access to: report_update, report_skip
     # shellcheck source=/dev/null
     source "$script"
 
+    echo "$migration_id" >> "$TRACKING_FILE"
     MIGRATIONS_RUN=$((MIGRATIONS_RUN + 1))
 done
 

package/skills/migrate/scripts/migrations/001-discussion-frontmatter.sh

@@ -24,9 +24,7 @@
 #   Exploring, Deciding → in-progress
 #   Concluded, Complete, ✅ Complete → concluded
 #
-# This script is sourced by migrate-documents.sh and has access to:
-#   - is_migrated "filepath" "migration_id"
-#   - record_migration "filepath" "migration_id"
+# This script is sourced by migrate.sh and has access to:
 #   - report_update "filepath" "description"
 #   - report_skip "filepath"
 #
@@ -43,24 +41,14 @@ fi
 for file in "$DISCUSSION_DIR"/*.md; do
     [ -f "$file" ] || continue
 
-    # Check if already migrated via tracking
-    if is_migrated "$file" "$MIGRATION_ID"; then
-        report_skip "$file"
-        continue
-    fi
-
     # Check if file already has YAML frontmatter
     if head -1 "$file" 2>/dev/null | grep -q "^---$"; then
-        # Already has frontmatter - just record and skip
-        record_migration "$file" "$MIGRATION_ID"
         report_skip "$file"
         continue
     fi
 
     # Check if file has legacy format (look for **Status**: or **Status:** or **Date**: or **Started:**)
     if ! grep -q '^\*\*Status\*\*:\|^\*\*Status:\*\*\|^\*\*Date\*\*:\|^\*\*Started:\*\*' "$file" 2>/dev/null; then
-        # No legacy format found - might be malformed, skip
-        record_migration "$file" "$MIGRATION_ID"
         report_skip "$file"
         continue
     fi
@@ -134,7 +122,5 @@ date: $date_value
         echo "$content"
     } > "$file"
 
-    # Record and report
-    record_migration "$file" "$MIGRATION_ID"
     report_update "$file" "added frontmatter"
 done

package/skills/migrate/scripts/migrations/002-specification-frontmatter.sh

@@ -34,8 +34,6 @@
 #   (not found or unrecognized) → empty (requires manual review)
 #
 # This script is sourced by migrate.sh and has access to:
-#   - is_migrated "filepath" "migration_id"
-#   - record_migration "filepath" "migration_id"
 #   - report_update "filepath" "description"
 #   - report_skip "filepath"
 #
@@ -57,24 +55,14 @@ for file in "$SPEC_DIR"/*.md; do
         *-review-*|*-tracking*) continue ;;
     esac
 
-    # Check if already migrated via tracking
-    if is_migrated "$file" "$MIGRATION_ID"; then
-        report_skip "$file"
-        continue
-    fi
-
     # Check if file already has YAML frontmatter
     if head -1 "$file" 2>/dev/null | grep -q "^---$"; then
-        # Already has frontmatter - just record and skip
-        record_migration "$file" "$MIGRATION_ID"
         report_skip "$file"
         continue
     fi
 
     # Check if file has legacy format (look for **Status**: or **Status:** or **Type**: or **Last Updated**:)
     if ! grep -q '^\*\*Status\*\*:\|^\*\*Status:\*\*\|^\*\*Type\*\*:\|^\*\*Last Updated\*\*:' "$file" 2>/dev/null; then
-        # No legacy format found - might be malformed, skip
-        record_migration "$file" "$MIGRATION_ID"
         report_skip "$file"
         continue
     fi
@@ -206,7 +194,5 @@ date: $date_value
         echo "$content"
     } > "$file"
 
-    # Record and report
-    record_migration "$file" "$MIGRATION_ID"
     report_update "$file" "added frontmatter (status: $status_new, type: $type_new)"
 done

package/skills/migrate/scripts/migrations/003-planning-frontmatter.sh

@@ -32,8 +32,6 @@
 #   Completed, Done → concluded
 #
 # This script is sourced by migrate.sh and has access to:
-#   - is_migrated "filepath" "migration_id"
-#   - record_migration "filepath" "migration_id"
 #   - report_update "filepath" "description"
 #   - report_skip "filepath"
 #
@@ -55,16 +53,8 @@ for file in "$PLAN_DIR"/*.md; do
         *-review-*|*-tracking*) continue ;;
     esac
 
-    # Check if already migrated via tracking
-    if is_migrated "$file" "$MIGRATION_ID"; then
-        report_skip "$file"
-        continue
-    fi
-
     # Check if file already has full frontmatter (topic field present)
     if head -10 "$file" 2>/dev/null | grep -q "^topic:"; then
-        # Already has full frontmatter - just record and skip
-        record_migration "$file" "$MIGRATION_ID"
         report_skip "$file"
         continue
     fi
@@ -75,8 +65,6 @@ for file in "$PLAN_DIR"/*.md; do
     has_inline_metadata=$(grep -c '^\*\*Date\*\*:\|^\*\*Status\*\*:\|^\*\*Specification\*\*:' "$file" 2>/dev/null || true)
 
     if [ "${has_partial_frontmatter:-0}" = "0" ] && [ "${has_inline_metadata:-0}" = "0" ]; then
-        # No legacy format found - might be malformed, skip
-        record_migration "$file" "$MIGRATION_ID"
         report_skip "$file"
         continue
     fi
@@ -192,7 +180,5 @@ specification: $spec_value
         echo "$content"
     } > "$file"
 
-    # Record and report
-    record_migration "$file" "$MIGRATION_ID"
     report_update "$file" "added full frontmatter (status: $status_new, format: $format_value)"
 done

package/skills/migrate/scripts/migrations/004-sources-object-format.sh

@@ -29,8 +29,6 @@
 #   - If no matching discussion, add empty sources: [] and report for user review
 #
 # This script is sourced by migrate.sh and has access to:
-#   - is_migrated "filepath" "migration_id"
-#   - record_migration "filepath" "migration_id"
 #   - report_update "filepath" "description"
 #   - report_skip "filepath"
 #
@@ -92,15 +90,8 @@ for file in "$SPEC_DIR"/*.md; do
         *-review-*|*-tracking*) continue ;;
     esac
 
-    # Check if already migrated via tracking
-    if is_migrated "$file" "$MIGRATION_ID"; then
-        report_skip "$file"
-        continue
-    fi
-
     # Check if file has YAML frontmatter
     if ! head -1 "$file" 2>/dev/null | grep -q "^---$"; then
-        record_migration "$file" "$MIGRATION_ID"
         report_skip "$file"
         continue
     fi
@@ -113,7 +104,6 @@ for file in "$SPEC_DIR"/*.md; do
 
     # If sources field exists, check if already in object format
     if $has_sources_field && sources_already_object_format "$file"; then
-        record_migration "$file" "$MIGRATION_ID"
         report_skip "$file"
         continue
     fi
@@ -196,8 +186,6 @@ ${new_sources_block}"
         echo "$content"
     } > "$file"
 
-    record_migration "$file" "$MIGRATION_ID"
-
     # Report appropriate message based on what was done
     if $has_sources_field; then
         report_update "$file" "converted sources to object format"