How do I install the Wick Code Review skill?

Run npx skillmds@latest add agoradynamics/wick-code-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Wick Code Review safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Wick Code Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Wick Code Review free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Wick Code Review?

agoradynamics (@agoradynamics) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Wick Code Review by agoradynamics — Agent Skill

Name: Wick Code Review
Author: agoradynamics

Wick Code Review

Review code or a pull request through Wick's 5 operational gates. Provides severity-classified feedback distinguishing required from nice-to-have. Use when reviewing PRs, before committing substantial changes, or for adversarial pressure on your own work.

File contents

Wick — Code Review

Updated: 2026-04-20 · first written 2026-04-20

Code review through Wick's gates. More rigorous than generic AI review: each finding is framework-grounded and severity-classified.

Distinction from /review: /review audits your prediction ledger. wick-code-review audits code. Named separately to avoid conflict.

When to invoke

Reviewing a pull request or diff
Before committing a substantial change
When a teammate asks for an independent read
When you want adversarial pressure on your own work

What Wick does

Read the target scope (file, directory, or diff)
Apply the 5 Gates:
- Gate 1 (Control): what does this code let the caller control that they couldn't before? What was ceded?
- Gate 2 (Assent): are the assumptions in the code verified, or pattern-matched from other codebases?
- Gate 3 (Specificity): is the interface specific enough to its problem, or is it generic in a way that harms callers?
- Gate 4 (Adversarial Convergence): does the design hold if the next requirement is the opposite of today's?
- Gate 5 (Calibration): are probability/threshold/timeout claims grounded or hand-waved?
Classify findings:
- Required — must-fix before merge (correctness, security, real bugs)
- Strong recommendation — should-fix (readability, maintainability, test coverage, obvious footguns)
- Nice to have — optional (style, minor refactors)
Cite relevant frameworks (pre-mortem for risk, inversion for failure modes, 5 Whys for unexplained decisions)

Output format

## Required (ship-blocking)
- [file:line] Issue, Gate that caught it, proposed fix

## Strong recommendation
- [file:line] Issue, why it matters, proposed fix

## Nice to have
- [file:line] Optional improvement

## Summary
Approve / Request changes / Block — with reasoning

Framework grounding

Practical wisdom — knowing when a rule applies is itself a skill. Wick classifies findings by severity so you don't treat nitpicks as blockers or footguns as nits. Premortem analysis applied to the diff — imagine the worst case; what is this code doing to cause it or prevent it?

---name: wick-code-reviewdescription: Review code or a pull request through Wick's 5 operational gates. Provides severity-classified feedback distinguishing required from nice-to-have. Use when reviewing PRs, before committing substantial changes, or for adversarial pressure on your own work.license: MIT---# Wick — Code Review*Updated: 2026-04-20 · first written 2026-04-20*Code review through Wick's gates. More rigorous than generic AI review: each finding is framework-grounded and severity-classified.**Distinction from `/review`:** `/review` audits your prediction ledger. `wick-code-review` audits code. Named separately to avoid conflict.## When to invoke- Reviewing a pull request or diff- Before committing a substantial change- When a teammate asks for an independent read- When you want adversarial pressure on your own work## What Wick does1. Read the target scope (file, directory, or diff)2. Apply the 5 Gates: - **Gate 1 (Control):** what does this code let the caller control that they couldn't before? What was ceded? - **Gate 2 (Assent):** are the assumptions in the code verified, or pattern-matched from other codebases? - **Gate 3 (Specificity):** is the interface specific enough to its problem, or is it generic in a way that harms callers? - **Gate 4 (Adversarial Convergence):** does the design hold if the next requirement is the opposite of today's? - **Gate 5 (Calibration):** are probability/threshold/timeout claims grounded or hand-waved?3. Classify findings: - **Required** — must-fix before merge (correctness, security, real bugs) - **Strong recommendation** — should-fix (readability, maintainability, test coverage, obvious footguns) - **Nice to have** — optional (style, minor refactors)4. Cite relevant frameworks (pre-mortem for risk, inversion for failure modes, 5 Whys for unexplained decisions)## Output format```## Required (ship-blocking)- [file:line] Issue, Gate that caught it, proposed fix## Strong recommendation- [file:line] Issue, why it matters, proposed fix## Nice to have- [file:line] Optional improvement## SummaryApprove / Request changes / Block — with reasoning```## Framework groundingPractical wisdom — knowing when a rule applies is itself a skill. Wick classifies findings by severity so you don't treat nitpicks as blockers or footguns as nits. Premortem analysis applied to the diff — imagine the worst case; what is this code doing to cause it or prevent it?

Frequently asked questions