A multi-agent code and systems inspection skill for Claude. Deploy a team of 8 specialist AI agents that independently audit your codebase, conference on their findings, vote on priorities, and produce a unified report.
Built for use with OpenCode, Claude Code, and any Claude environment that supports skills.
When triggered, the skill assembles a full inspection team:
| Agent | Domain |
|---|---|
| Security | Injection vectors, auth gaps, exposed secrets, crypto, headers |
| Logic | Edge cases, async bugs, null handling, control flow, silent failures |
| Performance | N+1 queries, memory leaks, algorithmic complexity, caching gaps |
| Architecture | Coupling, separation of concerns, scalability, testability |
| DX | Naming, readability, error messages, docs, test quality |
| Dependencies | Vulnerable packages, abandoned libs, version pinning, bloat |
| Data | Schema design, migrations, transactions, PII, audit trails |
| Observability | Logging, error tracking, alerts, health checks, silent failures |
Each agent reads your code exhaustively, forms hypotheses, tests each one, and classifies every finding. Then they run a structured conference — responding to each other's findings across domains. Then they vote. Then you get a report.
Copy the skill folder into your OpenCode skills directory:
git clone https://github.com/moswek/systems-checker
cp -r systems-checker ~/.opencode/skills/systems-checkerOr if you use a custom skills path defined in your OpenCode config, copy it there instead.
git clone https://github.com/moswek/systems-checker
cp -r systems-checker ~/.claude/skills/systems-checkerOnce installed, just describe what you want checked. The skill triggers on phrases like:
audit this codebase
check my code for issues
security review on this
is this production ready
deep review of my API
find all issues in this project
For OpenCode specifically, point it at your project root:
check this codebase at ./src — full audit, Next.js 16 app, Postgres backend, deploying to Vercel
The more context you give upfront (stack, environment, known concerns), the faster it gets to findings.
The Coordinator asks what's being inspected and what the concern is. If you've already provided that context, it skips straight to deployment.
All 8 agents are spawned in parallel (or sequentially in single-turn environments like OpenCode — see below). Each agent reads the same source material through their specialist lens.
Each agent operates with the following mandate:
"I am the last line of defense before this system touches real users. I will not assume anything is fine. I will test every assumption. I look for what the author missed, not just what they checked."
Every agent must:
- State exactly what files they covered
- Classify every finding (Critical / High / Medium / Low / Info)
- Include location, reproduction path, impact, and fix for each finding
- Explicitly state what was clean — no silent passes
Agents present findings in a structured debrief format. Cross-domain responses are mandatory — if Logic flags unvalidated input and Security sees a vector there, Security elevates it. The cross-pollination is where the most interesting findings surface.
Agents vote on the top priority fixes. Any issue with 3 or more votes enters the priority queue, regardless of what the Coordinator thinks. The vote is binding.
[Issue]: Unvalidated input → SQL injection risk
Security ✓ | Logic ✓ | Performance — | Architecture ✓ | DX — | Data ✓ | Observability —
Result: 4/7 → PASSED — Fix First
EXECUTIVE SUMMARY
[Direct health assessment — no hedging]
CRITICAL ISSUES (fix before shipping)
HIGH PRIORITY ISSUES (fix this sprint)
MEDIUM PRIORITY ISSUES (add to backlog)
LOW / INFO
VOTED PRIORITY QUEUE
WHAT'S SOLID
RECOMMENDED NEXT STEPS
OpenCode doesn't spawn parallel subagents, so the skill runs in sequential inspection mode. Each agent activates one at a time, completes their investigation, then hands off. The conference, vote, and report still happen in full.
OpenCode's bash tool access makes this more powerful than paste-based review — agents can run:
npm audit
grep -r "console.log" src/
find . -name "*.env*"
git log --oneline -20
cat package.jsonFor large codebases, consider redirecting output:
audit ./src and write the full report to audit-report.md
systems-checker/
├── SKILL.md # Coordinator logic and full protocol
├── README.md # This file
├── agents/
│ ├── security-agent.md # Security specialist mandate
│ ├── logic-agent.md # Logic and correctness mandate
│ ├── performance-agent.md # Performance and scalability mandate
│ ├── architecture-agent.md # Architecture and design mandate
│ ├── dx-agent.md # Developer experience mandate
│ ├── dependency-agent.md # Dependency audit mandate
│ ├── data-agent.md # Data integrity mandate
│ └── observability-agent.md # Monitoring and logging mandate
└── references/
└── report-format.md # Shared finding schema and severity definitions
Each finding follows this schema:
FINDING #N
Severity: CRITICAL | HIGH | MEDIUM | LOW | INFO
Agent: [Name]
Title: [Specific, not generic]
Location: [file:line or module]
Description: [What is wrong, with specific code reference]
Reproduction Path: [How it manifests]
Impact: [Concrete consequence if unfixed]
Fix: [Specific remediation, code example where helpful]
Cross-Agent Notes: [Intersections with other domains]
| Level | Meaning |
|---|---|
| CRITICAL | Fix before any deployment. Active risk of breach, data loss, or system failure. |
| HIGH | Fix before production release. Will cause significant problems under real conditions. |
| MEDIUM | Fix this sprint. Creates compounding risk if left. |
| LOW | Track and address. Technical debt that slows future work. |
| INFO | Observation. No immediate action required. |
This skill is built on one idea: most code reviews are too polite and too fast.
Agents are explicitly instructed not to soften findings. If something is broken, it gets called broken. If it's dangerous, it gets called dangerous. The conference format exists because the most important findings often live at the intersection of two domains — a logic bug that's also a security vector, a performance issue that's also an architecture smell.
The vote exists to remove the Coordinator's editorial bias from prioritization. The team decides what matters most, not the summarizer.
To add a new agent:
- Create
agents/your-agent.mdfollowing the mandate format of existing agents - Add it to the agent list in
SKILL.mdunder Stage 2 - Add it to the vote format in Stage 5 and the conference format in Stage 4
- Update the agent table in this README
To modify an existing agent's domain, edit their .md file directly. The mandate structure (domain, mindset, what you must do, output format, conference behavior) should be preserved.