intake

Purpose

Authors high-quality intake issues: the write-side twin of /engineer's claim side. An intake issue decides WHAT (the problem, its impact, its evidence) and highlights OUTCOMES (what must be observably true when it's fixed). The engineer's DECIDE phase owns HOW. A great intake issue lets a zero-context engineer start debugging immediately — from the evidence in the issue alone — without anchoring them to the filer's first idea of a fix.

This skill applies whether the filer is the operator (from chat or phone) or an agent filing on the operator's behalf (halt monitor, follow-up proposals, bugs discovered mid-build). GitHub's intake issue form (.github/ISSUE_TEMPLATE/intake.yml) scaffolds the same shape on web/mobile; anything filed via gh issue create must follow it by hand — this skill is how.

The Intake Shape

Four sections. Three are required.

Section	Required	Contents
Observed	yes	Evidence of the problem — verbatim artifacts, not narrative
Impact	yes	One line minimum: who or what hurts, how often, what it costs / unblocks
Desired outcome	yes	Observable behavior that must hold afterward
Hypotheses	no	The filer's guesses about HOW — explicitly labeled as guesses

Practices

1. Gather Evidence First — While Context Is Warm

Collect concrete artifacts before writing a word of prose. Evidence is cheapest at the moment of observation; an hour later the logs have rotated and the repro is fuzzy.

Collect whichever of these exist:

• Exact commands + verbatim output. Copy the real invocation and the real output, trimmed to the relevant lines. Never paraphrase an error message — the exact string is what the engineer will grep for.
• Log excerpts with their source path and timestamp. e.g. .daemon/daemon.log, monitor.log, CI run URLs. Include a few lines of surrounding context, not just the one scary line.
• Precise references. file:line, commit SHAs, PR/issue numbers, run IDs. These are evidence, and always welcome — a file path cited as proof is not a "how".
• Reproduction steps. The minimal sequence a zero-context reader could run to see the problem. State what you expected vs what happened.
• Frequency and scope data. How many times, since when, how widespread — a grep count, a ledger scan, "3 of the last 5 daemon runs". Turns anecdote into signal.
• Environment facts when plausibly relevant: versions, branch, config values.