signalproof-build

Executes bounded implementation plans with protected state, verification gates, and recovery evidence.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents uncontrolled implementation work where AI-assisted changes silently expand scope, overwrite working baselines, skip verification, or claim success without evidence, leaving no way to review or roll back what was done. ## Core Features & Use Cases - Bounded Execution Contract: Confirms objective, protected state, authorized scope, acceptance criteria, and recovery path before any consequential change is made. - Checkpoint Verification & Partial-Actuation Containment: Verifies each meaningful change boundary and cleans up or preserves ownership of partially created resources when later gates fail. - Evidence-Backed Closure: Reports exact status (CANDIDATE PASS, ACCEPTED, PARTIAL, BLOCKED, REVERTED, STOP) with diffs, test results, and unverified gates stated honestly. - Use Case: You have an approved plan to modify a parser in a working codebase. This skill implements only the authorized change on an isolated branch, runs fixture tests at each checkpoint, preserves the known-good baseline, and closes with a full evidence report. ## Quick Start Ask the AI to implement the approved plan for your task using signalproof-build, preserving the current baseline and reporting verification evidence for each change.

Frequently Asked Questions about signalproof-build

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

FAQPage Schema
How do I implement an approved plan without scope creep?▼

Confirm the execution contract first: objective, protected state, authorized scope, acceptance criteria, and recovery path. Change only the smallest effective surface, and stop for a new decision if evidence requires material divergence from the plan.

How to verify code changes incrementally during implementation?▼

Run the cheapest relevant verification after each meaningful boundary changes, such as fixture tests for parser changes or contract tests for API changes. Treat a failed checkpoint as evidence and never bury it under additional changes.

What happens when a build step partially succeeds then fails?▼

The partial-actuation rule requires preserving the identity of the created resource, attempting cleanup only within scoped ownership, and verifying cleanup before clearing state. If cleanup cannot be verified, the failure is reported as unresolved with recoverable ownership retained.

When should implementation stop instead of continuing?▼

Stop when work would change protected state, expand scope, cross an authority boundary, or invalidate the recovery or acceptance model. Continuing after such evidence is classified as a STOP status, returning to planning or human decision.

Can a build be declared successful from compile checks alone?▼

No. Static validation, compilation, automated tests, runtime behavior, and release acceptance are distinct evidence gates. A build that compiles but cannot be runtime-tested must be reported as PARTIAL / UNVERIFIED, not accepted.