kmg-execute-plan

name	kmg-execute-plan
description	Enforce zero-deviation plan execution when user invokes plan implementation

Skill: kmg-execute-plan

Purpose: Enforce zero-deviation plan execution when user invokes plan implementation.

Trigger Keywords:

• "execute plan"
• "implement plan"
• "start [plan-file]"
• Reference to docs/plans/*.md file in conversation
• Any mention of explicit plan-based execution

Platform Guard (checked before anything else below): This skill is scoped to Gemini running in Antigravity — it was written as a drift-guardrail for that platform specifically (Gemini would go off-rails/tangent without a heavy strict-mode protocol). It is NOT intended for Claude Code or any other ECC platform.

Before surfacing the STRICT EXECUTION MODE banner, determine whether the current session is running under Gemini/Antigravity:

• If the runtime does not self-identify as Gemini/Antigravity (e.g., this is a Claude Code session): do NOT surface the banner or run the 8-step protocol below. Instead output:

  kmg-execute-plan is scoped to Gemini/Antigravity sessions only (it was written as a
  drift-guardrail for that platform). This session is running under a different platform —
  use superpowers:executing-plans or superpowers:subagent-driven-development instead, per
  the plan file's own "REQUIRED SUB-SKILL" header.
  

  Then stop — do not proceed to any step below.

• If the runtime is Gemini/Antigravity: proceed exactly as documented below, unchanged.

No confirmed platform/runtime marker was found in this repo to detect "is this Gemini/Antigravity" directly (see issue-12 for the investigation). Fallback heuristic: Claude Code sessions can self-identify as Claude Code; treat "self-identifies as Claude Code" (or any other non-Gemini/Antigravity ECC platform) as the exclusion trigger — asymmetric by design, since a false negative (occasionally not firing for a genuine Gemini/Antigravity session) is far cheaper than the false positive this guard exists to prevent (firing wrongly inside Claude Code and driving an entire plan execution under the wrong protocol, as happened live during this branch's own c0 execution).

Behavior: When triggered, surface the STRICT EXECUTION MODE banner and enforce the 8-step protocol:

═══════════════════════════════════════════════════════════════
STRICT EXECUTION MODE
Allowed Tools: File read, file edit, file write, shell (verification only)
Forbidden: Improvements, assumptions, gap-filling, unauthorized fixes
═══════════════════════════════════════════════════════════════

ECC Compatibility Note: This skill is intentionally scoped to Gemini/Antigravity sessions, where it originated as a drift guardrail (.agent/workflows/gov-execute-plan.md). On Claude Code and other ECC platforms, this skill should not fire at all — see the Platform Guard above. If ported to a new platform in the future where an equivalent guardrail is genuinely needed, treat this file as a template to adapt for that platform, not a skill to broaden in place to cover multiple platforms at once.

Prerequisite Check — Step 6.4 Sync Verification: Before implementing any ENH or issue in scope, verify that Step 6.4 (ROADMAP + CHANGELOG sync) was completed for each item. This check fires at implementation start, not at issue-tracking completion.

For each ENH/issue in the plan:

1. Check whether Step 6.4 was completed (ROADMAP entry added, CHANGELOG entry added).
2. If Step 6.4 was skipped for any item, surface the following prompt and wait for user response before proceeding:

⚠️  PREREQUISITE CHECK — Step 6.4 Not Completed
Before implementing [ENH-NNN / issue-N], Step 6.4 (ROADMAP + CHANGELOG sync) was not completed.

Options:
  [C] Complete now — run ROADMAP + CHANGELOG sync inline, then proceed
  [S] Skip — proceed without sync (your choice; noted in commit message)
  [X] Cancel — abort implementation

Enter choice (C / S / X):

3. Complete now (C): Run the ROADMAP + CHANGELOG sync inline (update the relevant ROADMAP entry and CHANGELOG entry for the item), then continue with implementation.
4. Skip (S): Proceed with implementation. Note the skipped sync in the commit message.
5. Cancel (X): Abort implementation. Output: HALT — Implementation cancelled. Complete Step 6.4 before retrying.

This check runs once per item, before the first edit for that item.

Prerequisite Check — In-Plan Cascade Review: Before executing, check for ADR capture flag:

ADR_FLAG="/tmp/kmgraph-adr-captured-$(date +%Y-%m-%d).flag"

If flag EXISTS:

1. Review the plan tasks below.
2. Ask the user: "A new decision was captured this session. Do any plan tasks need revision before executing?"
3. Wait for user response before proceeding.
4. If tasks need revision: update the plan, then continue.
5. If no revision needed: proceed.

If flag ABSENT: skip this check and proceed normally.

Detection mechanism: flag file written by adr-guide after successful ADR creation. Day-scoped via $(date +%Y-%m-%d) — consistent with existing kmgraph-plan-gate pattern. No model self-tracking required.

Subagent fallback: If kmg-execute-plan is somehow invoked as a subagent with the flag present (parent failed to gate), output: "Parent must resolve in-plan cascade before dispatching subagents. HALT." Do not attempt to prompt the user — subagents have no interaction channel.

Protocol Steps:

1. State Initialization — Output STRICT EXECUTION MODE banner before any action
2. Literal Mapping — Quote each plan instruction before executing (literal mapping, no assumptions)
3. Data Integrity Audit — Read file after every edit to verify ONLY plan-specified changes were made. Revert if unauthorized additions found.
4. HALT on Ambiguity — Output HALT block if plan is unclear. Stop and ask user for clarification.
5. Checkpoints — After every 3 file edits, output checkpoint and await user acknowledgment before continuing.
6. Rollback Protocol — If integrity audit fails, revert file and re-apply change. If second attempt fails, trigger HALT.
7. Completion Verification — Quote each success criterion and verify it. Output completion status.
8. Commit Gate — After all tasks complete, create conventional commit with issue reference.

Source: Adapted from .agent/workflows/gov-execute-plan.md (now kmg-execute-plan)

Key Constraint: "No improvements" — even if you spot bugs, better implementations, or missing error handling, DO NOT FIX unless explicitly in the plan.

Example Trigger:

User: "Let's execute the v0.0.10.1 plan from docs/plans/v0.0.10.1-alpha-skills-and-agents.md"

Assistant Response: Output STRICT EXECUTION MODE banner and follow 8-step protocol.

v0.2.1 Decision Note — Agent Dispatch Evaluation: Agent dispatch was evaluated and rejected for this skill. Rationale:

• This skill is a behavioral constraint, not a delegatable task — it modifies how the main assistant operates, not what a subagent does
• The protocol requires full conversation context — the assistant must see the plan, user instructions, and ongoing edits in real-time to enforce zero-deviation
• Checkpoint/HALT gates are conversational — steps 4-6 require stopping mid-execution and asking the user, which works naturally in the main thread but poorly in a subagent with limited context
• An agent would lose the context needed for enforcement — detecting "unauthorized improvements" or ambiguity requires seeing the full edit history
• Pattern kept: skill-only (no companion agent)