Feature Spec

Feature Spec is an official product-management skill from Anthropic’s knowledge-work-plugins. The original source was expected at product-management/skills/feature-spec. In the currently reachable main branch, the workflow is published at product-management/skills/write-spec; the candidate name feature-spec still describes the same documented purpose. The direct primary source for the current content is https://github.com/anthropics/knowledge-work-plugins/tree/main/product-management/skills/write-spec. According to the provider, the skill turns a feature, problem statement, user request, or still-vague idea into a structured feature specification or Product Requirements Document.

Problem and context

The workflow starts with a clear statement of what needs to be specified. It then gathers the user problem, affected target segments, desired success criteria, technical or organizational constraints, and prior attempts or solutions. This conversation is intentionally not a single large questionnaire. According to the provider, the most important uncertainties should be addressed first, with missing details filled in as the discussion develops. When connected project, knowledge, design, or feedback sources are available, the workflow can incorporate related tickets, research, mockups, meeting notes, and user feedback. Without those connections, it works entirely from the context supplied by the team.

Output structure

The recommended specification contains a problem statement describing affected people and the cost of inaction, measurable goals, and explicit non-goals. User stories describe specific roles, capabilities, and benefits without prescribing a particular implementation. Requirements are grouped into must-have elements, useful additions, and future considerations. Important requirements receive testable acceptance criteria, often expressed in Given-When-Then form. Success measurement distinguishes leading signals such as adoption, activation, completion rate, time to complete, usage frequency, and errors from lagging signals such as retention, satisfaction, support reduction, competitive outcomes, or business impact. Open questions are assigned to engineering, design, legal, data, or stakeholder owners. Timeline considerations capture hard deadlines, dependencies, and phasing.

Prioritization and scope

A major benefit is deliberate scope control. Non-goals prevent gradual expansion, while P0, P1, and P2 categories make clear what belongs in the first viable release, what can follow, and what should influence future architecture. The source also presents MoSCoW as a possible prioritization framework. A useful document records assumptions, risks, and dependencies instead of presenting uncertain decisions as facts. Acceptance criteria should cover happy paths, error states, empty states, and boundary conditions. Vague words such as fast or intuitive should be replaced by observable conditions. The specification is a shared basis for alignment and delivery, not an immutable contract.

Boundaries, safety, and fit

Feature Spec is not project-management software, product analytics, an autonomous prioritization decision, or an approval system. According to the provider, the generated document should be reviewed and iterated with stakeholders after it is produced. A model response cannot replace user research, reliable measurement, legal review, or engineering investigation. Connected sources must be used only within approved permissions. Internal tickets, personal feedback, and confidential product plans should be minimized and handled according to the applicable access policy. A local skill directory does not mean that prompts and results remain local; a connected model may transmit data to its model provider. Credentials, tokens, and production data do not belong in examples. According to the provider, Anthropic publishes the repository under Apache-2.0. This description was reviewed on September 9, 2026 against the official repository, its product-management overview, and official Claude Code documentation. It describes the documented workflow, not a guarantee of correct requirements or successful product decisions.