vince-intake

Files (1)

• SKILL.md

SKILL.md (first lines)

# Vince — Intake

Before the final user-facing response, apply `reference/brief.md`.

Classify the request before any implementation work. The purpose is not to formalize the user's
wording. It is to detect whether an agent can act without guessing what product to build, claiming
an impossible guarantee, or taking authority the user did not grant.

Preserve the user's intent and chosen scope. Do not begin implementation, inspect implementation
code, create a task ledger, or invoke `vince-implement` until the result is `READY`. Do not insult
the user or describe their prompt as stupid. Do not invent requirements merely to make the request
look complete.

## The three decisions

Return exactly one decision:

| Decision | Use it when | What to do |
|----------|-------------|------------|
| `READY` | The goal, affected system, and observable result are clear enough to derive testable acceptance criteria. Minor implementation choices can be discovered safely in the repo. | Restate a short contract, ask for confirmation when it came from chat, then invoke `vince-implement`. |
| `CLARIFY` | The intent is reasonable and recoverable, but one or more answers would materially change the result. | Ask only the smallest set of focused questions needed, normally one and never more than three at once. After the answers, restate the contract and classify again. |
| `BOUNCE` | The request is contradictory, impossible, unsafe, unauthorized, unbounded, or missing so much product intent that clarification would require designing a different project. | Stop. Explain the blocking fact plainly and state the minimum information, authority, or constraint that would make a new request actionable. Do not invoke `vince-implement`. |

Ordinary shorthand is not a defect. “Add dark mode to the settings page” can be `READY` when the
repo identifies the page and its conventions. “Make authentication better” is usually `CLARIFY`
because “better” has materially different meanings. “Fix the whole platform and guarantee no bugs
forever” is `BOUNCE`: it is unbounded and asks for an impossible guarantee.

## Decision test

Evaluate these in order:

1. **Authority and safety.** If the action is unauthorized or requires an unsafe or destructive
   leap, `BOUNCE` and name the missing authority or safe boundary.
2. **Internal consistency.** If all stated constraints cannot be true together, `BOUNCE` and
   identify the conflict.
3. **Feasibility.** If it demands an absolute guarantee no implementation can prove, `BOUNCE` and
   offer the nearest measurable replacement without silently adopting it.
4. **Bounded intent.** If there is no recognizable product outcome and stopping point, `BOUNCE`
   and state the minimum boundary required.
5. **Material ambiguity.** If two reasonable answers produce meaningfully different features,
   data handling, security, cost, or user experience, `CLARIFY` only those forks.
6. Otherwise, `READY`.

Do not ask questions that repository inspection can answer safely, such as the test command, file
location, framework convention, or existing naming. Do ask when the missing answer is a product,
security, data-retention, destructive-action, or externally visible behavior choice.

## Response shapes

For `READY`, provide the decision and proposed acceptance criteria. For an ad-hoc chat request,
ask the user to confirm because that restatement becomes the contract.

For `CLARIFY`, provide the decision, one sentence naming the ambiguity, and one to three numbered
questions. Do not include a guessed implementation plan.

For `BOUNCE`, provide the decision, blocking reason, and minimum change needed to submit an
actionable request. A bounce is not permanent: evaluate the revised request from scratch.

If answers still leave the request unclear, repeat `CLARIFY` once with only unresolved material
forks. If it remains unbounded after that, use `BOUNCE`; do not conduct an endless interview.

From elroykanye/vince-gate, MIT.

More from elroykanye/vince-gate