@leeovery/claude-technical-workflows 2.1.38 → 2.1.39

package/package.json

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

package/skills/start-feature/SKILL.md

@@ -80,7 +80,10 @@ This will create: docs/workflow/discussion/{suggested-topic}.md
 
 ```
 · · · · · · · · · · · ·
-Is this name okay, or would you prefer something else?
+Is this name okay?
+
+- **`y`/`yes`** — Use this name
+- **`s`/`something else`** — Suggest a different name
 · · · · · · · · · · · ·
 ```
 

package/skills/technical-implementation/SKILL.md

@@ -332,20 +332,4 @@ Update the tracking file (`docs/workflow/implementation/{topic}/tracking.md`):
 
 Commit: `impl({topic}): complete implementation`
 
----
-
-## References
-
-- **[environment-setup.md](references/environment-setup.md)** — Environment setup before implementation
-- **[linter-setup.md](references/linter-setup.md)** — Linter discovery and configuration
-- **[task-loop.md](references/task-loop.md)** — Task execution loop, task gates, tracking, commits
-- **[analysis-loop.md](references/analysis-loop.md)** — Analysis and refinement cycle
-- **[invoke-executor.md](references/invoke-executor.md)** — How to invoke the executor agent
-- **[invoke-reviewer.md](references/invoke-reviewer.md)** — How to invoke the reviewer agent
-- **[invoke-analysis.md](references/invoke-analysis.md)** — How to invoke analysis agents
-- **[invoke-synthesizer.md](references/invoke-synthesizer.md)** — How to invoke the synthesis agent
-- **[invoke-task-writer.md](references/invoke-task-writer.md)** — How to invoke the task writer agent
-- **[task-normalisation.md](references/task-normalisation.md)** — Normalised task shape for agent invocation
-- **[tdd-workflow.md](references/tdd-workflow.md)** — TDD cycle (passed to executor agent)
-- **[code-quality.md](references/code-quality.md)** — Quality standards (passed to executor agent)
 

package/skills/technical-specification/SKILL.md

@@ -72,7 +72,7 @@ additional material I should review?
 Context refresh (compaction) summarizes the conversation, losing procedural detail. When you detect a context refresh has occurred — the conversation feels abruptly shorter, you lack memory of recent steps, or a summary precedes this message — follow this recovery protocol:
 
 1. **Re-read this skill file completely.** Do not rely on your summary of it. The full process, steps, and rules must be reloaded.
-2. **Read all tracking and state files** for the current topic — plan index files, review tracking files, implementation tracking files, or any working documents this skill creates. These are your source of truth for progress.
+2. **Read all tracking and state files** for the current topic — the specification file, review tracking files, or any working documents this skill creates. These are your source of truth for progress.
 3. **Check git state.** Run `git status` and `git log --oneline -10` to see recent commits. Commit messages follow a conventional pattern that reveals what was completed.
 4. **Announce your position** to the user before continuing: what step you believe you're at, what's been completed, and what comes next. Wait for confirmation.
 5. **Check `finding_gate_mode`** in the specification frontmatter — if `auto`, the user previously opted in during this session. Preserve this value.
@@ -81,88 +81,120 @@ Do not guess at progress or continue from memory. The files on disk and git hist
 
 ---
 
-## The Process
+## Hard Rules
 
-**Load**: [specification-guide.md](references/specification-guide.md)
+1. **STOP AND WAIT** for explicit approval before any write to the specification. Present content, wait for the user to explicitly approve (`y`/`yes` or equivalent), then log. No exceptions.
+2. **Log verbatim** — when approved, write exactly what was presented. No silent modifications.
+3. **Commit frequently** — commit at natural breaks and before any context refresh. Context refresh = lost work.
 
-**Output**: `docs/workflow/specification/{topic}/specification.md`
+---
+
+## Output Formatting
+
+When announcing a new step, output `── ── ── ── ──` on its own line before the step heading.
+
+---
+
+## Step 0: Resume Detection
+
+Check if `docs/workflow/specification/{topic}/specification.md` exists.
+
+#### If no file exists
+
+→ Proceed to **Step 1**.
+
+#### If file exists
+
+Read the specification frontmatter.
+
+> *Output the next fenced block as markdown (not a code block):*
+
+```
+Found existing specification for **{topic}**.
 
-**When complete**: User signs off on the specification.
+· · · · · · · · · · · ·
+- **`c`/`continue`** — Walk through the specification from its current state. You can review, amend, or navigate at any point.
+- **`r`/`restart`** — Delete the specification and all review tracking files. Start fresh.
+· · · · · · · · · · · ·
+```
+
+**STOP.** Wait for user response.
 
-### Post-Completion: Handle Source Specifications
+#### If `continue`
 
-If any of your sources were **existing specifications** (as opposed to discussions, research, or other reference material), these have now been consolidated into the new specification.
+Reset `finding_gate_mode` to `gated` in the specification frontmatter (fresh invocation = fresh gates).
 
-After user signs off:
-1. Mark each source specification as superseded by updating its frontmatter:
-   ```yaml
-   status: superseded
-   superseded_by: {new-specification-name}
-   ```
-2. Inform the user which files were updated
+→ Skip Steps 1–2, proceed to **Step 3**.
 
-## CRITICAL: You Do NOT Create or Update the Specification Autonomously
+#### If `restart`
 
-**This is a collaborative, interactive process. You MUST wait for explicit user approval before writing ANYTHING to the specification file.**
+1. Delete the specification file and all review tracking files (`review-*-tracking-c*.md`) in the topic directory
+2. Commit: `spec({topic}): restart specification`
 
-❌ **NEVER:**
-- Create the specification document and then ask the user to review it
-- Write multiple sections and present them for review afterward
-- Assume silence or moving on means approval
-- Make "minor" amendments without explicit approval
-- Batch up content and log it all at once
+→ Proceed to **Step 1**.
 
-✅ **ALWAYS:**
-- Present ONE topic at a time
-- **STOP and WAIT** for the user to explicitly approve before writing
-- Treat each write operation as requiring its own explicit approval
+---
 
-**What counts as approval:** `y`/`yes` (the standard choice you present) or equivalent: "Approved", "Add it", "That's good".
+## Step 1: Verify Source Material
 
-**What does NOT count as approval:** Silence, you presenting choices, the user asking a follow-up question, the user saying "What's next?", or any response that isn't explicit confirmation.
+Load **[verify-source-material.md](references/verify-source-material.md)** and follow its instructions as written.
 
-If you are uncertain whether the user approved, **ASK**: "Ready to log it, or do you want to change something?"
+→ Proceed to **Step 2**.
 
 ---
 
-## What You Do
+## Step 2: Initialize Specification
+
+Load **[specification-format.md](references/specification-format.md)** for the template.
+
+Create the specification file at `docs/workflow/specification/{topic}/specification.md`:
+
+1. Use the frontmatter template from specification-format.md
+2. Set `topic` to the kebab-case topic name
+3. Set `status: in-progress`, `type: feature`, `review_cycle: 0`, `finding_gate_mode: gated`
+4. Set `date` to today's actual date
+5. Add all sources with `status: pending`
+6. Add the body template (title + specification section + working notes section)
 
-1. **Extract exhaustively**: For each topic, re-scan ALL source materials. When working with multiple sources, search each one - information about a single topic may be scattered across documents. Search for keywords and related terms. Collect everything before synthesizing. Include only what we're building (not discarded alternatives).
+Commit: `spec({topic}): initialize specification`
 
-2. **Filter**: Reference material may contain hallucinations, inaccuracies, or outdated concepts. Validate before including.
+→ Proceed to **Step 3**.
 
-3. **Enrich**: Reference material may have gaps. Fill them through discussion.
+---
 
-4. **Present**: Synthesize and present content to the user in the format it would appear in the specification.
+## Step 3: Load Specification Principles
 
-5. **STOP AND WAIT**: Do not proceed until the user explicitly approves. This is not optional.
+Load **[specification-principles.md](references/specification-principles.md)** and internalize the rules. These principles govern every subsequent step.
 
-6. **Log**: Only after explicit approval, write content verbatim to the specification.
+→ Proceed to **Step 4**.
 
-7. **Final review**: After all topics and dependencies are documented, perform a comprehensive review of ALL source material against the specification. Flag any potentially missed content to the user - but only from the sources, never fabricated. User confirms before any additions.
+---
 
-The specification is the **golden document** - planning uses only this. If information doesn't make it into the specification, it won't be built. No references back to source material.
+## Step 4: Spec Construction
 
-## Critical Rules
+Load **[spec-construction.md](references/spec-construction.md)** and follow its instructions as written.
 
-**STOP AND WAIT FOR APPROVAL**: You MUST NOT write to the specification until the user has explicitly approved. Presenting content is NOT approval. Presenting choices is NOT approval. You must receive explicit confirmation (e.g., `y`/`yes`) before ANY write operation. If uncertain, ASK.
+→ Proceed to **Step 5**.
 
-**Log verbatim**: When approved, write exactly what was presented - no silent modifications.
+---
 
-**Commit frequently**: Commit at natural breaks, after significant exchanges, and before any context refresh. Context refresh = lost work.
+## Step 5: Document Dependencies
 
-**Trust nothing without validation**: Synthesize and present, but never assume source material is correct.
+Load **[dependencies.md](references/dependencies.md)** and follow its instructions as written.
 
-**Surface conflicts**: When sources contain conflicting decisions, flag the conflict to the user during the discussion. Don't silently pick one - let the user decide what makes it into the specification.
+→ Proceed to **Step 6**.
 
 ---
 
-## Self-Check: Are You Following the Rules?
+## Step 6: Specification Review
+
+Load **[spec-review.md](references/spec-review.md)** and follow its instructions as written.
+
+→ Proceed to **Step 7**.
+
+---
 
-Before ANY write operation to the specification, ask yourself:
+## Step 7: Conclude Specification
 
-1. **Did I present this specific content to the user?** If no → STOP. Present it first.
-2. **Did the user explicitly approve it?** (Not "did I ask if it's good" - did THEY say yes?) If no → STOP. Wait for approval.
-3. **Am I writing exactly what was approved?** If adding/changing anything → STOP. Present the changes first.
+Load **[spec-completion.md](references/spec-completion.md)** and follow its instructions as written.
 
-> **If you have written to the specification file without going through steps 1-2-3 above, you have violated the workflow.** The user must approve every piece of content before it's logged. There are no exceptions.

package/skills/technical-specification/references/dependencies.md

@@ -0,0 +1,77 @@
+# Dependencies
+
+*Reference for **[technical-specification](../SKILL.md)***
+
+---
+
+At the end of every specification, add a **Dependencies** section that identifies **prerequisites** — systems that must exist before this feature can be built.
+
+The same workflow applies: present the dependencies section for approval, then log verbatim when approved.
+
+## What Dependencies Are
+
+Dependencies are **blockers** — things that must exist before implementation can begin.
+
+Think of it like building a house: if you're specifying the roof, the walls are a dependency. You cannot build a roof without walls to support it. The walls must exist first.
+
+**The test**: "If system X doesn't exist, can we still build this feature?"
+- If **no** → X is a dependency
+- If **yes** → X is not a dependency (even if the systems work together)
+
+## What Dependencies Are NOT
+
+**Do not list systems just because they:**
+- Work together with this feature
+- Share data or communicate with this feature
+- Are related or in the same domain
+- Would be nice to have alongside this feature
+
+Two systems that cooperate are not necessarily dependent. A notification system and a user preferences system might work together (preferences control notification settings), but if you can build the notification system with hardcoded defaults and add preference integration later, then preferences are not a dependency.
+
+## How to Identify Dependencies
+
+Review the specification for cases where implementation is **literally blocked** without another system:
+
+- **Data that must exist first** (e.g., "FK to users" → User model must exist, you can't create the FK otherwise)
+- **Events you consume** (e.g., "listens for payment.completed" → Payment system must emit this event)
+- **APIs you call** (e.g., "fetches inventory levels" → Inventory API must exist)
+- **Infrastructure requirements** (e.g., "stores files in S3" → S3 bucket configuration must exist)
+
+**Do not include** systems where you merely reference their concepts or where integration could be deferred.
+
+## Categorization
+
+**Required**: Implementation cannot start without this. The code literally cannot be written.
+
+**Partial Requirement**: Only specific elements are needed, not the full system. Note the minimum scope that unblocks implementation.
+
+## Format
+
+```markdown
+## Dependencies
+
+Prerequisites that must exist before implementation can begin:
+
+### Required
+
+| Dependency | Why Blocked | What's Unblocked When It Exists |
+|------------|-------------|--------------------------------|
+| **[System Name]** | [Why implementation literally cannot proceed] | [What parts of this spec can then be built] |
+
+### Partial Requirement
+
+| Dependency | Why Blocked | Minimum Scope Needed |
+|------------|-------------|---------------------|
+| **[System Name]** | [Why implementation cannot proceed] | [Specific subset that unblocks us] |
+
+### Notes
+
+- [What can be built independently, without waiting]
+- [Workarounds if dependencies don't exist yet]
+```
+
+## Purpose
+
+This section feeds into the planning phase, where dependencies become blocking relationships between epics/phases. It helps sequence implementation correctly.
+
+**Key distinction**: This is about sequencing what must come first, not mapping out what works together. A feature may integrate with many systems — only list the ones that block you from starting.

package/skills/technical-specification/references/exhaustive-extraction.md

@@ -0,0 +1,29 @@
+# Exhaustive Extraction
+
+*Reference for **[spec-construction](spec-construction.md)***
+
+---
+
+**This step is critical. The specification is the golden document — if information doesn't make it here, it won't be built.**
+
+For each topic or subtopic, perform exhaustive extraction:
+
+1. **Re-scan ALL source material** — Don't rely on memory. Go back to the source material and systematically review it for the current topic.
+
+2. **Search for keywords** — Topics are rarely contained in one section. Search for:
+   - The topic name and synonyms
+   - Related concepts and terms
+   - Names of systems, fields, or behaviors mentioned in context
+
+3. **Collect scattered information** — Source material is often non-linear. Information about a single topic may be scattered across:
+   - Multiple sections of the same document
+   - Different documents entirely
+   - Tangential discussions that revealed important details
+
+4. **Filter for what we're building** — Include only validated decisions:
+   - Exclude discarded alternatives
+   - Exclude ideas that were explored but rejected
+   - Exclude "maybes" that weren't confirmed
+   - Include only what the user has decided to build
+
+**Why this matters:** The specification is the single source of truth for planning. Planning will not reference prior source material — only this document. Missing a detail here means that detail doesn't get implemented.

package/skills/technical-specification/references/process-review-findings.md

@@ -0,0 +1,170 @@
+# Process Review Findings
+
+*Reference for **[spec-review](spec-review.md)***
+
+---
+
+Process findings from a review phase interactively with the user. The analysis phase writes findings to a tracking file. Read the tracking file and present each finding for approval.
+
+**Review type**: `{review_type:[Input Review|Gap Analysis]}` — set by the calling context (B or C in spec-review.md).
+
+Check if the tracking file exists at the expected path.
+
+#### If no tracking file exists (no findings)
+
+> *Output the next fenced block as a code block:*
+
+```
+{review_type} complete — no findings.
+```
+
+→ Return to **[spec-review.md](spec-review.md)** for the next phase.
+
+#### If tracking file exists
+
+Read the tracking file and count pending findings.
+
+→ Proceed to **A. Summary**.
+
+---
+
+## A. Summary
+
+> *Output the next fenced block as a code block:*
+
+```
+{review_type} — {N} items found
+
+1. {title} ({category})
+   {1-2 line summary from the Details field}
+
+2. ...
+```
+
+> *Output the next fenced block as a code block:*
+
+```
+Let's work through these one at a time, starting with #1.
+```
+
+→ Proceed to **B. Process One Item at a Time**.
+
+---
+
+## B. Process One Item at a Time
+
+Work through each finding **sequentially**. For each finding: present it, show the proposed content, then route through the gate.
+
+### Present Finding
+
+Show the finding with its proposed content, read directly from the tracking file.
+
+> *Output the next fenced block as markdown (not a code block):*
+
+```
+**Finding {N} of {total}: {brief_title:(titlecase)}**
+
+- **Source**: {from tracking file}
+- **Category**: {from tracking file}
+@if(review_type = Gap Analysis)
+- **Priority**: Critical | Important | Minor
+@endif
+- **Affects**: {from tracking file}
+
+**Details**: {from tracking file}
+
+**Proposed Addition**:
+{from tracking file — the content to add to the specification}
+```
+
+**For potential gaps** (items not directly from source material): you're asking questions rather than proposing content. If the user wants to address a gap, discuss it, then present what you'd add for approval.
+
+### Check Gate Mode
+
+Check `finding_gate_mode` in the specification frontmatter.
+
+#### If `finding_gate_mode: auto`
+
+1. Log the proposed content to the specification verbatim
+2. Update the tracking file: set resolution to "Approved"
+3. Commit
+
+> *Output the next fenced block as a code block:*
+
+```
+Finding {N} of {total}: {brief_title:(titlecase)} — approved. Added to specification.
+```
+
+→ Present the next pending finding, or proceed to **C. After All Findings Processed**.
+
+#### If `finding_gate_mode: gated`
+
+> *Output the next fenced block as markdown (not a code block):*
+
+```
+· · · · · · · · · · · ·
+**Finding {N} of {total}: {brief_title:(titlecase)}**
+- **`y`/`yes`** — Approved. Add to the specification verbatim.
+- **`a`/`auto`** — Approve this and all remaining findings automatically
+- **`s`/`skip`** — Leave as-is, move to next finding.
+- **Or provide feedback** to adjust.
+· · · · · · · · · · · ·
+```
+
+**STOP.** Wait for user response.
+
+#### If the user provides feedback
+
+Incorporate feedback and re-present the proposed content **in full**. Update the tracking file with the revised content. Then ask the same choice again. Repeat until approved or skipped.
+
+#### If approved
+
+1. Log the content to the specification verbatim
+2. Update the tracking file: set resolution to "Approved", add any discussion notes
+3. Commit — ensures progress survives context refresh
+
+> *Output the next fenced block as a code block:*
+
+```
+Finding {N} of {total}: {brief_title:(titlecase)} — added.
+```
+
+→ Present the next pending finding, or proceed to **C. After All Findings Processed**.
+
+#### If `auto`
+
+1. Log the content (same as "If approved" above)
+2. Update the tracking file: set resolution to "Approved"
+3. Update `finding_gate_mode: auto` in the specification frontmatter
+4. Commit
+5. Process all remaining findings using the auto-mode flow above
+
+→ After all processed, proceed to **C. After All Findings Processed**.
+
+#### If skipped
+
+1. Update the tracking file: set resolution to "Skipped", note the reason
+2. Commit — ensures progress survives context refresh
+
+> *Output the next fenced block as a code block:*
+
+```
+Finding {N} of {total}: {brief_title:(titlecase)} — skipped.
+```
+
+→ Present the next pending finding, or proceed to **C. After All Findings Processed**.
+
+---
+
+## C. After All Findings Processed
+
+1. **Mark the tracking file as complete** — Set `status: complete`.
+2. **Commit** the tracking file and any specification changes.
+
+> *Output the next fenced block as a code block:*
+
+```
+{review_type} complete — {N} findings processed.
+```
+
+→ Return to **[spec-review.md](spec-review.md)** for the next phase.

package/skills/technical-specification/references/review-gap-analysis.md

@@ -0,0 +1,84 @@
+# Gap Analysis
+
+*Reference for **[spec-review](spec-review.md)***
+
+---
+
+Phase 2 reviews the **specification as a standalone document** — looking *inward* at what's been specified, not outward at what else the product might need.
+
+**Purpose**: Ensure that *within the defined scope*, the specification flows correctly, has sufficient detail, and leaves nothing open to interpretation or assumption. This might be a full product spec or a single feature — the scope is whatever the inputs defined. Your job is to verify that within those boundaries, an agent or human could create plans, break them into tasks, and write code without having to guess.
+
+**Key distinction**: You're not asking "what features are missing from this product?" You're asking "within what we've decided to build, is everything clear and complete?"
+
+## What to Look For
+
+Review the specification systematically for gaps *within what's specified*:
+
+1. **Internal Completeness**
+   - Workflows that start but don't show how they end
+   - States or transitions mentioned but not fully defined
+   - Behaviors referenced elsewhere but never specified
+   - Default values or fallback behaviors left unstated
+
+2. **Insufficient Detail**
+   - Areas where an implementer would have to guess
+   - Sections that are too high-level to act on
+   - Missing error handling for scenarios the spec introduces
+   - Validation rules implied but not defined
+   - Boundary conditions for limits the spec mentions
+
+3. **Ambiguity**
+   - Vague language that could be interpreted multiple ways
+   - Terms used inconsistently across sections
+   - "It should" without defining what "it" is
+   - Implicit assumptions that aren't stated
+
+4. **Contradictions**
+   - Requirements that conflict with each other
+   - Behaviors defined differently in different sections
+   - Constraints that make other requirements impossible
+
+5. **Edge Cases Within Scope**
+   - For the behaviors specified, what happens at boundaries?
+   - For the inputs defined, what happens when they're empty or malformed?
+   - For the integrations described, what happens when they're unavailable?
+
+6. **Planning Readiness**
+   - Could you break this into clear tasks?
+   - Would an implementer know what to build?
+   - Are acceptance criteria implicit or explicit?
+   - Are there sections that would force an implementer to make design decisions?
+
+## The Review Process
+
+1. **Read the specification end-to-end** — Not scanning, but carefully reading as if you were about to implement it
+
+2. **For each section, ask**:
+   - Is this internally complete? Does it define everything it references?
+   - Is this clear? Would an implementer know exactly what to build?
+   - Is this consistent? Does it contradict anything else in the spec?
+   - Are there areas left open to interpretation or assumption?
+
+3. **Collect findings** — Note each gap, ambiguity, or area needing clarification
+
+4. **Prioritize** — Focus on issues that would block or confuse implementation:
+   - **Critical**: Would prevent implementation or cause incorrect behavior
+   - **Important**: Would require implementer to guess or make design decisions
+   - **Minor**: Polish or clarification that improves understanding
+
+5. **Create the tracking file** — If findings exist, write them to `review-gap-analysis-tracking-c{N}.md` using the format from **[review-tracking-format.md](review-tracking-format.md)**. Commit the tracking file.
+
+## What You're NOT Doing in Phase 2
+
+- **Not expanding scope** — Looking for gaps *within* what's specified, not suggesting features the product should have. A feature spec for "user login" doesn't need you to ask about password reset if it wasn't in scope.
+- **Not gold-plating** — Only flag gaps that would actually impact implementation of what's specified
+- **Not second-guessing decisions** — The spec reflects validated decisions; you're checking for clarity and completeness, not re-opening debates
+- **Not being exhaustive for its own sake** — Focus on what matters for implementing *this* specification
+
+## Completing Phase 2
+
+When you've:
+- Reviewed the specification for completeness, clarity, and implementation readiness
+- Created the tracking file (if findings exist) and committed it
+
+→ Return to **[spec-review.md](spec-review.md)** for finding processing.

package/skills/technical-specification/references/review-input.md

@@ -0,0 +1,57 @@
+# Input Review
+
+*Reference for **[spec-review](spec-review.md)***
+
+---
+
+Phase 1 compares the specification against all source material to catch anything missed.
+
+## The Review Process
+
+1. **Re-read ALL source material** — Go back to every source document, discussion, research note, and reference. Don't rely on memory.
+
+2. **Compare systematically** — For each piece of source material:
+   - What topics does it cover?
+   - Are those topics fully captured in the specification?
+   - Are there details, edge cases, or decisions that didn't make it?
+
+3. **Search for the forgotten** — Look specifically for:
+   - Edge cases mentioned in passing
+   - Constraints or requirements buried in tangential discussions
+   - Technical details that seemed minor at the time
+   - Decisions made early that may have been overshadowed
+   - Error handling, validation rules, or boundary conditions
+   - Integration points or data flows mentioned but not elaborated
+
+4. **Collect what you find** — Note each finding for your summary. Categorize:
+   - **Enhancing an existing topic** — Details that belong in an already-documented section. Note which section it would enhance.
+   - **An entirely missed topic** — Something that warrants its own section but was glossed over. New topics get added at the end.
+
+5. **Never fabricate** — Every item you flag must trace back to specific source material. If you can't point to where it came from, don't suggest it. The goal is to catch missed content, not invent new requirements.
+
+6. **User confirms before inclusion** — Standard workflow applies: present proposed additions, get approval, then log verbatim.
+
+7. **Surface potential gaps** — After reviewing source material, consider whether the specification has gaps that the sources simply didn't address:
+   - Edge cases that weren't discussed
+   - Error scenarios not covered
+   - Integration points that seem implicit but aren't specified
+   - Behaviors that are ambiguous without clarification
+
+   Collect these alongside the missed content. This should be infrequent — most gaps will be caught from source material. But occasionally the sources themselves have blind spots worth surfacing.
+
+8. **Create the tracking file** — If findings exist, write them to `review-input-tracking-c{N}.md` using the format from **[review-tracking-format.md](review-tracking-format.md)**. Commit the tracking file.
+
+## What You're NOT Doing in Phase 1
+
+- **Not inventing requirements** — When surfacing gaps not in sources, you're asking questions, not proposing answers
+- **Not assuming gaps need filling** — If something isn't in the sources, it may have been intentionally omitted
+- **Not padding the spec** — Only add what's genuinely missing and relevant
+- **Not re-litigating decisions** — If something was discussed and rejected, it stays rejected
+
+## Completing Phase 1
+
+When you've:
+- Systematically reviewed all source material for missed content
+- Created the tracking file (if findings exist) and committed it
+
+→ Return to **[spec-review.md](spec-review.md)** for finding processing.