--- name: ptp-parcel-fast description: 'Activate this skill to run ONE committed parcel plan end-to-end under the locked AUTO + SINGLE preset — Phases 1-9 in a single fresh context per plan, Gates A/B auto-cleared, Gate C N/A, terminating at PHASE_9 with Gate D OPEN. Invoked only by the `parcel-sprint` batch host (through the `ptp-parcel-fast` subagent); never user-selectable.' version: 5 updated: 2026-09-16 --- # SKILL: Per-Plan Fast Runner (`ptp-parcel-fast`) > **Boundary:** This skill owns exactly **one** plan's Phases 1-9. It is spawned by the `parcel-sprint` batch host (through the `ptp-parcel-fast` subagent) with a single plan path. It never walks the queue, never spawns anything, and never asks the Mode/Topology questions. ## Activation - Owns one plan's Phases 1-9 in a single fresh context. - Locked preset: `Mode = AUTO`, `Agents = SINGLE`. **Never ask** the Mode or Topology selection questions. - The lifecycle, gate set, and phase content are owned by `@pass-the-parcel`; this skill only fixes *how* they are sequenced for the batch path. Do not restate the pipeline. ## Per-plan chain (exact order) 1. Play `ptp-context-hunter` **inline** (Phases 1-3). 2. Play `ptp-phase3-answerer` **inline** (Phase 3.5). 3. Auto-clear Gate A (see *Auto-clear test*). 4. Play `ptp-high-visionary` **inline** (Phases 4-5 — wiki spec + implementation plan + inline self-review). 5. Auto-clear Gate B; record Gate C `N/A`. 6. Play `ptp-code-surgeon` **inline** (Phases 8-9). 7. Commit the work with the exact message literal `plan: `. 8. Set bottom **Status** `PHASE_9`, **Active Persona** `Executor`, leave **Gate D** `OPEN`, and set the claim front-matter `claim_status: GATE_D_USER_APPROVAL` — **not** `CLAIMED`. That value is what marks the plan as executed-but-unverified; it is the batch path's terminal claim state, and it is the state a dependent's `depends_on` accepts. ## Plan Settings writer (frozen preset) The chain's **first** action — at claim time, before Phase 1 — writes the plan's `## ⚙️ Plan Settings` block as the locked preset: `Mode=AUTO`, `Agents=SINGLE`. This closes the gap where plan-start config had no assigned writer under the batch path. The host (`parcel-sprint`) never authors it, and it is frozen thereafter. **Record the flag in that same block.** When the claimed plan's claim front-matter carries `triage: MULTI`, the provenance line written with the preset must **name the flag** and state plainly that this run is `SINGLE` under the batch preset with **no independent review** — the operator accepted that risk at the fork (`@sprint-run` § 1), and the record belongs in the plan, not in a session transcript. Recording it at claim time is the one legal moment (the block is written once); Gate D then reads the risk instead of discovering it. Canonical semantics: `.devops/rules/plan-lifecycle.md` § Claim Protocol → *MULTI-worthy Yield*. ## Auto-clear test A gate auto-clears only when its outputs satisfy the canonical **AUTO Gate Evidence Contract** (`.devops/rules/plan-lifecycle.md` § AUTO Gate Evidence Contract) — cited, never restated here. This chain auto-clears Gate A and Gate B; Gate C is recorded `N/A` under the locked `SINGLE` preset. Otherwise halt with the failure outcome below. ## Named exception This single-context Phases 1→9 run is the **explicit, machine-enforced Strict Context Isolation exception** (see Deviations). Every other run keeps the one-phase-group-per-session bound. ## Per-plan outcome map (halt vs skip) - `PHASE_8_FAILED` (rollback after two failed self-healing attempts) → return `HALT : PHASE_8_FAILED`. - An `AUTO` gate whose outputs exist but fail the canonical **AUTO Gate Evidence Contract** → return `HALT : unproven — `. Never repaired inline, never downgraded to a skip. - A self-review `**REJECTED:**` at the inline Phase 6 checkpoint, or a Phase 3.5 `Unresolvable:` → return `HALT : `. **Never** start an inline `PHASE_5_REVISION` loop — revision belongs to a fresh Group B run, not this locked chain. - A plan whose bottom `Status` is already `PHASE_9` at entry → return `SKIP : already PHASE_9` without re-running. - A plan whose `depends_on` is unmet at entry → return `SKIP : unmet depends_on`. A code is **satisfied** when it is present in `.devops/archive/` **or** present in `.devops/plans/` with `claim_status: GATE_D_USER_APPROVAL`; any other state (still `QUEUED`, or `CLAIMED` below `PHASE_9`) is unmet. This is the **same rule** the host applies in `sprint-run` § 2 clause 2, whose executable embodiment is `scripts/sprint_eligible.py` — the two layers must not diverge, which is why neither restates the rule: they cite `.devops/rules/plan-lifecycle.md` § Claim Front-Matter. ## Output contract Return exactly one terse line: - `DONE ` — terminal `Status` `PHASE_9` with `claim_status: GATE_D_USER_APPROVAL` and Gate D `OPEN`, plus the touched-file list. - `SKIP : ` — nothing written. - `HALT : ` — nothing further attempted. Never advance past `PHASE_9`, never flip Gate D, never reorder or re-run a skipped plan. ## Safety Validation at trust boundaries, error handling, and the Gate D human sign-off are **not** simplifiable. The batch defers Gate D — it never skips it.