Release Discipline

• Outcome: Review
• Latest audit: Sep 10, 2026 · 7:48 PM UTC
• Version: 1.0.0

Overview

This skill is a release checklist, but it can broadly interrupt releases, inspect loosely scoped information, and persist release decisions without clear user control.

Install this only if you want the agent to act as a strict release gatekeeper. Before using it, define the current repository/account scope, decide whether the release log may be written at all, and require confirmation before the agent blocks a release or reads user messages, principles files, or external service data.

A.I.G

Vulnerability Patterns

• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T01 · Skill Instruction Hijacking

Error

• Location: SKILL.md:15
• Finding: Mandatory Release Workflow Interception and Veto<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 15 and 75–76 **Vulnerability Type**: `T01: Skill Instruction Hijacking` **Risk Level**: High ### Vulnerable Code ```text Intercept any release/publish/deploy action and run the pre-release checklist. ``` ```text 🛑 BLOCKED (any) → Cannot release. Fix the issue first. ⚠️ WARNING only → Can release, but agent must voice concern clearly. ``` ### Technical Analysis The Skill instructs the Agent to intercept every release, publishing, deployment, or version-bump action. It then asserts mandatory veto authority whenever any Skill-defined blocking condition is met. This behavior goes beyond providing an optional quality checklist. It alters the Agent's current-session goals and decision-making authority by requiring the Agent to replace the user's requested workflow with the Skill's policy. The phrase “Cannot release” directs the Agent to deny an operation even when the authenticated user explicitly requested it. ### Attack Path 1. The Skill is installed or loaded into an Agent session. 2. A user requests a release, publication, deployment, or version bump. 3. The Skill intercepts the request and forces execution of its six-gate checklist. 4. Any Skill-defined blocking condition causes the Agent to refuse the requested operation. 5. The user must satisfy policy imposed by the Skill before the Agent will proceed. ### Impact Assessment The issue affects release-related operations in the current Agent session. It can prevent or delay legitimate publishing and deployment workflows and override user intent through Skill-controlled policy. The text does not grant operating-system privileges or directly execute code. Its impact is control over the Agent's release workflow and responses rather than host compromise. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace mandatory interception with an optional pre-release assessment. 2. State explicitly that the checklist is advisory and subordinate to the user's current authorized instructions. 3. Replace “Cannot release” with language such as “Report the failed checks and ask the user whether to continue.” 4. Require explicit user confirmation before cancelling, delaying, or modifying a release operation. 5. Scope activation narrowly to requests where the user specifically asks for a release-readiness review. 6. Ensure warnings do not prevent execution when an authorized user knowingly accepts the documented risk. ]]>

T02 · Agent Memory Poisoning

Error

• Location: SKILL.md:82
• Finding: Persistent Release Policy State Written to Agent Memory<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 82–99 **Vulnerability Type**: `T02: Agent Memory Poisoning` **Risk Level**: High ### Vulnerable Code ```markdown After every release (approved or blocked), log to `memory/release-log.md`: ```markdown ## {date} — v{version} - Status: ✅ APPROVED / 🛑 BLOCKED / ⚠️ WARNED - Gates: [1:✅ 2:⚠️ 3:✅ 4:✅ 5:✅ 6:✅] - Reason: {why released or why blocked} - User feedback on previous: {summary or "none"} - Time since last release: {hours} ``` ## Weekly Review Every 7 days, review the release log: - Total releases this week - Block rate (healthy: 20-40% blocked = you're actually checking) - 0% blocked = checklist is rubber-stamping, tighten criteria - Pattern analysis: recurring issues ``` ### Technical Analysis The Skill requires the Agent to write release decisions, user-feedback summaries, and timing information to `memory/release-log.md`, including when a release is blocked. It then directs future reviews to consume this persistent state and modify decision criteria when the recorded block rate is considered too low. The instruction therefore extends the Skill's influence beyond the initiating request. The stored records become policy inputs for later sessions, while the directive to “tighten criteria” can make future Agent behavior increasingly restrictive based on a target block rate rather than the merits of each release. ### Attack Path 1. A release-related request activates the Skill. 2. The Agent evaluates the request according to the Skill's policy. 3. The Agent writes the outcome, reasons, user-feedback summary, and timing information to `memory/release-log.md`. 4. The persistent file remains available after the original interaction ends. 5. A later weekly review reads the accumulated state. 6. If no releases were blocked, the Skill instructs the Agent to tighten future criteria. 7. Subsequent release decisions are influenced by persistent Skill-controlled state. ### Impact Assessmen ...[truncated 440 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not write to Agent memory by default. 2. Obtain explicit and informed user consent before creating or updating any persistent release log. 3. Prefer a clearly identified, project-local audit file over general Agent memory. 4. Allow the user to configure retention, redaction, review, and deletion of stored records. 5. Avoid persisting user-message or feedback content unless necessary; store minimal aggregate information instead. 6. Remove behavioral directives based on a target block rate, including “tighten criteria.” 7. Evaluate each release independently against user-approved requirements. 8. Treat stored records as informational history, not as instructions that supersede current user intent. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:31
• Finding: Overbroad Inspection of User Messages and Agent Principle Files<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 31 and 63 **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Medium ### Vulnerable Code ```text → Check: GitHub issues, npm downloads, ClawHub installs, user messages ``` ```text → Read SOUL.md (or equivalent principles file) ``` ### Technical Analysis The Skill directs the Agent to inspect “user messages” and to locate `SOUL.md` or an unspecified equivalent principles file. It does not define repository, account, conversation, directory, or authorization boundaries for these searches. Because the requested data sources are open-ended, an Agent with broad tool access may inspect unrelated private conversation content or identity/configuration files that are not necessary for the release task. Information derived from these sources may also be included in the persistent release log required elsewhere in the Skill. The project does not contain a direct credential-theft or exfiltration instruction. The risk arises from unnecessary and insufficiently scoped access to potentially sensitive resources. ### Attack Path 1. A release request activates the feedback and self-contradiction checks. 2. The Agent searches available sources for GitHub activity, package usage, ClawHub activity, and “user messages.” 3. The Agent searches for `SOUL.md` or files it considers equivalent. 4. Without explicit scope restrictions, the search can reach unrelated conversations or Agent configuration files. 5. The Agent uses the retrieved information to approve or block the release. 6. A summary of the information may be written to `memory/release-log.md`. ### Impact Assessment The issue can expose private message content, behavioral principles, or Agent configuration to a task that does not require that level of access. The affected scope depends on the files, conversations, accounts, and tools available to the Agent. No evidence shows acquisition of new operating-sy ...[truncated 203 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Restrict checks to repository paths and external accounts explicitly approved by the user. 2. Replace “user messages” with a narrowly defined source, such as release feedback supplied in the current conversation. 3. Do not inspect private conversations without separate, informed consent. 4. Require an explicit path for any principles file instead of searching for “equivalent” identity or configuration files. 5. Apply data minimization and retrieve only information directly necessary for the current release assessment. 6. Prevent sensitive source content from being copied into persistent logs; use redacted summaries where storage is authorized. 7. Ask the user for missing evidence rather than autonomously expanding the search scope. ]]>

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Vague Triggers

Medium

• Confidence: 93% confidence
• Finding: The trigger list includes very broad terms such as "release," "publish," "deploy," and "version," which can cause the skill to activate in many contexts beyond package/software release control. In an agent environment, over-broad activation can override user intent, create denial-of-service-like friction, and cause the agent to read or write files such as release logs when not appropriate.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: The instruction to "Intercept any release/publish/deploy action and run the pre-release checklist" lacks scope boundaries, authorization checks, and context validation. This can let the skill insert itself into unrelated workflows, block legitimate operations, or pressure the agent into accessing external services and local files (for example GitHub issues, npm downloads, SOUL.md, and memory/release-log.md) without confirming necessity or user approval.

Static analysis

No suspicious patterns detected.