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'.

Datos de origen

Repositorio
greenpill-dev-guild/coop
Última actividad en el origen
17 de mayo de 2026 a las 03:22
Idioma detectado de SKILL.md
inglés
Estrellas
3
Forks
1

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
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
Ver en GitHub