@gordon.gan/specflow 1.0.0 → 1.0.2

package/prompts/{plan → propose}/tasks-draft.md

@@ -1,10 +1,10 @@
-> **HARD GATE — READ THIS FIRST.** Generate substantive first-iteration tasks. Not placeholders. Not "TBD". Not empty group headers. Each group gets real tasks with concrete verbs. Build Phase A will later rewrite this to writing-plans precision (exact paths, code blocks, bite-sized steps) — but you are producing the first honest pass at "what needs to happen," not a skeleton for someone else to fill.
+> **HARD GATE — READ THIS FIRST.** Generate substantive first-iteration tasks. Not placeholders. Not "TBD". Not empty group headers. Each group gets real tasks with concrete verbs. Apply Phase A will later rewrite this to writing-plans precision (exact paths, code blocks, bite-sized steps) — but you are producing the first honest pass at "what needs to happen," not a skeleton for someone else to fill.
 
 # Plan Phase: First-Iteration Tasks Draft
 
 ## Purpose
 
-Generate a substantive first-iteration `tasks.md` that maps the change into coarse, concrete work items. This is **v1 of the task plan** — Build Phase A will use writing-plans to produce v2 (with exact file paths, code snippets, and bite-sized test-first steps). Your job here is to outline the real work so refine can challenge it and Build Phase A can refine it into executable form.
+Generate a substantive first-iteration `tasks.md` that maps the change into coarse, concrete work items. This is **v1 of the task plan** — Apply Phase A will use writing-plans to produce v2 (with exact file paths, code snippets, and bite-sized test-first steps). Your job here is to outline the real work so refine can challenge it and Apply Phase A can refine it into executable form.
 
 ## Inputs You Must Read
 
@@ -18,10 +18,10 @@ Generate a substantive first-iteration `tasks.md` that maps the change into coar
 The generated `tasks.md` file **must begin** with this HTML comment as its first line (this is content you inject into the output file, not part of this prompt):
 
 ```
-<!-- Plan-phase first-iteration tasks. Will be rewritten to writing-plans precision in /specflow:build Phase A. -->
+<!-- Plan-phase first-iteration tasks. Will be rewritten to writing-plans precision in /specflow:apply Phase A. -->
 ```
 
-This marker tells future readers (and the Build Phase A prompt) that this document is coarse-grained by design and will be rewritten to a stricter format later.
+This marker tells future readers (and the Apply Phase A prompt) that this document is coarse-grained by design and will be rewritten to a stricter format later.
 
 ## Structure Rules
 
@@ -40,7 +40,7 @@ This marker tells future readers (and the Build Phase A prompt) that this docume
    - "handle searching" (bad — same problem in English)
    - "完善测试" (bad — improvement verb without a subject)
 
-4. **Each item should be a coherent unit of work** — roughly the size that Build Phase A will later expand into a handful of bite-sized TDD steps. If an item feels like it's really 5 unrelated actions, split it.
+4. **Each item should be a coherent unit of work** — roughly the size that Apply Phase A will later expand into a handful of bite-sized TDD steps. If an item feels like it's really 5 unrelated actions, split it.
 
 ## Grouping Guidance
 
@@ -58,7 +58,7 @@ If the change has both parallel capabilities and deep layering, a two-level grou
 Below is a short worked example for a hypothetical "add search to notes CLI" change. Study the **granularity and verb concreteness**, not the specific content.
 
 ```markdown
-<!-- Plan-phase first-iteration tasks. Will be rewritten to writing-plans precision in /specflow:build Phase A. -->
+<!-- Plan-phase first-iteration tasks. Will be rewritten to writing-plans precision in /specflow:apply Phase A. -->
 
 # notes-search Implementation Tasks
 
@@ -89,7 +89,7 @@ Note how each item names a specific artifact or action (`searchNotes` function,
 
 ## What This Draft Is NOT
 
-- It is **not** the writing-plans format. Build Phase A does that rewrite with exact file paths, code blocks, and `Write test → Run test → Implement → Run test → Commit` per step. Do not pre-write those here — you don't yet have the design detail to do it well, and duplicating effort wastes the refine pass.
+- It is **not** the writing-plans format. Apply Phase A does that rewrite with exact file paths, code blocks, and `Write test → Run test → Implement → Run test → Commit` per step. Do not pre-write those here — you don't yet have the design detail to do it well, and duplicating effort wastes the refine pass.
 - It is **not** a skeleton to be filled in. Every item should reflect a real action you'd expect to perform.
 - It is **not** a design document. If you find yourself writing "decide whether to use X or Y" as a task, that's a design decision that belongs in `design.md`. Move it there.
 
@@ -112,7 +112,7 @@ Save the document to:
 specflow/changes/<change-name>/tasks.md
 ```
 
-**Do NOT ask the user to confirm this draft at this stage.** The orchestrating SKILL will present all plan-phase artifacts together at the end of the plan phase. Refine will challenge and restructure; Build Phase A will rewrite to precision. Your job is to hand off a substantive first pass.
+**Do NOT ask the user to confirm this draft at this stage.** The orchestrating SKILL will present all plan-phase artifacts together at the end of the propose phase. Refine will challenge and restructure; Apply Phase A will rewrite to precision. Your job is to hand off a substantive first pass.
 
 ## Remember
 
@@ -120,4 +120,4 @@ specflow/changes/<change-name>/tasks.md
 - 3 to 8 groups, 2 to 6 items each
 - Concrete verbs on concrete subjects
 - Top-of-file marker comment is mandatory
-- Writing-plans precision comes in Build Phase A — do not pre-write it here
+- Writing-plans precision comes in Apply Phase A — do not pre-write it here

package/prompts/reference/specflow/example-design.md

@@ -75,7 +75,7 @@ specflow init                  # Generate .claude/skills/, .claude/commands/, op
 
 **Choice**: Design SpecFlow's CLI commands from scratch rather than copying OpenSpec's structure. Aligned with SpecFlow's 10-command workflow.
 
-**Rationale**: OpenSpec's CLI was designed for a broader audience (25+ tools). SpecFlow targets Claude Code specifically and has a different workflow (scan → plan → refine → build → ...). Commands should reflect this workflow.
+**Rationale**: OpenSpec's CLI was designed for a broader audience (25+ tools). SpecFlow targets Claude Code specifically and has a different workflow (scan → propose → refine → apply → ...). Commands should reflect this workflow.
 
 CLI design is a separate task — will be defined during implementation based on the workflows that SKILL.md files need to invoke.
 
@@ -83,23 +83,23 @@ CLI design is a separate task — will be defined during implementation based on
 
 **Choice**: SKILL.md files are lightweight orchestrators (~50-100 lines) that route execution through stages. Each stage loads its detailed prompt via Claude Code's Read tool from the `prompts/` directory.
 
-**Structure example** (`specflow-build/SKILL.md`):
+**Structure example** (`specflow-apply/SKILL.md`):
 ```
 SKILL.md (orchestrator, ~80 lines)
-├── Stage A: Read prompts/build/phase-a-plan.md → generate task plan
+├── Stage A: Read prompts/apply/phase-a-plan.md → generate task plan
 ├── User confirmation gate
-├── Stage B: Read prompts/build/phase-b-worktree.md → setup isolation
-├── Stage C: Read prompts/build/phase-b-execute.md → per-task TDD
+├── Stage B: Read prompts/apply/phase-b-worktree.md → setup isolation
+├── Stage C: Read prompts/apply/phase-b-execute.md → per-task TDD
 │   └── Each subagent: Read prompts/shared/implementer-prompt.md
-├── Stage D: Read prompts/build/phase-b-review.md → two-phase review
+├── Stage D: Read prompts/apply/phase-b-review.md → two-phase review
 │   ├── Read prompts/shared/spec-reviewer-prompt.md
 │   └── Read prompts/shared/code-reviewer-prompt.md
 └── User confirmation per task
 ```
 
-**Why**: A single specflow-build SKILL.md with all content inline would be ~1300 lines. Claude Code follows smaller, focused prompts more reliably than monolithic ones. Progressive loading keeps each execution stage in a clean context.
+**Why**: A single specflow-apply SKILL.md with all content inline would be ~1300 lines. Claude Code follows smaller, focused prompts more reliably than monolithic ones. Progressive loading keeps each execution stage in a clean context.
 
-**Target location in user projects**: `.claude/specflow/prompts/` (avoids conflicts with user's own directories). SKILL.md orchestrators use CWD-relative paths like `.claude/specflow/prompts/build/phase-a-plan.md`.
+**Target location in user projects**: `.claude/specflow/prompts/` (avoids conflicts with user's own directories). SKILL.md orchestrators use CWD-relative paths like `.claude/specflow/prompts/apply/phase-a-plan.md`.
 
 **Prompts directory organization** (hybrid):
 ```
@@ -193,14 +193,14 @@ my-project/
 | Superpowers skill | SpecFlow destination | Type |
 |---|---|---|
 | brainstorming | prompts/refine/brainstorm.md | Command prompt |
-| writing-plans | prompts/build/phase-a-plan.md | Command prompt |
-| subagent-driven-development | prompts/build/phase-b-execute.md | Command prompt |
-| using-git-worktrees | prompts/build/phase-b-worktree.md | Command prompt |
-| test-driven-development | prompts/build/ + prompts/test/ | Shared |
+| writing-plans | prompts/apply/phase-a-plan.md | Command prompt |
+| subagent-driven-development | prompts/apply/phase-b-execute.md | Command prompt |
+| using-git-worktrees | prompts/apply/phase-b-worktree.md | Command prompt |
+| test-driven-development | prompts/apply/ + prompts/test/ | Shared |
 | requesting-code-review + code-reviewer | prompts/review/ | Command prompt |
 | systematic-debugging | prompts/fix/debug.md | Command prompt |
 | verification-before-completion | prompts/test/ + prompts/verify/ | Shared |
-| finishing-a-development-branch | prompts/done/branch-finish.md | Command prompt |
+| finishing-a-development-branch | prompts/archive/branch-finish.md | Command prompt |
 | dispatching-parallel-agents | prompts/shared/ | Shared utility |
 | executing-plans | prompts/shared/ | Shared utility |
 | receiving-code-review | prompts/shared/ | Shared utility |
@@ -210,13 +210,13 @@ my-project/
 **Rewrite rules**:
 - Skill name references: `brainstorming` → `specflow:refine`
 - Path references: `docs/superpowers/specs/` → `openspec/changes/<name>/`
-- Next-step invocations: "Invoke writing-plans skill" → "Proceed to specflow:build"
+- Next-step invocations: "Invoke writing-plans skill" → "Proceed to specflow:apply"
 - All internal cross-references updated to SpecFlow equivalents
 - Logic, hard gates, fail-stops, verification requirements preserved exactly
 
 ### D7: Scan via code-review-graph
 
-**Choice**: `/specflow:scan` uses code-review-graph (npm dependency) to analyze codebase structure, then converts the analysis output into OpenSpec specs format.
+**Choice (deferred):** A future `/specflow:scan` may use code-review-graph to analyze codebase structure and convert output into OpenSpec specs format. Scan is **not shipped** in public releases; brownfield onboarding uses `/specflow:explore` or `/specflow:propose` instead.
 
 **Why**: Code analysis is a hard problem. Rather than building a custom AST parser for every language, leverage an existing tool that generates structured project knowledge. SpecFlow's value-add is converting that knowledge into actionable specs.
 
@@ -232,16 +232,16 @@ my-project/
 
 ### D9: Strict user confirmation mode
 
-**Choice**: Every task in `specflow:build` completes with a review summary and waits for user confirmation before proceeding to the next task.
+**Choice**: Every task in `specflow:apply` completes with a review summary and waits for user confirmation before proceeding to the next task.
 
 **Confirmation points across workflow**:
 1. `scan` → scan results confirmation
-2. `plan` → proposal direction confirmation
+2. `propose` → proposal direction confirmation
 3. `refine` → approach selection (2-3 options) + final design confirmation
-4. `build` Phase A → task plan confirmation
-5. `build` Phase B → per-task review result + user confirmation
+4. `apply` Phase A → task plan confirmation
+5. `apply` Phase B → per-task review result + user confirmation
 6. `review` → critical issues require confirmation
-7. `done` → 4 options (merge/PR/keep/discard)
+7. `archive` → 4 options (merge/PR/keep/discard)
 
 ### D10: Responsibility boundaries
 

package/prompts/reference/superpowers/anthropic-best-practices.md

@@ -129,9 +129,9 @@ Do not modify the command or add additional flags.
 * **Narrow bridge with cliffs on both sides**: There's only one safe way forward. Provide specific guardrails and exact instructions (low freedom). Example: database migrations that must run in exact sequence.
 * **Open field with no hazards**: Many paths lead to success. Give general direction and trust Claude to find the best route (high freedom). Example: code reviews where context determines the best approach.
 
-### Test with all models you plan to use
+### Test with all models you propose to use
 
-Skills act as additions to models, so effectiveness depends on the underlying model. Test your Skill with all the models you plan to use it with.
+Skills act as additions to models, so effectiveness depends on the underlying model. Test your Skill with all the models you propose to use it with.
 
 **Testing considerations by model**:
 
@@ -139,7 +139,7 @@ Skills act as additions to models, so effectiveness depends on the underlying mo
 * **Claude Sonnet** (balanced): Is the Skill clear and efficient?
 * **Claude Opus** (powerful reasoning): Does the Skill avoid over-explaining?
 
-What works perfectly for Opus might need more detail for Haiku. If you plan to use your Skill across multiple models, aim for instructions that work well with all of them.
+What works perfectly for Opus might need more detail for Haiku. If you propose to use your Skill across multiple models, aim for instructions that work well with all of them.
 
 ## Skill structure
 
@@ -984,17 +984,17 @@ Claude's vision capabilities help understand layouts and structures.
 
 ### Create verifiable intermediate outputs
 
-When Claude performs complex, open-ended tasks, it can make mistakes. The "plan-validate-execute" pattern catches errors early by having Claude first create a plan in a structured format, then validate that plan with a script before executing it.
+When Claude performs complex, open-ended tasks, it can make mistakes. The "plan-validate-execute" pattern catches errors early by having Claude first create a propose in a structured format, then validate that propose with a script before executing it.
 
 **Example**: Imagine asking Claude to update 50 form fields in a PDF based on a spreadsheet. Without validation, Claude might reference non-existent fields, create conflicting values, miss required fields, or apply updates incorrectly.
 
-**Solution**: Use the workflow pattern shown above (PDF form filling), but add an intermediate `changes.json` file that gets validated before applying changes. The workflow becomes: analyze → **create plan file** → **validate plan** → execute → verify.
+**Solution**: Use the workflow pattern shown above (PDF form filling), but add an intermediate `changes.json` file that gets validated before applying changes. The workflow becomes: analyze → **create propose file** → **validate plan** → execute → verify.
 
 **Why this pattern works:**
 
 * **Catches errors early**: Validation finds problems before changes are applied
 * **Machine-verifiable**: Scripts provide objective verification
-* **Reversible planning**: Claude can iterate on the plan without touching originals
+* **Reversible planning**: Claude can iterate on the propose without touching originals
 * **Clear debugging**: Error messages point to specific problems
 
 **When to use**: Batch operations, destructive changes, complex validation rules, high-stakes operations.

package/prompts/reference/superpowers/codex-tools.md

@@ -21,7 +21,7 @@ When skills or prompts reference Claude Code tool names, use these Codex equival
 
 - Skills: `.agents/skills/specflow-*/SKILL.md`
 - Runtime prompts: `.agents/specflow/prompts/`
-- Invoke workflows with `$specflow-plan`, `$specflow-refine`, `$specflow-build`, etc.
+- Invoke workflows with `$specflow-propose`, `$specflow-refine`, `$specflow-apply`, etc.
 
 ## Related references
 

package/prompts/refine/brainstorm.md

@@ -23,7 +23,7 @@ Before running this brainstorming flow, you MUST have read:
 - `specflow/specs/` baseline (main specs) for reference
 - `.claude/specflow/prompts/refine/update-artifacts.md` (the delegated artifact-update methodology)
 
-If any of the four change artifacts is missing, stop and tell the user to run `/specflow:plan` first.
+If any of the four change artifacts is missing, stop and tell the user to run `/specflow:propose` first.
 
 ## Iteration Rules
 
@@ -49,8 +49,8 @@ injected; steps 3–5 carry the discussion into artifacts; steps 6–8 close the
 ### Step 1 — Examine existing artifacts (inject Challenge Behavior #1)
 
 Re-read all 4 plan-phase artifacts with fresh eyes. This is not a summary exercise — look for
-what the plan *did not* say. Explicitly INJECT **Challenge Behavior #1 (challenge plan's
-assumptions)** here: list assumptions the plan glossed over and explain why each matters. Each
+what the propose *did not* say. Explicitly INJECT **Challenge Behavior #1 (challenge plan's
+assumptions)** here: list assumptions the propose glossed over and explain why each matters. Each
 round MUST produce this list of challenged assumptions, even if shorter than the previous round.
 
 ### Step 2 — Ask clarifying questions (inject Challenge Behaviors #3 and #4)
@@ -60,7 +60,7 @@ are reasonably enumerable. This is where you INJECT **Challenge Behavior #3 (exp
 boundaries)** — survey edge cases, permissions, error modes, non-functional concerns absent
 from specs — and **Challenge Behavior #4 (question scope)** — ask whether the change is too
 broad, too narrow, or should be split. Clarifying questions are how you explore boundaries
-the plan omitted and how you question scope with the user directly.
+the propose omitted and how you question scope with the user directly.
 
 Keep per-message questions small (1 question per message). Batch the mental exploration but
 serialize the user-facing dialogue.
@@ -70,7 +70,7 @@ serialize the user-facing dialogue.
 For every non-trivial design decision surfaced by Steps 1–2 (both the ones in the existing
 `design.md` and new ones revealed by this round's challenges), INJECT **Challenge Behavior #2
 (propose new options)**: for each existing decision, propose alternative approaches not
-considered in the plan — at least 2 such alternatives per decision, each with pros/cons and
+considered in the propose — at least 2 such alternatives per decision, each with pros/cons and
 a recommendation.
 
 The 2-3 approaches MUST include the currently-chosen option from `design.md` PLUS genuinely
@@ -151,7 +151,7 @@ Announce clearly:
 > "Refine converged after N rounds. All artifacts have been updated and validated. Please
 > review the final state of proposal.md, specs/, design.md, tasks.md. Confirm that this
 > refined state is what you want — on confirmation I will mark phase as `refined` and you
-> can run `/specflow:build` next."
+> can run `/specflow:apply` next."
 
 Do NOT invoke phase transition directly from this prompt — the calling SKILL.md owns that
 handoff, which happens only after explicit user confirmation of the final refined state.
@@ -164,25 +164,25 @@ to see each behavior fired in the round's output.
 
 ### Behavior 1 — challenge plan's assumptions
 
-- **Rationale**: plan was a first-iteration pass; assumptions were made under incomplete
+- **Rationale**: propose was a first-iteration pass; assumptions were made under incomplete
   information and some were glossed over. Refine's job is to challenge those assumptions
   before they harden into implementation.
-- **AI self-prompt**: "What did the plan treat as given that actually deserves interrogation?
+- **AI self-prompt**: "What did the propose treat as given that actually deserves interrogation?
   What 'of course'-flavored premises are hiding in `proposal.md` or `design.md`?"
-- **Sample user-facing question**: "The plan implies that [X]. Is that actually true for this
+- **Sample user-facing question**: "The propose implies that [X]. Is that actually true for this
   user/context, or is it a plan-time shortcut?"
 - **Expected output per round**: a bulleted list titled "Plan assumptions under scrutiny"
   with at least 1 item (generally 2-5 early rounds, trailing toward 0 as convergence nears).
 
 ### Behavior 2 — propose new options
 
-- **Rationale**: plan usually picked the first-plausible option per decision. For each
+- **Rationale**: propose usually picked the first-plausible option per decision. For each
   existing design decision you should propose alternatives — alternatives are where better-fit
   designs emerge.
 - **AI self-prompt**: "For each design decision already in `design.md`, what are the
-  alternatives the plan did not consider? For each new decision surfaced by this round's
+  alternatives the propose did not consider? For each new decision surfaced by this round's
   challenges, what are the 2-3 approaches?"
-- **Sample user-facing question**: "The plan chose [current approach] for decision D3. I
+- **Sample user-facing question**: "The propose chose [current approach] for decision D3. I
   also see two alternatives worth considering: [alt A] and [alt B]. Shall I walk through
   trade-offs?"
 - **Expected output per round**: for at least one existing decision, a block showing
@@ -190,7 +190,7 @@ to see each behavior fired in the round's output.
 
 ### Behavior 3 — explore omitted boundaries
 
-- **Rationale**: plan specs are drafted under time pressure and tend to cover happy paths
+- **Rationale**: propose specs are drafted under time pressure and tend to cover happy paths
   first. You must explore omitted boundaries — edge cases, permissions, errors,
   non-functional concerns — because those are the most common omissions.
 - **AI self-prompt**: "What scenarios belong in the specs but are missing? What permission,
@@ -202,7 +202,7 @@ to see each behavior fired in the round's output.
 
 ### Behavior 4 — question scope
 
-- **Rationale**: plan sets scope early with incomplete information. Refine is the right
+- **Rationale**: propose sets scope early with incomplete information. Refine is the right
   place to question scope — whether the change is too broad (decompose), too narrow
   (expand), or mis-cut (split capability A from B).
 - **AI self-prompt**: "Does the change try to do too much? Too little? Are any capabilities
@@ -235,7 +235,7 @@ diff summary format.
 
 After Step 9 announces final convergence AND the user confirms the refined state:
 the calling SKILL.md will invoke `specflow change phase <name> --set refined`, then suggest
-`/specflow:build` as the next slash command to run.
+`/specflow:apply` as the next slash command to run.
 
 This prompt itself never writes the phase transition — that is the SKILL orchestrator's job,
 and it happens only after explicit user confirmation of the refined state.

package/prompts/refine/design-output.md

@@ -123,4 +123,4 @@ Commit the design document to git.
 
 ## Next Step
 
-Once the design is approved, invoke specflow:build Phase A to create the implementation plan.
+Once the design is approved, invoke specflow:apply Phase A to create the implementation plan.

package/prompts/refine/spec-document-reviewer.md

@@ -23,7 +23,7 @@ Task tool (general-purpose):
     | Completeness | TODOs, placeholders, "TBD", incomplete sections |
     | Consistency | Internal contradictions, conflicting requirements |
     | Clarity | Requirements ambiguous enough to cause someone to build the wrong thing |
-    | Scope | Focused enough for a single plan -- not covering multiple independent subsystems |
+    | Scope | Focused enough for a single propose -- not covering multiple independent subsystems |
     | YAGNI | Unrequested features, over-engineering |
 
     ## Calibration

package/prompts/review/code-review.md

@@ -9,7 +9,7 @@ Dispatch a code-reviewer subagent to catch issues before they cascade. The revie
 ## When to Request Review
 
 **Mandatory:**
-- After each task in specflow:build Phase B
+- After each task in specflow:apply Phase B
 - After completing major feature
 - Before merge to main
 
@@ -101,7 +101,7 @@ Task tool (general-purpose):
     - All tests passing?
 
     **Requirements:**
-    - All plan requirements met?
+    - All propose requirements met?
     - Implementation matches spec?
     - No scope creep?
     - Breaking changes documented?
@@ -196,12 +196,12 @@ You: [Fix progress indicators]
 
 ## Integration with Workflows
 
-**specflow:build Phase B:**
+**specflow:apply Phase B:**
 - Review after EACH task
 - Catch issues before they compound
 - Fix before moving to next task
 
-**specflow:build Phase B (inline mode):**
+**specflow:apply Phase B (inline mode):**
 - Review after each batch (3 tasks)
 - Get feedback, apply, continue
 

package/prompts/shared/code-reviewer-prompt.md

@@ -59,7 +59,7 @@ Task tool (general-purpose):
     - All tests passing?
 
     **Requirements:**
-    - All plan requirements met?
+    - All propose requirements met?
     - Implementation matches spec?
     - No scope creep?
 

package/prompts/shared/executing-plans.md

@@ -6,14 +6,14 @@
 
 Load plan, review critically, execute all tasks, report when complete.
 
-**Announce at start:** "I'm using specflow:build Phase B (inline mode) to implement this plan."
+**Announce at start:** "I'm using specflow:apply Phase B (inline mode) to implement this plan."
 
-**Note:** SpecFlow works much better with access to subagents. The quality of its work will be significantly higher if run on a platform with subagent support (such as Claude Code or Codex). If subagents are available, use specflow:build Phase B instead of this skill.
+**Note:** SpecFlow works much better with access to subagents. The quality of its work will be significantly higher if run on a platform with subagent support (such as Claude Code or Codex). If subagents are available, use specflow:apply Phase B instead of this skill.
 
 ## The Process
 
 ### Step 1: Load and Review Plan
-1. Read plan file
+1. Read propose file
 2. Review critically - identify any questions or concerns about the plan
 3. If concerns: Raise them with your human partner before starting
 4. If no concerns: Create TodoWrite and proceed
@@ -29,8 +29,8 @@ For each task:
 ### Step 3: Complete Development
 
 After all tasks complete and verified:
-- Announce: "I'm using specflow:done to complete this work."
-- **REQUIRED SUB-SKILL:** Use specflow:done
+- Announce: "I'm using specflow:archive to complete this work."
+- **REQUIRED SUB-SKILL:** Use specflow:archive
 - Follow that skill to verify tests, present options, execute choice
 
 ## When to Stop and Ask for Help
@@ -46,22 +46,22 @@ After all tasks complete and verified:
 ## When to Revisit Earlier Steps
 
 **Return to Review (Step 1) when:**
-- Partner updates the plan based on your feedback
+- Partner updates the propose based on your feedback
 - Fundamental approach needs rethinking
 
 **Don't force through blockers** - stop and ask.
 
 ## Remember
-- Review plan critically first
-- Follow plan steps exactly
+- Review propose critically first
+- Follow propose steps exactly
 - Don't skip verifications
-- Reference skills when plan says to
+- Reference skills when propose says to
 - Stop when blocked, don't guess
 - Never start implementation on main/master branch without explicit user consent
 
 ## Integration
 
 **Required workflow skills:**
-- **specflow:build Phase B (worktree)** - REQUIRED: Set up isolated workspace before starting
-- **specflow:build Phase A** - Creates the plan this skill executes
-- **specflow:done** - Complete development after all tasks
+- **specflow:apply Phase B (worktree)** - REQUIRED: Set up isolated workspace before starting
+- **specflow:apply Phase A** - Creates the propose this skill executes
+- **specflow:archive** - Complete development after all tasks

package/prompts/shared/implementer-prompt.md

@@ -12,7 +12,7 @@ Task tool (general-purpose):
 
     ## Task Description
 
-    [FULL TEXT of task from plan - paste it here, don't make subagent read file]
+    [FULL TEXT of task from propose - paste it here, don't make subagent read file]
 
     ## Context
 
@@ -50,7 +50,7 @@ Task tool (general-purpose):
     - Follow the file structure defined in the plan
     - Each file should have one clear responsibility with a well-defined interface
     - If a file you're creating is growing beyond the plan's intent, stop and report
-      it as DONE_WITH_CONCERNS -- don't split files on your own without plan guidance
+      it as DONE_WITH_CONCERNS -- don't split files on your own without propose guidance
     - If an existing file you're modifying is already large or tangled, work carefully
       and note it as a concern in your report
     - In existing codebases, follow established patterns. Improve code you're touching
@@ -65,7 +65,7 @@ Task tool (general-purpose):
     - The task requires architectural decisions with multiple valid approaches
     - You need to understand code beyond what was provided and can't find clarity
     - You feel uncertain about whether your approach is correct
-    - The task involves restructuring existing code in ways the plan didn't anticipate
+    - The task involves restructuring existing code in ways the propose didn't anticipate
     - You've been reading file after file trying to understand the system without progress
 
     **How to escalate:** Report back with status BLOCKED or NEEDS_CONTEXT. Describe

package/prompts/test/verification.md

@@ -94,7 +94,7 @@ WRONG:   "Linter passed" (linter doesn't check compilation)
 
 **Requirements:**
 ```
-CORRECT: Re-read plan -> Create checklist -> Verify each -> Report gaps or completion
+CORRECT: Re-read propose -> Create checklist -> Verify each -> Report gaps or completion
 WRONG:   "Tests pass, phase complete"
 ```
 

package/prompts/verify/verification.md

@@ -58,7 +58,7 @@ Skip any step = lying, not verifying
 
 | Signal | Action |
 |--------|--------|
-| Changed files not in the plan | Flag and explain why |
+| Changed files not in the propose | Flag and explain why |
 | Added features not in spec | Recommend removal |
 | Refactored unrelated code | Recommend reverting |
 | Over-engineered solution | Simplify to match requirements |
@@ -75,7 +75,7 @@ Skip any step = lying, not verifying
 | Regression test works | Red-green cycle verified | Test passes once |
 | Agent completed | VCS diff shows changes | Agent reports "success" |
 | Requirements met | Line-by-line checklist | Tests passing |
-| No scope creep | Diff matches plan scope | "I only changed what was needed" |
+| No scope creep | Diff matches propose scope | "I only changed what was needed" |
 
 ## Red Flags - STOP
 
@@ -111,7 +111,7 @@ WRONG:   "Should pass now" / "Looks correct"
 
 **Requirements + Scope:**
 ```
-CORRECT: Re-read plan -> Create checklist -> Verify each -> Check diff scope -> Report
+CORRECT: Re-read propose -> Create checklist -> Verify each -> Check diff scope -> Report
 WRONG:   "Tests pass, phase complete" (without scope check)
 ```
 

package/schemas/specflow/schema.yaml

@@ -1,12 +1,14 @@
 name: specflow
 version: 3
-description: SpecFlow workflow — scan → plan → refine → build → review → test → verify → done
+description: SpecFlow workflow — explore → propose → refine → apply → review → test → verify → archive
 
 artifacts:
-  - id: scan
-    generates: "specflow/specs/**/*.md"
-    description: Brownfield project scan - generates specs baseline
+  - id: explore
+    generates: "explore.md"
+    description: Pre-plan exploration - problem space, options, and recommended direction
     requires: []
+    instruction: |
+      Explore the problem before proposing. Capture findings in explore.md for propose handoff.
 
   - id: proposal
     generates: "proposal.md"

package/skills/{specflow-build → specflow-apply}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: specflow-build
-description: "Two-phase build — plan rewrite + subagent TDD execution"
+name: specflow-apply
+description: "Two-phase apply — task rewrite + subagent TDD execution"
 ---
 
-# SpecFlow: Build
+# SpecFlow: Apply
 
 > **HARD GATE (prerequisite)**: phase must be `refined`. Run /specflow:refine first if not.
 > **HARD GATE (Phase A)**: rewritten tasks.md must be user-confirmed before Phase B.
@@ -12,10 +12,10 @@ description: "Two-phase build — plan rewrite + subagent TDD execution"
 ## Prerequisites
 
 - An active change exists with `.specflow.yaml` and `phase: refined`.
-  - If phase is not `refined`, REFUSE to proceed and suggest: "This change is in phase `<phase>`. Run `/specflow:refine` first to complete deep review before build."
+  - If phase is not `refined`, REFUSE to proceed and suggest: "This change is in phase `<phase>`. Run `/specflow:refine` first to complete deep review before apply."
 - `design.md` is finalized (refine closed any ambiguity).
 - `specs/` is finalized (delta specs present for all modified/added capabilities).
-- Existing `tasks.md` is present (coarse first-iteration from `/specflow:plan`, or a refine-updated version).
+- Existing `tasks.md` is present (coarse first-iteration from `/specflow:propose`, or a refine-updated version).
 - `specflow` CLI is available on PATH.
 
 ---
@@ -26,7 +26,7 @@ Phase A transforms the existing coarse `tasks.md` into writing-plans precision.
 
 ### Stage A1: Load Inputs
 
-Read the file at `.claude/specflow/prompts/build/phase-a-plan.md` and follow its instructions.
+Read the file at `.claude/specflow/prompts/apply/phase-a-plan.md` and follow its instructions.
 
 Then read, in this order:
 1. `design.md` (finalized)
@@ -64,7 +64,7 @@ Present the rewritten `tasks.md` to the user. **Ask the user to confirm the rewr
 
 ### Stage B1: Worktree Setup
 
-Read the file at `.claude/specflow/prompts/build/phase-b-worktree.md` and follow its instructions.
+Read the file at `.claude/specflow/prompts/apply/phase-b-worktree.md` and follow its instructions.
 
 Set up the isolated build environment (worktree or branch) for implementation.
 
@@ -72,7 +72,7 @@ Set up the isolated build environment (worktree or branch) for implementation.
 
 After Stage B1 completes successfully and before the per-task loop starts:
 
-1. Read `.claude/specflow/prompts/build/language-router.md`.
+1. Read `.claude/specflow/prompts/apply/language-router.md`.
 2. If the file is missing, log `language-router.md not found, falling back to generic reviewer`, set `Language: unknown`, set `ReviewerFile: prompts/shared/code-reviewer-prompt.md`, and continue without interrupting Phase B.
 3. Otherwise check detection signals at the project root only, in router priority order (do not recurse into subdirectories).
 4. On first match, set `Language` to the language ID and `ReviewerFile` to the corresponding reviewer file path from the router table.
@@ -85,7 +85,7 @@ For each atomic task in the confirmed rewritten plan:
 
 #### B2a: Execute Task (implementer subagent)
 
-Read the file at `.claude/specflow/prompts/build/phase-b-execute.md` and follow its instructions.
+Read the file at `.claude/specflow/prompts/apply/phase-b-execute.md` and follow its instructions.
 
 Dispatch a fresh implementer subagent to implement the task using TDD:
 1. Write failing tests first
@@ -95,7 +95,7 @@ Dispatch a fresh implementer subagent to implement the task using TDD:
 
 #### B2b: Review Task (spec reviewer → code reviewer)
 
-Read the file at `.claude/specflow/prompts/build/phase-b-review.md` and follow its instructions.
+Read the file at `.claude/specflow/prompts/apply/phase-b-review.md` and follow its instructions.
 
 Dispatch a two-stage review: first a spec reviewer (does the implementation match the spec?), then a code quality reviewer (does the code meet quality standards?).
 
@@ -124,6 +124,6 @@ Once all tasks are confirmed:
 ## Phase Transition Notes
 
 - **On Phase B success**: phase → `built` (automatic via Stage B3 CLI call).
-- **On Phase A gap halt (Outcome 3)**: phase remains `refined`. No transition. User runs `/specflow:refine` to close gaps, then re-runs `/specflow:build`.
-- **On Phase A reorganization choice C**: phase remains `refined`. No transition. User edits groups manually, then re-runs `/specflow:build`.
+- **On Phase A gap halt (Outcome 3)**: phase remains `refined`. No transition. User runs `/specflow:refine` to close gaps, then re-runs `/specflow:apply`.
+- **On Phase A reorganization choice C**: phase remains `refined`. No transition. User edits groups manually, then re-runs `/specflow:apply`.
 - **On Phase B interruption or failing tests**: phase remains `refined`. User resumes Phase B later.