Specs that live in your repo — and double as design-control evidence.

## How it works

One contract. Two ways to edit. Git in the middle.

The skill edits programmatically; humans review visually. Both obey the same schema and governance rules — and git keeps the history.

## Features

Spreadsheet-fast on the surface. Audit-grade underneath.

Each capability twice over — what you see in the editor, and the mechanism behind it.

01 Effortless requirements editing

A spreadsheet-fast table for your SRS and VTP. The editor opens files straight from your repo — no server, no import, nothing leaves your machine.

02 Docs that keep up with your code

The Claude skill reads and writes the same files. Finish a change, say “update the spec” — requirements and tests stay current without leaving the terminal.

claude — your repo

> update the spec for the new export flow

✓ updated specpad.srs.json (2 requirements)
✓ updated specpad.vtp.json (2 tests)
✓ validation + governance clean

03 Traceability by construction

Every test declares what it verifies, linked by stable ids that survive renames. Governance checks flag untested requirements before an auditor does.

04 Redlines, automatically

The editor diffs your working copy against the released baseline — see exactly what changed since the last release, with no hand-maintained change tables.

05 Version history from your tags

Releases are just git tags. SpecPad snapshots each one, so any past revision is one click away — author and date come from the commit itself.

06 Tied to your ticket

Associate working changes with a job — a ticket key, an issue number — so every requirement edit traces back to why it happened.

07 Validated twice: structure and policy

JSON Schema catches malformed files; governance rules catch broken links, missing expected results, and untraceable requirements. The skill and the editor run the same checks from one shared module.

## The full picture

One traceable chain, captured as you build.

Every artifact a design-controls reviewer expects — and that good engineering wants anyway — living in your repo, kept current by the working loop.

• Product requirementsUser needs and product intent (PRD) — the top of the trace matrix, with proposed vs implemented status.
• Requirements & verificationTestable “shall” requirements (SRS), each proven by a verification test with a defined expected result (VTP).
• Traceability matrixProduct requirement → requirement → verification, with each requirement’s result rolled up and gaps flagged.
• Auditor design-control mapIEC 62304 & 21 CFR 820.30 elements → the exact place each piece of evidence lives. Answer “where are your design inputs?” in one click.
• ArchitectureAn arc42 document with draw.io diagrams, co-versioned with the spec and diffed per change.
• Change controlEvery change tied to a job; see a job’s in-progress and released SRS/VTP/architecture diffs, derived from git.
• ReleasesVersioned design-control checkpoints — a full-document snapshot and the jobs that shipped in each.
• Governance, enforced twiceStructure (JSON Schema) then policy (traceability, coverage) — the same gates run by the skill and the editor.
• ThemesDeveloper, editorial, or blueprint — pick the look; your choice follows you.
• eQMS export soonA versioned evidence package for your external quality system.

## Who it’s for

Built for regulated work. Useful everywhere.

## Get started

Installed in under a minute.

1. 1

   Download the skill

   specpad-skill.zip

2. 2

   Unzip it

   into ~/.claude/skills/

3. 3

   Say the words

   set up specpad in your repo