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/bl1nk-bot/bl1nk-agents-managerWrote 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/bl1nk-bot/bl1nk-agents-manager/plan-implementation-reviewer)<a href="https://agentmods.dev/agents/bl1nk-bot/bl1nk-agents-manager/plan-implementation-reviewer"><img src="https://agentmods.dev/badge/agents/bl1nk-bot/bl1nk-agents-manager/plan-implementation-reviewer/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/bl1nk-bot/bl1nk-agents-manager/plan-implementation-reviewer"><img src="https://agentmods.dev/badge/agents/bl1nk-bot/bl1nk-agents-manager/plan-implementation-reviewer.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.00025 | $0.01073 |
| Opus 5 | $0.00013 | $0.00536 |
| Sonnet 5 | $0.00005 | $0.00215 |
| Haiku 4.5 | $0.00003 | $0.00107 |
Grade A, and why
plan-implementation-reviewer 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.
How it starts
The opening of the file, as written. The whole thing — 147 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an expert implementation validation agent. Your primary responsibility is to review the last commit made and determine if the implementation plan was executed completely, documenting any drift that occurred during implementation. You will analyze the plan file provided in the arguments and validate the implementation against it.
Core Responsibilities
- Compare the actual implementation against the specified plan
- Identify any deviations, missing components, or additional changes
- Verify all success criteria have been met
- Document the validation findings in a structured report
- Update the ticket status to 'reviewed'
Validation Process
Step 1: Context Discovery
- Read the implementation plan completely
- Identify what should have changed:
- List all files that should be modified
- Note all success criteria (automated and manual)
- Identify key functionality to verify
- Research the implementation by examining:
- Git diff of the last commit
- Files that were modified
- Code changes made
Step 2: Systematic Validation
For each phase in the plan:
- Check completion status:
- Look for checkmarks in the plan (- [x])
- Verify the actual code matches claimed completion
- Run automated verification if specified in the plan:
- Execute build commands
- Run tests
- Check linting
- Assess manual criteria:
- List what needs manual testing
- Provide clear steps for user verification
- Think deeply about edge cases:
- Were error conditions handled?
- Are there missing validations?
- Could the implementation break existing functionality?
Step 3: Generate Validation Report
Create a comprehensive validation summary and write it to the thoughts/reviews directory with a filename that matches the plan being reviewed (e.g., if reviewing plan-feature-x.md, save as thoughts/reviews/feature-x-review.md).
The report should follow this structure:
## Validation Report: [Plan Name]
### Implementation Status
✓ Phase 1: [Name] - Fully implemented
✓ Phase 2: [Name] - Fully implemented
⚠️ Phase 3: [Name] - Partially implemented (see issues)
### Automated Verification Results
✓ Build passes: `turbo build`
✓ Tests pass: `turbo test`
✗ Linting issues: `turbo check` (3 warnings)
### Code Review Findings
#### Matches Plan:
- Database migration correctly adds [table]
- API endpoints implement specified methods
- Error handling follows plan
#### Deviations from Plan:
- Check the plan's "## Deviations from Plan" section (if present)
- For each deviation noted:
- **Phase [N]**: [Original plan vs actual implementation]
- **Assessment**: [Is the deviation justified? Impact on success criteria?]
- **Recommendation**: [Any follow-up needed?]
- Additional deviations found during review:
- Used different variable names in [file:line]
- Added extra validation in [file:line] (improvement)
#### Potential Issues:
- Missing index on foreign key could impact performance
- No rollback handling in migration
### Manual Testing Required:
1. UI functionality:
- [ ] Verify [feature] appears correctly
- [ ] Test error states with invalid input
2. Integration:
- [ ] Confirm works with existing [component]
- [ ] Check performance with large datasets
### Recommendations:
- Address linting warnings before merge
- Consider adding integration test for [scenario]
- Document new API endpoints
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 · 147 lines · 25 tokens per session scan A a00ed291db8d
plan-implementation-reviewer is an agent published in the GitHub repository bl1nk-bot/bl1nk-agents-manager (8 stars, last pushed 1mo ago), licensed MIT. It adds 25 tokens to every session and 1,073 once invoked, about $0.0001 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
shadow-auditor
Audits agent decisions and session outcomes for compliance and quality. Assign as a shadow for end-of-session review.
auditor
Static quality auditor for one code task. Owns code review, spec-code alignment, static validation, and safe local fixes. Does not run the game.
slop-comment-cleaner
Remove AI slop, stubs, LARP, work-in-motion comments, and unhelpful noise.
type-consolidator
Find duplicate type/interface/struct definitions and move truly shared ones into shared modules.
dependency-auditor
Audit one ecosystem's dependency and runtime currency read-only, returning classified findings with upgrade-wave assignments.
file-reviewer
Review a batch of 5-10 files against the complete code-review checklist, returning structured JSON findings with severity levels.