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 and the faster hackathon mode for a time-boxed MVP/demo are available. This is informational, not a recommendation or a second discovery question.

# First-run discovery

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/`.