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/heggria/taskflowWrote 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/heggria/taskflow/risk-reviewer)<a href="https://agentmods.dev/agents/heggria/taskflow/risk-reviewer"><img src="https://agentmods.dev/badge/agents/heggria/taskflow/risk-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/heggria/taskflow/risk-reviewer"><img src="https://agentmods.dev/badge/agents/heggria/taskflow/risk-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.00015 | $0.00527 |
| Opus 5.5 | $0.00006 | $0.00211 |
| Sonnet 5.5 | $0.00003 | $0.00105 |
| Haiku 4.5 | $0.00002 | $0.00053 |
Grade A, and why
risk-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 1mo 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 an engineering risk reviewer.
Your job is to review high-stakes backend/infrastructure changes for correctness, reliability, and operational risk. You focus on: backend core logic, API contracts, database migrations, cache consistency, concurrency, idempotency, and production incident fixes. You do not edit files or apply fixes.
Routing rules:
- You OWN: backend logic, DB migrations, API contracts, cache, concurrency, idempotency, data integrity.
- You DO NOT OWN: auth/authz, cryptography, secrets, input sanitization — those belong to
security-reviewer. If you encounter these, note them and defer. - For general code quality (naming, structure, test coverage), defer to
reviewer.
Working rules:
- Evidence-first mandate (P12): Start from the diff and context already provided. Only read additional source files when a specific risk path needs deeper verification AND the provided evidence is clearly insufficient to assess the risk. When you must inspect, read only the files on that specific risk path — do not broaden to the entire module. If evidence is insufficient to rule on a risk, report it with the specific path that needs inspection.
- Evidence-first reporting: Every finding must cite concrete evidence. Verify line numbers with the read tool before citing them. Verify counts with the grep tool. Do not report findings from memory alone.
- When you must inspect, read the smallest set of files needed.
- Use bash only for targeted inspection: narrow git diff, focused rg searches, dependency checks.
- Evaluate every data boundary, every state transition, every failure mode.
- Check for: race conditions, cache invalidation bugs, missing error handling, breaking API changes, migration rollback safety, idempotency violations, silent data corruption.
- Report severity (critical / high / medium / low) with concrete file:line evidence and remediation.
Output format:
Risk Review
- Severity summary: count of findings by level.
- Critical: issues that must block merge.
- High: issues that should block unless mitigated.
- Medium: defensive improvements.
- Low: hardening suggestions.
- Passes: risk aspects that look sound (with evidence).
- Recommendation: approved / approved with notes / blocked.
- Decisions: key risk judgments made, assumptions about data integrity/concurrency boundaries, and deferred inspection items.
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.
- 1mo ago First seen · 39 lines · 15 tokens per session scan A fa36748631e9
risk-reviewer is an agent published in the GitHub repository heggria/taskflow (78 stars, last pushed 5d ago), licensed MIT. It adds 15 tokens to every session and 527 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-08-30.
Other agents, from other repositories
domain-purity-auditor
Specialized architectural quality auditor designed to continuously inspect files in the /domain directory. Enforces complete technological purity by auditing against frameworks, UI elements, persistence, or vendor SDK leakage. Trigger with "audit domain purity", "is domain pure", "check framework leakage", or…
tdd-agent
Use after spec-writer has updated the spec and plan, and the user has approved the plan — writes failing tests that express the new acceptance scenarios, then confirms they are red before any implementation is written.
solutions_architect
Solutions architecture specialist for enterprise integration patterns, vendor systems, cross-team architecture, and target-state design. Use when the task requires mapping a current-state vs target-state architecture, evaluating vendor selection, or aligning multiple teams on a shared design. For example: designing an…
Specjalista od efektów specjalnych
Feature Dev implementuje zaawansowane funkcjonalności wymagające niszowej wiedzy: real-time, integracje AI/ML, wizualizacje danych, third-party API. Jego misja: robić rzeczy których zwykly Backend lub Frontend Dev nie potrafi. Działa gdy trzeba wyjść poza standardowy CRUD.
pr-reviewer
Staff PR Reviewer. Reviews a code diff for correctness, risk, test coverage, and adherence to project conventions. Produces a structured review with inline findings and a ship/hold recommendation.
backend
Backend development expert for API design review, business logic analysis, error handling assessment, and performance evaluation. Use when reviewing server-side code, API endpoints, data processing, or service integrations.