# Implementation Plan: Resolving Empty `${@}` Placeholder in `p-plan.md`

> **Note on input:** The task argument arrived as the literal sentinel `${@:-the current task}` — the shell's default-value expansion never resolved because no real argument was passed. The previous `p-brainstorm` step (severity: blocker) flagged the identical issue. I will not fabricate a plan against a placeholder; instead, the plan below scopes the *real* work that must happen first: obtaining a concrete task. Once a real task is supplied, this artifact is re-runnable against it.

---

## 1. Goal
Produce a concrete, verifiable implementation plan for a real task by closing the input-validation gap in the `p-plan` prompt (and sibling `p-*` prompts) so a missing argument yields a clarifying question instead of a placeholder-substituted phantom task.

## 2. Constraints
- **No implementation yet.** This step only produces a plan; the parent decides whether to execute.
- **Working directory:** `/home/liph/dotfiles/pi/.pi/agent/prompts/` — contains 12 `p-*.md` prompts and 4 `c-*.md` commands, all using the same `${@:-...}` pattern.
- **Existing contract:** the `p-plan` body mandates a 7-section format (Goal, Constraints, Approach, Steps, Verification, Risks & Rollbacks, Open Questions). Any new validation must preserve that contract when a real task *is* supplied.
- **Acceptance contract (from parent):** attested level; final reply must end with a fenced `acceptance-report` JSON block; `criteriaSatisfied[].status` ∈ {satisfied, not-satisfied, not-applicable}; `commandsRun[].result` ∈ {passed, failed, not-run}.
- **No write tools in scope** for the current run (review/find only) — if the parent wants the prompt edited, it must do that itself or assign a write-capable subagent.
- **Subagent role:** I am a delegated worker, not the orchestrator. I must not propose further subagents; I report findings only.

## 3. Approach
Adopt the **"refuse and ask"** strategy recommended by the prior `p-brainstorm` step (Approach A, score 5/5 on fit). Treat the placeholder as a blocking precondition, not a topic to plan around. The plan's *Steps* therefore describe the smallest set of clarifications and follow-up actions the parent must take to unblock a real plan.

Rationale: every other branch (infer from context, meta-plan the prompt) requires a writeable surface or risks guessing wrong. Refusal is the only branch that is reversible, low-cost, and aligned with the prompt's own "ask clarifying questions" rule.

## 4. Steps
1. **Confirm the input is empty** — re-read the rendered argument; verify it equals the sentinel `${@:-the current task}` rather than an empty string. *(This step is satisfied: the prior step's diff confirmed the sentinel leaked through.)*
2. **State the blocker explicitly** to the parent, naming the sentinel and the file responsible (`p-plan.md` line 4).
3. **Request the minimum task shape** needed to re-emit a real plan: target system/codebase, user/audience, desired change, acceptance bar, hard constraints (language, runtime, deadline, regulatory).
4. **Offer the meta-fallback** (Approach C from the brainstorm): if the actual goal is to harden the `p-*.md` prompt family, the parent can confirm and the next plan will cover input validation, sentinel detection, and failure-mode UX.
5. **On receipt of a real task:** re-run this prompt with the task substituted, then verify all 7 sections of the produced plan against the acceptance contract.
6. **On receipt of "harden the prompts":** produce a follow-up plan covering (a) sentinel detection in the prompt loader, (b) clarifying-question branch, (c) regression test using a sample invocation with an empty arg, (d) roll-forward migration for the other 11 `p-*.md` files.

## 5. Verification
- **Step 1:** re-render `${@}` via the same shell that invoked this prompt; confirm sentinel presence. *(Already done by the parent before this delegation.)*
- **Step 3:** parent's reply contains at least the 5 fields listed (target, user, change, acceptance, constraints).
- **Step 5:** re-issued plan contains 7 sections, each non-empty, no `TBD` placeholders, all `Open Questions` either resolved or explicitly deferred with a reason.
- **Step 6:** follow-up plan names all 12 `p-*.md` files and the 4 `c-*.md` commands; lists the migration order (lowest-risk prompts first, e.g. `p-explain.md` before `p-brainstorm.md`).
- **Acceptance report:** final reply ends with a parseable JSON `acceptance-report` block; `criteriaSatisfied[].status` values are valid; `commandsRun[]` reflects only what was actually run.

## 6. Risks & Rollbacks
- **Risk: parent interprets refusal as a hang.** Mitigation: this reply is the refusal, with a single concrete question, so no rollback is needed.
- **Risk: meta-fallback (Step 4) is misread as scope creep.** Mitigation: explicitly framed as a branch the parent must opt into; default branch is "supply a real task."
- **Risk: a follow-up subagent re-introduces the sentinel** by echoing `${@:-...}` in its own template. Mitigation: the follow-up plan (Step 6c) should require a grep-based check that no rendered output contains the literal string `${@:-`.
- **Rollback:** this artifact is review-only; nothing was written, so "rollback" is just discarding this reply and re-invoking with a real task.

## 7. Open Questions (require parent decision before any real planning)
1. **What is the actual task?** (Required — see brainstorm's Unknown #1.)
2. **Is the user available now, or is this an autonomous run?** If autonomous and the parent can supply context, I can attempt context-inferred planning (Approach B from the brainstorm) on the next turn.
3. **Is the goal to fix the `p-*.md` prompt family itself?** If yes, switch this plan to Step 6's scope.
4. **Which subagent gets write access to `p-*.md`?** I do not, and the parent should not assume I will.
5. **What is the deadline for a real plan?** Drives whether to spend a turn on clarification or accept a lower-confidence inference.

---