@gordon.gan/specflow 1.1.0 → 1.1.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gordon.gan/specflow",
-  "version": "1.1.0",
+  "version": "1.1.1",
   "type": "module",
   "description": "SpecFlow — unified spec-driven development: OpenSpec planning + Superpowers execution in one CLI and cross-IDE workflow",
   "keywords": [

package/skills/specflow-apply/SKILL.md

@@ -5,6 +5,15 @@ description: "Two-phase apply — task rewrite + subagent TDD execution"
 
 # SpecFlow: Apply
 
+## Invocation mode
+
+Inspect the current user invocation before any stage work:
+
+- **Default mode:** `/specflow:apply` preserves every existing user confirmation gate and the default interactive behavior.
+- **Yes mode:** `/specflow:apply --yes` records non-interactive confirmation mode for the current invocation only. It auto-accepts only successful acknowledgement gates; it never bypasses prerequisites, gap detection, failing verification, or a review `Block`.
+
+Report the selected mode once at the start of the session. Do not persist it to future invocations.
+
 > **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.
 > **HARD GATE (Phase B)**: each task must be reviewed (spec + code quality) and user-confirmed before next task.
@@ -56,7 +65,10 @@ Present the audit summary to the user: per-group task count (coarse → atomic),
 
 ### Gate A: Rewrite Confirmation
 
-Present the rewritten `tasks.md` to the user. **Ask the user to confirm the rewrite.** Do NOT proceed to Phase B until the user explicitly confirms.
+- **Default mode:** Present the rewritten `tasks.md` and ask the user to confirm the rewrite. Do NOT proceed to Phase B until the user explicitly confirms.
+- **Yes mode:** Present the rewrite audit and continue directly to Phase B after recording the rewrite as automatically accepted for this invocation.
+
+If Phase A reports a reorganization choice or a design gap, stop regardless of mode; `--yes` does not choose a reorganization or fill a missing design decision.
 
 ---
 
@@ -108,16 +120,26 @@ ECC reviewer verdict routing:
 
 #### Gate B: Per-task Confirmation
 
-Present the task output and both review reports to the user. **Ask the user to confirm the task is complete.** Do NOT proceed to the next task until confirmation is received.
+- **Default mode:** Present the task output and both review reports. Ask the user to confirm the task is complete. Do NOT proceed to the next task until confirmation is received.
+- **Yes mode:** Present the task output and both review reports. If spec review passes and code-quality review returns `Approve` or `Warning`, record the task as automatically accepted and start the next task without waiting.
 
-If the user rejects, return to Stage B2a for the same task.
+If either review blocks, return to Stage B2a for the same task. `--yes` never advances past a blocked review.
 
 ### Stage B3: Phase Transition
 
-Once all tasks are confirmed:
+Once all tasks are confirmed in default mode or automatically accepted in yes mode:
 - Invoke `specflow change phase <name> --set apply` to transition the phase.
 - Summarize the build results and overall coverage.
-- Inform the user they can now run `/specflow:review` or `/specflow:verify`.
+
+#### Yes-mode downstream sequence
+
+When yes mode reaches this point:
+1. Invoke `/specflow:review`. Stop if it reports a CRITICAL or HIGH finding.
+2. Invoke `/specflow:test` only after review has no CRITICAL/HIGH findings. Stop if tests cannot be made green.
+3. Invoke `/specflow:verify` only after test succeeds. Stop if verify returns `FAIL`.
+4. Report review, test, and verification evidence. Do NOT invoke `/specflow:archive` automatically; archive remains the user's manual choice.
+
+When default mode reaches this point, inform the user that they can now run `/specflow:review` or `/specflow:verify`.
 
 ---