skills

Recurring maintenance pass over automated dependency-bump PRs (Dependabot, Renovate, or similar) — rebase, relock, verify, and report what's ready to merge. Meant to be handed to a time-based loop or schedule, not run once.

Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand.

Reference for designing agent loops — cycles of work that repeat until a stop condition is met. Covers the four loop shapes, writing completion criteria, carrying state and isolating work across cycles, and what running unattended still leaves on you.

Recurring check-in on a stack of dependent PRs — rebase children onto updated parents, surface CI state, flag anything waiting on a human-only gate, and report only what changed since last time. Meant to be handed to a time-based loop, not run once.

Pick the skill or flow that fits your situation. A router over the skills in this repo.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

Shared vocabulary and principles for designing deep modules. Use when the user wants to design or refine a module's interface, hunt for deepening opportunities, decide where a seam belongs, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

Actively build and refine a project's domain model as you design. Use when the user wants to nail down domain terminology or a ubiquitous language, capture an architectural decision as an ADR, or when another skill needs to keep the domain model current.

A relentless interview that sharpens a plan while writing the domain model down as you go — glossary terms and ADRs captured inline.

Implement a piece of work based on a PRD or set of issues.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.

Use when you need to resolve an in-progress git merge/rebase conflict.

Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Distill a conformance suite out of a spec and the current conversation — every normative requirement turned into an implementation-independent test any conforming implementation must pass — and write it to an in-repo doc. Use when the user wants conformance tests, a spec compliance suite, test vectors for a format or protocol, to check an implementation against its spec, or to turn MUST/SHOULD requirements into tests.

Distill a fuzzing plan out of the current conversation and codebase — the targets worth fuzzing, each with its entry point, input model, and failure oracle — and write it to an in-repo doc. Use when the user wants to fuzz-test something, harden a parser or decoder against untrusted input, find crashes/panics/UB, turn invariants into fuzz targets, or plan a fuzzing campaign.

Distill the invariants — properties that must always hold — out of the current conversation and codebase, and write them to an in-repo doc. Use when the user wants to capture invariants, pin down what must always be true, harden a design, or turn a discussion/spec/PRD into checkable properties.

Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.

Turn the current conversation into a PRD and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.

Move issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.

Install a Claude Code hook that stops destructive git commands (push, reset --hard, clean, branch -D, and friends) before they run. Use when the user wants to guard against dangerous git operations, add git safety hooks, or block git push/reset inside Claude Code.

Convert `as` type assertions in test files to @total-typescript/shoehorn helpers. Use when the user mentions shoehorn, wants to remove `as` from tests, or needs to pass partial data to a typed function under test.

Scaffold an exercise directory tree — sections, problems, solutions, and explainers — that passes the course linter. Use when the user wants to scaffold exercises, stub out exercise folders, or spin up a new course section.

Add a Husky pre-commit hook backed by lint-staged (Prettier), plus type checking and tests, to the current repo. Use when the user wants pre-commit hooks, wants to set up Husky or lint-staged, or wants Prettier, typecheck, and tests to run at commit time.

Produce and verify mkit attestations — in-toto v1 Statements wrapped in DSSE envelopes, attached to a signed commit. Use when attaching provenance, review, or SBOM claims to a commit, verifying attestations against a trust-roots registry, setting up co-signers, or wiring attestation into CI. Assumes a `.mkit/` repo; for general mkit CLI use see the `mkit` skill.

Verify an mkit PR is genuinely green across its real CI surface — the GitHub Actions gates AND the Google Cloud Build `mkit-*-pr` checks — before merging. Use when preparing to merge a PR into mkit's `main`, when a PR looks green but you want to confirm the expected workflows actually ran, when a rustdoc/docs or codegen change might slip past the GitHub rollup, or when reviving CI on a stale branch.

Cut a signed, attested mkit release by driving the real tag-triggered release machinery end to end. Use when tagging a new mkit version, publishing to crates.io / npm / GitHub Releases, verifying a published release, or rotating the release-attestation key.

Drive the `mkit` CLI — a content-addressed version control tool with BLAKE3 object IDs, Ed25519-signed commits, and native in-toto/DSSE attestation. Use when working in a `.mkit/` repository, making signed commits, managing signing keys, inspecting content-addressed objects, or syncing over mkit+ssh/https/s3/file transports. mkit mirrors git's CLI/UX, so git reflexes apply — this skill covers only the parts that are *not* git.

Scaffold a new mkit SPEC document with the repo's real structure, then register it in the spec index and wire any parity follow-up. Use when adding a docs/specs/SPEC-*.md for a new wire format, on-disk format, or subsystem; when an in-scope command or behavior needs a normative spec; or when a format change requires a spec per the CONTRIBUTING review bar.

A relentless, one-decision-at-a-time interview that sharpens a plan or design.

Interrogate the user's plan or design one decision at a time until you both share the same understanding. Use when the user wants to pressure-test an idea before building it, or reaches for any 'grill' trigger phrase.

Compact the current conversation into a handoff document for another agent to pick up.

Teach the user a new skill or concept, within this workspace.

House style for technical writing — the voice, sentence craft, formatting, and user-facing-copy rules that make docs and product text clear, direct, and consistent. Use when writing or editing a README, docs, a spec, release notes, a changelog, help text, or any error/CLI/UI copy a person reads; when reviewing a diff that touches prose or messages; or when a project needs a writing standard. Reference-heavy mechanics live in REFERENCE.md.

Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.