PRDs and Tasks

Xavier helps you go from idea to implementation plan. /xavier prd conducts an interview to produce a product requirements document. /xavier tasks decomposes that PRD into phased vertical slices ready for execution.

Both operations are enriched with your vault context — past PRDs, architecture notes, team conventions, and review history inform every step.

Writing a PRD

/xavier prd

The flow

1. Vault context selection — Xavier presents titles and frontmatter from your existing PRDs, repo knowledge, and team conventions. You pick what's relevant to this feature
2. Interview — Xavier asks about the problem, explores the codebase, asks relentless follow-up questions, and works through module design with you
3. User quiz — Xavier verifies its understanding before writing
4. Output — a structured PRD stored in ~/.xavier/prd/

PRD structure

Every PRD follows this template:

• Problem Statement — what's broken or missing
• Solution — what you're building
• User Stories — who benefits and how
• Implementation Decisions — concrete choices with rationale
• Testing Decisions — what to test and how
• Out of Scope — explicit boundaries
• Further Notes — anything else that matters

PRDs include Zettelkasten frontmatter and wikilinks to related vault notes.

Decomposing into tasks

/xavier tasks

The flow

1. PRD selection — Xavier lists PRDs from ~/.xavier/prd/, you pick one
2. Codebase exploration — Xavier reads the repo to understand current state
3. Vault context — follows the PRD's related wikilinks to pull in architecture notes, team conventions, and dependency-skills automatically
4. Backpressure detection — identifies verification commands from your project config
5. Durable decisions — surfaces architectural decisions that apply across all phases
6. Vertical slices — drafts phased implementation tasks, each a thin end-to-end slice
7. User quiz — verifies the decomposition makes sense before writing

Task format

Tasks are organized into phases, each with:

• Clear scope and deliverables
• Acceptance criteria
• Backpressure commands (automated verification after each phase)
• Completion criteria

Stored in ~/.xavier/tasks/ with a wikilink back to the source PRD.

Example: full cycle

Here's what a PRD → tasks workflow looks like in practice.

Step 1: Write the PRD

/xavier prd

Xavier asks about your feature. Say you're adding webhook support to your API:

Xavier: What problem are we solving?

You: Our users need to get notified when events happen in their workspace. Right now they poll our API.

Xavier: I see you have an event system in src/events/. Are we building on top of that?

You: Yes, webhooks should subscribe to existing event types.

The interview continues until Xavier has a complete picture. It writes a PRD to ~/.xavier/prd/webhook-support.md.

Step 2: Decompose into tasks

/xavier tasks

Xavier reads the webhook PRD, follows its links to your API architecture notes and team conventions, and produces:

• Phase 1: Webhook registration endpoint + database schema
• Phase 2: Event subscription wiring + delivery queue
• Phase 3: Retry logic + failure handling
• Phase 4: Management UI + webhook logs

Each phase is a vertical slice — it works end-to-end, not layer-by-layer.

Step 3: Execute with the loop

Tasks feed directly into /xavier loop. See Autonomous Loop.

Context warnings

When a PRD links to many vault notes, Xavier warns you before loading everything:

"This PRD links to 12 notes (~8,000 words of context). Proceed or trim?"

This prevents context pollution while making sure nothing important is missed.