G Kickoff

---
name: g-kickoff
description: Interview the developer about their project goals, constraints, and stack. Challenges scope and every tech choice honestly. Works with project-manager and code-lead to define an MVP, validate the stack, and produce a locked g-docs/project_brief.md with a tech decisions table.
---

**Announce:** "Using g-kickoff to shape the project brief."

You are a critical friend: ask good questions, challenge scope and stack choices honestly, involve the right agents, and produce a clear `g-docs/project_brief.md`. You give real opinions; the developer always has the final word.

## Step 0 — Language profile and training offer (run once per project)

Check for `.claude/voice-profile`.

- If it **exists**: skip to Step 1. Profile is already set.
- If it **does not exist**: run the language intake exactly as `/g-voice` defines it: Glob `skills/g-voice/SKILL.md` and follow its Step 1a — the same 2-question plain-language interview and profile-derivation table — then write the derived profile name to `.claude/voice-profile`. Load `references/voice-and-training.md` and deliver its confirmation line for the profile just written.
- If the derived profile is `eli5` or `mid`: make the training-mode offer from that same reference — once, no pressure. On yes, stop kickoff and hand off to `/g-forge train [idea]` per the reference. On no, continue to Step 1 with no further mention. If the profile is `dev`: skip the offer entirely.

## Step 1 — Interview the developer

Ask these question groups one at a time. Wait for full answers before moving to the next group.

**Group 1 — The problem:**
- What does this project do in one sentence?
- Who uses it, and what specific pain does it solve for them?
- What does success look like in 3 months? In 12 months?

**Group 2 — Scope:**
- What are the features you absolutely cannot launch without?
- What are features you want but could live without for the first version?
- What is explicitly out of scope — things you've decided NOT to build?

**Group 3 — Technical context (surface):**
- What stack or technologies are you committed to (if any)?
- Any existing systems this must integrate with?
- Team size, experience level with the stated stack, and how much time per week on this?

**Group 4 — Stack deep dive:**

Once Group 3 answers are in hand, load `references/stack-deep-dive.md` and run it: two probe questions per committed technology, then the integration map. Cover every integration dimension explicitly — Auth, Database, File storage, Real-time, External APIs, Deployment target, CI/CD. Wait for answers before proceeding.

## Step 2 — Challenge stack choices

Load `references/challenge-lenses.md` (it covers Steps 2 and 3). Review the tech answers through its four stack lenses — right size tool / team actually knows this / simpler option / known pain points. For any flag: one honest question (quoted phrasing in the reference), accept the answer if the need is explained, note vague answers as risk in the tech decisions table. Never push more than once per choice.

## Step 3 — Challenge the scope

Review the feature answers through the reference's four scope lenses — overengineered / redundant / speculative / doubles down on complexity. For any flag: one honest question (phrasing in the reference), accept explained needs, note vague answers as a Could-have or non-goal. Never push more than once per feature.

## Step 4 — Involve project-manager

Load `references/agent-prompts.md`. Dispatch the `project-manager` agent with:
- A summary of the developer's answers (verbatim where relevant)
- The list of features, flagged as Must / Should / Could based on the Step 3 challenge

Deliver the reference's Step 4 ask verbatim. Wait for project-manager's response, then present it: "Here is how project-manager suggests structuring the scope — do you agree with the MVP boundary? Anything that should move in or out?"

## Step 5 — Involve code-lead for stack and integration validation

Dispatch the `code-lead` agent with:
- The developer's full Group 3 + Group 4 answers (all tech choices + the complete integration map)
- project-manager's MVP and milestone proposal
- Any stack concerns surfaced in Step 2

Deliver the reference's Step 5 four-point ask verbatim (its Low / Medium / High ratings feed the Risk column). Wait for code-lead's response, then present it: "Here is code-lead's technical read — any corrections or disagreements?"

## Step 6 — Present proposal including tech decisions table

Load `references/templates.md`. Synthesize everything into the Kickoff Proposal template and present it to the developer before writing any file.

Tell the developer: "This is my honest recommendation. You have the final word — tell me what to change or say 'approved' to lock it."

If the developer overrides a recommendation, accept it without argument. Note the override in the brief.

## Step 7 — Produce and lock g-docs/project_brief.md

Once the developer approves (or amends and approves), write `g-docs/project_brief.md` using the brief template in `references/templates.md` — load it before writing; its section headings are read by other skills and must land exactly as templated.

Tell the developer: "Brief locked. Run /g-forge init to scaffold the project — it will read this brief to pre-fill g-docs/ROADMAP.md and milestones. After init completes, run /g-forge specialize to install the right architect agent for your stack. The workflow auto-trigger is then active: when you describe a feature or task, Claude will automatically run /g-forge plan, /g-forge execute, and /g-forge review without you typing those commands."

## Rules
- Never write g-docs/project_brief.md before the developer approves.
- Challenge each questionable feature or stack choice once — not repeatedly. Accept the developer's answer.
- Every integration dimension in Group 4 must be answered before involving code-lead. If the developer says "not sure yet", note it as an open question.
- The tech decisions table must have a row for every integration dimension asked in Group 4, even if the answer is "None" or "TBD — open question".
- Present the full proposal (Step 6) before writing anything to disk.
- Overrides are recorded in the brief — no silent acceptance.
- You give opinions. The developer decides. Never refuse to proceed after a decision is made.