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 skills add shinpr/codex-workflows --skill recipe-front-reviewgit clone --depth 1 https://github.com/shinpr/codex-workflowsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/shinpr/codex-workflows/recipe-front-review)<a href="https://agentmods.dev/skills/shinpr/codex-workflows/recipe-front-review"><img src="https://agentmods.dev/badge/skills/shinpr/codex-workflows/recipe-front-review.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector pass
What 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.1 | $0.00029 | $0.01582 |
| Opus 5 | $0.00015 | $0.00791 |
| Sonnet 5 | $0.00006 | $0.00316 |
| Haiku 4.5 | $0.00003 | $0.00158 |
Grade A, and why
recipe-front-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 4d 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 — 130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Context: Post-implementation quality assurance for React/TypeScript frontend
Required Skills [LOAD BEFORE EXECUTION]
- [LOAD IF NOT ACTIVE]
coding-rules-- repository implementation rules - [LOAD IF NOT ACTIVE]
testing-- verification and test quality rules - [LOAD IF NOT ACTIVE]
ai-development-guide-- review and repair discipline - [LOAD IF NOT ACTIVE]
llm-friendly-context-- task file contract - [LOAD IF NOT ACTIVE]
subagents-orchestration-guide-- agent coordination and result handling
Spawn rule: every spawn_agent call uses fork_turns="none" so the subagent receives only the task message and explicitly provided context.
Execution Method
- Implementation review -> performed by code-reviewer
- Security validation -> performed by security-reviewer
- Code-side fix path -> performed by task-executor-frontend
- Design-side update path -> performed by technical-designer-frontend in update mode, then document-reviewer, then design-sync when multiple Design Docs exist
- Quality checks -> performed by quality-fixer-frontend
- Re-validation -> performed by code-reviewer / security-reviewer
Orchestrator spawns agents and passes structured data between them.
Design Doc (uses most recent if omitted): $ARGUMENTS
Execution Flow
1. Prerequisite Check
Identify the Design Doc in docs/design/. Derive $STEP_1_FILES as the complete change set for the current work from repository history, tracking state, and the working tree. Include committed, staged, unstaged, and untracked paths, and pass the complete set unchanged to both reviewers.
If a single active work plan is explicitly provided or unambiguously resolved for that Design Doc, read its Review Scope line. Otherwise set Work Plan: none and Review Scope: none; do not infer.
[STOP -- BLOCKING] If no Design Doc or implementation files found, notify user and halt. CANNOT proceed without both a Design Doc and implementation files.
2. Execute code-reviewer
Spawn code-reviewer agent: "Review the completed frontend implementation. governingDocuments: [{type: design-doc, path: [design-doc-path]}]. Work Plan: [resolved work plan path or none]. Review Scope: [literal Review Scope value or none]. implementationFiles: [$STEP_1_FILES]. Return the initial review JSON."
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 4d ago Changed fa836953066d
- 8d ago First seen · 130 lines · 29 tokens per session scan A 1ed7574bba85
recipe-front-review is a skill published in the GitHub repository shinpr/codex-workflows (37 stars, last pushed yesterday), licensed MIT. It adds 29 tokens to every session and 1,582 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-30.
Other skills, from other repositories
code-quality
Use for React, TypeScript, hooks, tests, build quality, maintainability, AI-generated code risk, and safe quality-gate routing. Do not use to add dependencies, change package managers, reformat broadly, duplicate Superpowers, or rewrite architecture for scanner output.
recipe-front-review
Reviews completed frontend implementation for governing-source compliance, scope economy, repository quality, and security, then applies user-approved React corrections.
frontend-code-review
Trigger when the user requests a review of frontend files (e.g., .tsx, .ts, .js). Support both pending-change reviews and focused file reviews while applying the checklist rules.
spotpatch
A development workflow for React that connects a selected page element to its JSX or TSX source code and gathers context for review.
ring:applying-composition-patterns
React composition patterns that scale. Avoid boolean prop proliferation by using compound components, lifting state, and composing internals. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or during architecture review. Skip for simple components with 1-2 props…
ring:checking-frontend-quality
Checking frontend quality against changed UI via ring:qa-frontend in accessibility, visual, e2e, or performance mode and aggregating pass/fail verdicts. Use when a frontend change needs standalone a11y, visual-snapshot, Playwright e2e, or Lighthouse/Core-Web-Vitals validation outside the dev cycle. Skip for…