菜单
Run the 3-Layer Review (you: visual/functional check, a second AI: code quality, a security-focused AI: vulnerabilities), and be explicit about the limits of same-model-family review. Use after any major feature; for anything security-critical, pair with /security-audit.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Run the SHIP checklist (Stable, Hidden secrets, Inputs validated, Performance) immediately before every deploy, using the agent's own tools directly. Use right before any git push to a branch that auto-deploys, after /verify-path and /security-audit have already passed.
Run a short retrospective right after a feature actually ships (post /ship-checklist Green, post-deploy) — capture what worked, what didn't, and any surprise, then feed genuine lessons forward into PRD.md's non-goals or behavior rules. Use once per shipped feature/milestone, not on a calendar cadence (that's /weekly-plan's reconciliation step).
Orient a founder who has never used an AI coding agent (Claude Code, OpenCode, or Codex CLI) before to how the *tool* works, before anything about their product idea comes up. Use this first, before /validate-demand, whenever the founder seems unfamiliar with AI coding agents generally — confused by terminal/CLI concepts, unsure what a "slash command" is, or asking how to talk to the agent at all.
Turn a rough product idea into a structured Founding Prompt using the BRIEF framework, then generate PRD.md, AGENTS.md, and llms.txt from it. Use this once demand is validated (after /validate-demand) and before any prototyping begins.
Reverse-engineer a PRD.md/AGENTS.md from a codebase that already exists (with no PRD, or one from another tool/convention), instead of eliciting from scratch. Use this instead of /validate-demand + /founding-prompt whenever a project already has code before founder-os is installed.
Commit in small, atomic "save points" (roughly one logical change each) during any non-trivial task, so a broken step is one git revert/reset away from a known-good state instead of losing a whole session's progress. Use during any multi-step build/fix/refactor, not just at the end.
| name | multi-model-review |
| description | Run the 3-Layer Review (you: visual/functional check, a second AI: code quality, a security-focused AI: vulnerabilities), and be explicit about the limits of same-model-family review. Use after any major feature; for anything security-critical, pair with /security-audit. |
The founder can't read code, so "review" has to produce an actionable verdict, not prose. The three layers catch different classes of problems and aren't interchangeable — running one doesn't excuse skipping another.
Layer 1 — founder, visual + functional. Point to /verify-path for
the structured PASS/FAIL walkthrough. This skill precedes that step,
it doesn't replace it.
Layer 2 — second AI, code quality. Use the Red/Yellow/Green prompt
already codified in commands/review-code.md — BUGS, SECURITY,
PERFORMANCE, QUALITY.
Be honest about the cross-model caveat. A same-model-family subagent persona is a weaker substitute for true cross-model review — different model families miss different things, and a persona prompt alone doesn't reproduce that. For anything that matters (payments, auth, user data), recommend pasting a redacted excerpt into a genuinely different model provider rather than relying on an in-session "act as reviewer" persona. Always strip secrets, tokens, and user data before exporting anything outside the session — cross-model review is not worth a leak.
Layer 3 — security AI. Don't fold security review into this same
pass. Hand off explicitly to /security-audit (the LOCK checklist) —
commands/review-code.md already says to do this; keep both
consistent.
Consolidate into one Red/Yellow/Green verdict per layer, with a
specific fix for anything not Green — never "this could be improved."
When Layer 2/3 run via the code-critic/security-reviewer subagents,
each report leads with a standardized VERDICT/FINDINGS/
RECOMMENDATION/CONFIDENCE block — read that first for the
consolidated verdict rather than re-deriving it from the detailed
per-category grid below it.
State which layers actually ran before declaring anything "reviewed." A clean Layer 2 pass isn't evidence of security. A clean Layer 1 pass isn't evidence of code quality.
/security-audit for anything touching auth, payments, or user
data — even after Layers 1-2 come back clean.