// Orchestrate a release cycle across multiple harny runs. Dispatch with product-vision prompts, parallelize when safe, code-review every merge, triage findings into NOW-blocks/NOW-quick/BACKLOG. Use as release manager across N runs.
| name | release |
| description | Orchestrate a release cycle across multiple harny runs. Dispatch with product-vision prompts, parallelize when safe, code-review every merge, triage findings into NOW-blocks/NOW-quick/BACKLOG. Use as release manager across N runs. |
| allowed-tools | Bash, Read, Write, Edit, Agent |
Operate the release-manager role: dispatch, monitor, code-review, merge, triage findings. Iterate. Sister of /review (per-run post-mortem) and /learn + /drain (learnings inbox).
| Role | Who | What they do |
|---|---|---|
| Architect | User + Claude | Discuss design, agree on outcomes, decide what's next, analyze run outputs, refine approach. Make decisions. |
| Release manager | Same humans, different hat | Operate harness invocations: dispatch, monitor, code-review, merge, triage findings. Execute. This skill guides the release-manager role. |
Same humans wear both hats; over time the release-manager role increasingly delegates to AI-orchestrated runs while the architect stays human-in-the-loop.
You are a release manager, not a mega-architect.
Your input is product-vision + verification-clarity:
The detailed plan (file paths, function signatures, code shape) is the planner's job. When you do that work in the prompt, you:
Litmus test before dispatching: if your prompt contains file paths, function signatures, or code blocks → STOP, you're doing the planner's job. Rewrite as outcome + AC.
These rules are policy, not contract. If a rule isn't serving after 5+ runs, change it explicitly.
No human writes production code by hand. Every change goes through a harness run.
No harny clean during active development. Every run's .harny/<slug>/ directory stays on disk. Historical record + training data + comparison fuel.
When .harny/ gets too cluttered, revisit — but default is preserve.
Each harny "..." invocation should produce a coherent commit chain representing one focused change. Multi-task plans are fine if the validator gates each task individually. Don't bundle multiple concerns into one prompt — that's N runs.
After every passing run: git checkout main && git merge --no-ff harny/<slug> before invoking the next run.
main "forget" prior runs and silently regress files modified on dangling branches.main as source of truth.Exception: stacking by intent (a follow-up fix on top of a half-done feature). Explicitly git checkout harny/<prior-slug> first and document why.
Branches are still preserved (Rule 2); merging doesn't delete them.
After every PASS verdict and before git merge --no-ff, the architect MUST:
git show <commit>). Look for: code smells, dead code, unused imports, missing error handlers, hidden side effects, observability gaps.The validator verifies functional correctness against AC. The architect verifies code shape, integration, and what the validator's prompt-scoped check can't see.
Issues found → triage per "Per-run loop" step 6.
If a rule isn't serving you, change it — but change it explicitly, not silently.
harny --name <slug> "..." in background. Parallel where safe (see "Parallelism" below).ScheduleWakeup for long runs OR await background notification. Don't poll.git show <commit> + re-run new probes + scan for dead code, missing error handlers, observability gaps, scope drift.git checkout main && git merge --no-ff harny/<slug> before next run./review <slug> for non-trivial runs (failed, retried, novel architectural surface). Route its findings through the same triage in step 6.Emergent planning principle: plan the immediate next move with full attention. Plan the run after that with what we learn from the immediate run. No batch planning.
Multiple runs can dispatch concurrently if they touch disjoint file sets. Before dispatching, build a touch matrix:
| Run | Files touched | Conflicts with |
|---|---|---|
| (one row per pending run) |
Rule of thumb:
| Anti-pattern | Cost | Fix |
|---|---|---|
| Architecture-detail prompts | Planner over-thinks; hides gaps | Product-vision prompts; trust planner |
| Mocks without smoke | Mocks pass while real system breaks | Always run a real end-to-end smoke when wiring crosses a module boundary |
| Ambiguous OR-AC | Validator can't satisfy "either A or B" when env limits one branch | Separate "MUST exercise" vs "MUST verify by reading" explicitly |
| Merging without diff review | Observability gaps + resource leaks slip past AC-scope checks | Rule 5: git show <commit> + re-run probe before every merge |
| Branching successive runs from stale main | Sibling-branch divergence | Rule 4: merge to main between runs |
| Stuck processes accumulate | CPU/token burn | Kill on first sign of hang; ask architect for auth |
The validator is a phase of your harness run. It is expensive when it does expensive things, cheap when it does cheap things.
The validator NEVER spawns a nested harness invocation of its own. A validator that re-invokes the full harness to verify its work burns real LLM tokens, introduces non-determinism, and makes the harness non-composable — process nesting, double-state writes, and a second run the outer harness cannot observe.
Before (expensive, non-deterministic):
AC: Run the full CLI against a tmp git repo. Assert the run produces a commit
on the branch and state shows status = "done".
Spends real tokens; non-repeatable.
After (fixture-based, zero tokens):
AC: bun <probe-path> exits 0.
The probe stubs the actors/phase-runner with canned outputs, runs the workflow
end-to-end in-process, and asserts the final state structurally.
Deterministic, fast, same correctness signal.
If returning to this work after a context compaction:
CLAUDE.md — invariants, gotchas, key paths.git log --oneline -20 — what was last committed..harny/ for the most recent run; read its state.json + review.md (if /review was invoked)./review <slug> — post-mortem of one finished run; emits findings pre-triaged (NOW-blocks / NOW-quick / BACKLOG) so this skill can route them without re-classifying./learn + /drain — capture (/learn <text>) + drain the inbox into Issues / CLAUDE.md edits / discards./check-repo — pre-flight readiness assessment, run before adopting harny in a fresh repo./harny — onboarding + router if you've never used harny before.Onboarding and router for the harny plugin. Teaches the harny mental model (run anatomy, .harny/ state, architect role) and routes to focused skills. Use when adopting harny or unsure where to start.
Walk a repo through the harny readiness checklist. Score 10 dimensions Red/Yellow/Green, surface anti-signals, output a scorecard + prep checklist. Use when adopting harny in a new repo, or troubleshooting why it struggles in a familiar one.
Triage accumulated learnings from the local harny inbox into GitHub Issues, CLAUDE.md edits, or discards. Walks one entry at a time, verifies claims against current code, opens issues with provenance. Sister of /learn.
Append a one-line learning to the local harny inbox. Fast, non-analytical capture — copies text verbatim, no analysis, no follow-ups. Use when the user wants to note something about harny adoption mid-conversation without breaking flow.
Post-mortem of a single harny run. Reads state.json + plan.json + per-phase transcripts. Emits a leaves-to-trunk review with evidence-backed proposals (triaged NOW-blocks/NOW-quick/BACKLOG). Use after failed, retried, slow, or novel runs.