Spec-Driven Development

Turn requirements into specs, plans, code, and traceable change records.

Give people and coding agents a shared contract before implementation begins. FiboCode and Fibo Skills turn an initial request into explicit acceptance criteria, a linked design, an ordered plan, reviewed code, and a change record that stays with the repository.

Fast code is not the same as aligned code.

A coding agent can move from a short request to implementation quickly, but missing assumptions often surface only after files have changed. If the requirement, boundary, and proof of completion remain implicit, reviewers must reconstruct the intended behavior while also judging the code.

Spec-driven development creates an explicit path before execution. The requirement becomes testable acceptance criteria; design decisions state how those criteria will be met; the plan names ordered tasks, files, and verification. Implementation then has a visible contract, and the final diff record explains what actually changed.

See the workflow stay connected to real work.

These demonstrations show traceable project records growing with the code and the Agent CLI remaining inside the existing terminal workflow.

Demo video — spec, design, plan, diff, and analysis records unfolding with the codebase

See the document chain that connects an initial requirement to decisions, tasks, implementation evidence, and later understanding.

Demo video — workspace-aware file search, symbol lookup, image paste, and clickable terminal paths

Keep the Agent CLI in the terminal while giving it concrete files, symbols, screenshots, and navigable output paths.

Move from intent to evidence in four stages.

Each stage has a distinct purpose, so questions are resolved before they become hidden implementation choices.

  1. Clarify the requirement and acceptance criteria.

    Turn the initial request into explicit, testable outcomes and define what is outside the change. The developer signs off on the contract before production code begins.

  2. Design the approach against the criteria.

    Describe how the system will satisfy each criterion, including boundaries, interfaces, and important tradeoffs. Links keep decisions traceable to the behavior they serve.

  3. Create and execute an ordered plan.

    Break the design into bounded tasks with involved files and acceptance methods. The coding agent works through the sequence with the agreed context available.

  4. Review the code and record the real change.

    Inspect the resulting diff, verify the acceptance criteria, and preserve a hunk-focused explanation of what changed and why for future work.

A traceable contract around agent execution.

  • Acceptance criteria before implementation.

    A specification turns fuzzy intent into observable outcomes, giving both the developer and agent a shared definition of completion.

  • Design decisions linked to behavior.

    The design explains how the change should work and keeps each important decision connected to the criterion that requires it.

  • Bounded, ordered execution.

    Plans name tasks, involved files, and verification methods so implementation proceeds in reviewable units instead of one opaque leap.

  • Change history grounded in the diff.

    After execution, a real-diff record explains the implementation hunks and connects them back to surrounding logic and project intent.

Use case: changing behavior across several modules.

A request sounds simple but touches routing, state, UI, and validation. The developer first agrees on observable outcomes and exclusions. The design maps those outcomes to the affected boundaries, and the plan separates the work into file-scoped tasks with a verification method for each one.

The Agent CLI then executes with fewer hidden choices. Reviewers can compare the result with the signed criteria, inspect the actual code changes, and retain a diff record that explains how the implementation connects to the original requirement.

A workflow layer, not a replacement for your agent or tests.

Fibo Skills guides the clarification, specification, design, planning, execution, and change-record stages. Your chosen Agent CLI still performs the coding work, and the project’s real tests and acceptance methods still determine whether the result is correct.

The value is shared alignment and traceability. A prompt-first workflow can start coding with unresolved intent; the spec-driven path makes that intent reviewable before the change and keeps its evidence available afterward.

Spec-driven development FAQ

Do I need a specification for every small edit?

Use the workflow where behavior, boundaries, or acceptance need alignment. A tiny mechanical change may not need the same depth as a feature spanning several modules.

What are Fibo Skills?

Fibo Skills are the workflow instructions used with supported Agent CLI environments to guide clarification, specification, design, planning, execution, and change recording.

Can the agent start coding before sign-off?

The intended workflow asks the developer to approve the specification first, so production code is based on an explicit behavioral contract rather than unresolved assumptions.

How are design and plan kept traceable?

Design decisions link back to acceptance criteria, while plan tasks name the criteria, files, and acceptance methods involved in the work.

What happens after implementation?

The result is reviewed against the specification and real diff. A change record can then explain the implementation hunks and preserve why they exist.

Align the change before the agent writes it.

Download FiboCode for a connected spec workflow, or continue to the review surface that keeps the final implementation under human control.