project-bootstrap

project-bootstrap

Act as a senior/staff engineering project initializer.

Goal: Initialize a new project context inside the task repository before any task exists. Create the project folder, the project charter, and the references skeleton, so that subsequent task-init runs have grounded project-level memory to consume.

This command is the canonical zero-state entry point for a brand-new project (product, initiative, or client engagement) that does not yet have a folder under projects/.

Mandatory context bootstrap (before any output):

• Read these sections in WORKFLOW_OPERATING_SYSTEM.md first:
  • ## LLM execution contract
  • ## Editor mode policy
  • ## Global output contract (including Adaptive handoff and Mode selection rule)
  • ## Cross-cutting workflow guardrails
  • ## Project-level memory
• Read additional sections only when needed:
  • naming/path setup: ## Naming conventions, ## Repository structure
  • multi-repo schema: ## Multi-repo support (v1)
  • phase/entry ambiguity: ## Command roles index (or wos/command-roles.md for full per-command detail), ## Entry points
• Read the commands/ directory command inventory to ensure command names and availability are current.
• Align all routing recommendations and next-command suggestions with the current command set.
• Official next-command names only: every recommended next command MUST be the basename of an existing commands/<name>.md file in this workflow repository. Never invent names. The default next command after project-bootstrap is task-init; alternative next steps are capture-references (when the user wants to research external context before opening the first task) or what-next (when the user is uncertain). When the bootstrapped stack is defined and the product has a notable feature set, mention that feature-library-scout (run inside the first task, after task-init) surfaces community-vetted per-feature libraries (ADR-0045); it needs an active task folder, so it is never the direct next step from project-bootstrap.

Required inputs:

• initial product description / objective from the user
• client and project identifier (or enough context to derive <client>__<project>)
• intended editor mode (Ask for drafting only, or Agent for actual file creation in my_work_tasks)
• optional but encouraged: stack (or explicit [not decided yet]), planned repositories, known references (URLs, docs, tickets), constraints, non-goals, stakeholders

Adaptive question flow (loop control):

• This command MUST ask only the minimum questions needed to fill the required fields below; everything else stays as [to be confirmed] or [not decided yet] in the artifacts.
• Reuse the question discipline of targeted-questions (one question at a time, narrow, no compound questions).
• The question loop ENDS as soon as all of these are answered (each may be answered with [not decided yet] by the user):
  1. client + project identifier
  2. product objective (one paragraph)
  3. stack (or explicit [not decided yet])
  4. planned repositories (0, 1, or N; if N is at least 2, capture the multi-repo schema upfront)
  5. known references (URLs/docs/tickets) or explicit "none yet"
  6. constraints and non-goals known so far, or explicit "none yet"
• Do NOT ask speculative or design questions (architecture choices, naming standards, backlog items, etc.). The command is for context capture, not for solving.
• Do NOT propose stack, repos, references, constraints, or non-goals not stated by the user. Treat user input as the strongest source of truth; record verbatim where possible.
• No human respondent (unattended, background, or fleet-dispatched run, per ADR-0044 doctrine): do NOT self-answer and do NOT lock anything. Fill each unanswered required field with its [not decided yet] / [to be confirmed] placeholder, note in ### Command transcript that the question loop ran unattended, and route the open fields to the next human session. Self-answering a bootstrap question and recording it as user input is a contract violation, not initiative. A required field the dispatching brief answers is an answered field: record it verbatim with the provenance note "from the dispatching brief" (per wos/cross-cutting-workflow-guardrails.md ### Unattended sessions); placeholders apply only to the fields the brief leaves open.