signalproof-cleanup

Verifies resource ownership before removing artifacts left by failed operations.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Failed or partial operations leave behind processes, files, locks, ports, and registrations that are risky to delete blindly. This Skill prevents accidental destruction of unrelated resources by requiring verified ownership identity before any cleanup action. ## Core Features & Use Cases - Ownership Verification: Preserves and re-checks strong identity signals such as PID plus start identity, service/task identity, lock tokens, exact paths, and registration IDs before destructive action. - Bounded Cleanup Scope: Removes only the owned boundary of the failed operation and refuses to broaden cleanup when a narrow attempt fails. - Explicit Status Tracking: Classifies resources as NOT PRESENT, PRESENT/OWNED, PRESENT/EXTERNAL, OWNERSHIP UNKNOWN, CLEANED/VERIFIED, or CLEANUP PARTIAL, with STOP conditions and handoff to Recovery Continuity. - Use Case: A deployment script crashes after starting a service and creating temp files. Use this Skill to confirm which resources the script actually owns, clean only those, and preserve evidence for anything unresolved. ## Quick Start Use the signalproof-cleanup skill to safely clean up the resources left behind by my failed deployment run without touching anything else.

Frequently Asked Questions about signalproof-cleanup

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

FAQPage Schema
How do I safely clean up resources after a failed operation?▼

Identify the operation that created each resource, preserve the strongest ownership identity available such as PID plus start identity or lock tokens, then re-verify identity before any destructive action. Remove only the owned boundary and verify cleanup before clearing recovery state.

How to avoid deleting the wrong process or file during cleanup?▼

Never destroy a resource merely because its name, PID, path, or port looks familiar. Verify ownership first using strong identity signals, and treat resources as PRESENT/EXTERNAL or OWNERSHIP UNKNOWN when identity cannot be confirmed.

What happens when resource ownership cannot be verified?▼

The Skill enters a STOP condition when ownership cannot be distinguished from an external resource or identifier reuse is plausible. Unresolved state and failure evidence are preserved and handed off to Recovery Continuity instead of forcing cleanup.

When should cleanup stop instead of retrying?▼

Stop when destructive scope would exceed the failed operation's owned boundary, when identifier reuse is plausible and not rechecked, or when a cleanup failure is being hidden by dropping the ownership record. A failed narrow attempt never justifies broadening cleanup.

What are the limitations of automated post-failure cleanup?▼

Cleanup requires authority appropriate to the resource and cannot proceed safely without verifiable ownership identity. Resources with ambiguous provenance must remain untouched and escalated rather than removed, so full automation is not always achievable.