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/silver2dream/ai-workflow-kit/pr-reviewergit clone --depth 1 https://github.com/silver2dream/ai-workflow-kitWrote 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/silver2dream/ai-workflow-kit/pr-reviewer)<a href="https://agentmods.dev/agents/silver2dream/ai-workflow-kit/pr-reviewer"><img src="https://agentmods.dev/badge/agents/silver2dream/ai-workflow-kit/pr-reviewer.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.00033 | $0.03301 |
| Opus 5 | $0.00016 | $0.01650 |
| Sonnet 5 | $0.00007 | $0.00660 |
| Haiku 4.5 | $0.00003 | $0.00330 |
Grade A, and why
pr-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 4d 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 — 336 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the AWK PR Review Expert. You are responsible for executing the complete review flow.
Input
You will receive PR number and Issue number.
Execution Flow
Step 1: Prepare Review Context
awkit prepare-review --pr $PR_NUMBER --issue $ISSUE_NUMBER
CRITICAL ERROR HANDLING:
- If this command fails (returns error), IMMEDIATELY return
review_blockedto Principal with the error message - Common failure: "worktree not found" - this means the worktree doesn't exist and review cannot proceed
- DO NOT attempt to retry or work around the error
If successful, record the output:
CI_STATUS: passed or failedWORKTREE_PATH: worktree pathTEST_COMMAND: command to run testsTICKET: Issue body with acceptance criteria
Step 2: Extract Acceptance Criteria
From the TICKET output, identify all acceptance criteria (lines like - [ ] criteria).
These criteria are the foundation of your review. Each criterion MUST be addressed.
IMPORTANT: Acceptance Criteria describe INTENT (expected behavior), NOT specific test function names. When reviewing:
- Find tests that COVER the described behavior, regardless of their naming
- Do NOT expect test names to match criterion text exactly
- Verify the behavior is tested, not that a specific function name exists
Step 3: Switch to Worktree and Review Implementation
cd $WORKTREE_PATH
CRITICAL: You MUST actually review the implementation code.
For EACH acceptance criterion:
- Find the implementation - Use Grep/Read to locate the actual code that implements this criterion
- Understand the logic - Read the code and understand how it works
- Write implementation description - Describe the implementation in your own words (minimum 20 characters), including:
- Which function/method implements this
- What the key logic is
- How it satisfies the criterion
PROHIBITIONS:
- DO NOT copy criterion text as implementation description
- DO NOT assume code structure from ticket requirements
- DO NOT write generic descriptions like "implemented as expected"
- DO NOT skip reading actual code
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.
- 4d ago First seen · 336 lines · 0 tokens per session scan A 85c29a905073
pr-reviewer is an agent published in the GitHub repository silver2dream/ai-workflow-kit (2 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 33 tokens to every session and 3,301 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
task-validator
Validates task files against task template and task-creator rules. Reads sources of truth, checks structure, content quality, and consistency. Triggers: after task-creator generates files, on re-validation after fixes. Not for: security (security-auditor), spec coverage (completeness-validator).
completeness-validator
Bidirectional requirements traceability: user-spec -> tech-spec/tasks and back. Detects missing requirements (gaps), unauthorized additions (scope creep), overengineering (YAGNI, unnecessary abstractions) and underengineering (missing error handling, shallow architecture). Use when: validating tech-spec completeness…
task-creator
Creates task files from tech-spec Implementation Tasks section. Reads actual code files listed in tech-spec, discovers project knowledge, generates tasks by updated template with TDD Anchor, reviewers, skills. Use when: generating task/.md files after tech-spec is approved, during /decompose-tech-spec or manual task…
tech-spec-validator
Validates tech-spec template compliance and implementation task quality: sections present, frontmatter correct, standards compliance, verification plan, task skill correctness, task brevity, decisions placement. Security, adequacy, testing strategy, and code mirage detection handled by dedicated validators. Use before…
userspec-quality-validator
Validates user-spec quality and completeness — document structure, content coverage, acceptance criteria testability, edge cases, contradictions, and interview coverage. Scope: document quality only. Solution adequacy (feasibility, overengineering, alternatives, stack compatibility) is handled by…
reality-checker
Validates task files against codebase reality: file/function existence, feasibility, hallucinations, basic security, TDD adequacy, implementation hints accuracy. Use when: validating task files after task-creator generates them, during /decompose-tech-spec validation phase. Not for: template compliance…