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.
npx agentmods add agents/watt-mind/factory/merge-applygit clone --depth 1 https://github.com/watt-mind/factoryWrote 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/watt-mind/factory/merge-apply)<a href="https://agentmods.dev/agents/watt-mind/factory/merge-apply"><img src="https://agentmods.dev/badge/agents/watt-mind/factory/merge-apply.svg" alt="Measured on agentmods" 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 | $0.00000 | $0.00332 |
| Opus 5 | $0.00000 | $0.00166 |
| Sonnet 5 | $0.00000 | $0.00066 |
| Haiku 4.5 | $0.00000 | $0.00033 |
Grade A, and why
merge-apply 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 3d 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
merge-apply — deterministic batched landing
This is a closed command definition, not a model prompt. Its input contains
a schema-validated plan[] of merge_pr items from merge-plan@1 (size 1
through policy.merge.batch_size). Immediately before each squash, the
command re-reads that PR's head and base SHA, exact branch names,
open/draft/mergeable state, GitHub and Linear holds, and required CI. A
stale, unmergeable, held, or red item is skipped with a reason; the rest
of the batch continues. Only develop is auto-mergeable.
The command uses --match-head-commit, never deletes a branch, never tears
down a worktree, and never marks Linear Done.
After GitHub proves each successful squash is MERGED, the command records
that item's exact merge SHA. One idempotent factory.merge-landed event is
emitted for the whole batch, carrying landed[] (pr, ticket, headSha,
mergeSha, headRef) plus finalSha (the last successful merge SHA). That
event is the only path to merge verification. If nothing landed, a refresh
factory.merge.requested is emitted so skipped items can be re-planned.
Uncertain merge (squash succeeded but SHA unreadable) fails the run when
nothing has landed yet; after earlier successes it skips the remainder.
bun {factoryRoot}/event-runtime/lib/merge-apply.mjs
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.
- 3d ago First seen · 26 lines · 0 tokens per session scan A 2dd21b7c8463
merge-apply is an agent published in the GitHub repository watt-mind/factory (10 stars, last pushed 3d ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 332 tokens. 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
ap-implementer
L3 executor - G4 IMPLEMENT. Builds one feature from its approved executable roadmap item or conditional frozen plan using strict TDD and real test runs; coverage >=95% on changed lines. Reports PLAN-CONFLICT rather than improvising.
ap-manager
L2 optional manager - coordinates a multi-lane slice, builds compact pointer envelopes, and dispatches disjoint L3 work without executing it.
ap-feature-coordinator
L1 feature coordinator - drives approved ROADMAP.md lanes through their required build/review/verification gates and owns the run-wide feature frontier.
ap-framework-generator
L3 executor - FRAMEWORK GENERATE. When the SELECTOR returns MISS, generates a one-off custom framework for the exact task shape - classifies the orthogonal axes, composes the gate sequence from the GATE-LIBRARY with the correct axis-specific gate, emits the gen- leaf with the BLOCKED invariant verbatim, binds an…
ap-framework-validator
L4 terminal leaf - FRAMEWORK VALIDATE (HRN-5). A fresh, default-FAIL juror that proves a GENERATED framework is SOUND before any gate runs. Checks the HRN-5 default-FAIL checklist - every gate mapped, exactly one terminal DONE with negatives looping UP, the BLOCKED invariant verbatim, a non-empty acceptance set. PASS…
ap-scope-coordinator
L1 scope coordinator - drives the useful-first adaptive roadmap flow and returns one independently approved executable ROADMAP.md before build.