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) runs propose + spec + design + tasks in a single pass for changes with clear, well-understood scope. Instead of reviewing each phase independently and running /sdd-continue three times, you review one consolidated set of artifacts before moving to implementation. The output is identical to the standard workflow — same four documents, same quality — just generated in a single uninterrupted pass.

When to use fast-forward

Use /sdd-ff when:
  • The scope is clear and you can describe it in a sentence
  • The change is self-contained (one domain, few files)
  • You’re working solo and don’t need per-phase team review
  • The feature or fix is straightforward with no cross-domain dependencies
Use the standard path (/sdd-new + /sdd-continue) when:
  • The change is large or touches multiple domains
  • Your team needs to review and approve the spec before design starts
  • You’re in an unfamiliar area of the codebase and want to validate understanding at each step
  • There is meaningful uncertainty about scope that should be resolved before documenting design decisions

Standard path vs. fast-forward

AspectStandardFast-Forward
PhasesSequential, reviewed one by oneAll 4 docs in one pass
Best forComplex changes, team reviewClear scope, solo dev
Pause pointsAfter each phaseOnly on ambiguity
Output artifactsSameSame
Context clearsBetween each phase recommendedOnce, before /sdd-apply

The fast-forward flow

/sdd-ff "add /health endpoint"
# AI generates proposal.md + specs/ + design.md + tasks.md in one pass
# Review the artifacts
/sdd-apply
/sdd-verify
/sdd-archive
The AI works through propose → spec → design → tasks without pausing between phases. If it encounters ambiguity it cannot resolve on its own, it pauses to ask a targeted question, then continues. After the pass completes, all four artifacts are presented together for your review before any code is written.

Real example: add-health-check

The api-demo example in the SDD Skills repository demonstrates a complete fast-forward cycle. The change adds a GET /health endpoint to a minimal Node.js API. Below are the actual artifacts produced.
# Proposal: Add health check endpoint

## Metadata
- **Change:** add-health-check
- **Ticket:** N/A
- **Date:** 2026-04-15

## Context

The API has a single root endpoint. Monitoring and orchestration tools (load
balancers, Kubernetes, uptime checks) need a dedicated health endpoint to
determine if the service is running and ready to serve traffic.

## Problem

There is no way to programmatically check if the API is healthy. The root
endpoint (`/`) returns `{ "status": "ok" }` but it is semantically a
general-purpose response, not a health signal. Monitoring tools need a
conventional `/health` endpoint.

## Scope

**In scope:**
- `GET /health` endpoint returning service status
- Response includes uptime

**Out of scope:**
- Dependency checks (database, external services)
- Authentication
- Metrics or Prometheus format

## Proposed Solution

Add a `GET /health` route that returns `200 OK` with a JSON body containing
`status` and `uptime` fields. Implement as a separate route handler file
following the project conventions.

## Alternatives Discarded

| Alternative | Reason discarded |
|-------------|-----------------|
| Reuse `GET /` as health check | Mixes concerns — root should describe the API, not its health |
| Return plain text `OK` | Inconsistent with JSON-only API convention |

## Risks & Mitigations

| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| Endpoint exposes internal info | Low | Low | Only return uptime, no version or env details |

## Impact

- **Files affected:** 2 (1 new route handler, 1 modified index.js)
- **Domains:** api
- **Tests:** 1 new test file for the health endpoint

## Dependencies

- None

## Acceptance Criteria

- [ ] `GET /health` returns `200` with `{ "status": "healthy", "uptime": <number> }`
- [ ] Other endpoints continue working unchanged
- [ ] Test covers happy path
# Spec: API — Add health check endpoint

## Metadata
- **Domain:** api
- **Change:** add-health-check
- **Date:** 2026-04-15
- **Status:** approved

## Expected Behavior

### Main Case

**Given** the API server is running
**When** a client sends `GET /health`
**Then** the server responds with:
- Status: `200 OK`
- Content-Type: `application/json`
- Body: `{ "status": "healthy", "uptime": <seconds since start> }`

### Alternative Cases

| Scenario | Condition | Result |
|----------|-----------|--------|
| Server just started | Uptime < 1 second | Returns `uptime: 0` (integer, floored) |

### Errors

| Error | When | Response |
|-------|------|----------|
| Method not allowed | `POST /health` | `405` with `{ "error": "method not allowed" }` |

## Business Rules

- **BR-01:** The health endpoint MUST NOT require authentication
- **BR-02:** Uptime MUST be an integer (seconds, floored)

## Decisions Made

| Decision | Alternative discarded | Reason |
|---------|-----------------------|--------|
| Return integer seconds for uptime | Milliseconds or ISO duration | Simplicity — seconds are universally understood |
| Include only status + uptime | Add version, commit hash | Minimize info exposure for a demo project |
# Design: Add health check endpoint

## Metadata
- **Change:** add-health-check
- **Date:** 2026-04-15
- **Status:** approved

## Technical Summary

Add a health check route handler in a new file under `src/routes/`. Modify
the main server to import and dispatch to this handler when the path matches
`/health`. Record the server start time at boot to calculate uptime.

## Architecture

    Request GET /health
      → index.js (routing)
        → routes/health.js (handler)
          → Response { status: "healthy", uptime: N }

## Files to Create

| File | Type | Purpose |
|------|------|---------|
| `src/routes/health.js` | Route handler | Returns health status + uptime |
| `test/health.test.js` | Test | Validates health endpoint behavior |

## Files to Modify

| File | Change | Reason |
|------|--------|--------|
| `src/index.js` | Import health handler, add route dispatch, record start time | Wire up the new endpoint |

## Scope

- **Total files:** 3
- **Result:** Ideal

## Design Decisions

| Decision | Alternative | Reason |
|---------|------------|--------|
| Separate route file | Inline in index.js | Follows convention: one file per domain in routes/ |
| Pass startTime as parameter | Global variable | Explicit dependency, testable |

## Implementation Notes

- `startTime` is captured once at server boot via `Date.now()`
- Health handler receives `startTime` and computes `Math.floor((Date.now() - startTime) / 1000)`
- The `src/routes/` directory does not exist yet — create it
# Tasks: Add health check endpoint

## Metadata
- **Change:** add-health-check
- **Ticket:** N/A
- **Branch:** add-health-check
- **Date:** 2026-04-15

## Implementation Tasks

- [x] **T01** Create `src/routes/health.js` — health check route handler
  - Commit: `[add-health-check] Add health route handler`

- [x] **T02** Modify `src/index.js` — import health handler, add route dispatch, record start time
  - Commit: `[add-health-check] Wire up health endpoint in server`
  - Depends on: T01

- [x] **T03** Create `test/health.test.js` — test health endpoint
  - Commit: `[add-health-check] Add health endpoint tests`
  - Depends on: T01, T02

## Quality Gate

- [x] **QG** Run tests and quality checks
  - `node --test`
With all four artifacts reviewed and approved, the remaining steps are the same as the standard workflow:
/sdd-apply     # implement T01 → T02 → T03, atomic commits
/sdd-verify    # full test suite + self-review checklist + PR
/sdd-archive   # merge delta spec into canonical, close cycle
Fast-forward is not guaranteed to be fully automated. If the AI finds ambiguity during any phase — for example, a spec edge case with two plausible behaviors, or a design decision that depends on a team preference — it pauses, asks a targeted question, and continues once you answer. The pause is surgical: only one question at a time, only when genuinely necessary.

Comparison

AspectStandardFast-Forward
PhasesSequential, reviewed one by oneAll 4 docs in one pass
Best forComplex changes, team reviewClear scope, solo dev
Pause pointsAfter each phaseOnly on ambiguity
OutputSame artifactsSame artifacts
When to clear contextBetween each phaseOnce, before /sdd-apply

Build docs developers (and LLMs) love