Spec-Driven Workflow

The three stages that route every significant change through human review.

This is what most distinguishes Prompter. Instead of asking an AI to write code immediately, you make it pass through three human-reviewable stages. Specs are truth; changes are proposals.

The three stages

Create a proposal

The agent writes proposal.md (why & what), tasks.md (a checklist), and spec deltas marking which requirements are ADDED, MODIFIED, or REMOVED. No code is written at this stage.

prompter validate <change-id> --strict

Implement

Once you approve the proposal, the agent works through tasks.md in order and ticks items off only when genuinely done. That approval gate is deliberate.

prompter show <change-id> --json --deltas-only

When is a proposal warranted?

Warrants a proposal

A new feature or capability
A breaking change to an API or schema
An architecture or pattern change
Significant security or performance work

Just do it directly

A bug fix restoring intended behavior
Typos, formatting, or comments
Non-breaking dependency updates
Configuration changes

Spec Deltas

A proposal doesn't rewrite an entire spec. It records just the change, using four operations:

ADDED: A new capability that stands on its own.
MODIFIED: Changes an existing requirement's behavior. You must paste the full old requirement and then edit it — otherwise the old detail is lost at archive time.
REMOVED: A discontinued feature, with a reason and migration path.
RENAMED: Only the name changes; behavior stays put.

Scenario format

Every requirement needs at least one scenario, and scenarios must use four hashes. Bullets or bold text are skipped by the parser without warning.

#### Scenario: OTP required
- **WHEN** valid credentials are provided
- **THEN** an OTP challenge is required

Last updated: May 16, 2026