Onboarding — turning documents into project context

What you need: A scaffolded project-state/ directory.

Scaffolding creates the empty substrate. Onboarding fills it with context from your existing project documents. These are different operations, and they run as different skills — but onboarding is designed to run immediately after scaffolding.

The inbox-first approach

The pattern is simple: drop files, triage, promote.

1. Copy your project documents into project-state/documents/inbox/. Anything works — PDFs, Word docs, spreadsheets, slide decks, markdown files. The inbox is a staging area, not a permanent location.

2. Run the triage:

/project-inbox

3. The inbox skill reads each document, scores its relevance, and produces a triage summary:

# Inbox Triage — 2026-05-28

| # | Document                        | Type          | Relevance | Route         |
|---|--------------------------------|---------------|-----------|---------------|
| 1 | Contribution-Agreement-v2.pdf  | legal         | high      | imprint       |
| 2 | Project-Charter-Draft.docx     | planning      | high      | imprint       |
| 3 | Weekly-Standup-Notes-W19.md    | status        | medium    | reference     |
| 4 | Vendor-Quote-Enzymes.pdf       | procurement   | low       | reference     |
| 5 | Team-Slack-Export.json          | communication | medium    | intel         |

Imprint documents: 2 (will seed onboarding context)
Reference documents: 2
Intel documents: 1

Documents classified as "imprint" are the high-value ones — project charters, contribution agreements, proposals, grant applications. These contain the information that seeds milestones, stakeholders, risks, and goals.

What the inbox extracts

The triage produces two things:

1. Classification metadata — each document gets a type, relevance score, and routing recommendation.
2. Orientation YAML — for imprint documents, the inbox extracts structured data: project goals, named stakeholders, timeline commitments, budget figures, deliverable lists, risk factors.

This orientation data flows directly into the onboarding skill. When you run:

/project-onboarding

The nine onboarding chapters check for inbox-orientation data first. If it exists, the onboarding flow uses PreFilledField components — instead of asking "What are your project milestones?", it says "The project charter mentions these milestones. Confirm or edit:"

Milestone 1: Pilot-scale extraction protocol validated    [confirmed]
Milestone 2: Regulatory pre-submission package complete   [confirmed]
Milestone 3: Cost-per-kg target met at bench scale        [edit → "...at pilot scale"]

The difference between blank-slate onboarding and inbox-primed onboarding is significant. With documents, onboarding takes 10-15 minutes of confirmation. Without documents, it takes 30-45 minutes of answering questions.

The nine chapters

The onboarding skill runs as a guided 9-chapter flow:

1. Project identity — name, organization, kind, timeline
2. Stakeholders — people, roles, organizations, contact info
3. Milestones — deliverables, target dates, owners
4. Risks — known risks, likelihood, impact, mitigation
5. Decisions — key decisions already made
6. Surfaces — where to publish (Slack, Gmail, blog, website, calendar)
7. Reporting matrix — what reports, for whom, at what cadence
8. Phase configuration — current phase, gate status
9. Context documents — goals, scope, constraints, background

Each chapter writes directly to the substrate. By the end, you have populated milestones/, risks/, decisions/, and documents/references/ directories, a filled-in manifest.yaml, and a working reporting-matrix.yaml.

Output artifacts

After onboarding completes, the substrate contains:

project-state/
├── manifest.yaml                    # Filled with real stakeholders and contacts
├── reporting-matrix.yaml            # Configured for your stakeholder groups
├── state.json                       # Phase set, counters updated
├── milestones/
│   ├── M01-pilot-extraction.yaml    # From chapter 3
│   ├── M02-regulatory-package.yaml
│   └── M03-cost-target.yaml
├── risks/
│   ├── R-01-enzyme-supply.yaml      # From chapter 4
│   └── R-02-regulatory-timeline.yaml
├── decisions/
│   └── 2026-05-28-extraction-method.yaml  # From chapter 5
├── documents/
│   ├── references/
│   │   ├── goals.md                 # Extracted from imprint docs
│   │   └── context.md               # Background, constraints, scope
│   └── inbox/                       # Now empty (documents promoted)
└── logs/
    └── activity.ndjson              # Every onboarding action logged

Without documents

Onboarding works without any inbox documents. The chapters still run — they just ask questions instead of presenting pre-filled confirmations. You type the answers, and the same substrate gets created.

The inbox-first approach is faster and more accurate (documents don't forget details), but it's not required. Some projects start with nothing but a conversation.

Next step

The substrate is populated. The natural question becomes "what should I do now?" The daily routine shows how the orchestrator reads your state and calendar to answer that question every day.