@gordon.gan/specflow 1.0.1 → 1.1.0

package/skills/specflow-refine/SKILL.md

@@ -16,8 +16,8 @@ emits a round diff summary.
 
 ## Prerequisites
 
-- Active change with `.specflow.yaml` `phase=plan` (refine refuses if phase is not `plan`).
-- All 4 plan-phase artifacts exist in `specflow/changes/<name>/`:
+- Active change with `.specflow.yaml` `phase=propose` (refine refuses if phase is not `propose`).
+- All 4 propose-phase artifacts exist in `specflow/changes/<name>/`:
   - `proposal.md`
   - `specs/**/*.md` (at least one delta spec)
   - `design.md`
@@ -107,18 +107,18 @@ Stage 4 round-end output.
 Only reached after Stage 5 declared convergence AND the user did not request another round.
 
 1. Present a **cross-round summary**: what changed in each round, which artifacts now differ
-   from the plan-phase baseline, which decisions were resolved, which questions remained
+   from the propose-phase baseline, which decisions were resolved, which questions remained
    open (if any).
 2. **HARD GATE**: Wait for the user's explicit confirmation of the final refined state.
    A mere acknowledgement of a round's diff summary is NOT confirmation of the overall
    refined state — ask explicitly: "Confirm this refined state is final and I should mark
    the phase as `refined`?"
 3. On explicit confirmation: invoke `specflow change phase <name> --set refined` to
-   advance `.specflow.yaml` `phase` from `plan` to `refined`.
+   advance `.specflow.yaml` `phase` from `propose` to `refined`.
 4. Suggest `/specflow:apply` as the next slash command.
 
 If the user declines to confirm and requests more exploration, treat it as a user-requested
-extra round (loop back to Stage 2, phase stays `plan`).
+extra round (loop back to Stage 2, phase stays `propose`).
 
 ## Not covered by refine
 

package/skills/specflow-snap/SKILL.md

@@ -39,7 +39,7 @@ Do NOT archive until confirmed.
 
 ## Stage 4: Mark Phase Built
 
-Before archive, invoke `specflow change phase <name> --set built` since snap produces a complete retroactive record equivalent to a built change. The CLI creates the snap change with `phase=plan`, but snap's entire flow (analyze → generate → infer → confirm) is post-hoc documentation of already-built work, so setting the phase explicitly satisfies the archive guard without needing `--force`.
+Before archive, invoke `specflow change phase <name> --set apply` since snap produces a complete retroactive record equivalent to an apply-complete change. The CLI creates the snap change with `phase=propose`, but snap's entire flow (analyze → generate → infer → confirm) is post-hoc documentation of already-implemented work, so setting the phase explicitly satisfies the archive guard without needing `--force`.
 
 ## Stage 5: Archive
 

package/skills/specflow-scan/SKILL.md

@@ -1,48 +0,0 @@
----
-name: specflow-scan
-description: "[PLANNED v0.3] Brownfield project scanner -- not yet functional"
----
-
-# SpecFlow: Scan (Planned — v0.3)
-
-> **NOT YET FUNCTIONAL.** The `specflow scan` CLI subcommand does not exist in v0.2.x. Invoking this skill would immediately fail when it tries to run `specflow scan`. The skill is kept registered so its slot is reserved in the command namespace; the implementation is planned for v0.3.
-
-## Behavior in v0.2.x
-
-If the user triggers `/specflow:scan` or `$specflow-scan`, do NOT attempt to run `specflow scan` (the CLI will return an unknown-command error). Instead respond:
-
-> "`/specflow:scan` / `$specflow-scan` is planned for v0.3 and not yet implemented in v0.2.x. For a brownfield project that has no `specflow/specs/` baseline yet, the workable alternative today is:
->
-> 1. Run `specflow init --ide both` (or `--ide all` / `--ide codex`) if not already done (creates `specflow/` and IDE assets under `.cursor/`, `.claude/`, and/or `.agents/`).
-> 2. Identify one capability area you are about to change (e.g. `user-auth`, `billing`).
-> 3. Run `/specflow:explore` when requirements are fuzzy, then `/specflow:propose`. Or run `/specflow:propose` directly if you already know exactly what to build. In the proposal Q&A, describe the existing behavior in the affected area — propose will generate both the delta spec for your change and an implicit first pass at the capability's contract. After the first archive, the delta becomes the main spec baseline for that capability.
->
-> This is not a perfect substitute for a full code scan, but it keeps the spec-driven flow moving without waiting for v0.3."
-
-Then stop. Do not proceed to any Stage 1/2/3 behavior below — those describe the planned v0.3 flow.
-
-## Planned design (v0.3) — for reference, not currently executable
-
-### Planned Stage 1: Execute Scan
-
-Run `specflow scan` against the target project. If `--module` flag is provided, read the IDE-local prompt file:
-
-- Cursor: `.cursor/specflow/prompts/shared/dispatching-parallel-agents.md`
-- Claude: `.claude/specflow/prompts/shared/dispatching-parallel-agents.md`
-- Codex: `.agents/specflow/prompts/shared/dispatching-parallel-agents.md`
-
-Then scan modules in parallel; otherwise run a single pass.
-
-### Planned Stage 2: Present Results
-
-Scan produces `specflow/SCAN_REPORT.md`. Present a summary highlighting detected modules, identified specs and coverage gaps, and suggested next actions.
-
-### Planned Gate: User Confirmation
-
-Ask the user to confirm the scan results. Do NOT proceed until explicit confirmation. Confirmed results become the Source of Truth for all downstream commands.
-
-### Planned Stage 3: Finalize
-
-Once confirmed, the scan results are locked and the user can run `/specflow:propose` to begin requirements planning.
-
-The v0.3 design rationale, scope, and risks will be captured in a dedicated `openspec` change at v0.3 planning time.