cc-dev-template 0.1.80 → 0.1.82

package/src/skills/spec-interview/references/step-3-ui-ux.md

@@ -1,83 +0,0 @@
-# Step 3: UI/UX Design
-
-If the feature has no user interface, skip to `references/step-4-deep-dive.md`.
-
-## Determine Design Direction
-
-Before any wireframes, establish the visual approach. Use AskUserQuestion to confirm:
-
-**Product context:**
-- What does this product need to feel like?
-- Who uses it? (Power users want density, occasional users want guidance)
-- What's the emotional job? (Trust, efficiency, delight, focus)
-
-**Design direction options:**
-- Precision & Density — tight spacing, monochrome, information-forward (Linear, Raycast)
-- Warmth & Approachability — generous spacing, soft shadows, friendly (Notion, Coda)
-- Sophistication & Trust — cool tones, layered depth, financial gravitas (Stripe, Mercury)
-- Boldness & Clarity — high contrast, dramatic negative space (Vercel)
-- Utility & Function — muted palette, functional density (GitHub)
-
-**Color foundation:**
-- Warm (creams, warm grays) — approachable, human
-- Cool (slate, blue-gray) — professional, serious
-- Pure neutrals (true grays) — minimal, technical
-
-**Layout approach:**
-- Dense grids for scanning/comparing
-- Generous spacing for focused tasks
-- Sidebar navigation for multi-section apps
-- Split panels for list-detail patterns
-
-Use AskUserQuestion to present 2-3 options and get the user's preference.
-
-## Create ASCII Wireframes
-
-Sketch the interface in ASCII. Keep it rough—this is for alignment, not pixel precision.
-
-```
-Example:
-┌─────────────────────────────────────────┐
-│  Page Title                [Action ▾]   │
-├──────────┬──────────────────────────────┤
-│ Nav Item │  Content Area                │
-│ Nav Item │  ┌─────────────────────────┐ │
-│ Nav Item │  │ Component               │ │
-│          │  └─────────────────────────┘ │
-└──────────┴──────────────────────────────┘
-```
-
-Create wireframes for:
-- Primary screen(s) the user will interact with
-- Key states (empty, loading, error, populated)
-- Any modals or secondary views
-
-Present each wireframe to the user. Use AskUserQuestion to confirm or iterate.
-
-## Map User Flows
-
-For each primary action, document the interaction sequence:
-
-1. Where does the user start?
-2. What do they click/type?
-3. What feedback do they see?
-4. Where do they end up?
-
-Format as simple numbered steps under each flow name.
-
-## When to Move On
-
-Proceed to `references/step-4-deep-dive.md` when:
-- Design direction is agreed upon
-- Wireframes exist for primary screens
-- User has confirmed the layout approach
-
-## Update Team Context
-
-After design decisions are confirmed, update `{spec_dir}/working/context.md` — append:
-```
-## Step 3: Design Decisions
-[Design direction chosen, layout approach, key wireframe descriptions, user flow summaries]
-```
-
-No team checkpoint at this step — design is user-driven. Teammates will read the updated context.md on their own.

package/src/skills/spec-interview/references/step-4-deep-dive.md

@@ -1,119 +0,0 @@
-# Step 4: Deep Dive
-
-Cover all specification areas through conversation. Update `docs/specs/<name>/spec.md` incrementally as information emerges.
-
-Use AskUserQuestion whenever requirements are ambiguous or multiple approaches exist. Present options with tradeoffs and get explicit decisions.
-
-## Areas to Cover
-
-### Intent & Goals
-- Primary goal and business/user value
-- Success metrics and how to verify it works
-
-### Integration Points
-- Existing system components this touches
-- External services, APIs, or libraries
-- Data flows in and out
-
-The Researcher has been exploring the codebase since Step 1. Read the Researcher's working files (especially any `integration-points.md` or related files). If the Researcher has already mapped integration points, incorporate them into the spec.
-
-If specific questions remain, message the Researcher via SendMessage with targeted questions like "How does authentication work in this codebase?" or "What middleware handles protected routes?" and wait for a response.
-
-No assumptions. If something is unclear, ask the Researcher to investigate.
-
-### File Landscape
-
-Read the Researcher's `file-landscape.md` working file. The Researcher should have identified concrete file paths by now. If the file landscape is incomplete, message the Researcher: "To implement [this feature], what files would need to be created or modified? Give me concrete file paths."
-
-Capture:
-- **Files to create**: New files with full paths (e.g., `src/models/notification.ts`)
-- **Files to modify**: Existing files that need changes (e.g., `src/routes/index.ts`)
-- **Directory conventions**: Where each type of code lives in this project
-
-This becomes the File Landscape section of the spec, which spec-to-tasks uses directly.
-
-### Data Model
-- Entities and relationships
-- Constraints (required fields, validations, limits)
-- Extending existing models vs creating new ones
-
-### Behavior & Flows
-- Main user flows, step by step
-- Triggers and resulting actions
-- Different modes or variations
-
-### Edge Cases & Error Handling
-- Failure modes and how to handle them
-- Invalid input handling
-- Boundary conditions
-- Partial failure recovery
-
-### Blockers & Dependencies
-- External dependencies (APIs, services, libraries)
-- Credentials or access needed
-- Decisions that must be made before implementation
-
-## Spec Structure
-
-Write to `docs/specs/<name>/spec.md` with this structure:
-
-```markdown
-# [Feature Name]
-
-## Overview
-[2-3 sentences: what and why]
-
-## Goals
-- [Primary goal]
-- [Secondary goals]
-
-## Integration Points
-- Touches: [existing components]
-- External: [APIs, services, libraries]
-- Data flows: [in/out]
-
-## File Landscape
-
-### Files to Create
-- [path/to/new-file.ts]: [purpose]
-
-### Files to Modify
-- [path/to/existing-file.ts]: [what changes]
-
-## Data Model
-[Entities, relationships, constraints]
-
-## Behavior
-### [Flow 1]
-[Step by step]
-
-## Edge Cases
-- [Case]: [handling]
-
-## Acceptance Criteria
-- [ ] [Testable requirement]
-  **Verify:** [verification method]
-
-## Blockers
-- [ ] [Blocker]: [what's needed]
-```
-
-## Team Checkpoint: Deep Dive
-
-After completing all deep dive subsections:
-
-1. Update `{spec_dir}/working/context.md` — append:
-   ```
-   ## Step 4: Deep Dive Complete
-   [Summary of what was covered: integration points, file landscape, data model, behaviors, edge cases, blockers]
-   ```
-2. Read all working files from the Critic and Pragmatist
-3. Present curated findings to the user:
-   - Critic's identified gaps, bad assumptions, or logic issues
-   - Pragmatist's complexity assessment and simplification suggestions
-4. Use AskUserQuestion to discuss significant findings. If the Critic found gaps, address them. If the Pragmatist suggests simplifications, let the user decide.
-5. Update spec.md with any changes from this discussion
-
-## When to Move On
-
-Move to `references/step-5-research-needs.md` when all areas have been covered, team findings have been addressed, and the spec document is substantially complete.

package/src/skills/spec-interview/references/step-5-research-needs.md

@@ -1,53 +0,0 @@
-# Step 5: Identify Research Needs
-
-Before finalizing, determine if implementation requires unfamiliar paradigms.
-
-## The Question
-
-For each major component in the spec, ask: **Does working code using this exact pattern already exist in this codebase?**
-
-This is not about whether Claude knows how to do something in general. It's about whether this specific project has proven, working examples of the same approach.
-
-## Evaluate Each Component
-
-Review the spec's integration points, data model, and behavior sections.
-
-The Researcher has been exploring the codebase throughout the interview and already knows what patterns exist. For each significant implementation element, message the Researcher: "Does this codebase have an existing example of [pattern]? If yes, where and how does it work?"
-
-You can ask about multiple patterns in a single message. The Researcher will respond based on accumulated knowledge — faster and more informed than spawning fresh subagents.
-
-Based on Researcher findings:
-- If pattern exists → paradigm is established, no research needed
-- If not found → this is a new paradigm requiring research
-
-Examples of "new paradigm" triggers:
-- Using a library not yet in the project
-- A UI pattern not implemented elsewhere in the app
-- An integration with an external service not previously connected
-- A data structure or flow unlike existing code
-
-## If Research Needed
-
-For each new paradigm identified:
-1. State what needs research and why (no existing example found)
-2. Use AskUserQuestion to ask if they want to proceed with research, or if they have existing knowledge to share
-3. If proceeding, invoke the `research` skill for that topic
-
-Wait for research to complete before continuing. The research output goes to `docs/research/` and informs implementation.
-
-## If No Research Needed
-
-State that all paradigms have existing examples in the codebase. Proceed to `references/step-6-verification.md`.
-
-## When to Move On
-
-Proceed to `references/step-6-verification.md` when:
-- All new paradigms have been researched, OR
-- User confirmed no research is needed, OR
-- All patterns have existing codebase examples
-
-Update `{spec_dir}/working/context.md` — append:
-```
-## Step 5: Research Needs
-[Which paradigms are established, which required research, research outcomes]
-```

package/src/skills/spec-interview/references/step-6-verification.md

@@ -1,89 +0,0 @@
-# Step 6: Verification Planning
-
-Every acceptance criterion needs a specific, executable verification method. The goal: autonomous implementation with zero ambiguity about whether something works.
-
-## Verification Methods
-
-### UI Verification: agent-browser
-
-For any criterion involving visual output or user interaction, use Vercel's agent-browser CLI:
-
-```
-agent-browser open <url>              # Navigate to page
-agent-browser snapshot                # Get accessibility tree with refs
-agent-browser click @ref              # Click element by ref
-agent-browser fill @ref "value"       # Fill input by ref
-agent-browser get text @ref           # Read text content
-agent-browser screenshot file.png     # Capture visual state
-agent-browser close                   # Close browser
-```
-
-Example verification for "Dashboard shows signup count":
-1. `agent-browser open /admin`
-2. `agent-browser snapshot`
-3. `agent-browser get text @signup-count`
-4. Assert returned value is a number
-
-### Automated Tests
-
-For logic, data, and API behavior, specify the exact test:
-- Unit tests for pure functions
-- Integration tests for API endpoints
-- End-to-end tests for critical flows
-
-Include the test file path: `pnpm test src/convex/featureFlags.test.ts`
-
-### Database/State Verification
-
-For data persistence criteria:
-1. Perform the action
-2. Query the database directly
-3. Assert expected state
-
-### Manual Verification (Fallback)
-
-If no automated method exists, document exactly what to check. Flag these as candidates for future automation.
-
-## Update Each Acceptance Criterion
-
-Review every acceptance criterion in the spec. Add a verification method using this format:
-
-```markdown
-## Acceptance Criteria
-
-- [ ] Dashboard loads in under 2s
-  **Verify:** `agent-browser open /admin`, measure time to snapshot ready
-
-- [ ] Flag toggles persist across refresh
-  **Verify:** `pnpm test src/convex/featureFlags.test.ts` (toggle persistence test)
-
-- [ ] Signup chart shows accurate counts
-  **Verify:** `agent-browser get text @chart-total`, compare to `npx convex run users:count`
-```
-
-## Confirm With User
-
-Use AskUserQuestion to review verification methods with the user:
-- "For [criterion], I'll verify by [method]. Does that prove it works?"
-- Flag any criteria where verification seems insufficient
-
-The standard: if the agent executes the verification and it passes, the feature is done. No human checking required.
-
-## Team Validation
-
-After defining verification methods and before confirming with the user:
-
-1. Message the Critic: "Review the verification methods in spec.md. Are they concrete and executable? Will each one actually prove its criterion works?"
-2. Message the Pragmatist: "Review the verification methods in spec.md. Are any over-complex? Could simpler verification achieve the same confidence?"
-3. Read their responses (via working files or SendMessage)
-4. Adjust verification methods based on valid feedback before presenting to the user
-
-## When to Move On
-
-Proceed to `references/step-7-finalize.md` when every acceptance criterion has a verification method and the user agrees each method proves the criterion works.
-
-Update `{spec_dir}/working/context.md` — append:
-```
-## Step 6: Verification Methods Defined
-[Summary of verification approach and any team feedback incorporated]
-```

package/src/skills/spec-interview/references/step-7-finalize.md

@@ -1,62 +0,0 @@
-# Step 7: Finalize
-
-Review the spec for completeness and soundness, then hand off.
-
-## Request Final Team Reviews
-
-Message both the Critic and Pragmatist requesting final assessments:
-
-1. Message the Critic: "The spec is substantially complete. Please do a final review against your completeness checklist and sanity check framework. Write your complete findings to `{spec_dir}/working/critic-final-review.md` using the format in your prompt."
-2. Message the Pragmatist: "The spec is substantially complete. Please do a final complexity assessment. Write your findings to `{spec_dir}/working/pragmatist-final-assessment.md` using the format in your prompt."
-3. Wait for both to respond (they will message you when their files are ready)
-4. Read their working files: `critic-final-review.md` and `pragmatist-final-assessment.md`
-
-## Curate the Findings
-
-Synthesize findings from the Critic's review and the Pragmatist's assessment. Some findings may be:
-- Critical issues that must be addressed
-- Valid suggestions worth considering
-- Pedantic or irrelevant items to skip
-
-For each finding, form a recommendation: address it or skip it, and why.
-
-The Critic and Pragmatist have had full context of the entire interview — their findings are more informed than cold reviews. Weight their input accordingly.
-
-## Walk Through With User
-
-Use AskUserQuestion to present findings in batches (2-3 at a time). For each finding:
-- State what the review found
-- Give your recommendation (always include a recommended option)
-- Let user decide: fix, skip, or something else
-
-Track two lists:
-- **Addressed**: findings the user chose to fix
-- **Intentionally skipped**: findings the user chose to ignore
-
-After walking through all findings, make the approved changes to the spec.
-
-## Offer Another Pass
-
-Use AskUserQuestion: "Do you want to run the reviews again?"
-
-If yes, message the Critic and Pragmatist again with additional context: "We already ran a review. These changes were made: [list]. These findings were intentionally skipped: [list]. Look for anything new we haven't considered."
-
-Read their updated working files and repeat the curate → walk through → offer another pass cycle until user is satisfied.
-
-## Complete the Interview
-
-Once user confirms no more review passes needed:
-
-1. Show the user the final spec
-2. Use AskUserQuestion to confirm they are satisfied
-3. Ask if they want to proceed to task breakdown
-4. Shutdown the team:
-   - Send shutdown requests to all three teammates (researcher, critic, pragmatist) via SendMessage with type "shutdown_request"
-   - After all teammates confirm shutdown, use TeamDelete to clean up team resources
-   - The `{spec_dir}/working/` directory remains on disk as reference for implementation
-
-If yes to task breakdown, invoke `spec-to-tasks` and specify which spec to break down.
-
-**IMPORTANT: You are not done. You MUST read and complete the next step. The workflow is incomplete without it.**
-
-Read `references/step-8-reflect.md` now.

package/src/skills/spec-interview/references/step-8-reflect.md

@@ -1,34 +0,0 @@
-# Step 8: Reflect and Improve
-
-**IMPORTANT: This step is mandatory. The spec interview workflow is not complete until this step is finished. Do not skip this.**
-
-Reflect on your experience conducting this spec interview. The purpose is to improve the spec-interview skill itself based on what you just learned.
-
-## Assess
-
-Answer these questions honestly:
-
-1. Were any interview steps wrong, incomplete, or misleading? Did any step send you down a wrong path or leave out critical guidance?
-2. Did the team coordination work smoothly? Were the checkpoint patterns (post-ideation, deep dive, finalize) at the right moments? Did any teammate produce findings too late or too early to be useful?
-3. Did the prompt templates (researcher, critic, pragmatist) give adequate direction? Did any teammate misunderstand its role or produce unhelpful output?
-4. Did you discover a question sequence, interview technique, or spec structure that worked better than what the skill prescribed?
-5. Did any commands, paths, tool interactions, or team communication patterns fail and require correction?
-6. Was the step ordering right? Should any steps be reordered, merged, or split?
-
-## Act
-
-If you identified issues above, fix them now:
-
-1. Identify the specific file in the spec-interview skill where the issue lives
-2. Read that file
-3. Apply the fix -- add what was missing, correct what was wrong
-4. Apply the tribal knowledge test: only add what a fresh Claude instance would not already know about conducting spec interviews or coordinating agent teams
-5. Keep the file within its size target
-
-If no issues were found, confirm that to the user.
-
-## Report
-
-Tell the user:
-- What you changed in the spec-interview skill and why, OR
-- That no updates were needed and the skill performed correctly

package/src/skills/spec-review/SKILL.md

@@ -1,92 +0,0 @@
----
-name: spec-review
-description: This skill should be used when the user says "review the spec", "check spec completeness", or "is this spec ready". Also invoked by spec-interview when a spec is complete.
-argument-hint: <spec-name>
-context: fork
----
-
-# Spec Review
-
-## Steps
-
-1. **Find the spec** - Use the path from the prompt if provided. Otherwise, find the most recently modified file in `docs/specs/`. If no specs exist, inform the user and stop.
-2. **Read the spec file**
-3. **Find all CLAUDE.md files** - Search for every CLAUDE.md in the project (root and subdirectories)
-4. **Read all CLAUDE.md files** - These contain project constraints and conventions
-5. **Evaluate against the checklist below** - Including CLAUDE.md alignment
-6. **Return structured feedback using the output format**
-
-## Completeness Checklist
-
-A spec is implementation-ready when ALL of these are satisfied:
-
-### Must Have (Blocking if missing)
-
-- [ ] **Clear intent** - What is being built and why is unambiguous
-- [ ] **Data model defined** - Entities, relationships, and constraints are explicit
-- [ ] **Integration points mapped** - What existing code this touches is documented
-- [ ] **Core behavior specified** - Main flows are step-by-step clear
-- [ ] **Acceptance criteria exist** - Testable requirements are listed
-- [ ] **Verification methods defined** - Every acceptance criterion has a specific way to verify it (test command, agent-browser steps, or explicit check)
-- [ ] **No ambiguities** - Nothing requires interpretation; all requirements are explicit
-- [ ] **No unknowns** - All information needed for implementation is present; nothing left to discover
-- [ ] **CLAUDE.md alignment** - Spec does not conflict with constraints in any CLAUDE.md file
-- [ ] **No internal duplication** - File Landscape contains no sets of new files that serve similar purposes and could share a common implementation
-
-### Should Have (Gaps that cause implementation friction)
-
-- [ ] **Edge cases covered** - Error conditions and boundaries are addressed
-- [ ] **External dependencies documented** - APIs, libraries, services are listed
-- [ ] **Blockers section exists** - Missing credentials, pending decisions are called out
-- [ ] **UI/UX wireframes exist** - If feature has a user interface, ASCII wireframes are present
-- [ ] **Design direction documented** - If feature has UI, visual approach is explicit (not assumed)
-
-### Implementation Readiness
-
-The test: could an agent implement this feature with ZERO assumptions? If the agent would need to guess, interpret, or discover anything, the spec is not ready.
-
-Flag these problems:
-- Vague language ("should handle errors appropriately" — HOW?)
-- Missing details ("integrates with auth" — WHERE? HOW?)
-- Unstated assumptions ("uses the standard pattern" — WHICH pattern?)
-- Blocking dependencies ("needs API access" — DO WE HAVE IT?)
-- Unverifiable criteria ("dashboard works correctly" — HOW DO WE CHECK?)
-- Missing verification ("loads fast" — WHAT COMMAND PROVES IT?)
-- Implicit knowledge ("depends on how X works" — SPECIFY IT)
-- Unverified claims ("the API returns..." — HAS THIS BEEN CONFIRMED?)
-- CLAUDE.md conflicts (spec proposes X but CLAUDE.md requires Y — WHICH IS IT?)
-- Near-duplicate new components (three card components for different pages — CONSOLIDATE into one shared component with props/configuration)
-
-## Output Format
-
-Return the review as:
-
-```
-## Spec Review: [Feature Name]
-
-### Status: [READY | NEEDS WORK]
-
-### Missing (Blocking)
-- [Item]: [What's missing and why it blocks implementation]
-
-### CLAUDE.md Conflicts
-- [Constraint from CLAUDE.md]: [How the spec conflicts with it]
-
-### Gaps (Non-blocking but should address)
-- [Item]: [What's unclear or incomplete]
-
-### Duplication Concerns
-- [Group of similar new files/components]: [How they overlap and consolidation recommendation]
-
-### Blocking Dependencies
-- [Dependency]: [What's needed before implementation can start]
-
-### Skill Observations (optional)
-If any checklist items, evaluation criteria, or output format instructions in this skill were wrong, incomplete, or misleading during this review, note them here. Leave empty if no issues were found.
-
-### Recommendation
-[Specific questions to ask the user, or "Spec is implementation-ready"]
-```
-
-**READY**: Spec can proceed to task breakdown.
-**NEEDS WORK**: List specific questions that need answers.

package/src/skills/spec-sanity-check/SKILL.md

@@ -1,82 +0,0 @@
----
-name: spec-sanity-check
-description: This skill should be used alongside spec-review to catch logic gaps and incorrect assumptions. Invoked when the user says "sanity check this spec", "does this plan make sense", or "what am I missing". Also auto-invoked by spec-interview during finalization.
-argument-hint: <spec-path>
-context: fork
----
-
-# Spec Sanity Check
-
-Provide a "fresh eyes" review of the spec. This is different from spec-review — you're not checking format or completeness. You're checking whether the plan will actually work.
-
-## Find the Spec
-
-Use the path from the prompt if provided. Otherwise, find the most recently modified file in `docs/specs/`. If no specs exist, inform the user and stop.
-
-## Read and Understand
-
-Read the entire spec. Understand what is being built and how.
-
-## Ask These Questions
-
-For each section of the spec, challenge it:
-
-### Logic Gaps
-- Does the described flow actually work end-to-end?
-- Are there steps that assume a previous step succeeded without checking?
-- Are there circular dependencies?
-- Does the order of operations make sense?
-
-### Incorrect Assumptions
-- Are there assumptions about how existing systems work that might be wrong?
-- Are there assumptions about external APIs, libraries, or services?
-- Are there assumptions about data formats or availability?
-- Use Explorer subagents to verify assumptions against the actual codebase
-
-### Unconsidered Scenarios
-- What happens in edge cases not explicitly covered?
-- What happens under load or at scale?
-- What happens if external dependencies fail?
-- What happens if data is malformed or missing?
-
-### Implementation Pitfalls
-- Are there common bugs this approach would likely introduce?
-- Are there security implications not addressed?
-- Are there performance implications not addressed?
-- Are there race conditions or timing issues?
-
-### The "What If" Test
-- What if [key assumption] is wrong?
-- What if [external dependency] changes?
-- What if [data volume] is 10x what we expect?
-
-## Output Format
-
-Return findings as:
-
-```
-## Sanity Check: [Feature Name]
-
-### Status: [SOUND | CONCERNS]
-
-### Logic Issues
-- [Issue]: [Why this is a problem]
-
-### Questionable Assumptions
-- [Assumption]: [Why this might be wrong] [Suggestion to verify]
-
-### Unconsidered Scenarios
-- [Scenario]: [What could go wrong]
-
-### Potential Pitfalls
-- [Pitfall]: [How to avoid]
-
-### Skill Observations (optional)
-If any evaluation questions, check categories, or output format instructions in this skill were wrong, incomplete, or misleading during this review, note them here. Leave empty if no issues were found.
-
-### Recommendation
-[Either "Plan is sound" or specific concerns to address]
-```
-
-**SOUND**: No significant concerns found.
-**CONCERNS**: Issues that should be addressed before implementation.

package/src/skills/spec-to-tasks/SKILL.md

@@ -1,24 +0,0 @@
----
-name: spec-to-tasks
-description: Converts a feature specification into implementation tasks. Use after a spec is complete and approved, or when planning work for a defined feature.
-argument-hint: <spec-name>
-context: fork
----
-
-# Spec to Tasks
-
-## Workflow Overview
-
-This skill has 5 steps. **You must complete ALL steps. Do not stop early or skip any step.**
-
-1. **Identify Spec** - Find and verify the spec file
-2. **Verify File Landscape** - Map files to acceptance criteria
-3. **Generate Tasks** - Create task files in `tasks/` directory
-4. **Review Tasks** - Run review checklist in a loop until no critical issues remain
-5. **Reflect** - Note any skill issues observed during this run
-
-Steps 4 and 5 are mandatory. The review loop in step 4 is automated — fix issues and re-check until clean, with no user input required.
-
-## What To Do Now
-
-Read `references/step-1-identify-spec.md` and begin.

package/src/skills/spec-to-tasks/references/step-1-identify-spec.md

@@ -1,39 +0,0 @@
-# Step 1: Identify the Spec
-
-Locate the specification to convert into tasks.
-
-## If Spec Path Provided
-
-Use the path from the user's prompt. Verify the file exists and read it.
-
-## If No Path Provided
-
-Find the most recently modified spec:
-
-```bash
-git log -1 --name-only --diff-filter=AM -- 'docs/specs/**/*.md' | tail -1
-```
-
-If no specs found in git history, check `docs/specs/` for any spec files and ask the user which one to use.
-
-## Verify the Spec
-
-Read the spec file. Confirm it contains enough detail to generate implementation tasks:
-
-**Required:**
-- Acceptance Criteria with verification methods (each criterion becomes a task)
-- Clear behavior descriptions
-
-**Expected (from spec-interview):**
-- File Landscape section listing files to create/modify
-- Integration points and data model
-
-**If missing acceptance criteria or verification methods:**
-Inform the user: "This spec doesn't have acceptance criteria with verification methods. Each task needs a clear pass/fail test. Would you like to add them now, or run spec-interview to complete the spec?"
-
-**If missing file landscape:**
-Proceed to step 2 where we'll discover file paths via exploration.
-
-## Next Step
-
-Once the spec is identified and verified, read `references/step-2-explore.md`.