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 skills/squadcodercom/squadcoder/code-reviewnpx skills add squadcodercom/squadcoder --skill code-reviewgit clone --depth 1 https://github.com/squadcodercom/squadcoderWhat 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.00099 | $0.00814 |
| Opus 5 | $0.00049 | $0.00407 |
| Sonnet 5 | $0.00020 | $0.00163 |
| Haiku 4.5 | $0.00010 | $0.00081 |
Grade A, and why
sc: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 yesterday.
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 — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review — senior-engineer pass over a diff/PR
Find what matters and say it clearly. A good review surfaces real defects with evidence, not a list of style opinions. Default to reviewing the changed lines and their blast radius.
Step 0 — orient
- What is this change trying to do? (Read the PR description / commit messages / the diff intent.)
- What's the blast radius — what calls this, what does it call, what data does it touch?
- Get the actual diff (
git diff), don't review from memory.
Review dimensions (in priority order)
- Correctness & edge cases — does it do what it claims? Off-by-one, null/empty/None, error paths, async races, unhandled rejections, boundary inputs, wrong default. This is most of the value.
- Security — input validation, injection (SQL/command/path traversal), authn/authz checks, secrets in code/logs, unsafe deserialization, XSS/CSRF for web, SSRF for fetchers.
- Resource & performance — N+1 queries, unbounded loops/memory, missing pagination, blocking I/O on a hot path, leaks (listeners, handles), needless re-renders.
- API & data contracts — backward compatibility, migration safety, nullable changes, error shapes.
- Readability & maintainability — names, dead code, duplication, function size, matches the surrounding style. Flag, don't bikeshed.
- Tests — is the new behavior covered? Are the tests meaningful (assert real outcomes) or hollow?
How to report findings
For each finding:
- Severity:
blocker/major/minor/nit. - Location:
file:line(clickable). - What & why: the concrete problem and the failure it causes — quote the code.
- Fix: a specific suggestion (or a diff), not "consider improving this".
Group by severity; lead with blockers. Example:
[blocker]
auth.ts:42— token compared with==, so an empty token matches when the stored value is also falsy. Use a constant-time compare and reject empty tokens.
Discipline
- Verify before asserting. Trace the data flow; don't claim a bug you didn't confirm in the code. If you're unsure, say "possible issue — verify X", don't state it as fact.
- Separate must-fix (correctness/security) from nice-to-have (style). Don't drown blockers in nits.
- Praise genuinely good choices briefly — it calibrates the rest.
- If the diff is large, review in passes (correctness → security → the rest) rather than skimming once.
- RTL/Hebrew web code: check for physical-CSS leftovers (
left/right/ml-/mr-) that break RTL — prefer logical properties.
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.
- yesterday First seen · 56 lines · 99 tokens per session scan A ee5d675cd210
sc:code-review is a skill published in the GitHub repository squadcodercom/squadcoder (11 stars, last pushed 2mo ago), licensed MIT. It adds 99 tokens to every session and 814 once invoked, about $0.0005 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 skills, from other repositories
write-zot-themes
Help the user create, install, or package zot themes, including theme-only extensions.
python-testing
Python testing best practices using pytest including fixtures, parametrization, mocking, coverage analysis, async testing, and test organization. Use when writing or improving Python tests.
database-migrations
Database migration best practices for schema changes, data migrations, rollbacks, and zero-downtime deployments across PostgreSQL, MySQL, and common ORMs (Prisma, Drizzle, Django, TypeORM, golang-migrate). Use when planning or implementing database schema changes.
docker-patterns
Docker and Docker Compose patterns for local development, container security, networking, volume strategies, and multi-service orchestration. Use when setting up containerized development environments or reviewing Docker configurations.
python-patterns
Python-specific design patterns and best practices including protocols, dataclasses, context managers, decorators, async/await, type hints, and package organization. Use when working with Python code to apply Pythonic patterns.
st-full-workflow
Use when the user asks to run the complete end-to-end Strikethroo workflow for a work order in one shot in this repository — triggers include full workflow, end-to-end, plan and execute, do everything, run the whole strikethroo workflow. Do not use when the user wants only one stage (create a plan, generate tasks, or…