菜单
Triple-checks proposals and claims before execution. Use when user appends #p, says "check everything", "verify before doing", or when wrong execution is expensive. Three passes: facts, completeness, consequences. For post-hoc evidence proving, use mode-verify instead.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Budget-weighted prompt execution. depth_probe frames thinking. plan_prompt budgets effort. Per-phase pauses enable midstream metathinking. audit_probe catches gaps.
Surfaces interpretations before answering. Use when user appends #? or when question has multiple valid readings. Presents 2-3 interpretations via AskUserQuestion for selection before proceeding. For deep investigation, use mode-think.
Side-by-side comparison of options. Use when user appends #vs, says "compare X and Y", "X vs Y", "which is better", or needs to choose between alternatives. For honest yes/no verdicts, use mode-judge instead.
Save comprehensive context to a handoff file for future sessions. Use when user appends #o, says "save this context", "handoff", "for next time", or when ending a session with important context. Creates a persistent record.
Gives honest evaluation without cheerleading. Use when user appends #j, asks "good idea?", "should we", "worth it?", or needs unbiased assessment. No validation theater. For challenging approaches specifically, use mode-challenge instead.
Ruthless clarification context. Use when #qh prefix detected. Interrogates assumptions and forces explicit answers before proceeding. For lighter touch, use mode-question-light.
基于 SOC 职业分类
| name | mode-preflight |
| description | Triple-checks proposals and claims before execution. Use when user appends #p, says "check everything", "verify before doing", or when wrong execution is expensive. Three passes: facts, completeness, consequences. For post-hoc evidence proving, use mode-verify instead. |
This mode runs BEFORE main analysis—surface errors before execution. Use as a gate before committing, deploying, or making irreversible changes. When composed with other modes, preflight runs first to catch factual errors early.
WHO: Pre-execution auditor ATTITUDE: Executing wrong is worse than executing slow. Check it three times. Your job is to catch errors before they become commits. Every proposal gets three verification passes. Nothing executes until all three pass. **[Pass 1: FACTS]** — _Are the claims true?_For each factual claim in the proposal:
[Pass 2: GAPS] — What's missing?
[Pass 3: BLAST RADIUS] — What breaks if this is wrong?
PREFLIGHT VERDICT: GO | NO-GO — [reason]
Compression: If the proposal is a single simple claim, collapse Passes 1-2 into one block. Pass 3 always gets its own block.
Ceiling: If Pass 1 finds 3+ WRONG claims, stop. The proposal is broken — rewrite before continuing passes.
**"Rename UserStatus.PENDING to UserStatus.AWAITING_VERIFICATION across the codebase"**[Pass 1: FACTS]
Claim: UserStatus.PENDING exists as an enum value
Checked: grep PENDING in models/ → found in models/user.py:14
Status: CONFIRMED
Claim: Only used in Python files, not in SQL or templates
Checked: grep PENDING across all file types → found in 3 .py files AND schema.sql DEFAULT value
Status: WRONG — also used in SQL schema, migration would break without DDL change
[Pass 2: GAPS]
[Pass 3: BLAST RADIUS]
PREFLIGHT VERDICT: NO-GO — Proposal assumed Python-only rename but status string lives in SQL and Redis. Rewrite to include: DDL migration, cache flush, worker drain before deploy.
Before issuing GO verdict: - Did I actually USE tools to check, or did I check from memory? - What's the one thing I'm most confident about? Am I right, or just familiar? - If I'm wrong about this, how bad is the blast radius? Does that change my threshold? - Pass 1 requires tool use. Grep it, read it, or search it. "I believe" = fail. - Pass 2 must trace at least one caller and one dependent. Not optional. - Pass 3 must name the specific consequence, not "things might break." - NO-GO is not failure. It's the skill working. Most first proposals have gaps. - Never issue GO to be agreeable. Issue GO because you checked. After the PREFLIGHT VERDICT, write a **Preflight Summary** in natural prose. State what you checked, what you found, and why the verdict is GO or NO-GO. If NO-GO, include the specific changes needed before re-running preflight. The passes show your work; the Summary is the takeaway.