crew-kickoff

Crew Kickoff Sequence

This skill defines the canonical startup sequence for a new engineering crew initiative. Follow it to avoid the most common failure mode: specialists building before the architecture is clear.

---

Step 0 — Receive the initiative

Morgan collects the raw brief:

• What problem are we solving?
• Who are the users / stakeholders?
• What is the rough deadline or timeline?
• What hard constraints exist (budget, existing tech stack, compliance, integrations)?
• What does success look like in 3 months?

Write this down in a docs/architecture/BRIEF.md before anything else.

---

Step 1 — Morgan briefs Archie

Morgan hands Archie the brief and asks for:

1. SYSTEM.md — component map, boundaries, non-goals, crew handoff table
2. The ADRs for each major decision (storage, communication pattern, auth strategy, deployment model)
3. The artefacts each specialist needs before they can start
4. A seeded beads board — one task per work item, wired with dependencies (the roadmap; no flat DELIVERY-MAP.md)

Morgan gives Archie enough time to do this properly. No specialist work starts during this step.

---

Step 1.5 — Ensure the shared task board exists

The roadmap lives on the shared beads board, not in a file. Before Archie seeds work, initialise beads in the project (once) and wire the harness hooks. Full install and operation steps are in the beads skill (plugins/engineering/skills/beads/SKILL.md) — don't repeat them here. In short: bd init, then bd setup copilot / bd setup claude; commit .beads/issues.jsonl, gitignore the Dolt DB. The crew works the board via the beads/* MCP.

---

Step 2 — Archie produces the architecture

Archie creates docs/architecture/ with at minimum:

docs/architecture/
├── SYSTEM.md
├── adr/
│   └── ADR-001-*.md   (one per major decision)
└── <relevant subdirectories for this system>
    ├── api/openapi.yaml
    ├── schema/erd.md + init.sql
    ├── frontend/DESIGN.md   ← design tokens (colours, type, spacing, components)
    ├── frontend/pages.md + flows.md
    ├── infra/topology.md + slos.md
    └── data/pipelines.md

Only create what is relevant. A pure backend service won't need frontend/. Alongside these artefacts, Archie seeds the beads board — one task per work item, wired with dep links and acceptance criteria, left unassigned for Morgan.

---

Step 3 — Morgan and Archie review the plan

Before handing off to specialists:

• Does SYSTEM.md correctly describe the problem and scope?
• Is every ADR written for decisions that are hard to reverse?
• Does each specialist have a concrete artefact to build against?
• Does the beads board have a task per work item, with explicit dep links and acceptance criteria?
• Are there any decisions marked "TBD" that would block Phase 1? Resolve them.

---

Step 4 — Morgan opens Phase 1 work

Morgan assigns and sequences the board: for each ready Phase 1 task, update it with an owner and priority, then hand the delegation payload to that specialist:

**To**: <crew member>
**Task**: <one clear deliverable>  (beads: <task id>)
**Build against**: `docs/architecture/<path>` — section: <specific section>
**Done when**: <acceptance criteria>
**Blocked by**: <dependency, if any>
**Sync needed with**: <other crew member, if outputs touch>

Specialists receive this context — not a verbal description, a written delegation.

---

Step 5 — Build phase

Crew builds. Morgan checks in at cadence (not daily — trust the crew):

• Blockers surfaced immediately → loop in Archie or the relevant crew member
• Scope creep flagged → decision from Morgan, not the specialist
• Design ambiguity → always back to Archie, never assumed by the implementer

---

Step 6 — Phase boundary review

Before Phase N+1 begins:

1. Morgan delegates Sherlock: "Review Phase N output against docs/architecture/"
2. Sherlock produces a review with pass/fail per artefact section
3. Any divergence: Archie decides whether to adjust the design or adjust the implementation
4. Hawke confirms: golden signals instrumented, alert rules written, runbooks linked
5. Morgan signs off — Phase N is closed, Phase N+1 is opened

---

Antipatterns to avoid

Antipattern	Why it hurts	Correct action
Specialist starts implementing from a Slack message	Builds the wrong thing	Archie must produce a spec file first
Archie writes a design doc nobody reads	Work diverges silently	Morgan enforces the artefact-first gate
Design decisions made in PR reviews	Too late, too expensive	Design ambiguity → Archie before coding
Sherlock reviews only at the end	Architectural drift compounds	Phase-boundary reviews after every phase
Morgan re-scoping work without Archie's input	Phase plan diverges from technical constraints	Design changes → back to Archie; he re-seeds/edits the affected board tasks