sp-debugging

Traces software symptoms to verified root causes and authors worker-executable fix plans with exact paths and commands.

23|2|Updated Mar 1, 2026
One-click install
npx skills add https://github.com/tta-lab/ttal-cli --skill sp-debugging-tta-lab
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sp-debugging
Source: https://github.com/tta-lab/ttal-cli/tree/main/skills/sp-debugging
Command: npx skills add https://github.com/tta-lab/ttal-cli --skill sp-debugging-tta-lab

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve?

It helps teams stop random symptom-chasing by forcing a systematic bug diagnosis and producing a precise fix plan that a worker can execute without guessing.

Core Features & Use Cases

  • Root-cause-first diagnosis: ALWAYS trace from symptom to root cause using evidence, reproduction, recent changes review, and data-flow tracing.
  • Worker-ready plan writing: Convert the confirmed diagnosis into an implementation plan with exact file paths, before/after changes, test steps, commands, and commit messages.
  • Safety checkpoints against premature fixes: Requires alignment checkpoints before Phase 1 investigation and again before Phase 4 plan writing, and explicitly blocks “write solutions before understanding.”

Example use: you receive an error report or failing test output, perform investigation to identify where invalid data originated, then author a minimal change plan plus the exact failing test that demonstrates the fix.

Quick Start

Use sp-debugging to diagnose the bug described in the task, then output a Phase 4 fix plan with symptom, root cause, reproduction steps, implementation tasks (including exact files, failing/passing commands, and a ready-to-copy commit message).

Frequently Asked Questions about sp-debugging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I systematically diagnose test failures and error logs to find the root cause?

Systematically diagnose test failures and error logs by tracing symptoms back to verified root causes using evidence, reproduction, recent changes review, and data-flow tracing before writing any fix. This approach enforces investigation checkpoints to prevent premature implementation.

What is the best way to write an actionable fix plan for worker handoff in multi-component systems?

Writing an actionable fix plan for worker handoff in multi-component systems requires converting confirmed diagnoses into exact file paths, before/after changes, test commands, and commit messages. This structured output enables workers to execute fixes without guessing.

Why should I trace symptoms to root causes before writing code fixes?

Tracing symptoms to root causes before writing code fixes prevents random symptom-chasing and ensures evidence-driven decision making. Mandatory alignment pauses block solutions until investigation checkpoints confirm the verified root cause.

How do I create a minimal change plan that includes exact files and verification steps for debugging?

Create a minimal change plan for debugging by authoring a structured Phase 4 output that includes the symptom, root cause, reproduction steps, exact implementation tasks with file paths, failing and passing test commands, and verification steps.

Does this debugging workflow support multi-component systems with failing tests?

This debugging workflow fully supports multi-component systems with failing tests. It applies evidence-driven diagnosis workflows to trace invalid data origins across components and generates precise plans demonstrating the fix.

What are the limitations of fixing bugs without mandatory investigation checkpoints?

Fixing bugs without mandatory investigation checkpoints leads to random symptom-chasing and premature fixes. The absence of alignment pauses before investigation and plan writing risks implementing solutions before understanding the verified root cause.