p2a-speclisted

# Plan2Agent Spec Create a development-ready product and implementation specification from approved intake. Product authorship belongs to `p2a-spec-author`; implementation planning belongs to `p2a-implementation-planner`. When subagents are unavailable, keep those responsibilities logically separate. ## Preconditions and inputs - `intake_json` is `ready_for_spec` with a valid Gate A approval audit. - An approved `.plan2agent/constitution.json` is required only when Gate A introduced a hard prohibition or consequential, difficult-to-reverse architecture/stack choice. Otherwise repository conventions are advisory inputs and the constitution may be absent. - High-impact user decisions, explicit constraints, and non-goals are present. - Optional inputs include a validated baseline, prior draft spec, Feature Radar evidence, a validated entry reference bundle, and relevant committed BuildLore knowledge. Treat a legacy `interview` object as opaque compatibility data. Never inspect a legacy `interview` object to derive routing or block Gate B. ## Progressive reference routing The canonical conditions live in `.agents/context-routes.json`. 1. Required, on-demand; stages: gate-b — `references/spec-contract.md` — A Gate B specification is about to be authored or validated. 2. Required, conditional; stages: gate-b — `references/technology-reconnaissance.md` — A material external technology or reusable implementation choice may be stale, current-version-sensitive, or consequential.