Idea to merged PR,
through one gated pipeline.

Most features get built twice. Once in a hurry to see the thing work, and again when you realize nobody wrote down the problem it solved, the acceptance criteria drifted, and the review was a rubber stamp. The parts that make a feature correct are the first to get skipped when you move fast with an AI agent. harness-kit puts them back, and does the writing for you.

What you get: one command takes a raw idea to a merged pull request. Six documents, a check and a scored review at each stage, and two moments where a human decides, is this the right direction, and is this PR good to open. You spend your attention there, not on formatting a spec.

sequenceDiagram
    actor You
    participant PM as product-manager
    participant Gate as sensor + eval
    participant SSE as staff-engineer
    participant GH as GitHub
    You->>PM: idea
    PM->>Gate: PRD
    Gate-->>You: pass + score
    You->>PM: approve direction
    PM->>Gate: PRP
    Gate-->>PM: pass + score
    PM->>SSE: approved spec
    SSE->>Gate: plan, then dev, then test
    Gate-->>SSE: pass + score at each
    You->>SSE: approve the PR
    SSE->>GH: open PR
    GH-->>You: merged
      

idea in, merged PR out · two human decisions, everything else on rails

harness-kit is one product with four surfaces. Each does one job, and they chain: shape the idea, run the pipeline, watch its quality, drive it from a terminal. Start anywhere.

front 2 is the engine · front 1 feeds it · front 3 measures it · front 4 drives it

A single web page that turns a rough idea into a well-formed /golden-path prompt. Fill squad, problem, hypothesis, and metric; it validates each field against the PRD conventions as you type, and builds the exact prompt to paste into Claude Code. No blank-page problem.

idea-brief builder · live preview

fields on the left, the prompt assembles live on the right

Shipping a feature on vibes skips the parts that make it correct: framing the problem, writing acceptance criteria, holding the conventions, gating the review. harness-kit puts those back, without you hand-writing a single doc.

flowchart LR
    idea([idea]) --> prd
    subgraph PM[product-manager]
        prd --> prp
    end
    subgraph SSE[staff-software-engineer]
        plan --> dev --> test --> pr
    end
    prp --> plan
    pr --> merged([merged PR])
      

two agents, one pipeline · each arrow is a gated handoff

How one stage is gated

The same loop runs at every stage. The agent generates the artifact, a sensor checks its structure, an eval scores its quality, and only then does a human approve. Failures self-correct before they reach you.

flowchart LR
    gen[generate artifact] --> sensor{sensor: structure check}
    sensor -->|fail| gen
    sensor -->|pass| eval{eval: LLM judge}
    eval -->|"score < 8.0, retry x3"| gen
    eval -->|"score ≥ 8.0"| approve[human approves]
    approve --> next([next stage])
      

guides steer before · sensors give deterministic feedback · evals give inferential feedback · humans stay on the loop

A gate that cannot lie

Böckeler splits controls into computational, deterministic and CPU-run, and inferential, needing judgment. Every sensor here declares which it is, and the difference is the whole point: a sensor nothing machine-checked can never report a pass.

flowchart LR
    s[sensor declares how it is enforced] --> c{Execution?}
    c -->|computational| r[runner enforces it]
    c -->|inferential| m[a model applies it]
    r --> ok[pass]
    r --> no[fail]
    r --> err[broken spec is an error, never a pass]
    m --> inf[logged inferential, never a pass]
      

a sensor that claims to be deterministic but checks nothing is an error, not a pass

Each agent, end to end

The same gated loop, once per agent. These are the three pipelines you actually run: what the command does, which sensors fire, which eval scores it, and where the gate sits. Every scored eval uses the same 8.0 threshold and the same three-attempt retry.

sequenceDiagram
    actor You
    participant PM as product-manager
    participant S as sensors
    participant E as eval (fresh judge)
    You->>PM: /product-manager:run
    PM->>PM: read intake artifact
    PM->>S: PRD → structure, acceptance criteria
    S-->>PM: pass or fail, retry up to 3
    PM->>E: prd-quality
    E-->>PM: score, needs ≥ 8.0
    PM->>PM: approval marker on the PRD
    Note over PM,E: no approved PRD, no PRP. the hook refuses to start it
    PM->>S: PRP → structure, context, links
    S-->>PM: pass or fail, retry up to 3
    PM->>E: prp-quality, prp-context-readiness
    E-->>PM: score, needs ≥ 8.0
    PM-->>You: PRP ready for handoff
      

product-manager · prd → prp · reads the intake artifact, never stops to ask you

sequenceDiagram
    actor You
    participant SSE as staff-engineer
    participant S as sensors
    participant E as eval (fresh judge)
    participant GH as GitHub
    You->>SSE: /sse:run
    SSE->>SSE: read approved PRP, detect area skill
    SSE->>S: plan → plan-structure
    S-->>SSE: pass
    SSE->>E: plan-quality
    E-->>SSE: score ≥ 8.0, approved
    SSE->>S: dev → conventions, coverage, structure
    S-->>SSE: fail means fix and retry, stop after 3
    SSE->>E: dev-quality
    E-->>SSE: score ≥ 8.0, approved
    SSE->>SSE: detect and run the test suite
    SSE->>E: test-quality, only if exit code is 0
    E-->>SSE: score ≥ 8.0, approved
    Note over You,GH: the PR gate. --local stops here for good
    SSE->>GH: gh pr create --draft
    GH-->>SSE: PR url
    SSE->>E: pr-quality
    E-->>SSE: score ≥ 8.0, approved
    SSE->>GH: pr-monitor polls for the merge
    GH-->>You: merged, state cleared
      

staff-software-engineer · plan → dev → test → pr · dev is the one stage gated twice, on the code and on the summary

sequenceDiagram
    actor You
    participant SA as system-architect
    participant S as sensors
    participant E as eval (fresh judge)
    You->>SA: /system-design:run
    SA->>SA: route to a topic skill, or generic design
    SA->>S: design → structure, rigor
    S-->>SA: a missing number or diagram blocks
    SA->>E: design-quality
    E-->>SA: score ≥ 8.0, approved
    SA->>SA: adversarial review, 10 staff questions
    SA->>S: review → structure, review variant
    S-->>SA: questions answered, verdict present
    SA->>E: design-review-depth
    E-->>SA: score ≥ 8.0
    SA-->>You: verdict ship, revise, or block
      

system-architect · design → review · optional front stage before the PRP · block is terminal

One command, idea to merged PR.

/golden-path

Squad: checkout
Problem: Returning guests abandon checkout when a card is declined once …
Hypothesis: If we add one-tap retry, then completion rises 5 points, because …
Success metric: checkout completion, from 71% to 76% within 30 days

Every flow shares the same pipeline state, so you can switch between them mid-feature.

Scores used to get lost in chat once a stage was approved. The quality dashboard persists per-phase signal across every run and answers one question: is each stage getting better or worse over time?

phase-quality dashboard · sample data

drop a phase-log.json and see where the pipeline drifts

Every time a phase is approved, a post-eval hook appends one deterministic entry, zero token cost, to phase-log.json: the eval score, the count of open gaps, the sensors re-run pass/fail, and a derived status (ok / degraded / failed). Drop that JSON on the page (a standalone file, no build, no network) for KPI tiles, a score trend by stage, failure rate, average score vs the 7.0 threshold, the sensors that block most, and the full run table.

A terminal UI over the pipeline. Every stage live, a stage run on a keypress, humans on the loop at two gates.

hk-tui · a feature at the PR gate

open a feature, read each artifact, approve the gate, all from the terminal

It renders each artifact, runs a stage on a keypress, and turns the two human gates into modal prompts, the direction gate lists intake's open NEEDS REVIEW items. It reads state and artifacts straight off disk, so it stays in sync with any Claude Code session driving the same feature. It ships bundled, no extra dependencies land in your project.

npm i -g @pieerry/harness-kit   # once, puts hk-tui on your PATH
hk-tui                     # open the cockpit in the current repo
hk-tui path/to/repo        # or point it at one
hk-tui -- "add one-tap retry to checkout"   # seed intake

Two layers: the plugin (fetched once from the marketplace) and the harness (laid into each repo you want it in).

/plugin marketplace add Pierry/harness-kit
/plugin install harness-kit@harness-kit

Restart Claude Code, then inside the repo you want to use it in:

/harness-kit:install

Lays the full harness into that repo, agents, commands, skills, hooks, and the status bar, under .claude/ plus AGENTS.md and CLAUDE.md at the root. Requires Claude Code, python3, git, and the gh CLI for PRs.

Optional, all local-first. As the repo and the harness grow, the tokens spent loading context and reading command output start to dominate. Four tools cut that, and they stack with the per-stage model tiers.

/context:pack and /context:graph ship with the harness and feed the plan and SDD-eval stages. qmd and rtk are third-party, install them yourself:

# rtk, output filter, auto-intercepts git/test/lint/grep
brew install rtk
rtk init -g            # select Claude Code; rtk gain shows savings

# qmd, semantic doc search over the harness guide tree
npm install -g @tobilu/qmd
setup/setup-qmd.sh     # indexes the guide tree, then embeds (~2GB models, once)

All registered in AGENTS.md. Each ships its own sensors, evals, guides, and skills.

This is not invented method. harness-kit is a concrete implementation of harness engineering, and the system-architect agent reasons from the established engineering canon.

Go deeper than this page.