feature-speclisted

Write a lightweight, AI-ready Feature Specification — a ~500-2000 token spec with Overview, EARS acceptance criteria, Design, and Edge Cases that an implementer or coding agent can act on directly. Use when a single feature needs a concise build-ready spec. Anti-trigger; for org-wide architecture use arc42-arch-doc, for a decision record use adr, for a multi-feature product doc use prd.
modeled-information-format/mif-docs-plugin · ★ 0 · AI & Automation · score 73

Install: claude install-skill modeled-information-format/mif-docs-plugin

# feature-spec Produces a **feature specification**: a short, self-contained document that gives an implementer (human or coding agent) exactly enough to build one feature correctly — and no more. It is deliberately lightweight (~500-2000 tokens). It is not a PRD (no market/persona framing), not an architecture doc (no system-wide views), and not an ADR (it records *what to build*, not *which option won*). ## Pattern (industry: lightweight AI-ready feature spec) 1. **Overview** — what the feature is and why, in a few sentences. State the user value and scope boundary. Keep it brief. 2. **Acceptance Criteria** — the testable contract, written in **EARS** notation (see `ears-acceptance-criteria`). Each criterion is one verifiable sentence a human and an agent grade identically. 3. **Design** — the approach: key components, interfaces, data shapes, and the flow between them. Enough for an implementer to start; not a full design doc. 4. **Edge Cases** — explicit boundary and error behavior. Name each case and the required response. This is where most specs fail, so make it concrete. ## Rules that keep it build-ready - Every acceptance criterion uses an EARS template (Ubiquitous / Event-driven / State-driven / Unwanted / Optional). Name a concrete component, not "the app". - Edge Cases is mandatory and specific: empty input, limits, concurrency, failures — each with the expected observable behavior, not "handle errors". Treat identifier/credential validit