Kickoff

Translation note: Originally authored in Portuguese (pt-BR) by Igor Uehara (igoruehara/spec-driven, MIT). Translated to English by this hub to keep the repository language consistent. Original content unchanged in meaning; see the upstream repo for the pt-BR source.

Skill: Project kickoff (Lean Inception + SDD)

You will interview, map, propose, and generate a roadmap. The first decision is the mode: the work for a project that is starting is different from one that already runs.

Conducting principles

• Ask in short batches with AskUserQuestion (max. 4 questions, 2-4 options each). Always offer a default "(Recommended)" as the first option; accept free-form "Other". When an axis opens a branched decision (choices that depend on each other — e.g.: architecture → bounded contexts → infra), replace the batch with a grilling session: run /clarificar.
• Do not invent architecture decisions. You propose options with trade-offs; the user decides.
• Do not raise or propose tools here — that is the /integracoes skill. The kickoff only makes a neutral offer (Phase 0.5) to connect. If /integracoes has already run, use the pulled inputs; otherwise, proceed without it and leave /integracoes as a roadmap item.
• Confirm a summary before generating files. Generate everything at once at the end.
• The final goal of both paths is the same: the project's constitution + an actionable roadmap to run with the team.

Phase 0 — Detect the mode

1. Inspect the directory: manifests (package.json, pyproject.toml, go.mod…), src/ with real code, git history, docs already filled in.
   • Only the boilerplate / empty repo → likely greenfield.
   • Existing product code → likely brownfield.
2. Confirm with AskUserQuestion: Greenfield (starting) · Brownfield (already running) · Hybrid (a base exists, but we will rethink). Route according to the answer.
3. Read README.md and CLAUDE.md to align with the SDD pipeline.

Phase 0.5 — Integration offer (neutral)

Connecting MCPs is orthogonal to the kickoff and is the job of the /integracoes skill. Here you only make a neutral offer — do not list or propose tools (the /integracoes skill raises the tooling; let the user say what they actually use there).

Ask with AskUserQuestion (one question, without citing tool names):

"Want to connect your tools via MCP now? Connecting first leaves the artifacts with real data (read-first)." — options: Connect now (recommended) · Proceed and connect later · Already connected.

• Connect now → run /integracoes and resume the kickoff with the pulled inputs (cite the source in the phases).
• Connect later → proceed only with the interview; /integracoes becomes an adoption roadmap item (Phase 5).
• Already connected → use the pulled inputs (cite the source) in the phases below.

/integracoes is re-runnable. Later, if a tool becomes helpful (pulling an epic, reading a PR), re-offer it at the point where the value appears — it doesn't have to be only here.

---

Phase 1A — [GREENFIELD] Discovery (Lean Inception)

Conduct the inception activities in batches of AskUserQuestion and generate one artifact per pillar (don't cram everything into a single doc — each pillar has its home):

1. Vision & scope → vision.md: the problem and for whom; category + differentiator; North Star; 2-3 things the product explicitly is NOT / does NOT do.
2. Stakeholders → stakeholders.md: who influences/is impacted (interest × influence) and how to engage each one.
3. Journeys → journeys.md: the 1-3 end-to-end journeys — stages, pain points, and opportunities.
4. Features → features.md: brainstorm from the journeys, classified by effort/value/confidence/UX and sequenced in waves (Wave 1 = MVP).
5. MVP → mvp-canvas.md: Wave 1 + the main hypothesis and the success criterion.

→ Outputs: vision.md · stakeholders.md · journeys.md · features.md · mvp-canvas.md. Wave 1 from features.md feeds roadmap.md (Phase 5).

Phase 1B — [BROWNFIELD] Map the current state (as-is)

Run the /mapear skill (same logic): read the code, interview the gaps, do the gap analysis of the 5 axes, and capture historical decisions as a retrospective ADR.

→ Outputs: docs/architecture/assessment.md (as-is + gaps) and the list of retrospective ADRs. These gaps feed Phases 2 and 5.

---

Phase 2 — Technical kickoff (the 5 axes)

One batch of AskUserQuestion per axis. Propose sensible defaults.

• Greenfield: these are decisions to make.
• Brownfield: these are decisions already made (capture as a retrospective ADR) + the ones the team wants to change (capture as a new ADR that replaces it, plus a roadmap item).

1. Tech stack — language, framework/runtime, package management, target version.
2. Base architecture — style (modular monolith / services / serverless), DDD layers (boilerplate default), and the bounded contexts (from the MVP in greenfield; validated in brownfield).
3. Infra — cloud, deployment model, environments, CI/CD, IaC.
4. Quality — test pyramid, minimum coverage, lint/format, static analysis (type-check, complexity, SAST/security — what is blocking vs warning), review policy, DoD.
5. Observability — structured logs, metrics, tracing, alerts, initial SLO/SLI.

Phase 3 — Confirmation

Show a summary in a table (decision → choice → becomes an ADR? new or retrospective?). Ask for OK.

Phase 4 — Document generation

Generate/update using the project's templates:

File	Mode	Template
docs/product/vision.md	greenfield	docs/product/_templates/vision.template.md
docs/product/stakeholders.md	greenfield	docs/product/_templates/stakeholders.template.md
docs/product/journeys.md	greenfield	docs/product/_templates/journeys.template.md
docs/product/features.md	greenfield	docs/product/_templates/features.template.md (classified + sequenced)
docs/product/mvp-canvas.md	greenfield	docs/product/_templates/mvp-canvas.template.md
docs/architecture/assessment.md	brownfield	docs/architecture/_templates/assessment.template.md
docs/architecture/context-map.md	both	existing (initial in greenfield; reverse-engineered in brownfield)
docs/architecture/overview.md	both	existing — consolidate the 5 axes + security + operational, with links to ADRs/context-map/diagrams/TESTING
docs/glossary.md	both	existing (seed the core terms)
CLAUDE.md	both	existing (fill in stack, commands, quality gates, observability)
docs/architecture/adr/NNNN-*.md	both	docs/architecture/adr/_template.md (one per structural decision; retrospective in brownfield)
docs/product/roadmap.md	both	docs/product/_templates/roadmap.template.md

docs/engineering/integrations.md and .mcp.json are generated by the /integracoes skill, not here. After context-map, offer to run /diagramar for the architecture diagrams (Mermaid).

Rules:

• ADRs: number after 0001. Greenfield: new decisions. Brownfield: retrospective (accepted status, recording the historical rationale) + new ones for proposed changes. Immutable.
• CLAUDE.md: fill in stack/commands/layers and add "Quality gates" and "Observability" blocks. Do not remove the existing SDD rules.
• Roadmap: low-risk quick wins first. In brownfield, include the incremental SDD adoption section (no big-bang: start with the next feature, backfill ADRs later).

Phase 4.5 — Project's agentic layer

Run the /camada-agentica skill (same logic): from stack + tools + process + domain, propose tuned rules, subagents, skills, and workflows/CI — with justification — and generate only what is approved. Unapproved items become roadmap items (Phase 5). Ref.: docs/engineering/agentic-layer.md.

Phase 5 — Roadmap and closing

• Run the /roadmap skill (same logic): build roadmap.md in Now/Next/Later, with value, effort, owner, and dependencies, quick wins first — to run and review with the team.
• If it is a git repository, offer git add -A && git commit -m "docs: kickoff do projeto".
• Summarize with clickable links and point to the next step: create the 1st feature in specs/NNNN-<nome>/ choosing the tier (see README.md).