SpecSeal

Skills

24 in the Claude listing

• Agent contractThe rules every SpecSeal agent works under — smith, warden, scribe, and any agent added after them.
• auditValidate project-specific rules a linter cannot express, declared as `.claude/audit-rules/*.md`.
• Build fixResolve build, compile, and type-check errors at their cause instead of suppressing them.
• checkpointEstablish a rollback point before an operation that is hard to undo, and get explicit approval with the blast radius stated.
• Code reviewTwo-stage review methodology (spec compliance, then quality) with comparison axes, cross-session review records, and re-review inheritance.
• Commit pr conventionFormat rules for commit messages, PR titles, PR bodies and branch names — the prefix vocabulary, the language the repository states in `seal/config.md`, where a translated body lives, and how to check
• Confidence checkReadiness check before implementing: does something equivalent already exist, is the API verified against the installed version, is the cause of the bug actually understood rather than guessed.
• configShow what this repository decided for itself and change any of it — the languages it writes in, where its records live, and the command its broad gate runs.
• debugFind the cause of wrong behavior: reproduce, locate, one hypothesis at a time, then a failing test before the fix.
• Evidence checkVerify that the evidence ledger's content anchors still resolve — a missing or ambiguous unit fails the build, changed content demands re-verification.
• Evidence ciWire the ledger drift check into this repo's CI — vendor the checker and write the workflow, so drift fails a build instead of waiting to be run by hand.
• Feature plannerDecompose work into ordered tasks with dependencies mapped, then lock scope in writing before starting.
• Gap analysisCompare a design or spec document against what was actually built — API surface, data model, business logic — and list what is missing, extra, or divergent.
• implementSpec-driven implementation methodology: document layout (docs/ + seal/), policy-first judgment, evidence feedback, and review incorporation.
• learnRecord an insight that cost real debugging effort and cannot be recovered from a search — project-specific causes, dependency quirks, the reason behind an architectural choice.
• Legacy parityBehavior-equivalence methodology for legacy migrations: three-way judgment (policy ↔ original code ↔ new code) with original-preservation as the default.
• Parity setupDeclare that this repo ports behavior from another codebase — find the original, record the baseline, write seal/parity.md.
• Preset setupMerge the specseal CLAUDE.md block into the user's CLAUDE.md with semantic dedup — propose, get approval, then apply.
• Security auditWalk a web-service security checklist — OWASP Top 10, auth, data exposure, configuration, dependencies.
• settleRetire a released work item by folding what is still true out of its `spec.md` into a `docs/` policy document, then removing the directory.
• testingWalk a test-strategy pass — which level each test belongs at, what to cover first, the edge cases that get missed.
• updateUpdate the plugin to the newest release and say what changed — runs both commands in the right order, then names the entries you are getting.
• verifyEvidence protocol for completion claims (the Seal Test): name the proving command before running it, show the check can fail, bind the result to a tree state, and label every claim executed / read / u
• Writing styleProse and structure rules for review comments, PR bodies, reports, and replies to the user.