other
- Location
SKILL.md:382- Finding
Mandatory Destructive Deletion Without Recovery Safeguards
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:382-391
Vulnerability Type: Unsafe destructive operation
Risk Level: MediumVulnerable Code
markdown Write skill before testing? Delete it. Start over. Edit skill without testing? Same violation. **No exceptions:** - Not for "simple additions" - Not for "just adding a section" - Not for "documentation updates" - Don't keep untested changes as "reference" - Don't "adapt" while running tests - Delete means deleteTechnical Analysis
The skill unconditionally instructs an agent to delete work created or edited before testing. It does not require the agent to:
- Obtain explicit user authorization.
- Confirm the exact files or changes within scope.
- Inspect version-control status.
- Preserve uncommitted work in a patch, branch, or backup.
- Preview the proposed deletion.
- Confirm that recovery is possible.
The supporting guide reinforces the same behavior in
testing-skills-with-subagents.md:186-198, increasing the likelihood that an agent will treat deletion as mandatory even under pressure.Although this is not malicious code and does not map directly to one of the T01–T09 attack categories, it is an unsafe operational instruction capable of causing irreversible data loss.
Attack Path
- The skill is loaded while an agent is creating or editing a skill.
- The agent determines that existing work was written before a failing test was recorded.
- The mandatory “Delete it” and “No exceptions” instructions are applied.
- The agent deletes files or uncommitted modifications without first requesting approval or creating a recoverable copy.
- If the work is not committed or backed up, the user cannot reliably restore it.
Impact Assessment
The instruction does not grant additional system privileges. Its impact is limited to files writable by the running agent, but that scope may include the entire active workspace.
A successful occurrence could result in:
- Loss of leg ...[truncated 375 chars]
- Remediation
View remediation
Remediation Suggestions
Replace unconditional deletion with a reversible rollback procedure:
- Require explicit user approval before deleting or reverting any existing work.
- Identify and display the exact files and changes proposed for removal.
- Inspect version-control status and distinguish committed, uncommitted, staged, and untracked content.
- Preserve affected work in a patch, backup, stash, or dedicated branch before rollback.
- Prefer reverting only the relevant changes instead of deleting complete files.
- Provide a dry-run or diff and request confirmation before execution.
- Refuse broad or ambiguous deletion operations until their scope is clarified.
- Document a tested restoration procedure.
A safer replacement would be:
markdown If implementation or documentation was written before its required failing test, pause and report the affected changes. With explicit user approval, preserve them in a patch or backup branch, verify restoration, and then revert only the relevant changes before restarting the TDD cycle. Never delete uncommitted work without confirmation and a recovery path.