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-verify is the final quality gate before a pull request is created. It runs the full test suite, checks linting on changed files, works through a structured self-review checklist, and confirms that the implementation matches the spec. It runs as a non-interactive subagent — it gathers results and produces a final report without asking questions during execution. Use /sdd-verify after all tasks in tasks.md are marked [x].

​
Usage

/sdd-verify                # Verify the active change
/sdd-verify {change-name}  # Verify a specific change

​
Prerequisites

  • /sdd-apply completed — all tasks in tasks.md marked [x]

​
What it does

1

Identify changed files

Builds the list of files to review by comparing against the base branch:
git diff --name-only main..HEAD
# or dev..HEAD depending on the project's base branch
2

Run the full test suite

Reads openspec/steering/tech.md for the configured test command. Runs all tests:
# Use whatever the project is configured to use:
pytest
npm test
go test ./...
./gradlew test
All tests must pass before proceeding. If no test command is configured and no test runner is detected, this step is skipped and noted in the final report as Tests: SKIPPED (no test runner configured).
3

Quality checks

Reads openspec/steering/tech.md for configured linters and formatters. Runs them on the changed files:
# Examples:
ruff check src/
eslint src/
golangci-lint run
Any issues found are fixed, re-run, and committed atomically as part of this verify step. If no linter is configured, noted in the report as Quality: SKIPPED (no linter configured). No new tools are installed during verify.
4

Self-review checklist

Reviews the changed code against eight categories:1. Tests exist for new code
  • New functions/methods have tests
  • Edge cases are covered
  • Error paths are tested
2. Input validated before processing
  • Required fields checked
  • Types/formats validated at system boundaries
  • No raw user input passed to internal logic unvalidated
3. Methods are small and focused
  • No method exceeds 50 lines
  • Nesting depth below 3 levels
  • One responsibility per method
4. No hardcoded values
  • Magic numbers extracted to constants
  • Status/type strings use enums or constants
  • No environment-specific values in source code
5. No code duplication
  • Similar logic extracted to shared methods
  • Consistent patterns with the existing codebase
6. Type hints / type safety
  • All method parameters typed
  • All return types declared
  • Nullable types explicit
7. Null / None checks
  • Results checked before use
  • Optional parameters handled
  • Exceptions raised for unexpected nulls
8. Spec compliance
  • All spec cases covered
  • Input/output contracts match
  • Business rules implemented
  • Error messages match spec
5

Smoke test (UI/TUI projects)

If the project has a UI, runs it manually and verifies the changed behavior end-to-end. If a bug is found during smoke test, it is documented as BUGxx in tasks.md before fixing, then committed atomically. Smoke test runs again until it passes.
6

Convention audit

If openspec/steering/conventions.md exists, runs sdd-audit on the changed files as an additional quality gate. Includes the audit result in the final report. Critical violations (MUST / MUST NOT rules) are fixed before proceeding.
7

Produce the final report

Outputs the verify report to the conversation:
VERIFY REPORT: {change-name}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Tests:        N/N PASS
Quality:      PASS
Self-review:  ✓
Spec compliance: ✓
Audit:        ✓ (N rules checked, 0 violations)

Status: READY FOR PR
If any check fails, the report lists the specific issues to address. Rerun /sdd-verify after fixing them.
8

Create the PR

After a clean report, pushes the branch and creates the pull request:
git push -u origin {branch-name}
Uses proposal.md for the PR title and body:
  • Title: short summary from the proposal
  • Body: Problem, Proposed Solution, and Acceptance Criteria sections
Shows the PR URL in the conversation.

​
Skill metadata

PropertyValue
model_hintsonnet
requiresopenspec/changes/{change}/tasks.md
producesVERIFY REPORT (no new OpenSpec artifacts)

​
Next steps

With a clean VERIFY REPORT and the PR created, run /sdd-archive to close the change cycle, merge the delta specs into the canonical specs, and move the change to the archive.
If verify finds issues in multiple categories, fix them in a single commit rather than one commit per issue. The goal is a clean, atomic fix commit — not a commit for every line changed.

Build docs developers (and LLMs) love

Get started for freeTalk to us