instant-execution-discipline

• Outcome: Review
• Latest audit: Sep 11, 2026 · 1:09 AM UTC
• Version: 0.1.6

Overview

The skill is openly designed to make agents act faster, but it also tells them to run tools immediately and permanently change memory or rules without clear user approval.

Install only if you are comfortable with an agent taking a strong execution-first posture. Before using it for publishing, releases, cron jobs, Discord reporting, or business workflows, add explicit confirmation gates, disable automatic MISSION or skill self-modification, and decide whether KPI data may be written to memory or Obsidian.

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
• 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
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs

Findings (2)

T02 · Agent Memory Poisoning

Error

• Location: SKILL.md:46

Finding

Persistent Agent-State Poisoning Through Automatic Rule and Memory Modification

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 46–51 and 89–93
Vulnerability Type: Persistent memory and behavioral-rule modification
Risk Level: High

Vulnerable Code

markdown

1. Record KPI in `memory/YYYY-MM-DD.md`
   - `executed`: what shipped
   - `result`: measurable outcome (URL/count/status)
   - `next`: one concrete optimization
2. Mirror the same KPI block to Obsidian daily note.
3. Include KPI in the completion message.

markdown

## Postmortem rule

If a delay occurs, immediately:
1. acknowledge miss,
2. apply a permanent rule update (MISSION or this skill),
3. log the change in `memory/YYYY-MM-DD.md`.

Technical Analysis

The skill directs the agent to write task-derived information into persistent memory and an Obsidian daily note. More critically, it requires the agent to apply a permanent update to MISSION or the skill whenever a delay occurs.

The content and boundaries of that permanent update are not defined. There is no requirement to obtain user approval, present a proposed diff, validate task-derived content, or constrain changes to a safe schema. Consequently, instructions or other content originating from an untrusted task can be incorporated into files that influence later agent sessions.

This is a persistent state-poisoning condition rather than ordinary operational logging. Changes to MISSION or the skill can alter future agent behavior after the original task has ended.

Attack Path

1. An attacker supplies a task containing adversarial instructions or content intended to influence future behavior.
2. The task experiences or appears to experience a delay.
3. The postmortem rule requires the agent to make a permanent update to MISSION or the skill.
4. The agent incorporates task-derived content into that update without mandatory review or sanitization.
5. The modified file or persistent memory is loaded during future session ...[truncated 1034 chars]

Remediation

View remediation

Remediation Suggestions

1. Remove the instruction to modify MISSION or the skill automatically.
2. Require explicit user authorization before changing any persistent behavioral configuration.
3. Present the exact target file and proposed diff before applying an approved rule change.
4. Store postmortem observations in a dedicated append-only operational log rather than executable or instruction-bearing files.
5. Make KPI logging opt-in and document every destination receiving the data.
6. Use a fixed structured schema and reject instruction-like fields, markup, or unbounded task content.
7. Apply destination allowlists and least-privilege filesystem permissions.
8. Avoid mirroring data to Obsidian unless the user has explicitly enabled that integration.
9. Separate untrusted task data from trusted instructions when persistent records are later loaded.
10. Add review, rollback, provenance, and audit mechanisms for all persistent configuration changes.

T01 · Skill Instruction Hijacking

Warning

• Location: SKILL.md:11

Finding

Execution-First Policy Can Trigger Unvalidated or Duplicate External Actions

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 11–15 and 25–34
Vulnerability Type: Unsafe instruction-level execution policy
Risk Level: Medium

Vulnerable Code

markdown

## Protocol (strict order)

1. Start execution first.
   - Trigger tools/subagent/cron immediately before long explanations.
2. Send start signal within 90 seconds.

markdown

## Hard rules

- Do not say "I will do it" without actually launching execution.
- Do not delay execution for planning text unless safety-critical.
- Do not ask user to run commands unless blocked by unavoidable identity/auth constraints.
- If blocked, report exact blocking layer and propose only design/permission change.
- Do not treat a kickoff/progress message as completion.
- For subagent runs, verify final outcome (published count / URLs / blockers) before reporting done.
- If a run ends with kickoff-only output, immediately relaunch with explicit "finish-required" constraints.

Technical Analysis

The skill prioritizes immediate invocation of tools, subagents, or cron jobs before ordinary planning. It also requires an immediate relaunch if a prior run returns only kickoff output.

Although the text contains a general safety-critical exception, it does not require the agent to verify authorization, execution scope, target identity, expected side effects, idempotency, cost, or rollback capability before acting. It also does not distinguish reversible local operations from publishing, release, financial, communication, or scheduling actions.

Automatic relaunch is especially unsafe for operations whose completion status is uncertain. A run may have performed its external side effect but failed to return final evidence because of a timeout or reporting failure. Relaunching in that state can repeat the action.

Attack Path

1. A user or attacker submits a broadly worded request involving publishing, distribution, release, ...[truncated 1356 chars]

Remediation

View remediation

Remediation Suggestions

1. Replace “start execution first” with a mandatory pre-execution validation phase.
2. Verify the requested target, scope, authorization, expected side effects, and rollback method before invoking tools.
3. Require explicit confirmation for destructive, costly, financial, publishing, communication, release, or scheduled operations.
4. Classify operations as read-only, reversible, or irreversible and apply controls appropriate to each class.
5. Permit automatic retries only when the operation has a stable idempotency key or has been proven idempotent.
6. Before relaunching, query the external system to determine whether the first operation actually completed.
7. Set retry limits and require human review when completion status remains ambiguous.
8. Separate status-message timing requirements from authorization and safety decisions.
9. Record execution identifiers and external result identifiers so duplicate operations can be detected.
10. Make cron creation and subagent delegation subject to the same authorization checks as direct execution.

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Memory Poisoning: Persistent Context Injection, Context Window Stuffing, Memory Manipulation
• 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

Findings (5)

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The activation trigger is very broad: 'When the user requests execution, run this protocol' can match many ordinary requests and push the agent into immediate-action behavior without explicit confirmation or scope checks. In context, that increases the chance of unintended tool use or premature side effects because the skill prioritizes acting before clarifying ambiguous requests.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 96% confidence

Finding

The prescribed start, progress, and completion formats use Japanese text such as "実行開始" and "進行中" as mandatory output templates. This imposes a specific language on users without opt-in, which is a natural-language policy concern unless the locale constraint is explicitly justified.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium

• Category: Excessive Agency
• Confidence: 91% confidence

Finding

The rule set pushes the agent toward autonomous execution and specifically discourages asking the user to run commands or pausing for planning unless 'safety-critical.' In this skill's context, that materially increases risk because it biases the agent toward acting with limited confirmation, which can lead to unauthorized changes, mistaken executions, or use of powerful tools without adequate user validation.

Content

Scanner excerpt · SKILL.md (reported line 27)May include surrounding context.

md

- Do not say "I will do it" without actually launching execution.
- Do not delay execution for planning text unless safety-critical.
- Do not ask user to run commands unless blocked by unavoidable identity/auth constraints.
- If blocked, report exact blocking layer and propose only design/permission change.
- Do not treat a kickoff/progress message as completion.
- For subagent runs, verify final outcome (published count / URLs / blockers) before reporting done.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The skill instructs the agent to persist KPI data to local memory files and mirror it into Obsidian, but it does not require user consent, data minimization, or sensitivity checks. This can silently store operational details, URLs, outcomes, or potentially sensitive business information in persistent locations beyond the immediate task context.

Content

No source excerpt is available for this finding.

Persistent Context Injection

Medium

• Category: Memory Poisoning
• Confidence: 95% confidence

Finding

The instruction to 'apply a permanent rule update (MISSION or this skill)' creates a persistent context injection path, allowing runtime events to modify long-lived agent behavior. This is dangerous because temporary task conditions or adversarial prompts could be transformed into durable operating rules, causing future sessions to inherit unsafe behavior without fresh review.

Content

Scanner excerpt · SKILL.md (reported line 92)May include surrounding context.

md

If a delay occurs, immediately:
1. acknowledge miss,
2. apply a permanent rule update (MISSION or this skill),
3. log the change in `memory/YYYY-MM-DD.md`.

Static analysis

No suspicious patterns detected.