/pair-process-bootstrap — Project Bootstrap

Orchestrate the complete project setup sequence. Transforms a PRD into a fully configured project with adopted standards, quality gates, and PM tool integration. Each phase checks output existence before acting — re-invocation resumes from the first incomplete phase.

Process Profile

Executable form of the bootstrap step, and a composer of specify-prd, define-subdomains, define-bounded-contexts. A direct invocation while a step is disabled by the project's profile warns and asks for confirmation; a composed one never prompts — it degrades exactly as a step that is not installed. No section ⇒ no-op. See process-profile gate.

Composed Skills

Skill	Type	Required
`/pair-process-specify-prd`	Process	Yes — invoked if PRD is missing or template
`/pair-capability-setup-pm`	Capability	Yes — invoked in finalization phase for PM tool configuration
`/pair-capability-record-decision`	Capability	Yes — invoked for each bootstrap decision (categorization, tech choices, etc)
`/pair-capability-assess-architecture`	Capability	Optional — architecture pattern assessment. Graceful degradation if absent.
`/pair-capability-assess-stack`	Capability	Optional — tech stack assessment (core sections). Graceful degradation if absent.
`/pair-capability-assess-testing`	Capability	Optional — testing strategy assessment. Graceful degradation if absent.
`/pair-capability-assess-infrastructure`	Capability	Optional — infrastructure assessment. Graceful degradation if absent.
`/pair-capability-assess-observability`	Capability	Optional — observability assessment. Graceful degradation if absent.
`/pair-capability-assess-methodology`	Capability	Optional — methodology assessment. Graceful degradation if absent.
`/pair-capability-assess-pm`	Capability	Optional — PM tool assessment (delegates to /pair-capability-setup-pm). Graceful degradation if absent.
`/pair-capability-assess-ai`	Capability	Optional — AI development tools assessment. Graceful degradation if absent.

Phase 0: PRD Verification (BLOCKING)

Step 0.1: Check PRD State

Check: Does adoption/product/PRD.md exist and is it populated (not a template)?
- A file is a template if it contains [Product/feature name] or [Creation date].
Skip (populated PRD): Extract project name and key constraints. Move to Phase 1.
Act (missing or template): Compose /pair-process-specify-prd.
- Wait for PRD approval before proceeding.
Verify: PRD exists and is populated. If not → HALT.

Step 0.2: Extract Key Constraints from PRD

Act: Read PRD and extract:
- Target users and scale expectations
- Budget and timeline constraints
- Team size and technical skills
- Compliance and integration requirements
- Key features (P0/P1/P2)
Verify: Key constraints documented in session state.

Phase 1: Project Categorization

Step 1.1: Check Existing Categorization

Check: Does adoption/decision-log/ contain a *-project-categorization.md file?
Skip: If categorization already recorded, read it and move to Phase 2.
Act: Proceed to categorization analysis.

Step 1.2: Categorize Project

Act: Evaluate project indicators from PRD:
- Team size and budget constraints
- Scale expectations and performance needs
- Compliance and integration complexity
- Timeline pressures and market requirements
Act: Present categorization with evidence:
Based on PRD analysis, this project fits [Type X] categorization:
- Type A (Pet/PoC): Small team (1-3), minimal budget, single user or small group, no compliance, fast iteration
- Type B (Startup/Scale-up): Growing team (3-15), moderate budget, scaling users, some integrations, rapid growth
- Type C (Enterprise): Large team (15+), significant budget, many users, compliance requirements, complex integrations
Evidence: [specific PRD indicators]

Does this categorization match your project?
Act: On confirmation, compose /pair-capability-record-decision:
- $type: non-architectural
- $topic: project-categorization
- $summary: "Project categorized as Type [X] — [category name]"
Verify: Categorization decision recorded.

Phase 2: Checklist Completion

Step 2.1: Check Existing Adoption Files

Check: Scan adoption/tech/ for existing files. Classify each as populated or template:
- architecture.md
- tech-stack.md
- infrastructure.md (optional — not all project types need it)
- ux-ui.md (optional — not all project types need it)
- way-of-working.md
Skip: Files that are already populated — do not re-generate.
Act: Build a checklist of missing or template files to complete.

Step 2.2: Assessment Phase (Optional)

Check: Are assess-* skills installed? Scan installed skills directory for assess-* skills.

Act (installed): Compose assess-* skills in recommended sequence. Each skill checks its own adoption file first — already-decided domains are skipped automatically (resolution cascade).

Recommended sequence (respects adoption file dependencies):

/pair-capability-assess-architecture → writes architecture.md (needed by stack and infrastructure)
/pair-capability-assess-stack → writes core sections of tech-stack.md (needed by testing and AI)
/pair-capability-assess-testing → writes testing section of tech-stack.md
/pair-capability-assess-ai → writes AI section of tech-stack.md
/pair-capability-assess-infrastructure → writes infrastructure.md (needed by observability)
/pair-capability-assess-observability → writes observability section of infrastructure.md
/pair-capability-assess-methodology → writes methodology section of way-of-working.md
/pair-capability-assess-pm → writes PM section of way-of-working.md (delegates to /pair-capability-setup-pm)

Section ownership (prevents parallel write conflicts):

Adoption File	Section	Owner Skill
`architecture.md`	Full file	`/pair-capability-assess-architecture`
`tech-stack.md`	Core sections	`/pair-capability-assess-stack`
`tech-stack.md`	Testing section	`/pair-capability-assess-testing`
`tech-stack.md`	AI section	`/pair-capability-assess-ai`
`infrastructure.md`	Core sections	`/pair-capability-assess-infrastructure`
`infrastructure.md`	Observability	`/pair-capability-assess-observability`
`way-of-working.md`	Methodology	`/pair-capability-assess-methodology`
`way-of-working.md`	PM tool	`/pair-capability-assess-pm`
`way-of-working.md`	Quality gates	`/pair-process-bootstrap` (Step 3.2)

Parallel safety: Skills writing different adoption files can run in parallel. Skills writing different sections of the same file are safe if each respects section ownership. The recommended sequence avoids any conflicts.

Partial installation: If only some assess-* skills are installed, compose those and skip the rest with a warning. Each assess-* skill is independent — partial installation is supported.

Act (not installed): Warn and proceed with manual assessment:

assess-* skills are not yet installed. Proceeding with manual assessment. For each technical area, I'll reference the guidelines and ask you to make decisions directly.
Verify: Assessment data collected (via skills or manually). All adoption files written by assess-* skills are consistent.

Step 2.3: Gather Information per Section

For each missing adoption file, work through the relevant checklist section. Reference the Bootstrap Checklist for section-specific questions.

Architecture — scale, integrations, compliance, patterns
- Reference: Architecture Guidelines
Tech Stack — languages, frameworks, libraries with versions
- Reference: Technical Standards
Infrastructure — deployment, CI/CD, monitoring, environments
- Reference: Infrastructure Guidelines
UX/UI — design system, accessibility, device support
- Reference: UX Guidelines
Way of Working — processes, quality gates, release cycles
- Reference: Collaboration Guidelines

Rules:

Ask 3-4 focused questions per section
Wait for developer responses before proceeding
Record each significant decision via /pair-capability-record-decision (non-architectural → ADL, architectural → ADR)

Phase 3: Standards Generation

Step 3.1: Generate Adoption Documents

For each missing adoption file (in order: architecture → tech-stack → infrastructure → ux-ui → way-of-working):

Check: Is this file already populated? If yes, skip.
Act: Generate the document following:
- Adopted Standards format (if format guide exists)
- Concise, prescriptive English
- Specific versions and configuration details
- References to KB guidelines for detailed rationale
Act: Present key decisions with rationale for developer review.
Act: Iterate on feedback until approved.
Act: Save to adoption/tech/<filename>.md.
Verify: File written, consistent with other adoption files.

Step 3.2: Quality Gate Setup

Check: Does adoption/tech/way-of-working.md already contain a Custom Gate Registry with entries?
Skip: If quality gates already configured, move to Phase 4.
Act: Ask the developer:

Quality gate setup: The standard pipeline includes: type checking, testing, linting, formatting.

Do you want custom quality gates beyond the standard pipeline? Examples: security scanning, bundle size checks, smoke tests, accessibility audits.

If yes, describe the additional gates. If no, I'll configure the standard pipeline only.
Act: For each quality gate (standard + custom):
- Add entry to the Custom Gate Registry in way-of-working.md with: Order, Gate name, Command, Scope Key, Required flag, Description
- Create placeholder script entries (in package.json scripts or technology-specific equivalent) so the gate infrastructure is executable from day one
Act: Record quality gate decisions via /pair-capability-record-decision:
- $type: non-architectural
- $topic: quality-gate-setup
Verify: Quality gates documented in way-of-working and placeholder scripts exist.

Phase 4: Finalization

Step 4.1: Consistency Verification

Act: Re-read all adoption files:
- architecture.md
- tech-stack.md
- way-of-working.md
- infrastructure.md and ux-ui.md (if generated)
Act: Verify cross-document consistency:
- Tech stack versions match architecture references
- Way-of-working references correct tools from tech-stack
- Infrastructure aligns with architecture patterns
Act: Fix any inconsistencies found.
Verify: All documents are internally and cross-referentially consistent.

Step 4.2: PM Tool Configuration

Check: Is PM tool already configured in way-of-working.md?
Skip: If configured, confirm and move to Step 4.3.
Act: Compose /pair-capability-setup-pm. The skill handles tool selection, configuration, and ADL recording.
Verify: PM tool configured and recorded.

Step 4.3: Final Summary

Act: Present bootstrap completion summary to the developer for final approval:

Bootstrap complete. All adoption files generated and approved. Review the summary below and confirm everything is correct.
Verify: Developer approves. If not → iterate on specific concerns.

Output Format

BOOTSTRAP COMPLETE:
├── PRD:             [verified | created via /pair-process-specify-prd]
├── Categorization:  [Type A | Type B | Type C] — [ADL path]
├── Adoption Files:
│   ├── architecture.md:    [generated | existing | skipped]
│   ├── tech-stack.md:      [generated | existing | skipped]
│   ├── infrastructure.md:  [generated | existing | skipped | n/a]
│   ├── ux-ui.md:           [generated | existing | skipped | n/a]
│   └── way-of-working.md:  [generated | existing | skipped]
├── Quality Gates:   [N gates configured — standard + custom]
├── PM Tool:         [configured via /pair-capability-setup-pm | already configured]
├── Decisions:       [N decisions recorded (ADR: X, ADL: Y)]
└── Status:          [Complete | Partial — details]

HALT Conditions

PRD missing or template and /pair-process-specify-prd fails (Phase 0) — cannot bootstrap without product context
Project categorization rejected (Phase 1) — developer must confirm before technical decisions
Critical technical decision unresolved (Phase 2) — cannot generate adoption files with gaps
Adoption file generation rejected (Phase 3) — each document needs developer approval

On HALT: report the blocker clearly, propose resolution, wait for developer.

Idempotent Re-invocation

Re-invoking /pair-process-bootstrap on a partially completed project is safe and expected:

PRD: detects existing populated PRD, skips Phase 0.
Categorization: detects existing ADL entry for project-categorization, skips Phase 1.
Adoption files: checks each file individually — only generates missing/template files.
Quality gates: detects existing Custom Gate Registry entries, skips Step 3.2.
PM tool: detects existing configuration in way-of-working, confirms and skips.
Decisions: existing ADL/ADR entries are not re-created.

Phase completion is detected via output file existence — never re-does completed work.

Graceful Degradation

assess-* skills not installed: Skip assessment phase, reference guideline files directly, ask developer for manual decisions. Log: "assess-* skills not installed — using manual assessment."
/specify-prd not installed: HALT at Phase 0 if PRD is missing. Suggest creating PRD manually using how-to-01.
/setup-pm not installed: Skip PM configuration in Phase 4. Warn: "PM tool not configured — /pair-capability-setup-pm not installed."
/record-decision not installed: Skip decision recording. Warn: "Decisions not recorded — /pair-capability-record-decision not installed. Document decisions manually in adoption files."
Bootstrap checklist asset not found: Use Phase 2 section questions as fallback — they cover the same areas.
Adoption directory doesn't exist: Create adoption/tech/ and adoption/decision-log/ on first write.

Notes

This is the most complex process skill — it orchestrates the full project setup sequence.
Each phase is independent: completion of one phase doesn't require re-running previous phases.
The developer can stop between phases. Re-invoke to resume (idempotency ensures correct state).
All decisions during bootstrap are recorded via /pair-capability-record-decision. Non-architectural → ADL. Architectural → ADR.
Quality gate setup ensures the gate infrastructure is executable from day one (not deferred to first implementation).
Content source: how-to-02 Phases 0-4. How-to-02 retains orchestration flow, this skill has operational detail.

pair-process-bootstrap

SKILL.md.claude/skills/pair-process-bootstrap/SKILL.md