Task Intake — Universal

Purpose

Shape the input before execution. A raw request usually lacks the context that tells the model which knowledge to load — so intake converts it into a structured brief: goal, relevant context, constraints, acceptance criteria, verification. The brief dictates what knowledge gets activated and what the output must look like.

When to use

• The request lacks a goal or constraints that materially change the result ("make this better", "fix it", "build the thing"). A one-line request with sufficient session/repository context does not require clarification.
• The task sits in a domain with many valid approaches (styling, architecture, APIs, algorithms).
• The request implies knowledge that was never stated (framework versions, project conventions, existing patterns).

Preconditions

• The raw request is available to re-read — never shape from memory of it.
• The repo is inspectable to fill context that the request did not state.

Workflow

1. Extract the goal. What must be true when the work is done? If the request does not say, that is the first gap to close.
2. Identify missing context that changes the approach — stack, versions, existing patterns, constraints, intended users.
3. Classify each gap: already stated / discoverable in the repo / must ask the user.
4. Fill what the repo answers. Inspect code and docs before asking anything.
5. Ask only for gaps the repo cannot answer and that change the outcome — one focused question, not a questionnaire.
6. Write the brief internally: Goal · Context loaded (the facts that drive the approach) · Constraints (what not to touch) · Acceptance criteria (how we know it is done) · Verification. Show it only when requested or useful for a consequential decision; it is not an approval form.
7. Execute the brief through the reliable-execution workflow.

Rules

• Never execute from the raw request alone — always from the brief.
• Load facts from the repo before asking the user; ask only for what the repo cannot answer.
• The brief must name acceptance criteria — without them every output is equally "done".
• Keep the brief to a few lines. It is a working contract, not documentation.

Common mistakes

• Executing a vague request as-is and hoping ("improve" without defining what improvement means).
• Asking the user questions the repo already answers.
• Writing a brief that restates the request instead of adding missing context and constraints.
• Skipping acceptance criteria — this is the point where the model starts guessing.

Validation

• Material decisions trace to the request, repository evidence or a user answer. Safe reversible defaults may be inferred and stated when useful; do not prohibit all assumptions or ask about routine implementation choices.
• The brief drove the execution; every statement in it traces to a source.
• Executing from the brief alone (without the raw message) reproduces the same outcome.