debugging

Triage and repair blocked builds, failing tests, and runtime crashes in Pulse projects.

Updated Mar 27, 2026
One-click install
npx skills add https://github.com/quanpersie2001/pulse --skill debugging-quanpersie2001
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: debugging
Source: https://github.com/quanpersie2001/pulse/tree/main/plugins/pulse/skills/debugging
Command: npx skills add https://github.com/quanpersie2001/pulse --skill debugging-quanpersie2001

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill provides a disciplined, step-by-step debugging workflow to triage, reproduce, diagnose, and fix blocked work, build and test failures, runtime crashes, and integration issues in Pulse-managed projects, preventing guesswork and promoting auditable fixes.

Core Features & Use Cases

  • Structured Triage: Classify issues into build, test, runtime, integration, or blocker before investigating.
  • Scoped Learning Lookups: Prefer bead-local learning_refs and decision_refs, then perform targeted searches of .pulse memory (corrections, ratchet, critical patterns) only when needed.
  • Reproduce, Diagnose, Fix, and Report: Reproduce failures verbatim, narrow to a one-sentence root cause, choose fix strategy by size, verify with the original failing command, and notify coordinators via Agent Mail.
  • Use Case: Reproduce a flaky CI test, identify a recent commit that introduced a regression, create a fix bead where appropriate, verify the fix, and submit a debug note for compounding.

Quick Start

Triage the failing build in the current bead by classifying the failure, reproducing it locally, writing a one-line root cause, and proposing a verified fix with a brief report for Agent Mail.

Frequently Asked Questions about debugging

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

FAQPage Schema
How do I systematically debug a blocked build or failing test in a Pulse project?

To debug a blocked build or failing test, classify the failure type through structured triage, reproduce the error locally, write a one-line root cause, apply a fix, and verify with the original failing command before reporting.

What's the best way to reproduce a flaky CI test and find the root cause?

The best way to reproduce a flaky CI test is to run the original failing command verbatim, narrow the failure to a single-sentence root cause using git history and bead learning_refs, and verify the regression before proposing a fix.

How does scoped triage work for runtime crashes and integration failures?

Scoped triage for runtime crashes and integration failures classifies the issue first, then searches bead-local learning_refs and decision_refs before querying .pulse memory for critical patterns and corrections to guide disciplined repair.

Do I need access to git history and .pulse memory to diagnose build failures?

Yes, diagnosing build failures requires access to git history, bead learning_refs, and the repository's .pulse memory to perform targeted lookups and identify the commit or pattern that introduced the regression.

How do I report a verified fix after resolving a test failure or crash?

After verifying your fix for a test failure or crash with the original failing command, notify coordinators via Agent Mail and submit a debug note to create a fix bead for compounding.

Why should I use a structured debugging workflow instead of directly patching a failing build?

A structured debugging workflow prevents guesswork by requiring reproduction, disciplined triage, and targeted memory lookups before fixing a failing build, ensuring the repair is auditable and the root cause is documented.