signalproof-document

Create evidence-backed project documentation with provenance, version scope, and explicit non-claims.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Project documentation often drifts from reality: stale status gets copied forward, proposals read like implemented features, and polished prose hides weak evidence. This Skill produces durable documentation that accurately represents verified system state without inventing facts or flattening evidence classes. ## Core Features & Use Cases - Evidence-preserving drafting: Distinguishes artifact-backed, runtime-verified, human-observed, inferred, proposed, and unknown states so claims stay proportional to actual proof. - Typed document workflows: Provides structured guidance for handoffs, SOPs/runbooks, ADRs, release notes, READMEs, and acceptance/build reports. - Staleness and claim control: Binds documents to version, commit, artifact, and environment scope, and blocks inflated claims like treating compiled code as runtime-verified. - Use Case: After a release candidate passes verification, use this Skill to write release notes that state the exact build identity, verified behavior, limitations, rollback state, and explicit non-claims instead of generic marketing copy. ## Quick Start Use the signalproof-document skill to write a handoff document for the current project state based only on verified evidence, with open gates and non-claims listed explicitly.

Frequently Asked Questions about signalproof-document

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

FAQPage Schema
How do I write project documentation that stays accurate over time?▼

Bind each document to a version, commit, artifact, or milestone scope and point volatile status to canonical sources instead of duplicating it. Mark freshness or last-verified state so readers know the document's boundary.

How to write release notes without overstating what was verified?▼

State the exact release identity, verified behavior, limitations, compatibility, and rollback state, then list explicit non-claims. Keep distinctions like compiled versus runtime-verified and release-ready versus published.

What should a good engineering handoff document include?▼

Include the objective, current and protected state, accepted decisions, open gates, supporting evidence, recovery steps, next action, and non-assumptions. This lets another person continue work without mistaking inference for verified fact.

Can documentation replace verification or security review?▼

No. Documentation consumes governed evidence but does not manufacture authority; writing that something is secure or active does not make it so. Material factual claims should be routed to verification or investigation first.

When should documentation work be blocked or stopped?▼

Stop when canonical truth for a material statement is unknown or contradictory, when secrets or private data would leak, or when stale or candidate state would be presented as current and active.