Open the editor

$ git log docs/specpad/srs.json

Requirements that live in your repo.

Regulatory-grade requirements management for engineers: a traceable SRS and verification tests stored as schema-validated JSON in git — kept in sync with your code by a Claude skill, reviewed and approved by humans in a visual editor.

Download the Claude skill See it live

MIT Free and open source — github.com/pizzaow/specpad

## 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.

The sync loop: code changes flow through the Claude skill into git, are reviewed and approved by a human in the editor, committed, and the loop repeats. your code changes Claude skill updates srs/vtp JSON docs/specpad/*.json in git human reviews & approves in the editor git commit / PR
The sync loop — spec and code never drift
One contract, two editors: the shared schema and governance module governs both the Claude skill and the visual editor; both read and write the same JSON files, with git as the history and merge layer. shared schema + governance (src/shared) Claude skill edits programmatically visual editor humans review & approve read / write read / write docs/specpad/*.json git is the history & merge layer
One contract, two editors — the rules cannot drift

## 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.

What it looks like ▸ live demo
The SpecPad editor showing an SRS as an editable table of requirements with codes, names, and statuses
How it works
The browser editor reads and writes docs/specpad JSON files directly via the File System Access API, with no backend. docs/specpad/ *.json your repo browser editor runs locally File System Access — no backend

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.

What it looks like
How it works
The Claude skill and the visual editor both read and write the same docs/specpad JSON files, governed by one shared contract. Claude skill edits from the terminal visual editor edits in the browser one shared contract docs/specpad/*.json

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.

What it looks like
The testing view pairing each verification test with the requirement it verifies, with pass and fail results
How it works
Requirements link to tests link to results by stable id, never by human-readable name. requirement id: r_4f2a test verifies: r_4f2a result ✓ passed linked by id, never by name — renames can’t break the chain

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.

What it looks like ▸ live demo
The redline view highlighting additions and deletions between the working copy and the released baseline
How it works
The baseline snapshot from the v1.0 git tag and the working copy are diffed to produce the redline view; git owns the history. baseline snapshot (v1.0 tag) working copy (your edits) diff − was + now redline view git owns the history — nothing is hand-maintained

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.

What it looks like
The version history dialog listing released revisions snapshotted from git tags, with author and date from each commit
How it works
Each git tag on the timeline gets a snapshot, and the snapshots populate the editor's history dialog. v0.1 v1.0 working snapshot snapshot uncommitted history dialog

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.

What it looks like
A job chip in the editor toolbar associating the current working changes with the landing-page job
How it works
A job marker file in the repo links the current working edits to the ticket that motivated them. job marker [name].job.json current edits working copy ticket JIRA-123 traces to

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.

What it looks like
The editor status bar reporting schema validation and governance checks as clean
How it works
Every file passes a structure gate (JSON Schema) and then a policy gate (governance rules); its schemaVersion pins the matching editor build. docs/specpad/*.json gate 1 · structure JSON Schema gate 2 · policy governance rules ✓ clean schemaVersion "1.0" → pinned editor /v01/

## Who it’s for

Built for regulated work. Useful everywhere.

Regulated industries

Audit-ready traceability, structured evidence, and human approval gates — without standing up heavyweight tooling.

Everyone else

The same rigor is just good engineering practice: specs that can’t silently rot, tests that can’t silently detach.

## Get started

Installed in under a minute.

  1. Download the skill

    specpad-skill.zip

  2. Unzip it

    into ~/.claude/skills/

  3. Say the words

    set up specpad in your repo

Download the Claude skill

specpad-skill.zip · schema v1.0

full instructions browse the source on GitHub