harness-verify

Solid

Headlessly A/B-test how a harness change (system prompt, tool, tool-result text, model) affects the agent's behavior, by replaying a REAL ModMixer chat transcript and running the agent's next turn against a chosen model — no GUI, no RimWorld, no manual clicking. Use when you've changed something that should change what the model DOES (e.g. "the agent should now ask before relaunching") and want runtime evidence across variants, not just a typecheck.

AI & Automation 16 stars 0 forks Updated today MIT

Install

View on GitHub

Quality Score: 80/100

Stars 20%
41
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# harness-verify — headless A/B turn replay Replays a recorded ModMixer chat up to a chosen point, then runs the agent's **next turn** headlessly against a chosen model — once per variant, repeated N times — and reports what the agent *did* (asked the user vs. fired a side-effecting tool like `run_test_cycle`). This is how you get runtime evidence that a prompt/tool/hint change actually moves model behavior, especially for non-frontier models (Kimi etc.) where "it's in the system prompt" is not the same as "the model obeys it". It runs the **real** system prompt, the **real** tool set, and the **real** model + credentials — but in an isolated session with side-effecting tools swapped for recording stubs, so nothing edits files, builds, launches RimWorld, or touches the user's conversation store. ## When to use - You changed how the agent should behave (a system-prompt rule, a tool description, a tool-result hint, a model) and want to see the effect. - You want an A/B: same history + model, with vs. without your change. - The surface is the agent's decision, and driving the GUI by hand is slow, costs RimWorld launches, and isn't repeatable. Not for: pure mechanical changes with no behavioral question (a typecheck is enough), or anything where you'd need many full agentic turns with real file mutation (this stubs the side-effecting tools). ## Run it ```powershell # Always dry-run first — proves the pipeline (Electron boot, model # resolution, session reconstruction, ...

Details

Author
lebek
Repository
lebek/modmixer
Created
3 months ago
Last Updated
today
Language
TypeScript
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

harness

Launch the Generator-Verifier harness for long-running app development. Spawns Opus Generator and Sonnet Verifier with sprint contracts, file-based handoff, and /loop 1m auto-unsticking monitor.

0 Updated 6 days ago
0xAddict
AI & Automation Listed

harness-contract

Run an autonomous Generator + Verifier harness against a sprint contract with hard ≥98% spec gate, file-based handoff, cron auto-unstick, Monitor on status.txt, read-only approved contracts, session-scoped Stop gate, optional Codex adversarial verification, and CronDelete-self on PASS. Use when the user says "sprint contract", "spec gate", "hard spec gate", "TDD-driven harness", "Generator + Verifier", "auto-unstick", "go end to end don't ask", "harness this", or "multi-task autonomous build". Triggers strongly when the request bundles ≥3 deliverables and wants measurable must_pass criteria, no further questions, and self-termination when the contract is met.

0 Updated 6 days ago
0xAddict
AI & Automation Listed

implementation-harness-evaluate-fit

Use when the user wants to check whether an already-installed harness is well-tuned to THIS project and fix any mismatches — phrases like "evaluate the harness fit", "does the harness suit this project", "check in on the harness", "tune the harness to the project", "the facets/floor look wrong for this repo", "/evaluate-fit". Runs a full multi-agent DEEP DIVE of the project (stack, module structure, risk profile, deploy/notify story, secret + visual surfaces), reads the CURRENT harness config, then produces ranked, evidence-backed recommendations across the ONLY customizable surfaces — the `custom/` overlay, `harness.env` knobs, and `facets.json` (`layer` vocabulary + `policy`) — and, on your approval, applies them. It NEVER edits harness mechanism (scripts/docs/dashboard) — an install stays fork-free and upgrade-clean. Ideal after a harness was scaffolded against an empty/young repo, or after the project has grown. Requires a scaffolded `.harness/`.

0 Updated 6 days ago
RyanMKrol