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 TheStack-ai/swing-skills --skill swing-reviewgit clone --depth 1 https://github.com/TheStack-ai/swing-skillsWrote 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/thestack-ai/swing-skills/swing-review)<a href="https://agentmods.dev/skills/thestack-ai/swing-skills/swing-review"><img src="https://agentmods.dev/badge/skills/thestack-ai/swing-skills/swing-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.1 | $0.00114 | $0.02716 |
| Opus 5 | $0.00057 | $0.01358 |
| Sonnet 5 | $0.00023 | $0.00543 |
| Haiku 4.5 | $0.00011 | $0.00272 |
Grade A, and why
swing-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 8d 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 — 289 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Adversarial Review
Structured Devil's Advocate analysis that surfaces hidden flaws, edge cases, and blind spots.
Rules (Absolute)
- Default to finding problems. Conduct rigorous analysis across all three vectors. Report every genuine issue found — do not downplay or omit real concerns. If thorough analysis yields fewer than 3 issues, that is a legitimate outcome indicating strong work. Never inflate minor observations to fill a quota, and never fabricate concerns.
- Attack the strongest points. Don't waste time on trivial issues. Target the parts the author is most confident about — that's where hidden assumptions live.
- Separate severity levels. Not all issues are equal. Clearly distinguish critical from minor.
- Propose alternatives. Every criticism must include a concrete alternative or mitigation.
- Steel-man first. Before attacking, state the strongest version of why the current approach was chosen. This prevents straw-man critiques.
- No ad hominem. Critique the work, not the author. Be sharp but constructive.
Ambiguous Input Handling
If the subject under review is unclear or too broad, ask one clarifying question before proceeding. Do not review a vague target. Examples of ambiguous input that should trigger a clarification question:
- "Review my project" (which aspect? architecture? security? specific files?)
- "Is this okay?" with no context (what is "this"?)
- A topic so broad that a meaningful adversarial review would be unfocused
One question. Get the answer. Then proceed.
Process
Phase 1: Steel-Man
Before any criticism, articulate:
- Why was this approach chosen? (Best possible justification)
- What does it optimize for? (Performance? Simplicity? Time-to-market?)
- Under what conditions is this the right choice?
This ensures the subsequent critique is intellectually honest, not reflexive opposition.
Phase 2: Adversarial Attack (3 Vectors)
Apply three independent attack vectors simultaneously:
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.
- 8d ago First seen · 289 lines · 114 tokens per session scan A adb7f73eedd6
swing-review is a skill published in the GitHub repository TheStack-ai/swing-skills (40 stars, last pushed 4mo ago), licensed MIT. It adds 114 tokens to every session and 2,716 once invoked, about $0.0006 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
audit
Project health audit and health check — architecture, performance, tests, dependencies, code quality. Use when assessing overall project health, before releases, or after refactors.
review
Review code with parallel agents — tests, security, Ecto, LiveView, Oban. Use after implementation to catch bugs and anti-patterns before committing.
pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
phx-pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
boundaries
Analyze Phoenix context boundaries and module coupling via mix xref. Use when checking cross-context calls, validating dependencies, before splitting modules, or reviewing architecture.
challenge
Challenge mode reviews - rigorous questioning before approving changes. Use when you want thorough scrutiny of Ecto changes, LiveView events, OTP designs, or PR readiness.