[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QJ5TY7PJNW6APSR7F4WWVW":3,"skill-same:01M6QJ5TY7PJNW6APSR7F4WWVW":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":13,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6QJ5TY7PJNW6APSR7F4WWVW","trace-execution",null,"Master tracing code execution: how to follow execution paths, set strategic breakpoints, and understand control flow. Use when debugging, understanding code flow, or when you need to figure out how code reaches a certain point. Triggers especially when user says \"trace execution\", \"follow the code\", \"debugging execution\", \"breakpoint strategy\", \"control flow\", or \"how does this get called\".","ImaginerLabs\u002Fskill-manager","ImaginerLabs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F214277308?v=4","01M6QGGDPNF15RMMT1RCFDH9FN","01M6QGGDTH5BY64DQ123NR8M33",0,"MIT","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Ftrace-execution\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"trace execution","execution","trace","master","point","path","you","code execution","paths","how to","triggers","get","debugging","strategy","coding","how","SET","flow","tracing","code","2026-11-10 10:12:30",false,"---\nname: trace-execution\ndescription: >-\n  Master tracing code execution: how to follow execution paths, set strategic breakpoints, and understand control flow. Use when debugging, understanding code flow, or when you need to figure out how code reaches a certain point. Triggers especially when user says \"trace execution\", \"follow the code\", \"debugging execution\", \"breakpoint strategy\", \"control flow\", or \"how does this get called\".\ncategory: coding\npriority: P2\ntrigger_patterns:\n  - \"trace execution\"\n  - \"follow the code\"\n  - \"debugging execution\"\n  - \"breakpoint strategy\"\n  - \"control flow\"\n  - \"how does this get called\"\n  - \"execution path\"\n---\n\n# Trace Execution — Systematic Code Path Analysis\n\n## Overview\n\nTrace-execution is a **behavioral specification skill** that encapsulates the methodology for **systematically following code execution paths, setting breakpoints strategically, and understanding how code flows through a system**.\n\nThis skill embodies the discipline of developers who've traced complex bugs and know that \"adding logs everywhere\" is not a strategy — understanding the path is.\n\n## Core Philosophy\n\n### The Execution Trace Principle\n\n> \"Code execution is a path through a graph. To understand it, you don't follow every edge — you find the critical path and follow that.\"\n\n### Tracing vs Logging\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    TRACING vs LOGGING                         │\n│                                                               │\n│    TRACING:                     LOGGING:                     │\n│    ─────────                     ───────                      │\n│    Understanding WHERE code     Recording WHAT happened       │\n│    is going                     for later analysis            │\n│                                                               │\n│    Tools: Breakpoints, Step     Tools: console.log, logger   │\n│    through, Call stack          Purpose: Audit, reproduce    │\n│    Purpose: Understand path     Purpose: Verify behavior      │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Decision Framework\n\n### When to Trace vs Log\n\n| Situation | Approach | Why |\n|-----------|----------|-----|\n| Understanding unfamiliar code | TRACE | Don't know where to log |\n| Reproducing a bug | LOG + TRACE | Need both |\n| Verifying a fix | LOG | Just need to confirm |\n| Understanding flow | TRACE | Follow the path |\n| Finding where code diverges | TRACE | Find the branch |\n\n### Breakpoint Strategy\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                  BREAKPOINT PLACEMENT                          │\n│                                                               │\n│    Entry Point ──► Key Decision ──► Important State ──► Exit │\n│         │                │                  │                │\n│         ▼                ▼                  ▼                │\n│    First line      Branch check        Before mutation        │\n│    of function     if\u002Felse\u002Fswitch     critical operation     │\n│                                                               │\n│    \"Where does it start?\"      \"Where might it branch?\"      │\n│    \"What's the flow?\"          \"Where is state changed?\"    │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Behavioral Specification\n\n### Phase 1: Map the Execution Path\n\n#### 1.1 Entry Point Identification\n\n```typescript\n\u002F\u002F Find where execution STARTS\n\u002F\u002F 1. Look for event handlers, API routes, main functions\n\u002F\u002F 2. Find the public\u002Fexported functions\n\u002F\u002F 3. Find where your code is CALLED\n\n\u002F\u002F Example: Understanding an API request flow\n\u002F\u002F 1. router.post('\u002Fusers', ...) → Entry point\n\u002F\u002F 2. createUser(req.body) → Function called\n\u002F\u002F 3. validateUserData(data) → Inside createUser\n\u002F\u002F 4. userRepo.save(user) → Database call\n```\n\n#### 1.2 Call Graph Construction\n\n```typescript\n\u002F\u002F Build a simple call graph\nfunction main() {\n  \u002F\u002F     main\n  \u002F\u002F    \u002F    \\\n  \u002F\u002F   A()    B()\n  \u002F\u002F  \u002F \\     |\n  \u002F\u002F C() D()  E()\n  \u002F\u002F\n  \u002F\u002F To trace from main to E:\n  \u002F\u002F main → B → E\n}\n\n\u002F\u002F How to trace:\n\u002F\u002F 1. Start at entry\n\u002F\u002F 2. For each function call, note WHERE it's called\n\u002F\u002F 3. Follow the most relevant path\n```\n\n#### 1.3 Async Execution Tracing\n\n```typescript\n\u002F\u002F Async adds complexity:\n\u002F\u002F 1. Promises resolve later\n\u002F\u002F 2. Call stack is lost\n\u002F\u002F 3. Order matters\n\n\u002F\u002F Trace async:\nasync function processOrder(orderId: string) {\n  \u002F\u002F 1. Fetch order (async)\n  const order = await fetchOrder(orderId); \u002F\u002F ← Breakpoint here\n\n  \u002F\u002F 2. Validate (sync)\n  validate(order); \u002F\u002F ← Then here\n\n  \u002F\u002F 3. Process (async)\n  const result = await processPayment(order); \u002F\u002F ← Then here\n\n  \u002F\u002F 4. Save (async)\n  await saveResult(result); \u002F\u002F ← Finally here\n}\n```\n\n### Phase 2: Strategic Breakpoint Placement\n\n#### 2.1 Breakpoint Types\n\n```typescript\n\u002F\u002F LINE BREAKPOINT: Stop at specific line\n\u002F\u002F Useful for: Known problematic area\n\n\u002F\u002F CONDITIONAL BREAKPOINT: Stop only when condition met\n\u002F\u002F Useful for: Specific case within a loop\n\n\u002F\u002F FUNCTION BREAKPOINT: Stop at function entry\n\u002F\u002F Useful for: Trace function calls\n\n\u002F\u002F EXCEPTION BREAKPOINT: Stop when exception thrown\n\u002F\u002F Useful for: Catch unhandled errors\n```\n\n#### 2.2 Strategic Placement\n\n```typescript\n\u002F\u002F PLACEMENT STRATEGY\n\n\u002F\u002F 1. ENTRY\u002FEXIT: Function boundaries\nfunction complexOperation(input) {\n  \u002F\u002F BREAKPOINT: Entry\n  console.log('Input:', input);\n\n  \u002F\u002F ... code ...\n\n  \u002F\u002F BREAKPOINT: Exit\n  console.log('Output:', result);\n  return result;\n}\n\n\u002F\u002F 2. DECISION POINTS: If\u002Fswitch\u002Fternary\nif (user.isAdmin) { \u002F\u002F BREAKPOINT: Before branch\n  \u002F\u002F Admin path\n} else {\n  \u002F\u002F Regular path\n}\n\n\u002F\u002F 3. STATE CHANGES: Assignments to important variables\nlet total = 0;\ntotal = calculate(items); \u002F\u002F BREAKPOINT: After important assignment\n```\n\n#### 2.3 Efficiency in Tracing\n\n```typescript\n\u002F\u002F BAD: Too many breakpoints\nfunction process() {\n  \u002F\u002F breakpoint at line 1\n  \u002F\u002F breakpoint at line 2\n  \u002F\u002F breakpoint at line 3 ... (useless noise)\n\n  \u002F\u002F GOOD: Strategic breakpoints\n  function process() {\n    \u002F\u002F breakpoint at key decision\n    \u002F\u002F breakpoint before mutation\n    \u002F\u002F breakpoint at return\n  }\n```\n\n### Phase 3: Call Stack Analysis\n\n#### 3.1 Reading the Stack\n\n```typescript\n\u002F\u002F Call Stack (top to bottom = recent to old):\n\u002F\u002F at C (c.ts:10)          ← CURRENTLY HERE\n\u002F\u002F at B (b.ts:20)          ← WHO CALLED C\n\u002F\u002F at A (a.ts:30)          ← WHO CALLED B\n\n\u002F\u002F To trace BACKWARDS:\n\u002F\u002F 1. Start at current (C)\n\u002F\u002F 2. Read up for caller (B)\n\u002F\u002F 3. Read up for caller (A)\n\n\u002F\u002F This is how you got HERE\n```\n\n#### 3.2 Async Stack Analysis\n\n```typescript\n\u002F\u002F Async stack is DISCONNECTED\n\u002F\u002F Example:\n\n\u002F\u002F Stack 1 (async trigger):\nasync function trigger() {\n  await process(); \u002F\u002F ← Point A: Called process\n}\n\n\u002F\u002F Stack 2 (async continuation):\nasync function process() {\n  \u002F\u002F ← Point B: Code here\n  \u002F\u002F The \"who called\" chain is broken!\n}\n\n\u002F\u002F Solution: Use correlation IDs\nasync function trigger(correlationId) {\n  await process(correlationId); \u002F\u002F Pass ID through\n}\n\nasync function process(correlationId) {\n  console.log('Triggered by:', correlationId);\n  \u002F\u002F Now you can trace!\n}\n```\n\n### Phase 4: Control Flow Patterns\n\n#### 4.1 Common Patterns\n\n```typescript\n\u002F\u002F Pattern 1: Linear Flow\nA(); B(); C(); \u002F\u002F Trace: A → B → C\n\n\u002F\u002F Pattern 2: Conditional Flow\nif (x) { A(); } else { B(); }\n\u002F\u002F Trace: x? → A or B\n\n\u002F\u002F Pattern 3: Loop Flow\nfor (const item of items) {\n  process(item);\n}\n\u002F\u002F Trace: items[0] → items[1] → items[2]...\n\n\u002F\u002F Pattern 4: Callback Flow\nfetch(url, (err, data) => {\n  if (err) handleError(err);\n  else process(data);\n});\n\u002F\u002F Trace: fetch → callback (success or error path)\n\n\u002F\u002F Pattern 5: Event Flow\nemitter.on('event', handler);\n\u002F\u002F Trace: emit → handler\n```\n\n## Common Scenarios\n\n### Scenario 1: \"How does this button click get handled?\"\n\n```typescript\n\u002F\u002F Step 1: Find the button\n\u002F\u002F \u003Cbutton onClick={handleSubmit}>\n\n\u002F\u002F Step 2: Trace the handler\nconst handleSubmit = async (event) => {\n  event.preventDefault(); \u002F\u002F Breakpoint here\n\n  \u002F\u002F Step 3: Find what it calls\n  const formData = new FormData(event.target);\n  const data = Object.fromEntries(formData);\n\n  \u002F\u002F Step 4: Continue tracing\n  await api.submit(data); \u002F\u002F Breakpoint here\n};\n\n\u002F\u002F Step 5: Trace the API\n\u002F\u002F POST \u002Fapi\u002Fsubmit → server route → handler\n```\n\n### Scenario 2: \"Why did this code path execute?\"\n\n```typescript\n\u002F\u002F Given: 'if (user.isAdmin)' branch was taken\n\u002F\u002F Question: Why was user.isAdmin true?\n\n\u002F\u002F Trace backwards:\nfunction handleRequest(user) {\n  \u002F\u002F user.isAdmin came from HERE\n  const userFromDB = await getUser(user.id);\n  \u002F\u002F Why was this true?\n\n  \u002F\u002F Continue backwards...\n  \u002F\u002F getUser returned { isAdmin: true }\n  \u002F\u002F Was the data correct in DB?\n  \u002F\u002F Did something modify it?\n}\n\n\u002F\u002F Solution: Breakpoint at assignment\nconst userFromDB = await getUser(user.id);\n\u002F\u002F Inspect: What did getUser return?\n\u002F\u002F If wrong → problem in getUser\n\u002F\u002F If right → problem elsewhere\n```\n\n### Scenario 3: \"This function is called but I don't see why\"\n\n```typescript\n\u002F\u002F Question: Who is calling this function?\n\u002F\u002F findAllUsers()\n\n\u002F\u002F Solution 1: Stack trace (runtime)\n\u002F\u002F Add breakpoint, look UP the stack\n\n\u002F\u002F Solution 2: IDE find usages (static)\n\u002F\u002F Right click → Find All References\n\u002F\u002F Shows all call sites\n\n\u002F\u002F Solution 3: Grep\ngrep -r \"findAllUsers\" --include=\"*.ts\"\n\u002F\u002F Lists all files that call this function\n```\n\n## Debugging Execution Tools\n\n### Browser DevTools\n\n```typescript\n\u002F\u002F 1. Breakpoints panel\n\u002F\u002F - Set by clicking line number\n\u002F\u002F - See all breakpoints\n\u002F\u002F - Enable\u002Fdisable individually\n\n\u002F\u002F 2. Watch panel\n\u002F\u002F - Add expressions to watch\n\u002F\u002F - See value update as you step\n\n\u002F\u002F 3. Call Stack panel\n\u002F\u002F - See current path\n\u002F\u002F - Click frame to jump to caller\n```\n\n### Node.js Debugging\n\n```bash\n# Start with inspector\nnode --inspect index.js\n\n# Or in Chrome DevTools\nnode --inspect-brk index.js\n# --inspect-brk pauses on first line\n\n# VS Code attach\n# Debug > Attach to Node\n```\n\n### Logging for Tracing\n\n```typescript\n\u002F\u002F When you can't use debugger\nconst trace = (label, value) => {\n  console.log(`[TRACE] ${label}:`, value);\n  return value;\n};\n\n\u002F\u002F Usage\nconst result = trace('processed', actualValue);\n\u002F\u002F Output: [TRACE] processed: { ... }\n```\n\n## The Trace Execution Checklist\n\n```\nTRACE EXECUTION CHECKLIST\n=========================\n\n□ 1. Identify entry point\n□ 2. Map the call graph (at least roughly)\n□ 3. Find the critical path\n□ 4. Place breakpoints strategically\n  □ Entry\u002Fexit of functions\n  □ Decision points\n  □ State mutations\n□ 5. Follow the call stack\n□ 6. Note any async boundaries\n□ 7. Verify understanding matches reality\n\nFOR ASYNC CODE:\n□ Use correlation IDs\n□ Break on promise creation and resolution\n□ Watch for detached stacks\n```\n\n## Key Principles\n\n### 1. Start at the Beginning\n\nAlways trace from a known point. Entry points are anchors.\n\n### 2. Follow One Path\n\nDon't try to trace all paths. Find the relevant one.\n\n### 3. Breakpoints > Logs for Tracing\n\nBreakpoints let you explore. Logs are for verification.\n\n### 4. Async Breaks the Stack\n\nRemember that async\u002Fcallbacks create gaps in the call stack.\n\n### 5. Correlation IDs Connect Async\n\nPass IDs through async chains to trace across boundaries.\n\n## Anti-Patterns\n\n### 1. Scatter Shot Logging\n\n```typescript\n\u002F\u002F BAD: Log everything\nconsole.log('A');\nconsole.log('B');\nconsole.log('C');\n\u002F\u002F Now you have noise, not signal\n\n\u002F\u002F GOOD: Strategic logging\nconsole.log('Before critical operation:', importantState);\n```\n\n### 2. Not Using IDE Tools\n\n```typescript\n\u002F\u002F BAD: Add logs to understand flow\nfunction trace(x) {\n  console.log('x:', x);\n  return x * 2;\n}\n\n\u002F\u002F GOOD: Use debugger\ndebugger; \u002F\u002F Or set breakpoint in IDE\n```\n\n### 3. Ignoring the Call Stack\n\n```typescript\n\u002F\u002F BAD: Don't look at call stack\n\u002F\u002F \"Something called my function\"\n\n\u002F\u002F GOOD: Read the stack\n\u002F\u002F \"Oh, moduleA.line 42 called this\"\n```\n\n## Relationship to Other Skills\n\n- `debug-session` — Uses tracing as part of debugging workflow\n- `debug-test` — Tracing helps understand test failures\n- `understand-error` — Stack trace reading uses this\n- `inspect-state` — Often used alongside tracing\n- `reproduce-bug` — Tracing is part of reproduction\n","# Trace Execution — Systematic Code Path Analysis\n\n## Overview\n\nTrace-execution is a **behavioral specification skill** that encapsulates the methodology for **systematically following code execution paths, setting breakpoints strategically, and understanding how code flows through a system**.\n\nThis skill embodies the discipline of developers who've traced complex bugs and know that \"adding logs everywhere\" is not a strategy — understanding the path is.\n\n## Core Philosophy\n\n### The Execution Trace Principle\n\n> \"Code execution is a path through a graph. To understand it, you don't follow every edge — you find the critical path and follow that.\"\n\n### Tracing vs Logging\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    TRACING vs LOGGING                         │\n│                                                               │\n│    TRACING:                     LOGGING:                     │\n│    ─────────                     ───────                      │\n│    Understanding WHERE code     Recording WHAT happened       │\n│    is going                     for later analysis            │\n│                                                               │\n│    Tools: Breakpoints, Step     Tools: console.log, logger   │\n│    through, Call stack          Purpose: Audit, reproduce    │\n│    Purpose: Understand path     Purpose: Verify behavior      │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Decision Framework\n\n### When to Trace vs Log\n\n| Situation | Approach | Why |\n|-----------|----------|-----|\n| Understanding unfamiliar code | TRACE | Don't know where to log |\n| Reproducing a bug | LOG + TRACE | Need both |\n| Verifying a fix | LOG | Just need to confirm |\n| Understanding flow | TRACE | Follow the path |\n| Finding where code diverges | TRACE | Find the branch |\n\n### Breakpoint Strategy\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                  BREAKPOINT PLACEMENT                          │\n│                                                               │\n│    Entry Point ──► Key Decision ──► Important State ──► Exit │\n│         │                │                  │                │\n│         ▼                ▼                  ▼                │\n│    First line      Branch check        Before mutation        │\n│    of function     if\u002Felse\u002Fswitch     critical operation     │\n│                                                               │\n│    \"Where does it start?\"      \"Where might it branch?\"      │\n│    \"What's the flow?\"          \"Where is state changed?\"    │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Behavioral Specification\n\n### Phase 1: Map the Execution Path\n\n#### 1.1 Entry Point Identification\n\n```typescript\n\u002F\u002F Find where execution STARTS\n\u002F\u002F 1. Look for event handlers, API routes, main functions\n\u002F\u002F 2. Find the public\u002Fexported functions\n\u002F\u002F 3. Find where your code is CALLED\n\n\u002F\u002F Example: Understanding an API request flow\n\u002F\u002F 1. router.post('\u002Fusers', ...) → Entry point\n\u002F\u002F 2. createUser(req.body) → Function called\n\u002F\u002F 3. validateUserData(data) → Inside createUser\n\u002F\u002F 4. userRepo.save(user) → Database call\n```\n\n#### 1.2 Call Graph Construction\n\n```typescript\n\u002F\u002F Build a simple call graph\nfunction main() {\n  \u002F\u002F     main\n  \u002F\u002F    \u002F    \\\n  \u002F\u002F   A()    B()\n  \u002F\u002F  \u002F \\     |\n  \u002F\u002F C() D()  E()\n  \u002F\u002F\n  \u002F\u002F To trace from main to E:\n  \u002F\u002F main → B → E\n}\n\n\u002F\u002F How to trace:\n\u002F\u002F 1. Start at entry\n\u002F\u002F 2. For each function call, note WHERE it's called\n\u002F\u002F 3. Follow the most relevant path\n```\n\n#### 1.3 Async Execution Tracing\n\n```typescript\n\u002F\u002F Async adds complexity:\n\u002F\u002F 1. Promises resolve later\n\u002F\u002F 2. Call stack is lost\n\u002F\u002F 3. Order matters\n\n\u002F\u002F Trace async:\nasync function processOrder(orderId: string) {\n  \u002F\u002F 1. Fetch order (async)\n  const order = await fetchOrder(orderId); \u002F\u002F ← Breakpoint here\n\n  \u002F\u002F 2. Validate (sync)\n  validate(order); \u002F\u002F ← Then here\n\n  \u002F\u002F 3. Process (async)\n  const result = await processPayment(order); \u002F\u002F ← Then here\n\n  \u002F\u002F 4. Save (async)\n  await saveResult(result); \u002F\u002F ← Finally here\n}\n```\n\n### Phase 2: Strategic Breakpoint Placement\n\n#### 2.1 Breakpoint Types\n\n```typescript\n\u002F\u002F LINE BREAKPOINT: Stop at specific line\n\u002F\u002F Useful for: Known problematic area\n\n\u002F\u002F CONDITIONAL BREAKPOINT: Stop only when condition met\n\u002F\u002F Useful for: Specific case within a loop\n\n\u002F\u002F FUNCTION BREAKPOINT: Stop at function entry\n\u002F\u002F Useful for: Trace function calls\n\n\u002F\u002F EXCEPTION BREAKPOINT: Stop when exception thrown\n\u002F\u002F Useful for: Catch unhandled errors\n```\n\n#### 2.2 Strategic Placement\n\n```typescript\n\u002F\u002F PLACEMENT STRATEGY\n\n\u002F\u002F 1. ENTRY\u002FEXIT: Function boundaries\nfunction complexOperation(input) {\n  \u002F\u002F BREAKPOINT: Entry\n  console.log('Input:', input);\n\n  \u002F\u002F ... code ...\n\n  \u002F\u002F BREAKPOINT: Exit\n  console.log('Output:', result);\n  return result;\n}\n\n\u002F\u002F 2. DECISION POINTS: If\u002Fswitch\u002Fternary\nif (user.isAdmin) { \u002F\u002F BREAKPOINT: Before branch\n  \u002F\u002F Admin path\n} else {\n  \u002F\u002F Regular path\n}\n\n\u002F\u002F 3. STATE CHANGES: Assignments to important variables\nlet total = 0;\ntotal = calculate(items); \u002F\u002F BREAKPOINT: After important assignment\n```\n\n#### 2.3 Efficiency in Tracing\n\n```typescript\n\u002F\u002F BAD: Too many breakpoints\nfunction process() {\n  \u002F\u002F breakpoint at line 1\n  \u002F\u002F breakpoint at line 2\n  \u002F\u002F breakpoint at line 3 ... (useless noise)\n\n  \u002F\u002F GOOD: Strategic breakpoints\n  function process() {\n    \u002F\u002F breakpoint at key decision\n    \u002F\u002F breakpoint before mutation\n    \u002F\u002F breakpoint at return\n  }\n```\n\n### Phase 3: Call Stack Analysis\n\n#### 3.1 Reading the Stack\n\n```typescript\n\u002F\u002F Call Stack (top to bottom = recent to old):\n\u002F\u002F at C (c.ts:10)          ← CURRENTLY HERE\n\u002F\u002F at B (b.ts:20)          ← WHO CALLED C\n\u002F\u002F at A (a.ts:30)          ← WHO CALLED B\n\n\u002F\u002F To trace BACKWARDS:\n\u002F\u002F 1. Start at current (C)\n\u002F\u002F 2. Read up for caller (B)\n\u002F\u002F 3. Read up for caller (A)\n\n\u002F\u002F This is how you got HERE\n```\n\n#### 3.2 Async Stack Analysis\n\n```typescript\n\u002F\u002F Async stack is DISCONNECTED\n\u002F\u002F Example:\n\n\u002F\u002F Stack 1 (async trigger):\nasync function trigger() {\n  await process(); \u002F\u002F ← Point A: Called process\n}\n\n\u002F\u002F Stack 2 (async continuation):\nasync function process() {\n  \u002F\u002F ← Point B: Code here\n  \u002F\u002F The \"who called\" chain is broken!\n}\n\n\u002F\u002F Solution: Use correlation IDs\nasync function trigger(correlationId) {\n  await process(correlationId); \u002F\u002F Pass ID through\n}\n\nasync function process(correlationId) {\n  console.log('Triggered by:', correlationId);\n  \u002F\u002F Now you can trace!\n}\n```\n\n### Phase 4: Control Flow Patterns\n\n#### 4.1 Common Patterns\n\n```typescript\n\u002F\u002F Pattern 1: Linear Flow\nA(); B(); C(); \u002F\u002F Trace: A → B → C\n\n\u002F\u002F Pattern 2: Conditional Flow\nif (x) { A(); } else { B(); }\n\u002F\u002F Trace: x? → A or B\n\n\u002F\u002F Pattern 3: Loop Flow\nfor (const item of items) {\n  process(item);\n}\n\u002F\u002F Trace: items[0] → items[1] → items[2]...\n\n\u002F\u002F Pattern 4: Callback Flow\nfetch(url, (err, data) => {\n  if (err) handleError(err);\n  else process(data);\n});\n\u002F\u002F Trace: fetch → callback (success or error path)\n\n\u002F\u002F Pattern 5: Event Flow\nemitter.on('event', handler);\n\u002F\u002F Trace: emit → handler\n```\n\n## Common Scenarios\n\n### Scenario 1: \"How does this button click get handled?\"\n\n```typescript\n\u002F\u002F Step 1: Find the button\n\u002F\u002F \u003Cbutton onClick={handleSubmit}>\n\n\u002F\u002F Step 2: Trace the handler\nconst handleSubmit = async (event) => {\n  event.preventDefault(); \u002F\u002F Breakpoint here\n\n  \u002F\u002F Step 3: Find what it calls\n  const formData = new FormData(event.target);\n  const data = Object.fromEntries(formData);\n\n  \u002F\u002F Step 4: Continue tracing\n  await api.submit(data); \u002F\u002F Breakpoint here\n};\n\n\u002F\u002F Step 5: Trace the API\n\u002F\u002F POST \u002Fapi\u002Fsubmit → server route → handler\n```\n\n### Scenario 2: \"Why did this code path execute?\"\n\n```typescript\n\u002F\u002F Given: 'if (user.isAdmin)' branch was taken\n\u002F\u002F Question: Why was user.isAdmin true?\n\n\u002F\u002F Trace backwards:\nfunction handleRequest(user) {\n  \u002F\u002F user.isAdmin came from HERE\n  const userFromDB = await getUser(user.id);\n  \u002F\u002F Why was this true?\n\n  \u002F\u002F Continue backwards...\n  \u002F\u002F getUser returned { isAdmin: true }\n  \u002F\u002F Was the data correct in DB?\n  \u002F\u002F Did something modify it?\n}\n\n\u002F\u002F Solution: Breakpoint at assignment\nconst userFromDB = await getUser(user.id);\n\u002F\u002F Inspect: What did getUser return?\n\u002F\u002F If wrong → problem in getUser\n\u002F\u002F If right → problem elsewhere\n```\n\n### Scenario 3: \"This function is called but I don't see why\"\n\n```typescript\n\u002F\u002F Question: Who is calling this function?\n\u002F\u002F findAllUsers()\n\n\u002F\u002F Solution 1: Stack trace (runtime)\n\u002F\u002F Add breakpoint, look UP the stack\n\n\u002F\u002F Solution 2: IDE find usages (static)\n\u002F\u002F Right click → Find All References\n\u002F\u002F Shows all call sites\n\n\u002F\u002F Solution 3: Grep\ngrep -r \"findAllUsers\" --include=\"*.ts\"\n\u002F\u002F Lists all files that call this function\n```\n\n## Debugging Execution Tools\n\n### Browser DevTools\n\n```typescript\n\u002F\u002F 1. Breakpoints panel\n\u002F\u002F - Set by clicking line number\n\u002F\u002F - See all breakpoints\n\u002F\u002F - Enable\u002Fdisable individually\n\n\u002F\u002F 2. Watch panel\n\u002F\u002F - Add expressions to watch\n\u002F\u002F - See value update as you step\n\n\u002F\u002F 3. Call Stack panel\n\u002F\u002F - See current path\n\u002F\u002F - Click frame to jump to caller\n```\n\n### Node.js Debugging\n\n```bash\n# Start with inspector\nnode --inspect index.js\n\n# Or in Chrome DevTools\nnode --inspect-brk index.js\n# --inspect-brk pauses on first line\n\n# VS Code attach\n# Debug > Attach to Node\n```\n\n### Logging for Tracing\n\n```typescript\n\u002F\u002F When you can't use debugger\nconst trace = (label, value) => {\n  console.log(`[TRACE] ${label}:`, value);\n  return value;\n};\n\n\u002F\u002F Usage\nconst result = trace('processed', actualValue);\n\u002F\u002F Output: [TRACE] processed: { ... }\n```\n\n## The Trace Execution Checklist\n\n```\nTRACE EXECUTION CHECKLIST\n=========================\n\n□ 1. Identify entry point\n□ 2. Map the call graph (at least roughly)\n□ 3. Find the critical path\n□ 4. Place breakpoints strategically\n  □ Entry\u002Fexit of functions\n  □ Decision points\n  □ State mutations\n□ 5. Follow the call stack\n□ 6. Note any async boundaries\n□ 7. Verify understanding matches reality\n\nFOR ASYNC CODE:\n□ Use correlation IDs\n□ Break on promise creation and resolution\n□ Watch for detached stacks\n```\n\n## Key Principles\n\n### 1. Start at the Beginning\n\nAlways trace from a known point. Entry points are anchors.\n\n### 2. Follow One Path\n\nDon't try to trace all paths. Find the relevant one.\n\n### 3. Breakpoints > Logs for Tracing\n\nBreakpoints let you explore. Logs are for verification.\n\n### 4. Async Breaks the Stack\n\nRemember that async\u002Fcallbacks create gaps in the call stack.\n\n### 5. Correlation IDs Connect Async\n\nPass IDs through async chains to trace across boundaries.\n\n## Anti-Patterns\n\n### 1. Scatter Shot Logging\n\n```typescript\n\u002F\u002F BAD: Log everything\nconsole.log('A');\nconsole.log('B');\nconsole.log('C');\n\u002F\u002F Now you have noise, not signal\n\n\u002F\u002F GOOD: Strategic logging\nconsole.log('Before critical operation:', importantState);\n```\n\n### 2. Not Using IDE Tools\n\n```typescript\n\u002F\u002F BAD: Add logs to understand flow\nfunction trace(x) {\n  console.log('x:', x);\n  return x * 2;\n}\n\n\u002F\u002F GOOD: Use debugger\ndebugger; \u002F\u002F Or set breakpoint in IDE\n```\n\n### 3. Ignoring the Call Stack\n\n```typescript\n\u002F\u002F BAD: Don't look at call stack\n\u002F\u002F \"Something called my function\"\n\n\u002F\u002F GOOD: Read the stack\n\u002F\u002F \"Oh, moduleA.line 42 called this\"\n```\n\n## Relationship to Other Skills\n\n- `debug-session` — Uses tracing as part of debugging workflow\n- `debug-test` — Tracing helps understand test failures\n- `understand-error` — Stack trace reading uses this\n- `inspect-state` — Often used alongside tracing\n- `reproduce-bug` — Tracing is part of reproduction\n",{"name":5,"category":37,"priority":48,"description":7,"trigger_patterns":49},"P2",[23,50,51,52,53,54,55],"follow the code","debugging execution","breakpoint strategy","control flow","how does this get called","execution path","main","b9a52d8e27455bdad953d64928696d028223ea1b","skills\u002Fcoding\u002Ftrace-execution","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager","https:\u002F\u002Fgithub.com\u002FImaginerLabs","2026-04-18 16:27:13",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add ImaginerLabs\u002Fskill-manager --skill trace-execution",{"tool":68,"command":69},"bunx","bunx skills add ImaginerLabs\u002Fskill-manager --skill trace-execution",{"tool":71,"command":72},"pnpm","pnpm dlx skills add ImaginerLabs\u002Fskill-manager --skill trace-execution","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Ftrace-execution\u002FSKILL.md",true,[],[77,110,131,159,192,218],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":91,"publishedAt":43},"01M6QJCB2SD5KHC41ZDQC0GA1T","meeting-minutes","Generate concise, actionable meeting minutes for internal meetings. Includes metadata, attendees, agenda, decisions, action items (owner + due date), and follow-up steps.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fmeeting-minutes\u002FSKILL.md",[83,88],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":89,"categoryName":90,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000034","行政与办公人员",[92,93,94,95,96,97,98,99,100,101,79,56,102,103,104,105,106,107,108,109],"meeting minutes","meeting","minutes","writing","github","copilot","generate","decisions","meetings","up","agenda","actionable","concise","follow-up","tree","true","action","for",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":43},"01M6QJC71RRGTGNNFEHJG6S20G","documentation-writer","Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[],[117,118,119,95,96,97,120,121,122,123,124,125,56,126,127,128,129,106,107,130],"documentation","documentation writer","writer","https","quality","technical","technical writer","expert","documentation expert","structure","authoring","software","principles","high",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":144,"publishedAt":43},"01M6QJC0V3C7C4R9768J1AJYWY","doc-coauthoring","Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdoc-coauthoring\u002FSKILL.md",[137,140,141],{"categoryNo":138,"categoryName":139,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},{"categoryNo":142,"categoryName":143,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000036","内容创作者",[145,146,95,147,148,117,149,150,151,152,153,154,56,155,156,127,157,158,106,109],"doc coauthoring","doc","workflow","official","tasks","decision","write","context","proposals","guide","refine","iteration","trigger","co",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":173,"publishedAt":43},"01M6QJBJ0YPVEWGEXZH3PJRRTT","code-review-workflow","Executes comprehensive 4-phase code review: basic review, quality check, bundle analysis, and test coverage. Should be used when the user mentions comprehensive code review, checking code quality, or reviewing staged changes with multi-phase analysis. This is the comprehensive review workflow, distinct from focused skills like frontend-code-review, staged-code-review, or code-change-test-designer.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-review-workflow\u002FSKILL.md",[165,168,171,172],{"categoryNo":166,"categoryName":167,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":169,"categoryName":170,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[174,175,147,42,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191],"code review","review","code review workflow","testing","frontend","test","change","code quality","code-review","analysis","check","coverage","quality check","basic","multi","comprehensive code review","with","phase",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":207,"publishedAt":43},"01M6QJB7XNHV3VEEQF4W7FMWF6","code-change-test-designer","Analyzes code changes and designs comprehensive test cases. Reads diffs, summarizes capability changes, and designs test cases covering main flows and edge cases. Should be used when the user mentions test coverage, designing tests for code changes, or analyzing diff\u002Fcommit for testing purposes. Distinguished from code-review-workflow which provides comprehensive review, this skill focuses on test case design for code changes.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-change-test-designer\u002FSKILL.md",[198,199,202,203,204],{"categoryNo":169,"categoryName":170,"taxonomyType":86,"taxonomyTypeDesc":87},{"categoryNo":200,"categoryName":201,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":205,"categoryName":206,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000032","设计师",[179,180,42,208,209,177,210,211,147,212,182,213,185,214,56,215,216,217,109,191],"designer","code change test designer","design","diffs","commit","edge","diff","tests","flows","which",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":225,"publishedAt":43},"01M6QJB195WD7DCJWDMKWKB29S","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fmeta-skills\u002Fskill-creator\u002FSKILL.md",[224],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},[226,227,228,229,148,230,231,232,233,234,183,235,236,237,56,238,239,106,109,220],"skill creator","creator","performance","run evals","variance analysis","create","run","benchmark","Meta","improve","edit","evals","optimize","existing skill"]