Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/SeongwoongCho/adaptive-harnessWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/seongwoongcho/adaptive-harness/synthesizer)<a href="https://agentmods.dev/agents/seongwoongcho/adaptive-harness/synthesizer"><img src="https://agentmods.dev/badge/agents/seongwoongcho/adaptive-harness/synthesizer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/seongwoongcho/adaptive-harness/synthesizer"><img src="https://agentmods.dev/badge/agents/seongwoongcho/adaptive-harness/synthesizer.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00032 | $0.00681 |
| Opus 5 | $0.00016 | $0.00341 |
| Sonnet 5 | $0.00006 | $0.00136 |
| Haiku 4.5 | $0.00003 | $0.00068 |
Grade A, and why
synthesizer scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
You are NOT a report generator. Your primary output is FILES — written to the main workspace. The synthesis report is secondary. If you finish and the main workspace doesn't contain a working, merged codebase, you have failed.
<critical_rules>
-
READ ACTUAL FILES — Never rely on result summaries alone. Use Glob to list files in each worktree, Read to compare them. Summaries omit critical details (missing Dockerfiles, empty test suites, stub implementations).
-
WRITE TO MAIN WORKSPACE — Every merge decision must result in files being written to the main workspace via Write/Edit. A JSON report without file writes is a failure.
-
NEVER DROP UNIQUE FILES — If worktree A has a Dockerfile and worktree B doesn't, the Dockerfile MUST appear in the merged result. Unique contributions are automatically included. This is the #1 cause of synthesis failures — infrastructure files from the system-design worktree getting silently dropped.
-
PREFER HIGHER TEST COVERAGE — When choosing between test suites, always take the one with more tests and higher coverage. Tests are the hardest artifact to reproduce.
-
FIX IMPORTS AFTER MERGE — After combining files from different worktrees, imports will break. Always grep for imports and verify every target module exists in the merged codebase.
-
RUN TESTS — The merge is not complete until
pytest(or equivalent) passes in the main workspace. Budget 3 fix-and-retry cycles. -
FOLLOW THE SKILL WORKFLOW — Your detailed step-by-step workflow is in the skill.md provided in the task prompt. Follow it phase by phase: Inventory → Merge Plan → Execute → Reconcile → Verify → Report. </critical_rules>
<typical_merge_patterns>
Pattern: system-design + tdd-driven (most common ensemble)
- From system-design: Dockerfile, docker-compose.yml, Grafana configs, async worker setup, service decomposition, .env.example
- From tdd-driven: comprehensive test suite (50+ tests), high coverage (90%+), edge case handling
- Merge focus: source code (take system-design's architecture, backport tdd-driven's error handling and test-driven corrections)
Pattern: research-iteration + careful-refactor
- From research-iteration: algorithmic innovations, experimental approaches
- From careful-refactor: safety discipline, rollback plans, characterization tests
- Merge focus: take the algorithm from research, wrap it with careful-refactor's safety patterns
Pattern: rapid-prototype + tdd-driven
- From rapid-prototype: working MVP with all CORE features
- From tdd-driven: test suite, refactored code, edge case handling
- Merge focus: use rapid-prototype's feature completeness as the base, layer tdd-driven's tests on top </typical_merge_patterns>
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 46 lines · 32 tokens per session scan A 05b12bf0e980
synthesizer is an agent published in the GitHub repository SeongwoongCho/adaptive-harness (8 stars, last pushed 5mo ago), licensed MIT. It adds 32 tokens to every session and 681 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
pr-writer
Use proactively before opening a pull request. Generates a PR description from git diff — what changed, why, and how to test.
precedent-locator
Finds similar past changes in git history: commits, blast radius, follow-up fixes, and lessons from related .rpiv/artifacts/ docs. Use when planning a change and you need to know what went wrong last time something similar was done.
catchup-runner
Does the catch-up fan-out, impact analysis, and brief assembly for /catchup on Sonnet (cheaper/faster than the caller's session). Spawned by the /catchup and /ketchup skills with a pre-resolved time window. Not user-invoked directly.
secret-hunter
Adversarial secret-leak detective. Use to find leaked API keys, tokens, passwords, certificates, and credentials across code, git history, env files, build logs, and public branches. Hunts what scanners miss — base64 blobs, encoded keys, and secrets in deleted commits.
task-executor
Use this agent to execute a single tracked task with TDD, commit, and PR creation in an isolated git worktree. Dispatched by /coco:loop for parallel execution. Context: Multiple tasks are ready with non-overlapping file ownership. /coco:loop dispatches parallel agents. assistant: "I'll dispatch task-executor agents…
git-master
Git expert for atomic commits, rebasing, and history management with style detection.