How do I install the Product Spec Kit skill?

Run npx skillmds@latest add majiayu000/product-spec-kit in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Product Spec Kit safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Product Spec Kit?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Product Spec Kit free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Product Spec Kit?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Product Spec Kit by majiayu000 — Agent Skill

Name: Product Spec Kit
Rating: 4.2 (5 reviews)
Author: majiayu000

Product Spec Kit

Comprehensive skill for Product Managers to create organize and manage Product Teams, Strategy, PRDs, release plans, user stories, and standalone issues with high-quality acceptance criteria. Supports both full documentation workflows (PRD → Plan → Stories) and quick issue creation (standalone stories, tasks, bugs). All documentation follows design-driven development principles with functional, testable acceptance criteria based on visual designs and user flows.

majiayu000 Updated Sep 9, 2026 567 repo stars

File contents

Overview

This skill helps Product Managers produce structured, high-quality documentation for product development. It supports both comprehensive documentation workflows (PRD → Plan → Stories) and standalone quick issues (individual stories, tasks, or bugs).

Always use the language of the user interaction to create the final files, including headings and default content of templates. If the user explicitly requests a different language, use it.

When to use?

Use this skill when user asks to:

Create a PRD specification
Create an epic and your stories/tasks
You need to create or clarify a product specification, such as a Product Requirements Document (PRD), a Release Plan, or a User Story.
It can also be used to create standalone PRD, Plan, Story, Task or Bug.

Core Principles Constitution

All documentations need to follow the constitution defined in rules/product-speckit-constitution.md. This constitution is a set of non-negotiable principles that govern all product documentation created with this skill. These principles apply regardless of language, workflow type (full or quick), or document format.

Principle I: Complete & Unambiguous Requirements

Every requirement must be clear enough that a reader with no prior context can understand what's needed and why.

Principle II: Design-Driven Acceptance Criteria

Acceptance criteria should be based on visual designs, user flows, and specific UI elements - never written from assumptions.

Principle III: Functional Over Descriptive

Criteria must describe what the system does, not what it looks like. Focus on behavior, actions, and outcomes.

Principle IV: Right Level of Detail

PRDs: Macro-level requirements and general rules
Stories: Detailed, functional acceptance criteria
Each document serves its purpose without overlap

Principle V: Never Assume, Always Validate

When information is missing or ambiguous:

Ask specific questions
Request designs/mockups
Reference previous discussions
Mark uncertain items for validation
Wait for confirmation before finalizing

Workflows or Commands

Starting the interaction - how to start a new specification: If the user don't provide the type of specification want to build, always ask for it, using the workflows/prod-start.md instructions. Ignore the start step if the user provide the type of specification want to build.
Creating a PRD: When the user want to create a PRD, use the workflows/prod-spec-prd.md instructions.
Clarifying an specification: When the user want to clarify an specification (such as PRD, Plan, Story, Task or Bug), use the workflows/prod-clarify.md instructions. If the user doesn't provide an existing specification, ask for it.
Breakdown specs: When the user want to break the PRD in smaller parts such as Epics -> Stories / Tasks, use the workflows/prod-spec-breakdown.md instructions. You need to validate an existing PRD or create the PRD before breaking it down. If the user doesn't provide an existing PRD, ask for it.
Creating a Story: When the user want to create a story, use the workflows/prod-spec-story.md instructions.
Creating a Task: When the user want to create a task, use the workflows/prod-spec-task.md instructions.

---name: product-spec-kitdescription: Comprehensive skill for Product Managers to create organize and manage Product Teams, Strategy, PRDs, release plans, user stories, and standalone issues with high-quality acceptance criteria. Supports both full documentation workflows (PRD → Plan → Stories) and quick issue creation (standalone stories, tasks, bugs). All documentation follows design-driven development principles with functional, testable acceptance criteria based on visual designs and user flows.--- ## Overview This skill helps Product Managers produce structured, high-quality documentation for product development. It supports both comprehensive documentation workflows (PRD → Plan → Stories) and standalone quick issues (individual stories, tasks, or bugs). Always use the language of the user interaction to create the final files, including headings and default content of templates. If the user explicitly requests a different language, use it. ## When to use? Use this skill when user asks to: - Create a PRD specification - Create an epic and your stories/tasks - You need to create or clarify a product specification, such as a Product Requirements Document (PRD), a Release Plan, or a User Story. - It can also be used to create standalone PRD, Plan, Story, Task or Bug. ## Core Principles Constitution All documentations need to follow the constitution defined in `rules/product-speckit-constitution.md`. This constitution is a set of non-negotiable principles that govern all product documentation created with this skill. These principles apply regardless of language, workflow type (full or quick), or document format. ### Principle I: Complete & Unambiguous Requirements Every requirement must be clear enough that a reader with no prior context can understand what's needed and why. ### Principle II: Design-Driven Acceptance Criteria Acceptance criteria should be based on visual designs, user flows, and specific UI elements - never written from assumptions. ### Principle III: Functional Over Descriptive Criteria must describe what the system does, not what it looks like. Focus on behavior, actions, and outcomes. ### Principle IV: Right Level of Detail - PRDs: Macro-level requirements and general rules - Stories: Detailed, functional acceptance criteria - Each document serves its purpose without overlap ### Principle V: Never Assume, Always Validate When information is missing or ambiguous: - Ask specific questions - Request designs/mockups - Reference previous discussions - Mark uncertain items for validation - Wait for confirmation before finalizing ## Workflows or Commands - *Starting the interaction - how to start a new specification*: If the user don't provide the type of specification want to build, always ask for it, using the `workflows/prod-start.md` instructions. Ignore the start step if the user provide the type of specification want to build. - *Creating a PRD*: When the user want to create a PRD, use the `workflows/prod-spec-prd.md` instructions. - *Clarifying an specification*: When the user want to clarify an specification (such as PRD, Plan, Story, Task or Bug), use the `workflows/prod-clarify.md` instructions. If the user doesn't provide an existing specification, ask for it. - *Breakdown specs*: When the user want to break the PRD in smaller parts such as Epics -> Stories / Tasks, use the `workflows/prod-spec-breakdown.md` instructions. You need to validate an existing PRD or create the PRD before breaking it down. If the user doesn't provide an existing PRD, ask for it. - *Creating a Story*: When the user want to create a story, use the `workflows/prod-spec-story.md` instructions. - *Creating a Task*: When the user want to create a task, use the `workflows/prod-spec-task.md` instructions.

Frequently asked questions