/ijfw-review
Use when the user asks for a review of any artifact -- code diff, PR, book chapter, campaign brief, landing-page copy, or design tokens. Trigger: review, code review, review this, PR review, review my X, review chapter, review brief, review page, /ijfw-review
$ npx -y skills add FerroxLabs/ijfw --skill ijfw-review --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/ijfw-review
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when the user asks for a review of any artifact -- code diff, PR, book chapter, campaign brief, landing-page copy, or design tokens. Trigger: review, code review, review this, PR review, review my X, review chapter, review brief, review page, /ijfw-review
SKILL.md
ijfw-review.SKILL.mdname: ijfw-review
since: '1.5.0'
description: "Use when the user asks for a review of any artifact -- code diff, PR, book chapter, campaign brief, landing-page copy, or design tokens. Trigger: review, code review, review this, PR review, review my X, review chapter, review brief, review page, /ijfw-review"
Domain-agnostic critique. One-line findings, severity-tagged, with a written `REVIEW.md` artifact.
Severity vocabulary (all domains)
- **BLOCK** -- must-fix before ship. Bug, data loss, broken claim, factual error, WCAG violation, missing CTA.
- **FLAG** -- should discuss. Risky choice, weak evidence, voice break, ambiguous audience, fragile coupling.
- **NIT** -- polish. Phrasing, micro-spacing, naming, redundancy.
Format per finding: `<LOC>: [SEVERITY] <one-line problem>. <one-line fix>.` `<LOC>` is `file:line` for code, `<section>` or `<page>` for prose/design.
Domain checklists
Software (code diff / PR)
- Null & undefined handling, error paths, retry/backoff semantics.
- Security boundaries: input validation, authz, secret leakage, path traversal.
- Test coverage: happy path + at least one failure case per public surface.
- Concurrency: race conditions, idempotency, ordering assumptions.
- Public API: backward compatibility, types, naming.
Book chapter
- Continuity with prior chapters (character state, world facts, timeline).
- Voice / POV consistency.
- Pacing: scene-vs-summary ratio, dwell on stakes.
- Character beats: motivation legible, agency visible.
- Stakes: what is at risk on this page, why now.
Campaign brief
- Audience: named, specific, has a current alternative.
- Message-to-channel fit: format matches where the audience already is.
- CTA: single, frictionless, measurable.
- KPI coverage: leading + lagging indicator named.
- Kill criteria: the condition under which you stop spending.
Landing page (copy + layout)
- Promise -> proof -> CTA alignment in the first viewport.
- Mobile-readiness: tap targets >= 44px, no horizontal scroll, hero readable at 375px.
- Accessibility: WCAG AA contrast 4.5:1 body / 3:1 large text; alt text on meaningful images; keyboard reachable CTA.
- Conversion-path friction: number of decisions before primary CTA.
Design artifact (tokens / mockup)
- Token consistency: every color/space/radius/shadow resolves to a defined token.
- Contrast: WCAG AA on every text-on-surface pair.
- Type scale: modular ratio respected; no orphan sizes.
- Spacing rhythm: 4/8 baseline (or declared grid) respected.
Output rules
- Lead with BLOCK findings, then FLAG, then NIT.
- No praise for meeting baseline expectations.
- Max 10 findings unless the caller asks for exhaustive.
- If nothing found: `Clean. Reviewed <N> <units> across BLOCK/FLAG/NIT gates. No findings.`
Artifact-write contract (MANDATORY)
Every review MUST write a `REVIEW.md` to a predictable path so the artifact is durable and resumable:
- **Software review of a planned unit of work**: `.planning/<milestone>/<phase-dir>/REVIEW.md`
- **Software review without a planning context** (ad-hoc PR): `REVIEW.md` at the repo root, or `<branch>-REVIEW.md` if reviewing a named branch.
- **Standalone artifact** (chapter, brief, page, design file): write `<artifact-basename>-REVIEW.md` alongside the artifact. Example: `chapter-7.md` -> `chapter-7-REVIEW.md`.
REVIEW.md required sections
# Review: <artifact name>
Reviewed: <ISO-8601 timestamp>
Reviewer: ijfw-review
Domain: <software | book | campaign | landing | design>
## Summary
<2-4 sentences. Headline verdict + the single most important thing to fix.>
## BLOCK findings (must-fix)
- <LOC>: <one-line problem>. <one-line fix>.
## FLAG findings (should-discuss)
- <LOC>: <one-line problem>. <one-line fix>.
## NIT findings (polish)
- <LOC>: <one-line problem>. <one-line fix>.
If a section has no findings, keep the header and write `(none)` underneath -- absence is a signal, not a typo.
Second opinion
For high-stakes artifacts the caller can request a multi-lens audit via `/cross-audit` -- this fans the same artifact across Trident (codex / gemini / claude) and converges on a consensus verdict. Use it when stakes warrant a second pair of eyes.
Output contract
Emit a `gate-result` block as the **LAST** content of your output. Nothing after it. Use `gate="swarm-review"`. Statuses: `PASS | CONDITIONAL | WARN | FLAG | FAIL`.
`affected_artifacts` MUST include the absolute path to the `REVIEW.md` that was written.
Format:
{
"schema_version": "1.0",
"gate": "swarm-review",
"status": "<STATUS>",
"project_type": "<from project-type-detector>",
"lenses": [],
"affected_artifacts": ["<absolute path to REVIEW.md>"],
"accounting": {"duration_ms": 0, "lenses_invoked": 0, "cost_usd": null},
"remediation": [],
"receipts_ref": null,
"supersedes": null,
"gate_id": "<gate-with-colons-replaced-by-dashes>-<ts>-<rand4>",
"emitted_at": "<ISO-8601>"
}Read more
name: ijfw-review since: '1.5.0' description: "Use when the user asks for a review of any artifact -- code diff, PR, book chapter, campaign brief, landing-page copy, or design tokens. Trigger: review, code review, review this, PR review, review my X, review chapter, review brief, review page, /ijfw-review"
Domain-agnostic critique. One-line findings, severity-tagged, with a written `REVIEW.md` artifact.
Severity vocabulary (all domains)
- **BLOCK** -- must-fix before ship. Bug, data loss, broken claim, factual error, WCAG violation, missing CTA.
- **FLAG** -- should discuss. Risky choice, weak evidence, voice break, ambiguous audience, fragile coupling.
- **NIT** -- polish. Phrasing, micro-spacing, naming, redundancy.
Format per finding: `<LOC>: [SEVERITY] <one-line problem>. <one-line fix>.` `<LOC>` is `file:line` for code, `<section>` or `<page>` for prose/design.
Domain checklists
Software (code diff / PR)
- Null & undefined handling, error paths, retry/backoff semantics.
- Security boundaries: input validation, authz, secret leakage, path traversal.
- Test coverage: happy path + at least one failure case per public surface.
- Concurrency: race conditions, idempotency, ordering assumptions.
- Public API: backward compatibility, types, naming.
Book chapter
- Continuity with prior chapters (character state, world facts, timeline).
- Voice / POV consistency.
- Pacing: scene-vs-summary ratio, dwell on stakes.
- Character beats: motivation legible, agency visible.
- Stakes: what is at risk on this page, why now.
Campaign brief
- Audience: named, specific, has a current alternative.
- Message-to-channel fit: format matches where the audience already is.
- CTA: single, frictionless, measurable.
- KPI coverage: leading + lagging indicator named.
- Kill criteria: the condition under which you stop spending.
Landing page (copy + layout)
- Promise -> proof -> CTA alignment in the first viewport.
- Mobile-readiness: tap targets >= 44px, no horizontal scroll, hero readable at 375px.
- Accessibility: WCAG AA contrast 4.5:1 body / 3:1 large text; alt text on meaningful images; keyboard reachable CTA.
- Conversion-path friction: number of decisions before primary CTA.
Design artifact (tokens / mockup)
- Token consistency: every color/space/radius/shadow resolves to a defined token.
- Contrast: WCAG AA on every text-on-surface pair.
- Type scale: modular ratio respected; no orphan sizes.
- Spacing rhythm: 4/8 baseline (or declared grid) respected.
Output rules
- Lead with BLOCK findings, then FLAG, then NIT.
- No praise for meeting baseline expectations.
- Max 10 findings unless the caller asks for exhaustive.
- If nothing found: `Clean. Reviewed <N> <units> across BLOCK/FLAG/NIT gates. No findings.`
Artifact-write contract (MANDATORY)
Every review MUST write a `REVIEW.md` to a predictable path so the artifact is durable and resumable:
- **Software review of a planned unit of work**: `.planning/<milestone>/<phase-dir>/REVIEW.md`
- **Software review without a planning context** (ad-hoc PR): `REVIEW.md` at the repo root, or `<branch>-REVIEW.md` if reviewing a named branch.
- **Standalone artifact** (chapter, brief, page, design file): write `<artifact-basename>-REVIEW.md` alongside the artifact. Example: `chapter-7.md` -> `chapter-7-REVIEW.md`.
REVIEW.md required sections
# Review: <artifact name> Reviewed: <ISO-8601 timestamp> Reviewer: ijfw-review Domain: <software | book | campaign | landing | design> ## Summary <2-4 sentences. Headline verdict + the single most important thing to fix.> ## BLOCK findings (must-fix) - <LOC>: <one-line problem>. <one-line fix>. ## FLAG findings (should-discuss) - <LOC>: <one-line problem>. <one-line fix>. ## NIT findings (polish) - <LOC>: <one-line problem>. <one-line fix>.
If a section has no findings, keep the header and write `(none)` underneath -- absence is a signal, not a typo.
Second opinion
For high-stakes artifacts the caller can request a multi-lens audit via `/cross-audit` -- this fans the same artifact across Trident (codex / gemini / claude) and converges on a consensus verdict. Use it when stakes warrant a second pair of eyes.
Output contract
Emit a `gate-result` block as the **LAST** content of your output. Nothing after it. Use `gate="swarm-review"`. Statuses: `PASS | CONDITIONAL | WARN | FLAG | FAIL`.
`affected_artifacts` MUST include the absolute path to the `REVIEW.md` that was written.
Format:
{
"schema_version": "1.0",
"gate": "swarm-review",
"status": "<STATUS>",
"project_type": "<from project-type-detector>",
"lenses": [],
"affected_artifacts": ["<absolute path to REVIEW.md>"],
"accounting": {"duration_ms": 0, "lenses_invoked": 0, "cost_usd": null},
"remediation": [],
"receipts_ref": null,
"supersedes": null,
"gate_id": "<gate-with-colons-replaced-by-dashes>-<ts>-<rand4>",
"emitted_at": "<ISO-8601>"
}IJFW — It Just F*cking Works. Ferrox Labs' local-first infrastructure for AI coding agents: shared memory, smart routing, multi-AI cross-audits, disciplined workflow.
Repo: FerroxLabs/ijfw
Other skills on ijfw.
- /ijfw-agents-md
Maintain canonical AGENTS.md (open spec). Trigger: 'agents.md', 'update AGENTS.md', or auto-fired by ijfw-team after agent generation.
Open skill - /ijfw-auto-memorize
Session-end auto-extraction of lessons, errors, fixes, and user feedback into structured memory. Fires at session end. Requires consent on first run.
Open skill - /ijfw-commit
Terse conventional commits. Trigger: commit, git commit, /ijfw-commit
Open skill - /ijfw-complete-milestone
Use when a milestone is shipping and you need to archive its artifacts, generate a summary, and seed the next milestone. Trigger: 'milestone complete', 'ship milestone', 'wrap milestone', 'complete milestone <id>', /ijfw-complete-milestone.
Open skill - /ijfw-compress
Compress memory/context files into terse form. Trigger: /compress, compress file
Open skill - /ijfw-compute
Use when the user says: 'compute', 'crunch this', 'analyze logs', 'aggregate the data', 'run a script', 'dedupe', 'count by', 'top N', or any data-shaping ask. Replaces dumping raw data into context with sandboxed script execution.
Open skill

