Bootstrap: guided or quick
Bootstrap your project's adoption files in one shot with KB-sensible defaults, instead of answering the full interview.
Bootstrap has two resolution depths and one entry point. Guided (the default) interviews you decision by decision. Quick takes the same defaults without asking, so an empty project reaches a first workable story in minutes.
This page is about the /pair-process-bootstrap skill. For installing the CLI and the Knowledge Base first, see the Quickstart.
Which depth do you want?
| Guided (default) | Quick | |
|---|---|---|
| You get asked | every decision, one at a time | only what has no safe default |
| Best for | a first setup, or a project whose direction is still open | an experienced user, a spike, a CI/scripted setup |
| Time | as long as the conversation takes | minutes |
| Files written | adoption files | the same adoption files |
Quick mode is additive. It is a second depth of the same skill, not a separate skill and not a replacement: if you omit the argument, the interview you already know runs exactly as before.
Run it
In your assistant: the command above. With /pair-assistant (optional, Claude Code): ask it to adopt the project; it runs the install, then hands off to /pair-process-bootstrap (how to ask).
One precondition: a populated .pair/adoption/product/PRD.md. Phase 0 of bootstrap is blocking in both depths, with no PRD it composes /pair-process-specify-prd, a full interactive authoring session that is neither defaulted nor counted below. Write the PRD first, then run quick mode.
With the PRD in place, expect at most two questions:
- Which PM tool?: the choice is organisational, not technical, so there is no safe default to guess. Skipped if your
way-of-working.mdalready names one. - Which tech stack?: normally read straight from
package.json, lockfiles and config. Only asked on a genuinely empty repository, where there is nothing to read.
One rarer third case can ask: /pair-capability-map-contexts, composed in Phase 3.5, stops on a relationship that is both unbalanced and volatile when neither a mitigation nor an explicit acceptance is on offer. Quick mode deliberately keeps that gate, recording a coupling risk nobody judged would be worse than one more question.
Everything else (project categorization, the per-section architecture/infrastructure/way-of-working decisions, the testing and AI sections that follow from your stack, the adoption documents, the standard quality-gate pipeline) is resolved from defaults and reported, not asked.
The assess-* skills bootstrap composes do not add confirmations of their own either: in quick mode their resolved values are accepted as-is and listed in the final summary, instead of being confirmed one skill at a time (there are eight of them).
When it finishes, the summary names the depth that ran and how many questions it asked:
Nothing about the output is "quick mode"
Every file quick mode writes is a normal adoption file, in the normal location and format: .pair/adoption/tech/*.md, the gate registry in way-of-working.md, ADRs and ADLs in the decision log. There is no quick-mode-only file, marker, or format.
So a default you disagree with is not a lock-in, edit the file by hand, or re-run the relevant phase, and the change sticks like any other adopted decision. Accepting a default costs you nothing you cannot change later.
An already-configured project is confirmed, not overwritten: each phase checks its own output first, in both depths.
Where the defaults come from
Quick mode does not invent its own resolution order. It follows the shared Guided / Quick Setup Convention that pair-cli package and the assess-* skills already use, highest wins:
- Explicit argument: anything you named in the invocation
- Project state: what is already on disk, except the decision log:
.pair/adoption/tech/**,.pair/adoption/product/**, the PRD,package.json, lockfiles, CI workflows,git config - Saved preferences: decisions a previous run recorded in
.pair/adoption/decision-log/ - Fallback: the Quick-Mode Per-Project-Type Defaults table in the KB bootstrap checklist (never its worked examples)
Bootstrap only declares which of its own decisions each tier fills. That mapping, decision by decision, lives next to the skill in quick-mode-defaults.md (.claude/skills/pair-process-bootstrap/quick-mode-defaults.md once the KB is installed).
In CI or a non-interactive session
Guided needs a terminal. With no TTY, bootstrap warns and runs quick instead rather than hanging on input that can never arrive. If a still-asked decision cannot be resolved either, the run halts and tells you which input to pass explicitly: it does not guess.
Next: Solo, team or organization, then verify the setup quick mode just produced.