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 commands/wake-engineering/ai-plugin/wake-code-reviewgit clone --depth 1 https://github.com/wake-engineering/ai-pluginWhat 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.00041 | $0.00787 |
| Opus 5 | $0.00020 | $0.00394 |
| Sonnet 5 | $0.00008 | $0.00157 |
| Haiku 4.5 | $0.00004 | $0.00079 |
Grade A, and why
wake-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 yesterday.
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 — 47 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Wake Code Review Workflow
Forbidden: api.fbits.net (and any *.fbits.net). Canonical source: https://wakecommerce.readme.io/docs/schema (for Wake API references).
Review code quality on a Wake Commerce storefront change. Focus is correctness, maintainability, and alignment with the project's Wake-specific patterns — not style nitpicks the linter already enforces.
Inputs
- Scope (required): a PR diff (
git diff origin/main...HEAD), a directory, or specific files. Examples:apps/storefront/src/checkout/**,PR #482. - Severity threshold (optional): minimum severity to surface (Critical / High / Medium / Low). Defaults to Medium.
- Focus areas (optional): subset of {style, types, error-handling, hooks, Wake-patterns, tests}. Defaults to all.
Steps
- Read the change in context. Open the diff and the surrounding files. Confirm the change has a single coherent purpose; flag drive-by edits that should be split.
- Style & naming. Check identifier clarity, no magic numbers, no commented-out code, no dead branches. Defer to ESLint/Prettier for mechanical issues — only flag what the linter cannot catch.
- DRY / SOLID. Identify duplicated logic that should be extracted, modules that took on a second responsibility, and abstractions that leak storage/transport details into UI.
- Error handling. Every async call has a defined failure path. User-visible messages are generic; internal logs include correlation IDs, never PII. No
catch {}silently swallowing errors. ConfirmApiAuthError(and any Wake-specific error types) is handled at the right layer. - React hooks discipline.
useCallback/useMemoonly where dependencies justify it (not as a default). No effects that re-run on every render. Confirm cleanup functions for subscriptions, listeners, and timers. - TypeScript hygiene. Strict mode is on; no
any(useunknown+ narrowing); noascast that bypasses a fixable type; null checks at boundaries. Confirm public functions are exported with explicit return types. - Wake patterns. Cross-check against the project's skills:
wake-storefront-api— productId vs handle, partnerAccessToken usagewake-checkout-flow— mutation orderwake-product-variants—attributeSelectionsresolution- Field names stay Portuguese (
produtoId,precoPor,nome) when surfacing Wake REST data.
- Tests. New behavior has a test; modified behavior has a regression test; tests assert outcomes, not implementation. Flag mocked-database tests where an integration test would catch more.
- Delegate. Hand the assembled notes to the wake-code-reviewer agent for the final write-up with rewritten code snippets.
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.
- yesterday First seen · 47 lines · 41 tokens per session scan A e00b7166f286
wake-code-review is a command published in the GitHub repository wake-engineering/ai-plugin (2 stars, last pushed 3mo ago), licensed MIT. It adds 41 tokens to every session and 787 once invoked, about $0.0002 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-31.
Other commands, from other repositories
merge
Finalize work on a branch: verify docs + tree are clean, merge to main, clean up. Supports both standard git checkout -b branches and git worktree flows — auto-detected at pre-flight.
expect
Diff-aware AI browser testing — reads the git diff, maps changes to affected pages via the route map, generates a targeted test plan, and executes it via agent-browser (Rust daemon + CDP, ARIA-tree-first) with pass/fail reporting. Use when testing UI changes, verifying PRs before merge, or running regression checks on…
speckit.tasks
Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.
dev
Runs Vendure in development mode. By default it starts three processes: the GraphQL server (ts-node ./src/index.ts), the worker (ts-node ./src/index-worker.ts), and the dashboard (a Vite dev server).
start
Runs a project that has already been compiled with vendure build.
pipeline-undo
Undo a pipeline run's result. With worktree isolation (the current engine), this is clean and low-risk: a run never touches your checkout — its result lives only on a pipeline/ branch (and, for a --push run, on the remote). "Undo" therefore means deleting that branch and its worktree, not reverting your working tree.