菜单
Draws, in ASCII, the sequence diagram and the flow diagram of a piece of existing code, to understand how it works before modifying it. Use it when the user wants to understand an existing flow, function or feature, or before scoping over legacy code.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | trace |
| description | Draws, in ASCII, the sequence diagram and the flow diagram of a piece of existing code, to understand how it works before modifying it. Use it when the user wants to understand an existing flow, function or feature, or before scoping over legacy code. |
You read the code the user points at (a function, an endpoint, a feature) and reconstruct its real behavior in two ASCII diagrams. Don't make things up: what you draw has to be in the code. If something isn't visible in the code (a branch that never runs, a case that isn't handled), say so instead of guessing.
Steps:
SEQUENCE. By default the compact version (an ordered list); the full one with lifelines only if the user asks for it.
Compact (default):
SEQUENCE (chronological order ↓)
1. Entry → ComponentA: call()
2. ComponentA → ComponentB: other()
3. ComponentB → ComponentA: data
4. ComponentA → Entry: response
Full (only if asked) — one vertical lifeline (│) per real participant, time going DOWN; calls solid arrow (──▶), returns dashed (◀ ─ ─):
Entry ComponentA ComponentB
│ │ │
│ call() │ │
│─────────────▶│ │
│ │ other() │
│ │─────────────▶│
│ │◀ ─ data ─ ─ │
│◀─ response ─ │ │
▼ ▼ ▼
FLOW (the real decisions and branches in the code):
input
│
▼
real condition? ──no──▶ branch it takes
│ yes
▼
action ──▶ result
Close by asking whether the flow you drew is the one the user expected. If it doesn't match, you already have the input for a scope of the fix.
Revisa los cambios (el diff) como un ingeniero senior contra la spec, mirando alcance, correctitud, simplicidad y consistencia. Úsala antes de commitear o mergear, cuando se pida revisar el código o el diff.
Reviews the changes (the diff) as a senior engineer against the spec, looking at scope, correctness, simplicity and consistency. Use it before committing or merging, when a review of the code or the diff is requested.
Implements ONE single task from an existing spec, without touching anything else. Use it when a spec file exists in the specs folder and the user asks to run or implement a concrete task (for example T1 or T2).
Verifies that a task is actually done by running its Verify step and showing the real output, no self-reporting. Use it after implementing a task, when you want to confirm it truly works and not just that the agent claims so.
Turns a vague idea or feature into an executable spec using the 5 questions (context, goal, constraints, tasks and verification) before writing any code. Use it when the user describes something they want to build and asks for a spec, or to plan the work before implementing.
Writes the commit message for the staged changes, in conventional commits format and explaining the why. Use it when you want to commit or generate the commit message.