Wick code review

Skill agoradynamics/wick/.claude/skills/wick-code-review

Drop-in thinking-partner personality layer for Claude Code, Cursor, ChatGPT, and 20+ AI agent runtimes. MIT. Plaintext. Persistent memory. Framework-grounded. Calibration-disciplined.

Install

npx -y skills add agoradynamics/wick --skill wick-code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.4 KB, as published. Nobody here has run it

Wick — Code Review

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?