instant-execution-discipline

Enforce immediate execution behavior when the user asks to implement/run/do something now. Use this skill to prevent delay between commitment and action, and...

Security Scan

The skill tells an agent to immediately launch tools, write local memory files, and post to external services (Obsidian/Discord) while not declaring any required credentials or config paths — this mismatch and the emphasis on automatic execution are concerning.

Purpose & Capability

The skill's name/description (force immediate execution) matches the instructions (launch tools/subagents, enforce start/progress/finish SLAs). However, the SKILL.md expects the agent to write to memory files, mirror to Obsidian, and report to Discord without declaring any required env vars, config paths, or permissions. That omission is an inconsistency between claimed capability and declared requirements.

Instruction Scope

Runtime instructions direct the agent to: trigger tools/subagents/cron immediately, send start/progress/completion signals on a strict cadence, write KPI records to memory/YYYY-MM-DD.md, mirror KPI blocks to an Obsidian daily note, and optionally post to Discord. It also instructs the agent not to ask the user to run commands unless 'blocked by unavoidable identity/auth constraints.' These instructions expand the agent's scope to file I/O and external posting and encourage autonomous execution without explicit user confirmation — this is scope creep and a potential safety concern.

Install Mechanism

Instruction-only skill with no install spec and no code files. No downloads or installers are present, so there is minimal installation risk.

Credentials

The SKILL.md references Obsidian and Discord posting and asks the agent to write memory files, but the skill declares no required environment variables, tokens, or config paths. External services (Obsidian vaults, Discord channels) normally require credentials/config; the absence of those declarations is disproportionate and unexplained, and could hide implicit expectations about agent privileges.

Persistence & Privilege

The skill instructs permanent behavioral changes (log entries in memory, 'apply a permanent rule update') and repeated cron/reporting behaviors. While it doesn't set always:true, its guidance to update mission rules and persist KPI logs means it can change the agent's persistent state and operational behavior — combined with the automatic execution instructions this increases risk.

What to consider before installing

This skill tells an agent to run actions immediately and to write/share execution evidence, but it doesn't declare any credentials or config paths for Obsidian/Discord or other services it mentions. Before installing, ask the publisher: (1) what exact tool/subagent permissions are required and where the skill will write files, (2) whether it will post to external services and what credentials are needed, and (3) whether the agent will require explicit user confirmation before executing non-trivial actions. If you consider using it, run in a sandbox or restrict the agent's tooling and network permissions, disable autonomous invocation or require user-invocable-only operation, and insist on audit/logging of any commands the agent runs. If you can't get those clarifications, treat the skill as risky and avoid installing it on agents that have access to sensitive systems or credentials.

When the user requests execution, run this protocol.

Protocol (strict order)

1. Start execution first.
   • Trigger tools/subagent/cron immediately before long explanations.
2. Send start signal within 90 seconds.
   • Format: 🔄 実行開始: <task>
3. Keep visibility during long work.
   • Send progress every 2–5 minutes.
   • Format: 🟡 進行中: <done>/<total> | blocker(if any)
4. Send completion within 60 seconds of finish signal.
   • Format: ✅完了 / ⚠️部分成功 / ❌失敗
   • Include: what changed, evidence, remaining items, next action.

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.

Quick templates

• Start:
  • 🔄 実行開始: <task>. 最小変更で適用する。
• Progress:
  • 🟡 進行中: <current step>. 問題: <none|brief>.
• Complete:
  • ✅ 完了: <result>. 変更: <files/config/jobs>. 次: <next>.

KPI logging add-on (for revenue/ops runs)

When the task is execution-heavy (publish/release/distribution):

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.

Funnel positioning (for ClawHub page + docs)

Use this skill when your agent has a conversion-sensitive workflow:

• paid content publishing
• product/skill release windows
• campaign distribution and post-release checks

Primary outcomes this skill should improve:

• faster time-to-first-action (TTFA)
• fewer "started but not finished" runs
• faster user-visible completion reporting

24h KPI checks (recommended)

Track these after each release:

1. SLA start rate: % runs with start signal <=90s
2. Finish integrity: % runs with evidence URLs/paths attached
3. Kickoff-only failure rate: runs ended without final outputs
4. Revenue-proxy conversion: CTA links added / clicked / downstream paid actions

Monetization packaging checklist (for ClawHub page)

Before each publish, ensure listing copy includes:

1. Immediate business outcome (faster shipping / fewer dropped tasks)
2. Clear operator steps (start/progress/finish format)
3. KPI proof points to measure value in 24h
4. Best-fit use cases (paid content, release windows, conversion funnels)

Discord reporting rule (for cron execution runs)

If a cron task explicitly requires Discord reporting:

1. include executed/result/next KPI in one compact completion block,
2. attach evidence pointers (URL/path/command output),
3. if direct sending is delegated by runtime, clearly note destination channel and message body draft.

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.