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 commands/opensesh/karimo-overview/code-reviewgit clone --depth 1 https://github.com/opensesh/karimo-overviewWhat 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.00010 | $0.01145 |
| Opus 5 | $0.00005 | $0.00573 |
| Sonnet 5 | $0.00002 | $0.00229 |
| Haiku 4.5 | $0.00001 | $0.00114 |
Grade A, and why
code-review 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.
How it starts
The opening of the file, as written. The whole thing — 165 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Provide a code review for the given pull request.
For BOS-3.0 projects, this review includes design system compliance checking alongside bug detection.
Agent assumptions:
- All tools are functional. Do not test tools or make exploratory calls.
- Only call a tool if required. Every tool call should have a clear purpose.
Step 1: Pre-check
Launch a sonnet agent to check if any of the following are true:
- The pull request is closed
- The pull request is a draft
- The pull request doesn't need code review (automated PR, trivial change)
- Claude has already commented on this PR
If any condition is true, stop.
Step 2: Find Guidelines
Launch a sonnet agent to return a list of file paths for all relevant guideline files:
- Root CLAUDE.md file, if it exists
- Any CLAUDE.md files in directories containing modified files
- For BOS projects: Check for
BOS-DESIGN-SYSTEM.mdandtheme.cssreferences
Step 3: Summarize Changes
Launch a sonnet agent to view the pull request and return a summary of the changes.
Step 4: Parallel Review
Launch 4 agents in parallel to independently review. Each agent returns issues with descriptions and reasons.
Agents 1 + 2: Guidelines Compliance (Sonnet)
Audit changes for CLAUDE.md compliance. Only consider CLAUDE.md files that share a path with the file.
For BOS projects, also check:
- Design token usage (CSS variables vs hardcoded colors)
- Border philosophy (40% opacity default, not harsh)
- Accessibility patterns (React Aria, focus states)
- Warm neutrals (Charcoal/Vanilla vs pure black/white)
Agent 3: Bug Detection (Opus)
Scan for obvious bugs in the diff. Focus only on the diff itself. Flag significant bugs; ignore nitpicks.
Agent 4: Logic Issues (Opus)
Look for security issues, incorrect logic in changed code only.
We only want HIGH SIGNAL issues:
- Code will fail to compile/parse (syntax, type errors, missing imports)
- Code will definitely produce wrong results (clear logic errors)
- Clear guideline violations you can quote exactly
- For BOS: Hardcoded colors that should use tokens, missing accessibility patterns
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 · 165 lines · 10 tokens per session scan A 15735545c7ae
code-review is a command published in the GitHub repository opensesh/karimo-overview (11 stars, last pushed 4mo ago), licensed Apache-2.0. It adds 10 tokens to every session and 1,145 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-30.
Other commands, from other repositories
doctor
Check the health of a KARIMO installation, identify issues, and provide actionable recommendations.
dashboard
Phase 3 monitoring — System health, execution insights, and velocity analytics.
run
Execute an approved PRD using feature branch workflow (v7.0). This command generates briefs, auto-reviews them, allows user iteration, and then orchestrates execution.
merge
Consolidate feature branch changes and create final PR to main. This completes the v5.0 feature branch workflow after all task PRs have been merged.
greptile-review
Execute the full Greptile review cycle on a PR, looping until score meets threshold or circuit breaker triggers.
feedback
Intelligent feedback capture with automatic complexity detection and adaptive investigation.