Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jorgeferrando/sdd-skills/llms.txt

Use this file to discover all available pages before exploring further.

/sdd-ff (Fast-Forward) is the accelerated path through SDD’s planning cycle. Instead of running /sdd-propose, /sdd-spec, /sdd-design, and /sdd-tasks individually and pausing for approval between each phase, Fast-Forward chains them all into a single uninterrupted pass. Use it when the scope is clear, the requirements are well-understood, and you want all four planning artifacts produced immediately. If any genuine ambiguity surfaces mid-run, the skill pauses to ask a targeted question and then resumes exactly where it left off.

​
Usage

/sdd-ff "add health check endpoint"   # Fast-forward from a description
/sdd-ff TICKET-789                    # Fast-forward from a ticket reference

​
Prerequisites

  • openspec/ initialized — run /sdd-init if it does not exist yet.

​
Fast-Forward vs. Standard Mode

Both paths produce the same four artifacts. The difference is pace and checkpoints.
Fast-Forward (/sdd-ff)Standard (/sdd-new + /sdd-continue)
Pauses between phasesNo — runs all four in sequenceYes — stops after each for review
Best forClear scope, well-understood requirementsComplex changes, multi-domain, team review needed
Ambiguity handlingPauses only when a decision cannot be inferredPauses after every phase by design
Time to first codeFasterSlower, more deliberate
Human checkpointsOne (final review before /sdd-apply)Four (one per phase)

​
What It Does

Fast-Forward runs five phases in sequence without prompting between them.
1
Explore
2
Quick read-only codebase scan:
3
  • Existing patterns similar to the requested change
  • Files likely to be affected
  • Related canonical specs in openspec/specs/
    • 4
    No files are written. The findings inform the proposal phase directly.
    5
    Propose
    6
    Analyzes the input against all required proposal sections — Context, Problem, Scope, Proposed Solution, Alternatives Discarded, Risks & Mitigations, Impact, Dependencies, and Acceptance Criteria. If any section cannot be substantively filled from the available information, the skill uses AskUserQuestion to resolve the gap before writing.
    7
    Produces: openspec/changes/{change-name}/proposal.md
    8
    Spec
    9
    Writes a behavior specification covering:
    10
  • Expected behavior in Given / When / Then format
  • Alternative and edge cases
  • Business rules
    • 11
    Produces: openspec/changes/{change-name}/specs/{domain}/spec.md
    12
    Design (as subagent)
    13
    Design runs as a subagent rather than inline. Because design is non-interactive — it reads proposal.md, spec.md, and existing source files, then writes design.md — running it as an agent keeps the Fast-Forward context clean of code-reading noise. The orchestrator waits for the agent to return its summary before moving on.
    14
    Produces: openspec/changes/{change-name}/design.md with:
    15
  • Technical architecture and files to create or modify
  • Implementation detail per file
  • Design decisions with alternatives considered
    • 16
    Tasks
    17
    Creates an ordered, atomic task list with commit hints and inter-task dependencies.
    18
    Produces: openspec/changes/{change-name}/tasks.md
    When the run completes, the skill prints a summary: 
    FF COMPLETE: {change-name}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
proposal.md  ✓
spec.md      ✓  ({domain})
design.md    ✓  ({N} files)
tasks.md     ✓  ({N} tasks)

Next: /sdd-apply to implement

    ​
    Output

    All four artifacts land in openspec/changes/{change-name}/:
    ArtifactPathContent
    Proposalproposal.mdProblem, solution, alternatives, acceptance criteria
    Specspecs/{domain}/spec.mdGiven/When/Then behaviors and business rules
    Designdesign.mdFile-level technical plan and design decisions
    Taskstasks.mdOrdered atomic tasks with commit hints

    ​
    Skill Metadata

    FieldValue
    model_hintsonnet (orchestrator); design subagent uses opus; tasks uses haiku
    requiresopenspec/config.yaml
    producesproposal.md, specs/*/spec.md, design.md, tasks.md
    Each sub-phase uses its own model hint internally. Propose and design use opus for judgment-heavy work; spec uses sonnet; tasks uses haiku for mechanical breakdown. If the tool does not support model selection, the default model is used throughout.

    ​
    Next Steps

    With all four artifacts in place, run /sdd-apply to implement the change task by task. Each task gets its own commit following the hints in tasks.md. If you want to review any artifact before implementing, open the relevant file under openspec/changes/{change-name}/ and edit it directly — /sdd-apply always reads the latest version on disk.

    Build docs developers (and LLMs) love

    Get started for freeTalk to us