一键导入
debug
Systematic debugging workflow: reproduce, isolate, hypothesize, verify, fix. Triggers: "debug", "find bug", "fix crash", "why is this broken", "not working".
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Systematic debugging workflow: reproduce, isolate, hypothesize, verify, fix. Triggers: "debug", "find bug", "fix crash", "why is this broken", "not working".
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Systematic UI workflow auditing for SwiftUI applications. Discovers entry points, traces user flows, detects dead ends and broken promises, audits data wiring, evaluates from user perspective. Triggers: "workflow audit", "audit flows", "find dead ends", "check navigation".
Mine for hidden bugs that pattern-based auditors miss. 7 analysis lenses: assumptions, state machines, boundary conditions, data lifecycle, error paths, time-dependent behavior, and platform divergence. Triggers: "prospect for bugs", "find hidden bugs", "assumption audit", "what could go wrong", "bug prospector".
Epic decomposition into trackable, right-sized tasks. Three modes — audit-aware (codebase-audit reports), workflow-audit-aware (handoff.yaml with pre-rated findings), standalone (from scratch). Light convention scanning for projects without CLAUDE.md.
Systematic UI workflow auditing for SwiftUI applications. Discovers entry points, traces user flows, detects dead ends and broken promises, evaluates from user perspective.
Sync website content with app codebase - features, changelog, FAQ, docs. Triggers: "update website", "sync website", "website sync".
Display list of all available custom commands for this project
| name | debug |
| description | Systematic debugging workflow: reproduce, isolate, hypothesize, verify, fix. Triggers: "debug", "find bug", "fix crash", "why is this broken", "not working". |
| version | 2.1.0 |
| author | Terry Nyberg |
| license | MIT |
| allowed-tools | ["Read","Grep","Glob","Bash","Edit","Write","LSP","AskUserQuestion"] |
| metadata | {"tier":"execution","category":"debugging"} |
Quick Ref: Systematic bug investigation: reproduce → isolate → hypothesize → verify → fix. Output:
.agents/research/YYYY-MM-DD-debug-*.md
YOU MUST EXECUTE THIS WORKFLOW. Do not just describe it.
Required output: Every finding MUST include Urgency, Risk, ROI, and Blast Radius ratings using the Issue Rating Table format. Do not omit these ratings.
git status --short
If uncommitted changes exist:
AskUserQuestion with questions:
[
{
"question": "You have uncommitted changes. Commit before proceeding?",
"header": "Git",
"options": [
{"label": "Commit first (Recommended)", "description": "Save current work so you can revert if this skill modifies files"},
{"label": "Continue without committing", "description": "Proceed — I accept the risk"}
],
"multiSelect": false
}
]
If "Commit first": Ask for a commit message, stage changed files, and commit. Then proceed.
Use AskUserQuestion if the user hasn't provided enough detail:
AskUserQuestion with questions:
[
{
"question": "What type of issue are you seeing?",
"header": "Bug type",
"options": [
{"label": "Crash", "description": "App crashes, EXC_BAD_ACCESS, fatal error, etc."},
{"label": "Wrong behavior", "description": "App runs but does the wrong thing"},
{"label": "UI issue", "description": "Layout broken, animation wrong, view not updating"},
{"label": "Performance", "description": "Slow, laggy, high memory, battery drain"}
],
"multiSelect": false
}
]
Collect these details (from user message or by asking):
Goal: Confirm the bug exists and understand the trigger conditions.
If the bug started recently, look at what changed:
# Recent commits touching Swift files
git log --oneline -10 -- '*.swift'
# Files changed in last N commits
git diff --name-only HEAD~5
# Full diff of recent changes
git diff HEAD~3 -- '*.swift'
If the user provided an error message, find it in code:
# Search for the error string in source
Grep pattern="error message text" glob="**/*.swift"
# Search for fatalError / precondition calls
Grep pattern="fatalError|preconditionFailure|assertionFailure" glob="**/*.swift"
Record:
Goal: Narrow down to the smallest code path that causes the bug.
Start from the user-facing symptom and trace inward:
# Find the entry point (e.g., button tap, view appear)
Grep pattern="<symptom_function_or_action>" glob="**/*.swift"
# Read the view/controller involved
Read file_path="<path_to_affected_file>"
# Trace function calls — use LSP when available for accurate resolution
LSP operation="goToDefinition" filePath="<file>" line=<N> character=<N>
LSP operation="findReferences" filePath="<file>" line=<N> character=<N>
# Fallback: Read each file along the call chain manually
Understand what the affected code touches:
# Find all callers of the broken function
Grep pattern="\.<brokenFunctionName>\(" glob="**/*.swift"
# Check protocol conformances if relevant
Grep pattern=":\s*<AffectedProtocol>" glob="**/*.swift"
# Check for build configuration differences
Grep pattern="#if DEBUG|#if targetEnvironment" glob="**/*.swift"
Goal: Collect concrete data about what the code is actually doing.
Read every file in the suspected code path. Don't guess — read.
# Read the primary file
Read file_path="<path_to_suspected_file>"
# Read related files along the call chain
Read file_path="<path_to_related_file>"
# When was the broken code last modified?
git log --oneline -5 -- "path/to/file.swift"
# What exactly changed?
git log -p -1 -- "path/to/file.swift"
# Find when a specific pattern was introduced or removed
git log -p -S "suspiciousCode" -- '*.swift'
# Find similar patterns that might also be affected
Grep pattern="<same_pattern_as_bug>" glob="**/*.swift"
# Find TODO/FIXME comments near the affected code
Grep pattern="TODO|FIXME|HACK|WORKAROUND" path="<affected_directory>"
Goal: Form ranked hypotheses based on evidence.
List possible causes ranked by likelihood:
| # | Hypothesis | Likelihood | Evidence | How to Verify |
|---|---|---|---|---|
| 1 | [Most likely cause] | High | [What evidence supports this] | [Specific check to confirm/deny] |
| 2 | [Second possibility] | Medium | [Evidence] | [Check] |
| 3 | [Third possibility] | Low | [Evidence] | [Check] |
State & Data:
as! and force unwraps)@MainActor missing on UI updates)Concurrency:
await (forgetting to await an async call, getting old value)Task.isCancelled)Memory:
[weak self] in escaping closures in classes)weak (strong reference cycle)UI:
@Published, wrong property wrapper)Goal: Test each hypothesis starting with the most likely.
For each hypothesis, design a specific check that will definitively confirm or deny it:
# Example: Hypothesis is "nil optional crash"
# Test: Search for force unwraps in the affected file
Grep pattern="as!" path="<affected_file>"
# Example: Hypothesis is "missing weak self"
# Test: Find closures in the affected class (only relevant for classes, not structs)
Grep pattern="\.sink|\.receive|completion.*=" path="<affected_file>"
# Example: Hypothesis is "race condition"
# Test: Find shared mutable state
Grep pattern="var\s+\w+.*=" path="<affected_file>"
Record results for each hypothesis:
Hypothesis 1: [description]
Test: [what I checked]
Result: CONFIRMED / DENIED / INCONCLUSIVE
Evidence: [what I found]
Continue until root cause is identified.
Goal: Document the confirmed root cause clearly.
## Root Cause
**What:** [One-sentence description of the bug]
**Why:** [Underlying reason — why did this code get written this way?]
**Where:** [File:line where the bug lives]
**When introduced:** [Commit hash/date if identifiable]
Goal: Implement the minimal correct fix.
Before editing, document:
| File | Change Required | Risk |
|---|---|---|
File.swift:45 | [what to change] | Low/Med/High |
Blast radius: How many files are affected? Regression risk: Low / Medium / High Test coverage: Do existing tests cover this? New tests needed?
Use Edit tool to make targeted changes. Keep the fix minimal — don't refactor unrelated code.
After fixing, search for the same pattern elsewhere:
# If the bug was a force cast, find other force casts
# INTENTIONAL: as! after guard let/is check is already validated
Grep pattern="as!" glob="**/*.swift"
# If the bug was a missing weak self, find other closures in classes
# INTENTIONAL: SwiftUI struct views don't need [weak self]
Grep pattern="\.sink\s*\{[^}]*self\." glob="**/*ViewModel*.swift"
Grep pattern="\.sink\s*\{[^}]*self\." glob="**/*Manager*.swift"
Or use /scan-similar-bugs for a more thorough scan.
Goal: Confirm the fix works and doesn't break anything.
Display the investigation summary, root cause, and fix inline, then write report to .agents/research/YYYY-MM-DD-debug-{summary}.md:
# Bug Investigation Report
**Date:** YYYY-MM-DD
**Bug:** [one-line description]
**Urgency:** 🔴 Critical / 🟡 High / 🟢 Medium / ⚪ Low
**Status:** Fixed
## Symptoms
[What the user observed]
## Root Cause
**What:** [description]
**Where:** FileName.swift:line
**Why:** [underlying reason]
**Introduced:** [commit or date if known]
## Fix Applied
| File | Change | Lines |
|------|--------|-------|
| FileName.swift | [description] | 45-48 |
## Verification
- [x] Bug no longer reproduces
- [x] Build succeeds
- [x] Tests pass
- [ ] Regression test added
## Issue Rating Table
| # | Finding | Urgency | Risk: Fix | Risk: No Fix | ROI | Blast Radius | Fix Effort |
|---|---------|---------|-----------|-------------|-----|-------------|------------|
| 1 | [Primary bug] File.swift:45 — [description] | 🔴 Critical | ⚪ Low | 🔴 Critical | 🟠 Excellent | ⚪ 1 file | Trivial |
Use the Issue Rating scale:
- **Urgency:** 🔴 CRITICAL (crash/data loss) · 🟡 HIGH (incorrect behavior) · 🟢 MEDIUM (degraded UX) · ⚪ LOW (cosmetic/minor)
- **Risk: Fix:** Risk of the fix introducing regressions (⚪ Low for isolated changes, 🟡 High for shared code paths)
- **Risk: No Fix:** User-facing consequence if left unfixed
- **ROI:** 🟠 Excellent · 🟢 Good · 🟡 Marginal · 🔴 Poor
- **Blast Radius:** How many callers/files are exposed to this bug
- **Fix Effort:** Trivial / Small / Medium / Large
## Similar Patterns Found
[List any other instances of the same bug pattern, or "None found"]
Include each similar pattern as a row in the Issue Rating Table above.
## Prevention
[What could prevent this class of bug in the future]
User: "My app crashes when I tap an item in the list"
Step 1 — Gather: Crash on tap, EXC_BAD_ACCESS, started after last commit
Step 2 — Reproduce: git log shows ItemDetailView.swift changed yesterday
Step 3 — Isolate: Trace: List tap → NavigationLink → ItemDetailView.init → viewModel.loadItem()
Step 4 — Evidence: Read ItemDetailViewModel.swift, find `item.category!` on line 34
Step 5 — Hypothesize:
#1: Force unwrap of nil optional (HIGH) — category is Optional, forced
#2: Array index out of bounds (LOW) — no array access nearby
Step 6 — Verify: Check data — category is nil for items imported from CSV
Step 7 — Root cause: Force unwrap of item.category which is nil for CSV imports
Step 8 — Fix: Replace `item.category!` with `item.category ?? "Uncategorized"`
Step 9 — Verify: Build passes, tap works, added test for nil category
Step 10 — Report: Written to .agents/research/2026-02-24-debug-item-detail-crash.md
| Problem | Solution |
|---|---|
| Can't reproduce the bug | Ask for exact steps, device/simulator, iOS version, data state |
| Multiple hypotheses seem equally likely | Test the cheapest-to-verify one first |
| Fix breaks something else | Revert, widen the blast radius analysis, find the shared dependency |
| Bug is intermittent | Likely a race condition — focus on concurrency patterns |
| No error message, just wrong behavior | Add strategic print/breakpoint to narrow the code path |
| Bug only happens in release builds | Check #if DEBUG blocks, compiler optimizations, stripped symbols |