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 skills add gtrabanco/agentic-workflow --skill review-codegit clone --depth 1 https://github.com/gtrabanco/agentic-workflowWrote 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/skills/gtrabanco/agentic-workflow/review-code)<a href="https://agentmods.dev/skills/gtrabanco/agentic-workflow/review-code"><img src="https://agentmods.dev/badge/skills/gtrabanco/agentic-workflow/review-code/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/skills/gtrabanco/agentic-workflow/review-code"><img src="https://agentmods.dev/badge/skills/gtrabanco/agentic-workflow/review-code.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00063 | $0.00730 |
| Opus 5.5 | $0.00025 | $0.00292 |
| Sonnet 5.5 | $0.00013 | $0.00146 |
| Haiku 4.5 | $0.00006 | $0.00073 |
Grade A, and why
review-code 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 26d 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 — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Review Code (internal)
Composed by review-change / product-audit within their conversation — on any
agent, follow this file inline as the routed step. Findings only; never edits,
never refactors.
Scope
The diff or path/glob the caller passes; default the current change vs the default branch. State the scope at the top of the returned table.
Checklist (evaluate EVERY item — none is optional; n/a must be stated)
✓ No logic errors on the changed paths (trace each modified function's inputs → outputs, including boundary values) ✓ Every error path is handled — no swallowed exceptions, no empty catch, no silently-ignored return codes ✓ No duplicated logic (a changed block does not re-implement an existing helper — cite the existing one if it does) ✓ No dead code introduced (unused functions, params, imports, unreachable branches) ✓ No leftover TODO/FIXME/HACK markers in the diff ✓ Naming and file conventions match the project's docs (read them first; cite the convention violated) ✓ No new abstraction beyond what the SPEC requires (an interface/base class with one implementation is a finding) ✓ No new dependency not justified in the SPEC ✓ Simplification: any changed block that can lose lines without losing behavior (cite before/after) ✓ Reference trace: every changed symbol/API got a reference search — un-updated callers are findings ✓ Edge cases the SPEC's dev scenarios name are actually handled in code, not just in tests
Materiality bar
Report a row only when a competent user's outcome changes or a rule the project
explicitly declares is violated — cite the rule it violates beside the evidence.
Not findings: comment/punctuation typos, formatting-only drift, style preference
with no cited rule, hypothetical robustness beyond the SPEC's named scenarios.
An empty table with Decision: PASS is the expected result for a well-formed
change — never pad the table.
Return exactly
REVIEW CODE — scope: <scope>
| # | Finding | Sev | Evidence | Suggested fix |
|---|---------|-----|----------|---------------|
| 1 | <what> | critical|major|minor | <file:line> | <smallest action> |
Checklist: <n> evaluated, <n> pass, <n> findings, <n> n/a (<which + why>)
Summary: <1-2 sentences>
Decision: PASS | FAIL
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.
- 26d ago Changed 3749fcb2ae0b
- 1mo ago Changed · +2 lines 7b5187877f99
- 1mo ago Changed · +9 lines 2a33e6aa89c5
- 1mo ago First seen · 70 lines · 63 tokens per session scan A 46853f776468
review-code is a skill published in the GitHub repository gtrabanco/agentic-workflow (22 stars, last pushed today), licensed MIT. It adds 63 tokens to every session and 730 once invoked, about $0.0003 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 skills, from other repositories
argumentation
Construct well-structured arguments using the hypothesis-argument-example triad. Covers formulating falsifiable hypotheses, building logical arguments (deductive, inductive, analogical, evidential), providing concrete examples, and steelmanning counterarguments. Use when writing or reviewing PR descriptions that…
cross-review-project
Conduct a structured cross-project code review between two Claude Code instances via the cross-review-mcp broker. Each agent reads its own codebase, reviews the peer's code, and engages in evidence-backed dialogue — with QSG scaling laws enforcing review quality through minimum bandwidth constraints and phase-gated…
create-pull-request
Create and manage pull requests using GitHub CLI. Covers branch preparation, writing PR titles and descriptions, creating PRs, handling review feedback, and merge/cleanup workflows. Use when proposing changes from a feature or fix branch for review, merging completed work into the main branch, requesting code review…
coding-guidance-python
Python implementation and review skill. Use when writing, modifying, refactoring, or reviewing Python code, especially production Python that needs clear contracts, type safety, testability, and maintainable module boundaries. Portable across Python repos and tooling stacks.
code-review
Review code for best practices and potential issues.
think-like-me
Personal engineering rules and reasoning patterns the user has curated over time. Consult BEFORE writing, modifying, debugging, or designing any technical feature — rules often cover domain-specific gotchas (e.g., mobile audio timers need background mode) that generic answers miss. Also triggers on /learn-this, "learn…