Spec Intake

spec-intake

Overview

Turn a task from anywhere — a Jira/Linear ticket, a URL, a Slack message, a vague sentence — into one normalized spec, before any planning. Usable standalone, and the entry point of eskills:task-flow Phase 1.

Steps

1. Pull the source. Read the ticket/URL/message. Quote the real wording; don't paraphrase away a constraint.
2. Resolve ambiguity now. If the objective or a success condition is unclear, ask the few questions that change the work — before writing the spec, not after.
3. Normalize into the shape below.
4. Classify for the flow (this is what task-flow consumes next).

Output shape

## Objective

<one or two sentences: the outcome, in the user's terms>

## Acceptance criteria

- [ ] <observable, checkable condition>
- [ ] …

## Constraints

- <tech, data, deadline, compatibility, non-goals>

## Definition of done

- <tests, docs, review, deploy — what "finished" requires>

## Classification

- Project shape: greenfield | brownfield
- Hard-tech challenge: yes (algorithm / performance) | no

Notes

• Acceptance criteria must be observable — "X is faster" is not a criterion; "p95 < 200ms on N=10k" is.
• The classification drives task-flow: brownfield → feature-dev:code-explorer; hard-tech → the SPIKE sub-phase.
• Keep the spec outside the repo (see eskills:standards) — it's an internal doc.