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/kyegomez/swarms/code-reviewnpx skills add kyegomez/swarms --skill code-reviewgit clone --depth 1 https://github.com/kyegomez/swarmsWrote 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/kyegomez/swarms/code-review)<a href="https://agentmods.dev/skills/kyegomez/swarms/code-review"><img src="https://agentmods.dev/badge/skills/kyegomez/swarms/code-review.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.00021 | $0.00571 |
| Opus 5 | $0.00010 | $0.00285 |
| Sonnet 5 | $0.00004 | $0.00114 |
| Haiku 4.5 | $0.00002 | $0.00057 |
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 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 — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review Skill
When reviewing code, follow this systematic approach to ensure thorough evaluation:
Review Checklist
1. Code Quality
- Readability: Is the code easy to understand?
- Naming: Are variables, functions, and classes well-named?
- Structure: Is the code properly organized and modular?
- Comments: Are complex sections adequately documented?
- Complexity: Are there overly complex functions that should be simplified?
2. Security Analysis
Check for common vulnerabilities:
- SQL injection vulnerabilities
- XSS (Cross-Site Scripting) vulnerabilities
- Authentication and authorization flaws
- Insecure data handling (passwords, sensitive data)
- Input validation and sanitization
- OWASP Top 10 vulnerabilities
3. Performance Considerations
- Identify potential bottlenecks
- Check for inefficient algorithms or data structures
- Look for unnecessary database queries or API calls
- Evaluate caching opportunities
- Assess memory usage patterns
4. Best Practices
- DRY Principle: Eliminate code duplication
- SOLID Principles: Verify adherence to design principles
- Error Handling: Check for proper exception handling
- Testing: Evaluate test coverage and quality
- Dependencies: Review external dependencies and their versions
5. Maintainability
- Is the code easy to modify and extend?
- Are there proper abstractions?
- Is the architecture scalable?
- Are there technical debt concerns?
Review Format
Structure your review as follows:
- Summary: High-level overview of the changes
- Critical Issues: Security vulnerabilities or bugs that must be fixed
- Major Concerns: Significant issues affecting quality or performance
- Suggestions: Optional improvements and best practices
- Positive Feedback: Acknowledge good practices and improvements
Guidelines
- Be constructive and respectful
- Provide specific examples and suggestions
- Explain the "why" behind recommendations
- Prioritize issues by severity (critical, major, minor)
- Reference documentation or standards when applicable
- Consider the context and constraints of the project
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 · 82 lines · 21 tokens per session scan A 2869a7c4a899
code-review is a skill published in the GitHub repository kyegomez/swarms (7,120 stars, last pushed today), licensed Apache-2.0. It adds 21 tokens to every session and 571 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 skills, from other repositories
analytics-instrumentation
Add product analytics (BI) events to Opik features. Use when wiring events on the frontend, the backend, or the Python SDK - all three report through Segment to PostHog.
playwright-pom-discovery
Use when building or extending a Page Object Model (POM) for the Opik E2E suite (under testsendtoend/e2e/pom/) and you need to choose stable selectors against the live UI. Walks through seeding required state, exploring the running page with the Playwright MCP (accessibility snapshot + data-testid enumeration)…
marimo-pair
Work inside the user's live marimo notebook from the code editor: run Python in the same kernel the user does, inspect live notebook state, and commit durable notebook changes through code mode. Use whenever you create, analyze, or improve the user's marimo notebook.
explore-feature
Use when a developer wants an e2e test covering a change they just made — e.g. "explore this feature", "add a test for my PR", "cover the feature in PR.
metrics-instrumentation
Specification for instrumenting an opik-backend workflow with operational OpenTelemetry metrics — per-stage throughput/latency/error counters and native histograms, dimensioned per-customer (workspace). Use when a pipeline (scoring, ingestion, experiments, jobs) needs per-stage visibility. Covers metric emission only…
write-docs
Authoring Fern MDX documentation pages for the Opik docs site, plus release-note and changelog routing. Use when writing or updating pages under apps/opik-documentation/documentation/fern/, drafting PR descriptions, or picking the right changelog surface.