$ loading_
Systematically investigate bugs, test failures, and unexpected behavior before fixing.
The material indicates this skill is essentially a debugging methodology/prompt with no declared secrets, remote endpoints, or standalone system privileges. Overall risk is low, but supply-chain confidence is limited by very low community adoption and unknown maintenance status.
The material explicitly states that no keys or environment variables are required; secrets/IDENTITY appear only as debugging examples in the README, with no indication that the skill collects, stores, or exfiltrates credentials.
No remote endpoints are declared, and the system flags it as prompt-only; based on the material, there is no evidence of active networking or sending user data to external services.
As a Skill marked prompt-only, the material itself does not have the ability to spawn local processes or execute code; the bash/security/codesign commands in the README are debugging examples, not evidence of automatic execution by the tool.
No filesystem, database, or other resource access interfaces are described; although it suggests reviewing errors, diffs, and environment variables, that is troubleshooting guidance for the user/model rather than intrinsic read/write permissions of the skill itself.
Positive factors include being open-source on GitHub and auditable; however, the repository has 0 stars, no declared license, and unknown maintenance status, so community validation and maintenance signals are weak. Review provenance and update status before using it in production workflows.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "systematic-debugging" skill from askskill: 1. Download https://raw.githubusercontent.com/obra/superpowers/main/skills/systematic-debugging/SKILL.md 2. Save it as ~/.claude/skills/systematic-debugging/SKILL.md 3. Reload skills and tell me it's ready
A unit test started failing unexpectedly. Don’t propose a fix yet. Use a systematic debugging approach to analyze possible cause categories, evidence to collect, minimal reproduction steps, debugging priority, and how to narrow the scope. Here are the error logs and relevant code: ...
A structured investigation plan with hypotheses, validation steps, reproduction steps, and prioritized next actions.
A production service shows intermittent errors and slower responses. Don’t suggest code changes yet. Follow a systematic debugging process and outline the symptom definition, possible blast radius, metrics and logs to inspect, investigation branches, and how to determine whether the issue is caused by configuration, dependencies, data, or code. Context: ...
A production-focused diagnostic checklist to quickly bound the issue and identify the most likely root cause.
My data processing script produces results that differ greatly from expectations. Without giving the final fix, systematically analyze how to inspect input data, transformation logic, edge cases, environment differences, and dependency versions, then provide a step-by-step validation plan. Here are the script and sample data: ...
A layered debugging framework specifying how to inspect each issue category, in what order, and what evidence to gather.
Random fixes waste time and create new bugs. Quick patches mask underlying issues.
Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
Violating the letter of this process is violating the spirit of debugging.
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
If you haven't completed Phase 1, you cannot propose fixes.
Use for ANY technical issue:
Use this ESPECIALLY when:
Don't skip when:
You MUST complete each phase before proceeding to the next.
BEFORE attempting ANY fix:
Read Error Messages Carefully
Reproduce Consistently
Check Recent Changes
Gather Evidence in Multi-Component Systems
WHEN system has multiple components (CI → build → signing, API → service → database):
BEFORE proposing fixes, add diagnostic instrumentation:
For EACH component boundary:
- Log what data enters component
- Log what data exits component
- Verify environment/config propagation
- Check state at each layer
Run once to gather evidence showing WHERE it breaks
THEN analyze evidence to identify failing component
THEN investigate that specific component
Example (multi-layer system):
# Layer 1: Workflow
echo "=== Secrets available in workflow: ==="
echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
# Layer 2: Build script
echo "=== Env vars in build script: ==="
env | grep IDENTITY || echo "IDENTITY not in environment"
# Layer 3: Signing script
echo "=== Keychain state: ==="
security list-keychains
security find-identity -v
# Layer 4: Actual signing
codesign --sign "$IDENTITY" --verbose=4 "$APP"
This reveals: Which layer fails (secrets → workflow ✓, workflow → build ✗)
Trace Data Flow
WHEN error is deep in call stack:
See root-cause-tracing.md in this directory for the complete backward tracing technique.
Quick version:
Find the pattern before fixing:
Find Working Examples
Compare Against References
Identify Differences
Understand Dependencies
Scientific method:
…
Execute implementation plans by splitting and advancing independent tasks in-session.
Create, revise, and validate AI skills before deployment.
Helps decide merge, PR, or cleanup steps after branch work is complete.
Turn requirements into a clear step-by-step execution plan before implementation.
Set conversation rules to discover and invoke skills before replying.
Clarify intent, requirements, and solution direction before any creative implementation work.
Systematically investigate bugs before fixing them with a four-phase debugging framework.
Systematically triage failures and fix broken builds or unexpected runtime issues.
Debug issues with a four-phase method that finds root causes before fixes.
Systematically reproduce, isolate, diagnose, and fix tricky software or environment issues.
Create debug tests and iterate to reliably reproduce and diagnose tricky bugs.
Trace bugs backward through call stacks to find the original trigger.