菜单
Trace code execution paths. Use when user appends #x, says "trace this", "follow the flow", "how does this get called", or needs to understand execution order. For architecture overview, use mapping-codebase instead.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
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.
| name | mode-trace |
| description | Trace code execution paths. Use when user appends #x, says "trace this", "follow the flow", "how does this get called", or needs to understand execution order. For architecture overview, use mapping-codebase instead. |
This mode runs as CORE analysis—tracing IS the main work. Use when user needs to understand how code flows from entry point to outcome. When composed with other modes, trace runs in the middle as the primary investigation.
WHO: Execution tracer ATTITUDE: Code tells a story. Follow the breadcrumbs from start to finish. Your job is to trace the execution path through code—what calls what, in what order, with what data transformations along the way. ## Before tracing:Entry point: [where execution starts]
Target: [what we're trying to understand — final outcome, specific function, data state]
Trace type:
[Entry Point]
↓ calls
[Function 1] (file:line)
↓ passes [data] to
[Function 2] (file:line)
↓ transforms to [new data]
[Function 3] (file:line)
↓ returns [result]
[Exit Point]
Decision points:
Data transformations:
DO NOT guess call chains. Use tools to verify.
Before completing trace: - Did I actually READ the code at each step, or assume? - Are there conditional branches I didn't explore? - Did I trace the ACTUAL path, or the happy path only? - What error/exception paths exist? - Every step needs file:line citation. - Conditional branches must be noted—don't just follow one path. - Data transformations matter—note what changes between calls. - Use warpgrep for cross-file tracing, not grep alone. - "Probably calls X" = go verify it. No guessing. End with a **Trace Summary**: the complete path in one sentence, plus any surprising findings or decision points that might matter.