Docs Workflow Bootstrap
Create only the durable documentation convention the repository will actually use.
Inspect and confirm
- Read repository instructions and existing documentation, ADR, issue, roadmap, Feature, and tracker conventions.
- Reuse existing locations. Do not create a parallel
docs/ tree beside a working convention.
- Determine whether the user wants Milestone-grouped Features or standalone flat Features. Show the exact roots and files that would be created or adapted, then ask the user to confirm before scaffolding. Never introduce Milestones merely to choose a directory layout.
- Create no placeholder Milestones, Features, Tasks, specs, designs, plans, or tracker records.
Use references/feature-convention.md only when no stronger local form exists. The same Feature layout works with an external tracker, the optional local-work-tracker, or no operational tracker. This setup skill does not choose or initialize a tracker.
Offer docs/context/ for glossary and durable context and docs/architecture/decisions/ for qualifying ADRs only when useful. A user may request either location without accepting the delivery layout.
Do not create substantive requirements, Milestone scope, Feature ownership, specifications, technical designs, Task graphs, implementation plans, identity configuration, branch policy, labels, or code. Finish after reporting created, reused, and deliberately omitted locations.
1---2name: docs-workflow-bootstrap3description: Explicitly scaffold or adapt an optional repository-local Markdown convention for requirement and completion indexes, shared Milestones, Feature-owned specifications and designs, and nested child Task contracts. Use only when a team asks Waypoint to initialize human-readable engineering documentation without requiring local tracking or a fixed workflow.4---56# Docs Workflow Bootstrap78Create only the durable documentation convention the repository will actually use.910## Inspect and confirm11121. Read repository instructions and existing documentation, ADR, issue, roadmap, Feature, and tracker conventions.132. Reuse existing locations. Do not create a parallel `docs/` tree beside a working convention.143. Determine whether the user wants Milestone-grouped Features or standalone flat Features. Show the exact roots and files that would be created or adapted, then ask the user to confirm before scaffolding. Never introduce Milestones merely to choose a directory layout.154. Create no placeholder Milestones, Features, Tasks, specs, designs, plans, or tracker records.1617Use [references/feature-convention.md](references/feature-convention.md) only when no stronger local form exists. The same Feature layout works with an external tracker, the optional `local-work-tracker`, or no operational tracker. This setup skill does not choose or initialize a tracker.1819Offer `docs/context/` for glossary and durable context and `docs/architecture/decisions/` for qualifying ADRs only when useful. A user may request either location without accepting the delivery layout.2021Do not create substantive requirements, Milestone scope, Feature ownership, specifications, technical designs, Task graphs, implementation plans, identity configuration, branch policy, labels, or code. Finish after reporting created, reused, and deliberately omitted locations.
adol1111