intake

name	intake
description	Turn a fragmented owner ask into main ideas, a restated fuller picture, a skill-index map, and structured-choice owner questions — before building (understand-and-reflect, executable).

intake

Turn a fragmented owner ask about superbot-games into a verified fuller picture before building. Executable wrapper around the understand-and-reflect doctrine (CONSTITUTION.md working agreement) — not new policy. Provenance: superbot router Q-0254 (owner-directed 2026-07-07, graduated to the kit's CONSTITUTION/collaboration-model templates the same day) plus the Q-0263.2 paste-ready-questions directive. Invoke on any non-trivial, non-mechanical owner ask — especially a fragmented or associative one.

What this does

The owner builds ideas iteratively and in fragments by design — a rough draft now, more shape later — and relies on the agent to reason a partial idea forward to its fuller form (docs/owner-profile.md). This skill runs that step as a procedure: one inline restate that pays off twice — verification (a wrong assumption stated now costs one correction; found after an hour of building it costs the hour) and idea-expansion (the filled-in picture is itself new material the owner reasons against and redirects).

Invocation

/intake <the ask, or a pointer to it>

Instructions

1. CONSOLIDATE — reduce the fragmented ask to its few MAIN IDEAS (usually 1–3). Name each in one line. The owner thinks associatively on purpose; consolidation is your half of the contract. Idea order is not implementation order — capture side ideas, never derail on them.
2. RESTATE — state back, inline in your first substantive response (never as a separate blocking question), the fuller picture you built from the ask: the implied specs, the surrounding constraints, the likely intended scope, and the follow-on the owner probably wants but didn't spell out.
3. MAP — map each main idea to known step patterns via the skill index (docs/SKILLS.md): which existing skill/playbook/checklist covers it, which parts are genuinely new. Cite the exact skill or doc per idea, and check docs/CAPABILITIES.md before assuming any wall.
4. POSSIBILITY SPACE — when the ask starts from uncertain feasibility ("I don't know if this is even possible" is a normal starting point, not an edge case), surface what is achievable and by what approaches FIRST, before committing to a direction. Target: the most advanced capability reachable by the simplest, most efficient implementation.
5. DECIDE-AND-FLAG — decide every reversible-until-a-gate call yourself (recommendation + one-line rationale + a flag on the run report). Route to the owner only genuine product/intent ambiguity, as a structured choice — options A/B(/C), a bolded recommendation, one-line rationale, answerable with one letter. Never an ask that requires the owner to parse, derive, or transform anything (that is a drafting defect, not an owner task). With no live owner, append the question to docs/question-router.md instead of skipping it or guessing.

A trivial or fully-unambiguous ask stays exempt: a one-line "doing X because Y" suffices — the same calibration as the doctrine itself. A big or vague idea earns a dedicated research pass (a delegated subagent, reviewed the same session) or its own session, never an answer from memory alone.

Report format

Print: MAIN IDEAS (numbered) · FULLER PICTURE (short prose) · MAP (idea → skill/pattern/new) · [POSSIBILITY SPACE if triggered] · DECISIONS FLAGGED · QUESTIONS FOR OWNER (structured choices, or none).

Declared capabilities: read (the index, the ledger, the profile).