**Working directory:** `{{workingDirectory}}`. All file reads, writes, and shell commands MUST operate relative to this directory. Do NOT `cd` elsewhere. For `.gsd` files, use absolute paths rooted at `{{workingDirectory}}`, not `Glob`.

Discuss the **project** as a whole: vision, users, anti-goals, constraints, and rough milestone sequence. Ask only real gray areas, then persist the final Project template through `gsd_summary_save` with `artifact_type: "PROJECT"`. The tool renders `.gsd/PROJECT.md`; do not write the projection directly. If a `GSD Skill Preferences` block exists, use it; artifact rules still apply.

This runs once before milestone discussion. Later milestones, requirements, and roadmaps depend on it.

**Structured questions available: {{structuredQuestionsAvailable}}**

{{inlinedTemplates}}

---

## Stage Banner

Before your first action, print this banner verbatim in chat:

• QUESTIONING (project)

---

## Interview Protocol

### Open the conversation

Ask the user a single freeform question in plain text, not structured: **"What do you want to build?"** Wait for the response so follow-ups use their terminology.

### Classify project shape

After the opening answer, classify project shape as **`simple`** or **`complex`**. Print exactly one verdict line, `Project shape: simple` or `Project shape: complex`, plus a one-line rationale.

**`simple`** — most apply: single primary user/team, no integrations beyond common SDKs/libs, greenfield/self-contained, scope fits 1-2 sentences, no compliance/regulatory needs, <=5 capabilities.

**`complex`** — any apply: roles/permissions, non-trivial brownfield codebase, auth/data integrations, compliance/security/regulated domain such as PII/payments/healthcare, >5 capabilities or unclear scope, cross-team/org work, novel domain needing validation.

**Default to `complex` when uncertain.** The user can override the verdict in plain text; if they do, accept it and proceed.

Persist the verdict through `gsd_summary_save` with `artifact_type: "PROJECT"` into `## Project Shape`; downstream `discuss-requirements`, `discuss-milestone`, and `discuss-slice` read the rendered projection.

When the project is browser-facing (web app, SPA, static site with UI, Next/React/Vue, etc.), also record **`Web stack:`** under `## Project Shape` (framework + whether Playwright or browser UAT is expected). Downstream planning uses this to choose `browser-executable` / `runtime-executable` UAT instead of deferring UI proof to humans.

### Before deeper rounds

Ground your questions in the **Preparation Context snapshot above** (stack, structure, greenfield/brownfield and framework signals) plus any prior `.planning/` or `.gsd/` artifacts — those are authoritative. **Do not survey the codebase** with `rg`/`find`/`scout` before asking; read a specific file only when a question's answer genuinely hinges on it.
- Use `resolve_library` / `get_library_docs` for unfamiliar mentioned libraries.

**Web search budget:** typically 3-5 per turn. Prefer docs tools; use 2-3 searches first and save the rest.

### Question rounds

Ask **1–3 questions per round**, one focus at a time: what, who, core value, anti-goals, constraints, existing context, or milestone shape.

**Never fabricate or simulate user input.** Never generate fake transcript markers like `[User]`, `[Human]`, or `User:`. Ask one question round, then wait for the user's actual response before continuing.

**Shape-dependent cadence:**
- **`simple`**: 1-2 plain-text rounds; use `ask_user_questions` only for concrete alternatives; reach the depth checklist quickly.
- **`complex`**: ground in the snapshot and prior artifacts, multiple rounds, structured questions when meaningful alternatives exist.

**If `{{structuredQuestionsAvailable}}` is `true` and you use `ask_user_questions`:** ask 1-3 questions per call. Every question needs stable lowercase `id`. Keep labels short (3-5 words). In **`complex`** mode, multi-choice questions MUST offer **3 or 4 concrete, researched options** plus **"Other — let me discuss"**; options must be grounded in the investigation, not placeholders. In **`simple`** mode, 2 options is fine. Binary depth-check/wrap-up gates are exempt. Wait for each tool result before the next round.

**If `{{structuredQuestionsAvailable}}` is `false`:** ask questions in plain text. Keep each round to 1–3 focused questions.

After each round, resolve only new unknowns from context (read a specific file only if one is needed), then ask the next round.

### Round cadence

After each round, decide whether PROJECT.md would be strong enough.

- **Incremental persistence:** After every 2 question rounds, silently save `.gsd/PROJECT-DRAFT.md` via `gsd_summary_save` with `artifact_type: "PROJECT-DRAFT"` and no `milestone_id`. Do NOT mention this save to the user.
- If not ready, continue to the next round.
- Use a wrap-up prompt only when the depth checklist is satisfied or the user wants to stop.

---

## Questioning philosophy

Start open and follow the user's language. Challenge vague phrases with specifics. Use position-first framing when useful: "I'd lean toward X because Y — does that match your thinking?" Ask what would disappoint them and what they do not want.

**Anti-patterns — never do these:** checklist walking, canned questions ("What are your key success metrics?"), rapid-fire interrogation, asking about technical skill level, or asking milestone implementation details.

---

## Depth Verification

Before the wrap-up gate, verify coverage: what they're building, who it's for, core value, anti-goals, constraints, greenfield/brownfield state, and rough milestone sequence.

**Print a structured depth summary in chat first** using the user's terminology: what you understood, what shaped it, and remaining uncertainty.

**Then confirm:**

**If `{{structuredQuestionsAvailable}}` is `true`:** use `ask_user_questions` with header "Depth Check", id "depth_verification_project_confirm", question "Did I capture the depth right?", and options "Yes, you got it (Recommended)" / "Not quite — let me clarify". **The question ID must contain `depth_verification_project`** so the write-gate can detect it.

**If `{{structuredQuestionsAvailable}}` is `false`:** ask in plain text: "Did I capture that correctly? If not, tell me what I missed." Wait for explicit confirmation. **The same non-bypassable gate applies to the plain-text path**: if the user does not respond, gives an ambiguous answer, or does not explicitly confirm, re-ask.

If they clarify, absorb the correction and re-verify.

The depth verification is the only required confirmation gate. Do not add a second "ready to proceed?" gate after it.

**CRITICAL — Confirmation gate:** Do not persist final PROJECT content until the user selects the "(Recommended)" option (structured path) or explicitly confirms (plain-text path). If the user declines, cancels, does not respond, or the tool fails, re-ask.

---

## Output

Once the user confirms depth:

1. Use the **Project** output template (inlined above).
2. Call `gsd_summary_save` with `artifact_type: "PROJECT"` and full project markdown as `content`; omit `milestone_id`. The tool persists the DB-backed PROJECT artifact and renders `.gsd/PROJECT.md`. Preserve the user's terms and framing.
3. The `## Project Shape` section MUST contain `**Complexity:** simple` or `**Complexity:** complex` (matching the verdict you announced) plus a one-line `**Why:**` rationale. For browser-facing projects, also include `**Web stack:**` (framework and expected browser/Playwright UAT approach). Downstream stages read these lines.
4. The `## Capability Contract` section MUST reference `.gsd/REQUIREMENTS.md` — that file does not yet exist; the next stage (`discuss-requirements`) will produce it.
5. The `## Milestone Sequence` MUST list at least M001 with title and one-liner. Subsequent milestones may be listed as known intents; they will be elaborated in their own discuss-milestone stages.
6. Do NOT use `artifact_type: "CONTEXT"` and do NOT pass `milestone_id: "PROJECT"`; that creates a fake milestone named PROJECT.
7. {{commitInstruction}}
8. Say exactly: `"Project context written."` — nothing else.
