First Run Discovery

---
name: first-run-discovery
description: Run adaptive discovery when shared project context is absent, unapproved, stale, or a mature harness needs staged adoption.
---

The required welcome also tells the user briefly that standard delivery (accompanied by default), autonomous end-to-end delivery, and the faster hackathon mode for a time-boxed MVP/demo are available. Include the mode preference in the single kickoff question when unanswered; never add a second question or repeat an already explicit choice.

# First-run discovery

Follow `../../../docs/DELIVERY-MODES.md`: even for a greeting-only first message such as "oi" or "hello", check initialization; if uninitialized, begin the visible reply with the kit-active welcome, then ask the unanswered mode preference in one cohesive kickoff question alongside any missing product intent. Offer standard delivery (accompanied by default), autonomous end-to-end delivery, and hackathon. Correct questions without the welcome are incomplete; self-check and rewrite before sending if it is missing. Record the selected preset, interaction, and scope limits in consolidated context approval without an extra questionnaire. Preserve approved choices on resume. Autonomous changes participation, not agent count, verification, authority, or learning consent.

Do not activate for an explicit request that passes the shared `direct-trivial` gate; make that bounded edit directly. If target inspection exposes behavior, ambiguity, risk, or broader impact, return here before implementation.

Follow `../../../harness/playbooks/first-run.md` and the neutral discovery role. On an uninitialized project's first response, stop before answering the substantive request. Restrict the response to a localized welcome saying Agent Harness Kit is active, the short explanation that it organizes project context, pending work, and verifiable execution, a discovery-before-proposals statement, and exactly one highest-leverage unanswered discovery question. In an empty or effectively empty project, do not propose anything first. Include no recommendation, inferred company fact, branding, color, product scope, feature, design, architecture, stack, implementation step, plan, status, or graph. Treat model memory and prior conversations as unverified; only the current user message and approved artifacts can establish project facts. Before sending, replace a response that contains a proposal or more than one question with the restricted handshake. When a briefing exists, write a draft `../../../harness-state/PROJECT-CONTEXT.md` before calling it recorded and cite its revision; never claim it was “registered mentally.” For mature hosts, use `../../../harness/playbooks/mature-harness-adoption.md`; do not overwrite existing root or platform files. After product intent is known, resolve architecture and folder organization adaptively before context approval: reuse approved context, otherwise inspect and preserve strong existing evidence, or let the user specify, choose evidence-based options, or request a recommendation. Coding conventions are optional; detect them first and ask only when absent, accepting stack defaults or no preference. Recognize hackathon, time-boxed MVP, and demo-first language as a `hackathon` mode proposal and follow `../../../harness/playbooks/hackathon-delivery.md`: at most two cohesive discovery questions unless consequential safety or authority blocks execution, then one spec-driven demo-first graph split by isolated workstream/agent/context. Inventory actual capabilities and rules, obtain context approval, then route through `writing-plans` before creating the initial graph: ready plan for non-simple work, compact inline spec for simple work. Canonical outputs belong in neutral paths, not `.claude/`.