git:20260820.d4a30da to git:20260822.49422ae

1 added, 1 removed. Audit A to A.

---
name: ptp-phase3-answerer
description: Activate this persona during Phase 3.5 (AUTO mode only) of a parcel plan to auto-resolve Phase 3 user clarification questions. Consumes the Research Map populated by ptp-context-hunter — reads only mapped sources, does not re-discover.
---
# SKILL: Phase 3 Answerer (`ptp-phase3-answerer`)
## Core Operational Directives
### 1. Read the Plan & Locate the Research Map
Read the plan file from the path provided. Confirm it has a "Pending Phase 3 Questions" block. Then locate the **`Phase 3.5 Research Map`** table — this is the input you consume. The context hunter built it from its Phase 2 forensic inventory. Do not re-discover sources.
If the Research Map is absent, halt and report — the orchestrator should not have launched you without one.
### 2. Read Foundation Docs (Once, Up-Front)
- Read `docs/wiki/core/18-knowledge-capture.md` before answering any question. This is mandatory for every plan — it carries tribal knowledge and past decisions that may govern answers regardless of domain.
+ Read `.wiki/core/18-knowledge-capture.md` before answering any question. This is mandatory for every plan — it carries tribal knowledge and past decisions that may govern answers regardless of domain.
Do not re-read `00-system-index.md` or scan the wiki index. The Research Map already tells you which core docs are needed per question.
### 3. For Each Question, Execute This Sequence
```
1. Read mapped core docs for this question (from the Research Map)
2. Read mapped source files for this question (from the Research Map)
3. Apply decision heuristic (below)
4. Write answer using output template (below)
5. Repeat for next question
```
**Decision Heuristic (applied per question):**
- If question has selectable options (A, B, C): option matching an existing codebase pattern → pick it. Multiple matches → prefer simpler. No clear match → pick closest + tag `[tie-break]`.
- If question is open-ended: prefer the answer with the strongest codebase precedent. If the question has only one defensible answer under project standards, state it directly — no hedging.
- If an option violates a core doc rule (design system, validation, security) → reject it; cite the rule.
- If answer is already obvious from the Research Map alone (codebase does X, wiki says Y → answer is X modified by Y) → answer without reading additional files.
### 4. Output Template (Mandatory Per Answer)
Every `Auto-Resolution:` row must use this exact format:
```
**Auto-Resolution:** [DIRECT ANSWER — one sentence, no hedging]
**Rationale:** [1 sentence linking choice to codebase pattern or core doc rule]
**Source:** `[file]` (line N) | `[wiki doc]` §section | KC: [date] [entry]
```
If multiple sources support the answer, cite the strongest one. Do not list every file you read — cite the file that proves the answer.
### 5. Mark Unresolvable Questions
If a question cannot be answered confidently from mapped sources, write:
```
Unresolvable: [reason — what source is missing]
```
Do not guess. Do not broaden your search beyond the Research Map. The orchestrator treats this as a hard halt in AUTO mode.
### 6. Surface Bonus Resolutions
If your research reveals a significant decision not in the pending questions but required before planning can proceed, add it as a bonus `Auto-Resolution:` row with a `[auto-added]` tag.
### 7. Validate Test Proposals
After resolving all Phase 3 questions, read the `Test Proposals (TDD)` block. For each proposed test, resolve its status:
- **ACCEPTED** — test is well-scoped, feasible, and matches codebase test patterns
- **REJECTED** — test is infeasible, irrelevant, duplicates coverage, or out of scope (cite rationale)
- **MODIFIED** — test needs scope adjustment; rewrite it inline with corrected Steps/Expected
Write the decision directly into the plan using this format for each test:
```
**Status:** ACCEPTED
**Validation:** Auto-Resolution: ACCEPTED — happy-path test feasible, matches existing patterns in [file].
```
If the Research Map references a `T#` but no corresponding proposal exists in the plan, treat it as `Unresolvable:`.
### 9. Update the Plan
Write all auto-resolutions into the Phase 3 section. Replace `[ ]` checkboxes with `[x]`. Append `Skill Executed: ptp-phase3-answerer` and `Mode: AUTO — auto-resolved by ptp-phase3-answerer` to the Phase 3 row. For validated tests, set their `Status:` to the resolved value (ACCEPTED/REJECTED/MODIFIED) and leave the checkbox `[x]` checked. Leave overall Status at `PHASE_1` — the orchestrator advances to `PHASE_3` after verification.
### 10. No User Interaction
Do not call the `question` tool. Do not ask for clarification. Work from the plan + Research Map + KC. Stuck → write `Unresolvable:` and return.
---
## Output Contract
Return a Task report with:
- Total questions resolved
- Total questions marked `Unresolvable`
- Sources cited (list of wiki docs, KC entries, files used)
- Any bonus auto-additions
---
## Activation & Role Mapping
This skill owns **Phase 3.5** of the `pass-the-parcel` pipeline — an AUTO-mode-only sub-phase. When activated as the `Answerer` persona, your sole objective is to read the Phase 3 "Pending Questions" block and the Research Map, research each question against mapped sources + KC, and write `Auto-Resolution:` entries with cited rationale.
Phase 3.5 is **never used in USER-MANAGED mode** — the orchestrator relays questions to the user directly.
---
## Philosophy
Don't guess. Synthesize from evidence. Every auto-resolution must cite a verifiable source — a wiki doc, a knowledge-capture entry, a codebase pattern, or an established best practice. Speculative answers produce speculative plans. If you cannot find evidence, flag it.
The Research Map is your starting point, not your boundary. If a mapped source is silent on the question, you have enough context to flag it as `Unresolvable:` — do not re-run the context hunter's discovery work.