Phase 1: Planning

Phase 1 transforms a vague idea into a validated, implementation-ready plan. It consists of seven steps, each with a dedicated skill and (in most cases) a dedicated persona.

1. Brainstorm

Skill: /specsafe-brainstorm Persona: Elena -- Scout (EXPLORE)

The first step is pure divergence. Elena opens the possibility space by asking clarifying questions, surfacing assumptions, and generating options without evaluating them. The goal is breadth, not depth.

No idea is rejected at this stage. Brainstorming is about filling the whiteboard before picking up the eraser.

Output: A collection of raw ideas, questions, and directions to explore.

2. Principles

Skill: /specsafe-principles

Product principles establish the decision-making framework for everything that follows. This step defines:

• Core principles -- What matters most. What the product stands for.
• Non-goals -- What you are explicitly choosing not to do.
• Quality priorities -- Where you want to invest (performance, accessibility, developer experience, etc.).

Principles act as a filter. When two valid approaches conflict later, principles break the tie.

Output: A principles document that guides all downstream decisions.

3. Brief

Skill: /specsafe-brief

The brief is a concise product and business framing. Think of it as a one-page elevator pitch that answers:

• What problem are we solving?
• For whom?
• Why now?
• What does success look like?

The brief keeps everyone aligned on the big picture without getting lost in implementation details.

Output: A focused product brief document.

4. PRD (Product Requirements Document)

Skill: /specsafe-prd Persona: Kai -- Mason (SPEC)

Kai is precise and structured. The PRD contains testable requirements written with normative language: SHALL, MUST, SHOULD, MAY. Every requirement must be verifiable -- if you cannot write a test for it, it does not belong in the PRD.

The PRD includes:

• User journeys with concrete scenarios
• Functional requirements (SHALL/MUST)
• Non-functional requirements (performance, security, accessibility)
• Acceptance criteria for each requirement

Output: A requirements document where every statement is testable.

5. UX

Skill: /specsafe-ux Persona: Aria -- Prism (UX)

Aria designs the user experience before any technical architecture is considered. This ordering is intentional and enforced: UX always comes before architecture. Technical decisions must serve the user experience, not constrain it.

The UX step covers:

• Design tokens (colors, spacing, typography)
• Component specifications
• User flows and interaction patterns
• Accessibility requirements (non-negotiable)
• Responsive behavior

Output: A UX specification that the architecture must support.

6. Architecture

Skill: /specsafe-architecture Persona: Nolan -- Sage (ARCHITECTURE)

Nolan is pragmatic and trade-off aware. The architecture step produces system design decisions informed by the UX specification and the PRD. Every significant decision is documented as an Architecture Decision Record (ADR).

ADRs capture:

• The decision and its context
• Options considered
• Trade-offs evaluated
• The rationale for the chosen approach

This creates an auditable trail of why the system is designed the way it is.

Output: System architecture with ADRs documenting key decisions.

7. Readiness

Skill: /specsafe-readiness

The Readiness check is the critical gate between planning and development. It verifies that all planning artifacts are coherent, complete, and aligned:

• Do the requirements match the UX specification?
• Does the architecture support all required user flows?
• Are there any contradictions between documents?
• Is every requirement testable?

The Readiness Gate

The check produces one of three outcomes:

Development cannot begin until the Readiness gate returns GO. This is not a formality -- it is the single most important quality gate in the entire workflow. Catching a contradiction here costs minutes. Catching it during development costs hours or days.