execute git:20260708.97c2331A

Immutable. This exact content never changes and is served at /api/v1/blob/a187b56f8d1a118d.

---
name: execute
description: Execute an approved ops plan — research, write, review, update state, archive. Use after /plan approval. Not for code.
argument-hint: <path to plan file>
---

Execute the plan at: $ARGUMENTS

**Scope:** This skill produces research, content, strategy, and specs — not code. If the plan involves code changes, use `/implement` instead.

## Instructions

### 1. Read the plan

Read the plan file. Understand the objective, steps, and success criteria.

### 2. Execute

Carry out the plan:

1. Do the research, analysis, or writing described in the plan.
2. When researching, **always cite sources** — include URLs, document names, or specific references.
3. Store outputs in the appropriate location:
   - Research findings → `references/<topic>/`
   - Work products and deliverables → `artifacts/` (or as specified in the plan)
4. If the plan needs to change mid-execution (new information, blocked path), update the plan file and confirm the revised approach with the user before continuing.

**Opportunity lifecycle:** When researching and qualifying opportunities (grants, partnerships, platforms, etc.):
1. Raw idea → backlog item. The item *is* the task: "research and qualify this."
2. After research → reference file gets the findings. Then either:
   - **Pursue** → backlog action item linking to the reference
   - **Pass** → reference entry updated with pass rationale + date, backlog entry removed

### 3. Review

Before updating state, review the deliverables. In autonomous execution this is the **only** verification gate — nothing you produce is seen by a human before it lands in the repo's state and knowledge base — so approach it as a skeptic reading someone else's work, not as a rubber-stamp of what you just wrote. A clean pass is fine, but only after you've genuinely tried to find the weak claim, the unsupported assertion, and the inconsistency:

1. **Fact-check** — verify claims against cited sources. Flag unsupported assertions.
2. **Consistency** — check that new artifacts don't contradict existing state files or prior completed plans.
3. **Completeness** — confirm the output covers everything the plan promised. Fill gaps or note them as out-of-scope with justification.
4. **Quality** — check formatting consistency, broken links, and missing references.

### 4. State updates

1. **Complete the plan file** — fill in Outcome, Key Decisions, Artifacts, and Session Log sections.
2. **Update `backlog/`** — **delete** the completed item from the relevant file (don't mark it "done"). If only part was completed, rewrite the entry to cover remaining work. If new tasks emerged, add them **in priority order** (highest first) — not at the end.
3. **Update `state/` files** — if the task changed anything documented in `state/`, update those files. Create a new state file if a significant new aspect emerged.
4. **Harvest insights** — review what you learned and persist it:
   - **MEMORY.md Key Learnings** — add or update if you learned something that changes the project's understanding of its landscape, constraints, opportunities, or strategic position. **Never put WAITING markers, task status, or blocked items in MEMORY.md.**
   - **New backlog items** — add actionable opportunities or follow-up tasks to the appropriate backlog file in priority order.
5. **Patterns, anti-patterns, and conventions** — if the work revealed patterns worth documenting for future agents (e.g., effective research approaches, naming conventions for artifacts, common pitfalls in a domain), add them to `CLAUDE.md` or the relevant reference file.
6. **INDEX.md cascade** — list every file created, moved, renamed, or significantly changed. For each, confirm its folder's `INDEX.md` is up to date. Cascade to parent INDEX.md if needed.

### 5. Archive the plan

Move the plan to `plans/completed/` with a date prefix: `YYYY-MM-DD_original-filename.md`.