Project Squad Framework · Guide

Choosing the right command

Use the lightest tool that gets you a decision you can build on. This guide explains when to use each command, what you walk away with, and how to know the process was worth running.

TL;DR: Sprint for foundational product decisions. Workshop to align on a leading option under time pressure. Spike to resolve a specific unknown blocking progress.

Is this process worth it?

The honest answer before you commit

↻

The cost of a bad foundational decision almost always exceeds the cost of running the process. If you skip this and build the wrong thing, you don't get the time back.

Sprint

A spec you can build from

The creative-brief.md success criteria become the validation checklist. No more arguing about what "done" means.

Spike

An unblocked decision

You stop arguing about the unknown. The answer is evidence-backed — not a guess, not a meeting outcome.

Workshop

Alignment in 2–3 hours

A decision memo that replaces a 3-hour stakeholder meeting with a 30-minute read.

The compounding benefit

The Dissent Register means you stop re-litigating the same closed decisions. Each sprint's summary.json is read by the next sprint's pre-flight check — context builds automatically rather than being reconstructed from memory.

By the third sprint, you spend almost no time on "why did we decide X?" — it is already in the documents.

≡

Command Comparison

Sprint vs. Workshop vs. Spike at a glance

	/create-sprint	/create-workshop	/create-spike
Time	Half-day to 1 day	2–3 hours	1–4 hours
Best for	Foundational product decisions — you don't know what to build yet	Aligning on a leading option — stress-testing it, not discovering it	Resolving one specific unknown blocking a decision or estimate
Use when	Defining a user moment, feature direction, or product principle for the first time	A stakeholder, deadline, or previous sprint forces a decision and you already have a candidate	A decision can't be made without answering a concrete question first
Skip when	A workshop or spike would get there faster	You haven't formed a view yet — run a sprint	There are multiple open questions — split into multiple spikes
Primary output	`decision.md` + `creative-brief.md` + `synthesis.md`	`workshop.md`	`output.md` (answer-first)
Also produces	`brief.md`, `sketches.md`, `ideas.md`, `summary.json`	`summary.json`	`brief.md`, `summary.json`, ADR (if technical)

→

Decision Flow

Four questions to pick the right command

Step 1

Can you articulate what you are deciding in one sentence?

No → Run a Sprint. The Map phase will sharpen the problem.

Yes → Continue to Step 2

Step 2

Do you already have a leading option?

No → Run a Sprint to evaluate from scratch.

Yes → Continue to Step 3

Step 3

Are you blocked by a specific unknown — technical, research, or design?

Yes → Run a Spike first. Return to Step 1 with the answer in hand.

No → Continue to Step 4

Step 4

Is a decision needed within 24–48 hours, or are you under external time pressure?

Yes → Run a Workshop to stress-test the leading option.

No → Run a Sprint to evaluate it properly.

ℹ

If you can't articulate the decision in one sentence — "we're choosing between X and Y, and we need an answer by Thursday" — run a Sprint. Workshops stress-test; they don't discover.

⇢

Sequencing Patterns

Commands are often stacked — these are the common combinations

Spike → Sprint

An unknown is blocking the sprint. Resolve it first, then run the sprint with the answer in hand. The spike's output.md feeds into the sprint brief.

Sprint → Workshop

A sprint produced a foundational decision. A follow-up question needs quick alignment before the next build cycle without reopening the sprint.

Workshop → Spike

A workshop surfaced an assumption the team can't validate without research. A spike answers it before the next sprint or build cycle.

Sprint → Sprint

Each sprint's synthesis.md and summary.json feed the next. Sprint 000 (Foundation) sets personas, principles, and first decisions. Subsequent sprints build on them automatically.

◫

What You Walk Away With

Concrete files produced by each command

create-sprint

brief.md

ArchivedThe sprint challenge, HMW questions, target user, and persona roster. Context for the sprint — not handed to builders.

sketches.md

ArchivedAll seven persona perspectives in their own voice. Internal reasoning — preserved for decision traceability.

decision.md

HandoffThe decision, rationale, rejected alternatives, and Elias's dissent. Primary reference for builders: "why did we build it this way?"

creative-brief.md

HandoffThe spec: target user, problem, solution direction, success criteria, guardrails. Produced for user-facing features. Success criteria become the validation checklist.

ideas.md

ArchivedOpportunities that surfaced but weren't the focus. Feeds the sprint backlog for future work.

synthesis.md

HandoffWhat changed, what the next sprint should know, open questions. Read by the next sprint's pre-flight check.

summary.json

MachineMachine-readable record. Read by future sprint pre-flight checks to surface context, open questions, and Elias's dissent without loading every document.

create-workshop

workshop.md

HandoffDecision memo: context, decision, rationale, rejected options, Elias's position, next action. Same structure as a sprint decision but compressed to 2–3 hours.

summary.json

MachineMachine-readable record read by future sprint pre-flight checks.

create-spike

brief.md

ArchivedThe specific question, acceptance criteria, investigation angles, and constraints. Context for the spike.

output.md

HandoffAnswer first, then evidence and recommendation. Read only the top half in practice — raw research sits below the stop line as backup.

summary.json

MachineIncludes confidence level (high/medium/low) and which work the spike unblocks.

ADR (if technical)

HandoffSaved to docs/decisions/ if the spike resolves a significant technical decision. Referenced from the spike frontmatter.

↗

The Handoff

What builders receive — and what stays archived

What developers and designers receive

creative-brief.md — the spec and success criteria. This is what the builder works from.

decision.md — the rationale and what was rejected. Answers "why did we build it this way?" without a meeting.

Spike output.md — if a specific unknown was resolved upstream, the builder gets the answer and recommendation.

What stays archived

sketches.md — internal persona reasoning. Preserved for decision traceability, not operational for builders.

brief.md — sprint context. Archived for audit trail and future sprint pre-flight checks.

✓

The creative-brief.md success criteria become the validation checklist. If validation fails, the finding is logged in research/DECISIONS.md and a new sprint is triggered — not a patch to the prototype. The framework ends at the decision.