harness

Record an architecture decision as a permanent ADR in docs/adr/ that binds future code changes. The skill applies its own gates and drops what does not qualify, so send any candidate. Planning calls it for the task and every approved decision; also use it directly ("write an ADR", "record this decision", "document why we chose X").

High-quality code patterns with strict types, functional programming, and immutability. Use when writing ANY code in any language. Trigger whenever the user writes, reviews, or refactors code — even if they don't explicitly ask for "quality" or "strict" patterns. This skill applies to TypeScript, Python, and any future languages. Always load this skill for implementation tasks.

Deep code review that hunts for subtle bugs and for code that works but should have been written differently. Runs eight reviewer personas in parallel, aggregates their findings into a report, then applies the fixes and records them in it. Use when the user says "/code-review", "review my code", "review this change", or "review this against the plan".

Coverage diagnostic for a package. Use this skill after writing or modifying code to see which code is uncovered and which spec behaviors that maps to. Diagnostic only — reports and asks the user; never generates specs, never invokes orchestrate, never fails a build.

Use when the user says "check docs", "audit docs", "doc quality", "doc slop", "stale docs", or wants to verify documentation accuracy and tone against the actual codebase.

Verify a feature actually works by driving it — the gate between "tests are green" and "feature is done" — MUST run before claiming a feature complete, opening a PR, or committing, and whenever orchestrate enters its verify stage. Passing unit and e2e tests are not verification. Trigger on "tests pass", "implementation done", "ready for review", "ready to ship", "ship it", "verify this", "is this working", "can we merge", or any other move toward calling a feature finished.

Analyzes dirty working trees, groups related changes into logical commits using hunk-level staging, and writes conventional commit messages. Use when the user asks to commit their changes or split them into separate commits, including "save my work to git" or "organize my git changes". Does not handle branch management, rebasing, merging, or pushing.

Audit a finished harness pipeline run and report the harness defects it exposed. Reads the run's session transcripts, finds what broke, and writes one ranked report for the people who build the harness. Use this skill whenever a pipeline run ends or aborts, and whenever the user says "retro", "retro this run", "post-mortem", "what went wrong in that run", "why did the harness stop", or gives you a session transcript path. Ranks correctness risk above time cost: a defect that would ship silently in --auto outranks one that wasted an hour.

Implement a requested change, plan, phase, or review feedback using test-first development. Runs directly in the current conversation or inside an orchestrate worker.

Capture learnings as clean, human-readable lesson docs in .harness/knowledge/lessons/. Use after solving a non-trivial problem, discovering a design pattern, hitting a gotcha, or making an architectural decision worth remembering. Triggers on: 'document this', 'capture this learning', 'that was tricky', 'let's compound this', or /learn. Also provides consolidate mode (the stage-5 curator over lesson-candidates.jsonl) — triggered by 'consolidate candidates' or the orchestrate pipeline's CURATE LEARNINGS step.

Trust gate that validates every external library/API named in design.md *before* the plan is built. Runs cheap health heuristics, then a use-case smoke test against the live service using credentials from project-root `.env.harness` (gitignored). Produces `.harness/<name>/library-probe.md` with a per-library verdict (VERIFIED / FAILED / UNTESTABLE). On FAILED, walks the declared fallback chain; after all alternatives are exhausted, escalates via AskUserQuestion. Runs inside the planning stage.

Orchestrate end-to-end development from a task to an open PR through a multi-agent pipeline. Use when the user says orchestrate, run the pipeline, or full workflow; supplies a prompt, ticket, PRD, or design document to take to a PR; or passes --auto for an unattended CI run.

Grill the open forks, checkpoint the solution inline, then build plan.html for review — one stage from idea to approved plan. Use for code work that needs thought before code ("plan this", "how should we implement"), and to interrogate an existing design or PRD ("grill this idea"). Runs as orchestrate's design-and-plan stage. Atomic one-edit work routes to `implement` after step 1.

Scaffold a full TypeScript project from a tech stack spec document. Creates Turborepo workspace, all packages with starter code, Podman Compose for local infra (PostgreSQL, Redis, etc.), and verifies the setup builds and runs. Use this skill whenever the user wants to set up a new TypeScript project, scaffold a project from a spec, bootstrap a multi-package TS project, or says "set up the project", "create the project", "scaffold", "bootstrap", "init the repo". Also triggers when the user has a tech stack design doc and wants to turn it into a working project.

Post-stage verification with hard pass/fail thresholds. Every claim backed by verbatim command output — no check may be silently absent, skipped, or weakened. Runs after TDD, refactor, and before PR. Reads each package's commands from orchestrate.config.json and its baseline metrics from .harness/<SPEC_NAME>/baseline.json.

Refactoring assessment and patterns. Use after tests pass (GREEN phase) to assess improvement opportunities, or when the user explicitly asks to refactor code. Guides what to look for, how to prioritize, and which techniques to apply. Trigger this skill whenever refactoring is mentioned, when assessing code quality after a GREEN phase, or when the user asks to clean up or improve existing code structure.

Resolves git merge and rebase conflicts, stopped locally or reported on an open pull request, by recovering the intent behind each conflicting change, then finishing the merge. Use when a merge, rebase, cherry-pick or stash pop has stopped with conflicts, when git reports 'CONFLICT', 'Unmerged paths', 'fix conflicts and then commit', or 'could not apply', when a pull request shows 'This branch has conflicts that must be resolved', and whenever the user says 'resolve the conflicts', 'fix the merge', 'the PR has conflicts', 'the rebase onto main stopped', 'rebase conflict', 'this won't merge' or asks what to keep from which side. Handles conflicts only — git-commit writes ordinary commits. Pushes only to return an open PR's resolution, and asks first.

Automated PR review fixer. Reads human code review comments, classifies each as a direct fix or orchestration task, applies fixes, runs quality gate, commits, pushes, and comments back on the PR. Designed to run in GitHub Actions via claude-code-action. Trigger when the prompt contains review comments JSON and asks to fix review feedback.

Apply QA or PR-review feedback to a ticket, across every PR it carries.

Set up the harness in a repo. Runs the doctor, fixes what can be fixed here, resolves any standing instruction that would pause an unattended run, hands the user what only they can do, and writes the project's `orchestrate.config.json`. Use when the user says 'set up the harness', is running a harness skill in this repo for the first time, or when a stage halts because a tool is missing or `orchestrate.config.json` is absent or stale.

Generates eval test suites (evals.json + fixture files) for any skill by analyzing its SKILL.md. Use when the user says "generate evals for X", "create tests for X skill", "write evals", "eval suite for X", or wants to create test coverage for a skill before running skill-creator eval. Also trigger when the user mentions testing skills, validating skill behavior, or creating eval fixtures. This skill generates the test definitions — it does not run them.

Reviews an agent skill against a rubric covering description quality, invocation, structure, integrity, coherence, test coverage, security, content, convention and cost, then writes a report plus machine-readable findings. Use whenever the user asks to review, audit, critique, grade, score or sanity-check a skill or a SKILL.md, whenever a skill has just been written or edited, whenever a skill under-triggers or behaves inconsistently between runs, and before any skill is shared, published or committed — even when the request is only "is this skill any good" or "what's wrong with my skill". This judges a skill as written; skill-creator measures one by running evals against it, and writing-skills helps author a new one from scratch.

Synchronizes documentation with code changes. Scans for stale, missing, or contradictory docs, then updates them to reflect the actual implementation. Structures docs for both human readability and AI consumption. Use after code changes are complete and quality gate has passed — before committing.

Test-Driven Development. Use for any implementation task — features, bug fixes, refactoring — whenever the project's CLAUDE.md signals TDD (mentions of TDD, test-driven, RED-GREEN-REFACTOR, "tests first"), or when the user asks for test-first work. Load before writing any production code. Its references are also the testing standard: skills reviewing or generating tests read references/testing.md and references/anti-patterns.md.

Use when the user says "find tech debt", "audit code quality", "what needs cleanup", "show me debt", "code health check", "scan for smells", or wants a comprehensive quality assessment before planning a refactor or sprint.

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

How to write any document a person will read — reports, plans, PR and issue bodies, READMEs, release notes, summaries. Use whenever you write or edit prose for a human reader. Trigger before writing a report, a plan, a summary, a commit or PR description, or documentation — even when the user never asks for "good writing". Covers voice, structure, claim-to-evidence matching, and a ship-check to run before delivering.