signalproof-investigate

Diagnose failures by localizing the failed layer and cause before proposing fixes.

Updated Aug 15, 2026
One-click install
npx skills add https://github.com/docreo/Signalproof-Skills --skill signalproof-investigate-docreo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: signalproof-investigate
Source: https://github.com/docreo/Signalproof-Skills/tree/main/skills/signalproof-investigate
Command: npx skills add https://github.com/docreo/Signalproof-Skills --skill signalproof-investigate-docreo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When something appears broken, teams often rewrite working systems based on guesses. This Skill enforces evidence-based root-cause investigation so failures are localized to the correct layer before any change is made, protecting working state and preventing shotgun fixes. ## Core Features & Use Cases - Layer Classification: Separates symptoms into execution, persistence, data, interpretation, presentation, environment, dependency, permission, or expectation-mismatch domains. - Hypothesis Tracking: Maintains a table of hypotheses with evidence for/against, discriminating tests, and confidence, retiring disproven theories. - Protected-State Discipline: Declares what must not change during diagnosis and prefers read-only evidence gathering first. - Structured Decisions: Returns explicit outcomes such as CAUSE SUPPORTED, LAYER LOCALIZED, NO FAILURE REPRODUCED, EXPECTATION MISMATCH, BLOCKED, or STOP. - Use Case: A UI banner stays blank after a scan. Instead of rewriting the scanner, the investigation shows records were written correctly, localizing the failure to the presentation layer before any bounded fix. ## Quick Start Ask the AI to investigate why a reported failure occurred, localizing the failed layer and cause with evidence before proposing any fix.

Frequently Asked Questions about signalproof-investigate

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

FAQPage Schema
How do I investigate a software failure before fixing it?▼

Start by recording the expected versus observed behavior, then gather read-only evidence such as logs, configuration, and state. Classify the symptom into a failure layer, form explicit hypotheses, and test the cheapest discriminating hypothesis before making any change.

What is root-cause investigation in debugging workflows?▼

Root-cause investigation localizes which system layer actually failed—execution, persistence, data, presentation, environment, dependency, permission, or expectation—using evidence rather than appearance. It prevents rewriting working subsystems based on misleading symptoms.

How do I avoid shotgun debugging when something breaks?▼

Avoid changing multiple unrelated surfaces at once. Maintain a hypothesis table with evidence for and against each theory, run discriminating tests that distinguish competing causes, and retire disproven hypotheses instead of repeating failed fixes.

When should I stop an investigation instead of continuing to fix?▼

Stop when repeated correction attempts fail without new evidence, when a test would disturb protected state without authority, or when required evidence or environment access is unavailable. The investigation then returns a BLOCKED or STOP decision with documented reasoning.

Why does a fix sometimes not resolve the reported problem?▼

Often the wrong layer was modified—for example, rewriting execution logic when the failure was in presentation or persistence. Localizing the failed layer with evidence first ensures the bounded correction targets the actual cause.