Agent-Harness-Kit: Skill for Claude Code

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.

1. Read ../../../harness/playbooks/first-run.md and the discovery-interviewer role it references.
2. Test ../../../harness-state/PROJECT-CONTEXT.md only if it exists in the host. Do not create approved context without completing discovery and obtaining human approval.
3. 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, a brief notice that the user may choose standard delivery (accompanied by default), autonomous end-to-end delivery, or the faster hackathon mode for a time-boxed MVP/demo, and exactly one highest-leverage unanswered discovery question.
4. 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.
5. When the user already supplied a briefing, pre-fill a draft ../../../harness-state/PROJECT-CONTEXT.md before claiming it was recorded and cite its revision. Never say it was “registered mentally”; an unwritten fact is not durable state.
6. For mature hosts, use ../../../harness/playbooks/mature-harness-adoption.md; never overwrite existing root or platform-native authorities.
7. Inventory actual rules and capabilities without assuming installation, authentication, secrets, network, or authorization.
8. After product intent is known, resolve architecture and folder organization adaptively before context approval. Reuse approved context; otherwise inspect existing evidence, preserve a proven existing shape, and ask for correction/approval. When evidence is absent or ambiguous, let the user specify, choose among evidence-based options, or delegate a recommendation. Coding conventions are optional: detect them first, then ask only when absent and accept normal stack defaults or no preference.
9. Produce neutral artifacts. Do not plan implementation until context is approved. Then route through writing-plans: create a ready plan for non-simple work or a compact inline spec for a simple task before the initial graph and dispatch.
10. Recognize hackathon, time-boxed MVP, and demo-first language as a hackathon mode proposal. 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.