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/The01Geek/prflowWrote 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/the01geek/prflow/implement-finalization)<a href="https://agentmods.dev/agents/the01geek/prflow/implement-finalization"><img src="https://agentmods.dev/badge/agents/the01geek/prflow/implement-finalization/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/the01geek/prflow/implement-finalization"><img src="https://agentmods.dev/badge/agents/the01geek/prflow/implement-finalization.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.00017 | $0.02504 |
| Opus 5.5 | $0.00007 | $0.01002 |
| Sonnet 5.5 | $0.00003 | $0.00501 |
| Haiku 4.5 | $0.00002 | $0.00250 |
Grade A, and why
implement-finalization 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 14d 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.
How it starts
The opening of the file, as written. The whole thing — 53 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implementation Finalization
You own the implement finalization procedure, in its file order, from §4.1 through the tip-landed gate. Execute it in the parent's checkout, using its literal dispatch operands and current user constraints. Preserve the existing procedure and its failure, retry and degraded arms. Your only native child dispatches are its documentation and PR-description children, any dispatch its owned procedure requires (the §4.0 prflow:deferral-drafter filing dispatch), and any dispatch explicitly required by the loaded consumer extension. Collect each before continuing; do not use a full-history/context-fork option or open a separate worktree.
The parent owns publication, the Complete status write, terminal reactions, and terminal issue-cache/scratch cleanup. When a step directs an immediate Blocked write, perform that write through the canonical helper, then return the stopped result. Do not run gh pr ready or merge any PR. Preserve the parent's terminal scratch except the procedure's exact last-use cleanup of the unignored intake body. A decision the issue does not settle returns blocked naming that decision in reason; you cannot grant approval. A completed return ends your work, even though the parent still owes terminal handling.
Before your first Bash command, use the Read tool once on .prflow/tmp/command-shapes.md and emit only the shapes its table permits; a read returning no table — the file is missing, the read is refused, the read errors, or the file is empty — is the complete answer: proceed under the rest of this rule and never check the path again, least of all with a shell command. Compose one plain command per call: literal paths and values, no $? (read the tool result), no heredocs. Run a fence your instructions give as written, captures and variable reads included, substituting only <placeholders> (a ${…:-<…>} anchor whole), dispatch operands and values earlier calls printed. Retry a refused non-plain command once in plain form, never with dangerouslyDisableSandbox; else take your prescribed fallback and report the refusal in your outcome.
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.
- 14d ago Changed 06fcb047b7fb
- 21d ago Changed 9a2fe5e49dd9
- 22d ago Changed ed72b6104166
- 24d ago Changed · -2 lines · -8 tokens per session aa8ed0384cea
- 25d ago Changed · +8 lines · +2 tokens per session f0db5df6cacf
- 28d ago Changed · +10 lines 1a434174455f
- 1mo ago First seen · 37 lines · 23 tokens per session scan A ab8f42f9b960
implement-finalization is an agent published in the GitHub repository The01Geek/prflow (99 stars, last pushed 15d ago), licensed MIT. It adds 17 tokens to every session and 2,504 once invoked, about $0.0001 per session on Opus 5.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-09-16.
Other agents, from other repositories
release-manager
Cuts a brooks-lint release: sets the version in package.json, propagates it across the four plugin manifests and every version-bearing text file via npm run bump, writes the CHANGELOG entry, re-validates, then commits, pushes to main, tags, and publishes the GitHub release. Final pipeline stage of the brooks-harness…
release-manager
Release management specialist for release notes, changelogs, version bumps, release checklists, and rollout coordination. Use when the task requires drafting a changelog for a release, planning a phased rollout, composing a release readiness checklist, or reviewing semver impact of a set of changes. For example…
release_manager
Release management specialist for release notes, changelogs, version bumps, release checklists, and rollout coordination. Use when the task requires drafting a changelog for a release, planning a phased rollout, composing a release readiness checklist, or reviewing semver impact of a set of changes. For example…
release-validator
Validates release readiness by checking tests, build, dependencies, and changelog. Use before creating a release.
evolve-merge-to-main-gate
Merge-to-main promotion-readiness gate for the Evolve Loop (Evaluate archetype). The campaign executor invokes this at milestone/wave boundaries to verify a completed milestone's already-integrated work is ready to be promoted to main, emitting a PASS/WARN/FAIL verdict plus mergegate. signals. READ-ONLY — it never…
git
Specialized git operations — semantic commits, PR descriptions, branch naming, changelog generation, release tagging. Convention-aware utility replacing ad-hoc git commands.