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 skills/anentrypoint/freddie/code-reviewnpx skills add AnEntrypoint/freddie --skill code-reviewgit clone --depth 1 https://github.com/AnEntrypoint/freddieWhat 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.00019 | $0.00564 |
| Opus 5 | $0.00010 | $0.00282 |
| Sonnet 5 | $0.00004 | $0.00113 |
| Haiku 4.5 | $0.00002 | $0.00056 |
Grade A, and why
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 2d 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 — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review
Perform rigorous, constructive code reviews. Flag real issues, suggest concrete fixes, acknowledge what is done well.
Review dimensions (in order of severity)
1. CORRECTNESS
- Does the code do what the PR description claims?
- Off-by-one errors, wrong comparisons, wrong variable names?
- Async/await patterns correct? Error propagation complete?
- Null/undefined/empty cases handled?
2. SECURITY
- Injection: SQL, shell, HTML, path traversal
- Hardcoded secrets or tokens in logs
- Protected routes actually protected?
- User input validated at boundaries?
- New deps pinned? Known CVEs?
3. PERFORMANCE
- N+1 queries (loop that calls DB/API per iteration)
- Missing indexes for new query patterns
- Blocking calls in async context
- Large allocations in hot paths
4. READABILITY
- Names accurate and unambiguous?
- Functions ≤20 lines?
- Magic numbers replaced with named constants?
- Error handling consistent with codebase?
5. TESTS
- New behaviour covered?
- Tests assert outcomes, not implementation details?
- Error paths tested, not just happy path?
- Tests deterministic (no flaky sleeps, no ordering dependence)?
Comment format
[BLOCKER] src/auth.js:42 — SQL built by string concatenation. Use: db.query('SELECT * FROM users WHERE id = $1', [id])
[SUGGESTION] src/api.js:88 — Loop calls getUserById() N times. Fetch all with WHERE id = ANY($1) and build a Map.
[NITPICK] src/util.js:15 — Variable name `d` is ambiguous. Use `date` or `deadline`.
[PRAISE] src/cache.js — Cache invalidation logic is clean; TTL=0 and concurrent write edge cases handled correctly.
Severity:
- BLOCKER — must fix before merge (bug, security, data loss)
- SUGGESTION — should fix, significant improvement
- NITPICK — optional, style/clarity
- PRAISE — acknowledge explicitly
Rules
- File:line reference on every comment.
- Every BLOCKER includes a concrete fix.
- Do not nitpick formatting if there is a linter — reference the linter rule.
- Do not comment on code outside the diff unless the diff depends on it.
- End with: APPROVE / REQUEST CHANGES / NEEDS DISCUSSION.
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.
- 2d ago First seen · 71 lines · 19 tokens per session scan A a2b82499da14
code-review is a skill published in the GitHub repository AnEntrypoint/freddie (5 stars, last pushed 2d ago), licensed MIT. It adds 19 tokens to every session and 564 once invoked, about $0.0001 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 skills, from other repositories
itchio-new-game-hunt
Hunt for fresh browser-playable games on itch.io /newest that are worth building SEO arbitrage sites for. Crawls new releases, scores them by signals, produces ranked shortlist.
arch-save
Save an architect's state, clear its context, and re-init automatically — the packaged save→clear→re-init refresh cycle. Use when the owner directs a context refresh, or says "/arch-save", "save and clear", "refresh your context". Runs on the owner's direction; an architect does not invoke it autonomously mid-task.…
arch-init
Adopt an architect identity and recover its state from codev/state/ .md. Use when an architect terminal needs to (re)establish which architect it is — after a restart, context loss, or session handoff — or when the user says "/arch-init", "you are the X architect", or "recover your architect state". Identity resolves…
runnable-worktrees
Make builder worktrees runnable — the .codev/config.json worktree block (symlinks, postSpawn, devCommand), the afx dev CLI, VSCode dev controls, and per-stack config recipes. Use when configuring a repo so reviewers can run a builder's branch, when afx dev fails to bind or start, when a dev process is orphaned holding…
codev
Codev project management CLI — init, adopt, update, and doctor commands. Check this skill before running any codev command (except consult, porch, or afx which have their own skills). Use when setting up new projects, adding codev to existing repos, updating framework files, or diagnosing missing dependencies.
porch
Protocol orchestrator CLI — drives SPIR, ASPIR, AIR, TICK, and BUGFIX protocols via a state machine. ALWAYS check this skill before running any porch command. Use when you need to check project status, approve gates, signal phase completion, or manage protocol state. Also use when a builder asks about gate approvals…