Fast-Forward Planning - Generate complete planning artifacts in one pass (Story → Plan → Tasks). Triggers: fast-forward, ff, all at once, 一次到位, 快轉
Scanned 9/2/2026
Install to Claude Code
npx -y skills add benwu95/prospec --skill prospec-ff --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Prospec Ff?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/benwu95-prospec-ff)More formats (shields.io, HTML) on the badges page.
---
name: prospec-ff
description: "Fast-Forward Planning - Generate complete planning artifacts in one pass (Story → Plan → Tasks). Triggers: fast-forward, ff, all at once, 一次到位, 快轉"
---
<!-- Generated by `prospec agent sync`. Do not edit — this file is regenerated on every sync. -->
# Prospec Fast-Forward Skill
## Activation
When triggered, briefly describe:
- That you'll generate planning artifacts (Story → Plan → Tasks) and can autonomously cascade through implementation, review, and verification
- A quick 3-question interview will be conducted first (or Draft-First inference if intent is clear)
- The metadata status will progress through story → plan → tasks (`scale: quick` skips plan: story → tasks)
- When cascading mode is active, execution continues until Verify Grade S/A is reached, halting for Tastemaker sign-off
## Language Policy
Write each generated document in the language the Constitution's Language Policy rule assigns to **its path** — change artifacts and their archived summaries in the project's artifact language, the trust zone (Knowledge base, Feature Specs, index) in English. One skill run may write both. Keep code, identifiers, technical terms, and git commit messages in English.
## CLI Prerequisite (required)
> The prospec CLI is a required file for this skill — its deterministic steps call `prospec`
> commands. Probe BEFORE any other step; there is no manual fallback.
1. Run `prospec --version` (Bash).
2. **Command not found / not executable** → STOP. Ask the user to install the prospec standalone
executable — the one-click installer script from the project README (macOS/Linux `install.sh`,
Windows `install.ps1`) or a release binary from GitHub Releases; prospec is NOT published to
npm. Then re-run this skill.
3. **Version older than 2.0.0** → STOP. Report the installed vs required version
and ask the user to upgrade, then re-run this skill.
Hand-executing a CLI-owned mutation is NEVER the fallback — that re-introduces the
nondeterministic serialization this contract exists to remove.
## Startup Loading
1. [STABLE] Read `prospec/CONSTITUTION.md` — prepare Constitution check
2. [DYNAMIC] Read `prospec/index.md` — identify related modules
> Format references are read **per phase on demand**, NOT as Startup Loading items (keeps the stable prefix lean): [`references/proposal-format.md`](references/proposal-format.md) + [`references/metadata-format.md`](references/metadata-format.md) at Phase 2, [`references/plan-format.md`](references/plan-format.md) + [`references/delta-spec-format.md`](references/delta-spec-format.md) + [`references/plan-verifier-rubric.md`](references/plan-verifier-rubric.md) at Phase 3, [`references/tasks-format.md`](references/tasks-format.md) + [`references/tasks-verifier-rubric.md`](references/tasks-verifier-rubric.md) at Phase 4, [`references/cascade-protocol.md`](references/cascade-protocol.md) + [`references/circuit-breaker.md`](references/circuit-breaker.md) + [`references/project-test-runner.md`](references/project-test-runner.md) for cascading execution. Read each when entering its phase; do not preload them into the stable prefix.
## Entry Gate
> Blocking precondition check before this skill runs. If any item FAILs, stop and tell the user what is missing — do not proceed.
- Constitution exists and is non-empty (ff runs the full story→plan→tasks chain).
- ff starts a new change — no prior `quality_log` to read on first run.
## Core Workflow
> Phases are numbered from 1 (no Phase 0).
### Harness Capabilities
**Harness capabilities** (resolved by `prospec agent sync` from this agent's registry entry — act on them, do not re-derive them at runtime): `can_spawn_subagent`: yes · `can_worktree`: no · `can_background`: yes
Sub-agents are available here, so take the sub-agent path. Should a spawn fail at runtime anyway, degrade — run planning verifiers sequentially with prompt isolation; after planning, re-read each downstream station and use that station's own disclosed degradation path — and name the path you took. A degraded path is never a silent skip: the developer is told which path ran, every time.
### Phase 1: Quick Interview (3 questions to converge)
Collect: Core goal (one sentence), primary user, key acceptance criteria (3-5 points).
Derive kebab-case change name. STOP. Ask the user to confirm the change name **and, in the same
question, which tracker item this change belongs to (optional — accept "none")**; do not enter Phase 2
until a reply is received. Folding the tracker question into the name confirmation is deliberate: it
is not a fourth interview question, so the three-question ceiling below still holds. The answer is
free-form (a reference, a URL, another tracker's id) and is written by `prospec change story --issue`
in Phase 2 — prospec judges nothing about its shape and calls no API (runs of whitespace, line breaks
included, collapse to one space). No answer means the field is simply
absent; never invent one, and never derive one from the branch name.
> **Phase 1 Gate** — proceed when:
> - [ ] change name (kebab-case) confirmed
> - [ ] core goal, primary user, and 3-5 ACs collected
> - [ ] tracker item asked for alongside the name — answered, or explicitly declined
### Phase 2: Story Generation
| Step | Action |
|------|--------|
| Scaffold | Run `prospec change story [name] --description "<one-liner>" [--issue <ref>]` (Bash) — CLI scaffolds `.prospec/changes/[name]/` + `metadata.yaml`(status: story) + `proposal.md`. Pass `--issue` only when Phase 1 got a tracker item; the flag exists ONLY here, so a skipped answer cannot be amended later without rebuilding the change |
| Scale | Run the complexity assessment from `prospec-new-story` Phase 3.5 (criteria table + quick veto). STOP. Ask the user to confirm the scale; do not proceed with this phase until a reply is received. Write it via `prospec change scale <scale>` (Bash). Quick → slim proposal form |
| Populate | Read [`references/proposal-format.md`](references/proposal-format.md) on demand, then write User Story and ACs to that format |
| Check | Site-specific Constitution check (this phase's rule: INVEST) → PASS continue / FAIL pause — the full every-principle audit is `prospec-verify` only |
**Scale routing:** when `scale: quick` is confirmed, SKIP Phase 3 entirely — no plan.md, no
delta-spec.md, and no module README loading (Phase 3's Layer 2 step; `prospec/index.md` from Startup
Loading is still read). Status advances `story → tasks` directly
(a legal quick-path transition; see `prospec/ai-knowledge/_status-lifecycle.md`). The
`prospec-archive` Entry Gate later re-checks spec and knowledge impact against the actual diff.
> **Phase 2 Gate** — proceed when:
> - [ ] `proposal.md` + `metadata.yaml`(status: story) created
> - [ ] `metadata.scale` confirmed by user and written
> - [ ] Site-specific Constitution check (INVEST) passed (pause on FAIL)
### Phase 3: Plan Generation (skipped when `scale: quick`)
| Step | Action |
|------|--------|
| Knowledge | Layer 1 (prospec/index.md) → Layer 2 (related module READMEs + any `{sub-module}.md` they link) |
| Scaffold | Run `prospec change plan` (Bash) — CLI scaffolds `plan.md` + `delta-spec.md` and advances status → `plan` |
| Populate | Read [`references/plan-format.md`](references/plan-format.md) + [`references/delta-spec-format.md`](references/delta-spec-format.md) on demand, then write to those formats |
| Check | Read [`references/plan-verifier-rubric.md`](references/plan-verifier-rubric.md) on demand. Run site-specific Architecture Verification (dependency-direction/layering & orthogonal rubric). Apply **Physical Receipt Verification Protocol** to verifier report (readable regular file exists, `size > 0`, valid schema); when a completion claim precedes the write, inspect lifecycle/transcript evidence and await it; missing or invalid report stops the phase, while terminal failure takes explicit Harness Degradation. Support harness degradation & manual bypass → PASS continue / WARN log / FLAW pause |
> **Phase 3 Gate** — proceed when:
> - [ ] (standard/full) `plan.md` + `delta-spec.md` created, status → `plan`
> - [ ] (quick) phase marked skipped per `scale: quick` — no plan artifacts produced
### Phase 4: Tasks Generation
| Step | Action |
|------|--------|
| Scaffold | Run `prospec change tasks` (Bash) — CLI scaffolds `tasks.md` and advances status → `tasks` (including the quick `story → tasks` transition) |
| Populate | Read [`references/tasks-format.md`](references/tasks-format.md) on demand, then decompose by architecture layer to that format |
| Check | Read [`references/tasks-verifier-rubric.md`](references/tasks-verifier-rubric.md) on demand. Run site-specific Task Contract Verification (bidirectional coverage, DAG dependency layering, TDD closure). Apply **Physical Receipt Verification Protocol** to verifier report (readable regular file exists, `size > 0`, valid schema); when a completion claim precedes the write, inspect lifecycle/transcript evidence and await it; missing or invalid report stops the phase, while terminal failure takes explicit Harness Degradation. Support harness degradation & manual bypass → PASS continue / WARN log / FLAW pause |
> **Phase 4 Gate** — proceed when:
> - [ ] tasks.md created with layer-ordered tasks and kind markers, status → `tasks`
> - [ ] Task Contract Verification passed (or documented Break-Glass override)
### Phase 5: Autonomous Execution & Cascading (when cascading active)
**Autonomous Pipeline Cascading**: in cascading mode, execution advances seamlessly across `story → [plan] → tasks → implement → review → verify → knowledge-update` as machine verifiers PASS, protected by Circuit Breakers, halting strictly at Tastemaker presentation for human sign-off.
**Station Transition & Receipt Protocol**: On advancing to each station, re-read and reload that downstream skill to ensure full compliance with its receipt contracts and entry gates.
Read [`references/cascade-protocol.md`](references/cascade-protocol.md), [`references/circuit-breaker.md`](references/circuit-breaker.md), and [`references/project-test-runner.md`](references/project-test-runner.md) on demand:
1. **Implementation**: Execute code tasks sequentially in the project's dependency-layer order (as grouped in `tasks.md` per [`references/tasks-format.md`](references/tasks-format.md) / `_conventions.md`). Invoke dynamic project test command (`check --record-tests` or detected runner) to ensure tests pass. Set `status: implemented`.
2. **Adversarial Review Loop**: Run review pass, enforcing the **Physical Receipt Verification Protocol** on review findings payloads (`ReviewFindingsInputSchema`) before calling `prospec review merge`, auto-fixing verifier-confirmed criticals. Guarded by Oscillation Breaker (red-green-red detector) and 3-5 round limit.
3. **Verify Audit**: Execute 5+1 dimension audit, enforcing the **Physical Receipt Verification Protocol** on dimension verdicts (`JudgmentDimensionsInputSchema`) before calling `prospec verify record`, until Grade S/A is reached (`status: verified`).
4. **Tastemaker Presentation**: Present Git Diff, Verify report, and Delta-Spec summary. **HALT** for human sign-off; do not commit or archive automatically.
> **Phase 5 Gate** — proceed when:
> - [ ] all code tasks implemented and test suite green (status: implemented)
> - [ ] review loop clean (0 unresolved criticals) and verify 5+1 audit achieves Grade S/A
> - [ ] Tastemaker summary presented for human review without automated commit or archive
### Completion: Summary Report
List all produced files and task statistics. If planning only, suggest `prospec-implement`. If cascading completed, present the Tastemaker summary for human sign-off.
## Next-Step Handoff
After the Output Summary, recommend the next step in the SDD workflow order
(`story → plan → tasks → implement → review → verify → knowledge-update → archive`, then periodic `learn`) — read
`metadata.yaml` status and `prospec/ai-knowledge/_status-lifecycle.md` (review and learn own no
status transition, so follow this order, not status alone). Provide the direct, actionable Skill
identity or CLI command for the next step (e.g. `prospec-plan`), allowing smooth continuation
without blocking on a separate confirmation turn. If the stage is terminal (`archived`), the linear
flow is complete — point to periodic `prospec-learn` rather than a workflow successor. If the result
does not advance (e.g. verify grade B/C/D), say so and point to the corrective step instead of
offering the next skill.
## Error Recovery
| Failed Phase | Preserved | Recovery Options |
|-------------|-----------|-----------------|
| Story fails | Change directory | Retry / switch to `prospec-new-story` |
| Plan fails | proposal.md | Retry / switch to `prospec-plan` |
| Tasks fails | proposal.md (+ plan.md + delta-spec.md for standard/full) | Retry / switch to `prospec-tasks` |
| Implement / Review fails | working tree + tasks.md | Resolve blocker or switch to single-station skill |
| Circuit breaker tripped | state & diagnostics | Escalate to human with trade-off options |
| Severe Constitution violation | All parts completed before failure | Pause FF, switch to single-phase Skill |
## When to Use vs. Not to Use
| Suitable for FF / Cascading | Not suitable for FF |
|-----------------------------|-------------------|
| Requirements clear, well-explored | Requirements vague, need discussion |
| Verifier gates in place | Major architectural uncertainty |
| Independent scope, low-to-medium risk | Untracked legacy codebase without tests |
| Tight schedule / high autonomy | First time with project |
## Output Contract
> After running, self-assess and emit a concise Output Summary. Every Success Criterion must be objectively checkable (file existence / grep / test result / count) — no subjective adjectives.
### Success Criteria
- [ ] proposal and tasks produced; plan produced unless `scale: quick` (quick: plan.md/delta-spec.md absent by contract)
- [ ] each stage's own Output Contract is satisfied (manual)
- [ ] cascading halts strictly at Tastemaker Sign-off (Verify S/A) without automated commit or archive
### Failure Conditions
- any stage artifact missing or failing its Output Contract (quick: plan artifacts are not missing — they are skipped by contract)
- auto-committing or archiving during cascading without explicit human sign-off
### Output Summary
Emit one line: `Met N/M | Unmet: <items> | Overall: PASS|WARN|FAIL | Next: <one-line>`
### Exit Gate (Constitution)
Verify the output against each phase's **site-specific** Constitution rule (INVEST for story, dependency-direction/layering and architecture verifier rubric for plan, TDD coverage and task verifier rubric for tasks) — NOT the full Constitution; the every-principle audit is `prospec-verify` V3/5 only. When a rule carries RFC-2119 severity, grade by weight — MUST→FAIL, SHOULD→WARN, MAY→informational (the grade vocabulary stays PASS/WARN/FAIL). A free-text Constitution falls back to judgment-based grading. Record each WARN/FAIL via `prospec change log --skill <station> --result WARN|FAIL --warning "<detail>"` (the CLI owns the `quality_log` serialization). Advisory — surface issues, do not hard-block.
## NEVER
- **NEVER** use FF when requirements are vague — guide user to `prospec-explore` first
- **NEVER** run a generic multi-principle Constitution scan per phase — each phase checks only its site-specific rule (INVEST / dependency-direction / TDD); the full every-principle audit is `prospec-verify`'s job (single-full-audit convergence)
- **NEVER** ask more than 3 questions in Phase 1 — FF prioritizes speed, use `prospec-explore` for depth
- **NEVER** inline full format prose into this skill body — load this skill's `references/` files directly
- **NEVER** skip metadata.yaml status progression — story → plan → tasks (or story → tasks under `scale: quick`); the `prospec change` commands own every transition — never hand-edit metadata.yaml
- **NEVER** discard completed phases on failure — error recovery is FF's core capability
- **NEVER** skip Layer 2 knowledge loading for standard/full — Plan phase must load related module AI Knowledge (quick skips Plan and loads none)
- **NEVER** skip Phase 3 without a `scale: quick` in metadata.yaml — confirmed by the user, or assigned by `prospec change auto-draft` from the drift check it drafted for; skipping plan is an explicit contract, not a shortcut
- **NEVER** take verbal shortcuts, bypass receipt gates, or fabricate mock payloads during fast-forward cascading — all subagent outputs must be physically verified
- **NEVER** automatically commit, push, or archive during autonomous cascading without explicit human Tastemaker approval
- **NEVER** continue cascading past a tripped circuit breaker or unresolved critical findings
- **NEVER** use passive voice for confirmation wait points (e.g., "confirm before proceeding") — always use an active imperative ("STOP. Ask the user...").
- **NEVER** proceed into Phase 2 without the user's explicit reply to the change name, nor proceed past the Scale step without the user's explicit reply to the scale.
## Error Handling
| Scenario | Action |
|----------|--------|
| Constitution severe violation at any phase | Pause FF, preserve completed parts, switch to single-phase Skill |
| User changes requirements mid-flow | Restart from Phase 1 with new requirements |
| Module Knowledge insufficient | Proceed with available info, note gaps in plan.md Risk Assessment |
| Circuit breaker tripped | Halt cascading, emit EscalationReport to human |
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!