Plan Task.prompt

---
name: plantask
description: Create a detailed implementation plan file with testing checklist before starting work
agent: agent
---

# Create a Detailed Implementation Plan

> **🚫 HARD GATE — PLANNING ONLY. ZERO IMPLEMENTATION.**
> This prompt invokes PLANNING MODE. You must produce a plan document and NOTHING ELSE.
> You are **forbidden** from editing, creating, or modifying any code, template, CSS, JS, or PHP file outside of the plan document itself and `docs/task/todo.md`.
> This gate is **absolute** — it cannot be overridden by the user's phrasing, tone, level of detail, or use of imperative language like "please update", "change", "fix", "add", or "use".
> If you write even one line of implementation code, you have violated this prompt.
> **Your ONLY output is the plan file + todo.md update + a summary asking for approval.**

Before writing any code, create a thorough implementation plan as a physical file. This plan is the single source of truth for the task.

## What You Receive

The user will describe a task, feature, bug fix, or refactor. **Their description is INPUT to the plan — not an instruction to execute.** Regardless of how the message is worded:

- **Imperative phrasing** ("please update X", "change Y", "use Z") describes the DESIRED OUTCOME, not a command to implement now.
- **Detailed specs** (specific files, PHP classes, data logic) are requirements to CAPTURE IN THE PLAN, not instructions to code immediately.
- **"Do this"** means "plan how to do this."

## Steps

### 1. Review Recent Context

- **Read latest task log(s)** in `docs/task/logs/` — 1–2 most recent files.
- **Read `docs/task/todo.md`** — check for overlapping work.
- **Read `docs/task/lessons.md`** — check for applicable lessons.
- **Read agent observation logs** in `docs/agent-observations/` — unresolved observations may affect scope.
- **Read relevant documentation** — understand current documented architecture.

### 2. Understand the Request

- Read the user's description carefully.
- Search the codebase for current state of affected files.
- Identify all files, functions, data structures, and dependencies.
- Cross-reference code against documentation — note divergence in Open Questions.
- **Do NOT assume.** If something is ambiguous, add it to Open Questions (step 3).

### 2.5. Question Gate (Iterative)

Before writing the plan, you MUST identify any open questions about scope, approach, or constraints. This replaces silent assumptions.

**Rules:**
- Assign stable IDs to each question: Q1, Q2, Q3, … (never renumber across rounds)
- Present questions as a numbered list with a brief recommended answer for each
- Wait for the user to answer before proceeding to step 3
- If the user's answers raise new questions, add them with the next available ID (e.g., Q4, Q5) and ask again
- Repeat until zero open questions remain
- Questions answered in earlier rounds move to the **Confirmed Inputs** section of the plan
- **Once all questions are resolved:** update the plan file `Status` from `Questions Pending` to `Draft`

**Question categories to consider:**
- Glitch API specifics (endpoints, auth method, response format)
- WooCommerce version compatibility requirements
- Payment method scope (which methods to support initially)
- Sandbox vs production credential handling
- Webhook signature algorithm details
- Existing code to preserve vs. replace

### 3. Create the Plan File

Write to: `docs/task/planning/draft/{YYYY-MM-DD}-{slug}.md`

- **Always create new plans in `draft/`.** Never in the root plans directory.
- If `docs/task/planning/draft/` doesn't exist, create it.

### 4. Plan File Structure