Spec intake

Lean personal Claude Code skills pack — my conventions, task flow, and quality lenses. Requires the superpowers plugin.

Install

npx -y skills add Endika/eskills --skill spec-intake

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when starting from a task described in Jira, Linear, a URL, or free text and you need it normalized into a spec (objective, acceptance criteria, constraints, definition of done) before planning.

SKILL.md

1.6 KB, as published. Nobody here has run it

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

Pull the source. Read the ticket/URL/message. Quote the real wording; don't paraphrase away a constraint.
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.
Normalize into the shape below.
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.