Phase 2 — Planning

The PRD and UX design. The output of this phase is enough alignment that the Architect can start composing SDKs without re-asking what you're trying to build.

Owners: PM (e11-agent-pm), UX Designer (e11-agent-ux-designer).

Workflows in this phase

Code	Workflow	Purpose	Owner	Output
[PR]	e11-prd	Create / Update / Validate a PRD — one consolidated skill	PM	{planning_artifacts}/prds/prd-<project>-<date>/prd.md (+ addendum.md, .memlog.md)
[UX]	e11-ux	Dual-spine UX design with E11 component classification	UX Designer	{planning_artifacts}/ux-designs/ux-<project>-<date>/DESIGN.md + EXPERIENCE.md

How the planning skills are shaped

The PRD and UX surfaces are consolidated:

• e11-prd detects intent (Create/Update/Validate) instead of making you pick a workflow. The old names — e11-create-prd, e11-edit-prd, e11-validate-prd — answer as deprecated shims that forward with the right intent, for one release.
• Stakes calibration + two paths. The skill reads stakes (hobby / internal / launch) and sizes the PRD accordingly; you pick the fast path (brain-dump → one batch of gap questions → full draft with [ASSUMPTION] tags) or the coaching path (section-by-section, with pushback).
• Memlog is the canonical memory. Every decision appends to the run's .memlog.md; the PRD is derived from it, and update runs append rather than silently rewriting. Post-finalize input lands in addendum.md rather than destabilizing the approved body.
• The Platform Capability Map (gate: e11_platform_capability_map, default on): during discovery the skill surveys the platform via skill:e11-knowledge and writes a PRD section classifying every MVP feature Covered / Composed / New with alloy:// citations. Downstream, the architecture composition, story SDK stamps, and review audits all trace to this map.
• A reviewer gate at finalize — reviewer subagents (finalize_reviewers, including a capability-map lens and the doc_standards editorial reviewers) run before the PRD is declared done; depth scales with stakes.
• e11-ux produces two spines: DESIGN.md (the buildable spec) and EXPERIENCE.md (journeys, states, rationale). e11-create-ux-design is a shim. Every component carries a P/D class and Tier A/B/C source (P → shadcn; D → E11 SDK first, cited; Tier C → custom, listed under Alloy follow-ups).

Standard flow

1. PM [PR] (Create) — from the brief. Pick your path; the PRD lands with the capability map inside.
2. UX [UX] (Create) — when UI is a primary piece. Component sourcing starts from the frontend SDK census, not from imagination.
3. PM [PR] (Validate) — cheap independent critique pass; also the right move for a PRD produced outside Foundry.
4. PM [PR] (Update) as downstream phases surface gaps — through the memlog, not hand-edits.

When to detour

• No UI. Skip [UX] entirely. Architecture goes straight to SDK composition.
• Brief was thin. Run [PR] anyway — discovery surfaces the gaps; if it's too thin the skill will say so.
• Scope changes mid-implementation. Don't slip scope in through Update — run [CC] Correct Course first, then apply the agreed change.
• Small, well-understood effort. Skip the PRD; distill straight to a spec kernel with e11-spec-flow (Quick flow).

Hand-off

Output of Phase 2 → input to Phase 3 (Solutioning). Architect [CA] inherits the capability map and (if present) the UX spines' component decisions.

Source

Workflow SKILL files:

• e11-agent-pm/SKILL.md · e11-agent-ux-designer/SKILL.md (the phase's agent-skills)
• e11-prd/SKILL.md · shims: e11-create-prd/SKILL.md, e11-edit-prd/SKILL.md, e11-validate-prd/SKILL.md
• e11-ux/SKILL.md · shim: e11-create-ux-design/SKILL.md