Skip to main content

debug

Debugging & Troubleshooting - systematic root cause investigation with hypothesis testing and evidence collection. Use when the user reports a bug, encounters an error, sees unexpected behavior, or says 'debug this' or 'investigate this issue'.

Quellinformationen

Repository
greenpill-dev-guild/coop
Letzte Quellaktivität
17. Mai 2026 um 03:22
Erkannte Sprache von SKILL.md
Englisch
Sterne
3
Forks
1

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
debug
description
Debugging & Troubleshooting - systematic root cause investigation with hypothesis testing and evidence collection. Use when the user reports a bug, encounters an error, sees unexpected behavior, or says 'debug this' or 'investigate this issue'.
context
fork
argument-hint
[error-description]
version
1.0.0
status
active
packages
["all"]
dependencies
[]
last_updated
2026-03-12
last_verified
2026-03-12
# Debug Skill Systematic debugging: find root causes before fixes, verify with evidence before completion. **References**: See `CLAUDE.md` for codebase patterns. --- ## Activation | Trigger | Action | |---------|--------| | `/debug` | Start root cause investigation | | `/debug --mode incident_hotfix` | Emergency stabilization with minimal fixes | | `/debug --mode tdd_bugfix` | Test-first bugfix loop | | Tests failing | Systematic debugging | | Build failures | Trace and fix | | Verifying completion | Evidence-based checks | ## Progress Tracking (REQUIRED) Use **TodoWrite** when available. If unavailable, keep a Markdown checklist in the response. See `CLAUDE.md` -> Session Continuity. --- ## Scope Confirmation When the input is ambiguous (no specific file paths, multiple possible interpretations), echo back scope before investigating: ``` Debug scope: [symptom described] Likely package: [shared | extension | app | unclear] Mode: [standard | incident_hotfix | tdd_bugfix] Starting with: Phase 0 sanity check Proceed? [y/n] ``` ## Safety Rules - Non-destructive recovery only - Save a patch snapshot before risky edits: `git diff > /tmp/coop-debug.patch` - Use a safety branch for experiments: `git switch -c debug/incident-$(date +%Y%m%d-%H%M%S)` - Never use destructive reset/reclone patterns in debug flow ## Core Principle > ALWAYS find root cause before attempting fixes. > Evidence before claims, always. --- ## Part 1: Root Cause Investigation ### Phase 0: 90-Second Sanity Check (ALWAYS DO FIRST) Before any deep investigation, rule out the simple causes that waste entire sessions: | Priority | Check | Command | Time | |----------|-------|---------|------| | 1 | **Stale build / cache** | `rm -rf dist .docusaurus node_modules/.vite && bun run build` | 45s | | 2 | **Missing import** | Verify the module/component is actually imported where it's used | 15s | | 3 | **Wrong file** | Confirm you're editing the file that's actually rendered (check Vite aliases, barrel re-exports) | 15s | | 4 | **Env var stale** | Env vars bake at build time — did you rebuild after changing `.env.local`? | 15s | If any of these fix the issue, **stop here**. Do not investigate further. Report the simple cause. Only proceed to Phase 1 if all sanity checks pass. ### Phase 1: Gather Evidence **DO NOT attempt any fixes yet.** 1. **Read error messages thoroughly** 2. **Reproduce consistently** — exact steps 3. **Check recent changes**: `git log --oneline -20` 4. **Trace data flow backward** — where does error manifest? ### Phase 2: Hypothesis Testing 1. **Form specific hypothesis** - "Error occurs because X calls Y with null" - NOT "Something is wrong with the API" 2. **Test minimally** — ONE variable at a time 3. **If 3+ fixes fail: STOP** - Question the architecture - Reassess understanding - Ask for help --- ## Part 2: Escalation | Fix Type | Criteria | Action | |----------|----------|--------| | **Simple** | <10 lines, single file | Fix directly | | **Complex** | >10 lines, multi-file, needs tests | Use TDD bugfix flow | | **Architectural** | Pattern change, refactor | TDD + /plan | ### Handoff Format ```markdown ## Debug Handoff ### Root Cause [What you found] ### Location [File:line where issue originates] ### Evidence [Commands/logs that prove the cause] ### Suggested Fix [Your recommendation] ``` --- ## Part 3: Verification Before Completion ### Mandatory Verification | Claim | Command | |-------|---------| | "Tests pass" | `bun run test` (NOT `bun test` -- see CLAUDE.md) | | "Build succeeds" | `bun run build` | | "Linting clean" | `bun lint` | ### Suspicious Language If you say these, STOP and verify first: - "should work" - "I think" - "probably" - "seems to" --- ## Part 4: Coop Debugging ### Local-First / Sync Issues - Check Dexie for stuck or corrupted records - IndexedDB: Chrome DevTools > Application > IndexedDB - Yjs document state: inspect Y.Doc in console - y-webrtc signaling: check if API server is running (`bun dev:api`) - Peer discovery: check WebRTC connection state in console ### Extension Issues ```bash # Check extension build output cd packages/extension && bun run build # Reload extension in Chrome # chrome://extensions > Developer mode > Reload # Background worker logs # chrome://extensions > "Inspect views: service worker" # Content script logs # Regular DevTools console on the page ``` ### App / PWA Issues ```bash # Check app build cd packages/app && bun run build # Service Worker registration: Chrome DevTools > Application > Service Workers # Check Vite dev server cd packages/app && bun dev ``` ### Build & Type Debugging ```bash # TypeScript errors without emitting cd packages/shared && npx tsc --noEmit # Check specific package types cd packages/app && npx tsc --noEmit # Vite build with verbose output cd packages/app && DEBUG=vite:* bun run build ``` ### Onchain Issues ```bash # Check Safe deployment status # Use the validate script bun run validate:arbitrum-safe-live # Check chain connectivity bun run probe:onchain-live ``` ### Common Debug Scenarios | Symptom | Likely Cause | Diagnostic | |---------|-------------|------------| | Stale data after publish | Yjs sync not propagating | Check y-webrtc peer connections | | Extension popup blank | Build error or manifest issue | Check chrome://extensions errors | | Passkey auth fails | WebAuthn API issue | Check browser console for DOMException | | Dexie version error | Schema migration mismatch | Check Dexie.version() calls | | Background worker crash | Unhandled promise rejection | Inspect service worker in chrome://extensions | | Receiver not pairing | API server down | Check `bun dev:api` output | --- ## Part 5: Cross-Layer Debugging For tracing issues through the full local -> sync -> publish pipeline: ### Coop Data Pipeline ``` Local Draft -> Dexie -> Yjs Doc -> y-webrtc Sync -> Publish -> Archive (Storacha) ``` ### Step-by-Step Trace #### Layer 1: Local Storage (Dexie) ```bash # Check IndexedDB for stuck records # Chrome DevTools > Application > IndexedDB # Check Dexie table state in console # db.table('flows').toArray().then(console.log) ``` | Symptom | Layer | Check | |---------|-------|-------| | Draft not saving | Dexie | Storage quota: `navigator.storage.estimate()` | | Data missing after refresh | Dexie | Check if table/version exists | | Schema error on open | Dexie | Version migration mismatch | #### Layer 2: Yjs Sync ```bash # Check Y.Doc state # In console: ydoc.getMap('flows').toJSON() # Monitor sync events # awareness.on('change', console.log) ``` #### Layer 3: Archive (Storacha) ```bash # Check if content was archived # Look for CID in Storacha responses in Network tab # Verify CID is retrievable node -e 'fetch("https://w3s.link/ipfs/<CID>").then(r => console.log(r.status))' ``` #### Layer 4: Onchain ```bash # Check Safe transaction status bun run validate:arbitrum-safe-live ``` --- ## Three-Strike Protocol After 3 failed fixes: 1. **STOP fixing** 2. **Document what you tried** 3. **Question assumptions** 4. **Consider alternatives** --- ## Output After debugging provide: ### Summary - Symptom and scope - Mode used ### Root Cause - Evidence-backed cause statement ### Actions - Fix applied (or recommended if report-only) ### Verification - Commands executed and outcomes ### Next Step - `DONE`, `NEEDS_INPUT`, or `ESCALATE` ## TDD Bugfix Mode (`/debug --mode tdd_bugfix`) Deterministic test-first bugfix loop. Use when reproducing and fixing a known bug. Required sequence: 1. **Reproduce** with a failing test (RED) 2. **Explain** root cause in one concise statement 3. **Fix** with minimal code change (GREEN) 4. **Verify** reproduction test passes 5. **Regression** — run broader suite: `bun run test && bun lint && bun run build` 6. **Report** with severity mapping (Critical/High → must-fix, Medium → should-fix, Low → nice-to-have) Anti-patterns for TDD bugfix: - Implementing without first reproducing in tests - Mixing unrelated refactors into bugfix commits - Skipping regression coverage after the initial fix passes ## Anti-Patterns - **Guessing without reproduction** — never change code before reproducing the issue - **Using destructive recovery commands** — avoid `git checkout -- .`, repo deletion, and forced resets in debug workflows - **Claiming success without evidence** — always attach commands and outputs for build/test verification - **Skipping dependency order checks** — shared/app/extension drift can hide root cause ## Related Skills - `error-handling-patterns` — Error categorization and handling strategies - `testing` — Writing regression tests after fixing bugs
Auf GitHub ansehen