Use when asked to design a new feature or project
/plugin marketplace add britt/claude-code-skills/plugin install britt-claude-code-skills@britt/claude-code-skillsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Write comprehensive product specification documents that clearly communicate what we're building, why we're building it, and how we'll know it's successful. Document everything stakeholders need to understand: the problem context, target audience, requirements, success criteria, and tradeoffs. Give them a complete picture of the feature or project.
Assume the reader is a skilled product person or engineer, but knows nothing about this specific feature or the problem domain. Assume they need clear context to understand the "why" behind the work.
Announce at start: "I'm using the writing-product-specs skill to create the product specification."
Context: This should be run when designing a new feature or planning a project that needs clear requirements documentation.
Save specs to artifacts named spec-<feature-name>-MM-DD-YYYY.md (or as requested by the user).
Core principle: Product specifications are detailed descriptions of the features and functionality of a product. They are used to communicate the requirements of the product to the development team.
Use this skill when:
Follow this process to elicit the necessary information and compose a comprehensive product specification.
Ask questions to understand the feature or project. Gather information about:
Continue asking questions until you have enough information to draft a complete spec. Don't proceed to drafting until you have clear answers to these core questions.
Using the information gathered, draft the product specification following the document structure outlined in the Product Spec Format section. Present the complete draft to the user.
After presenting the draft:
Once the user confirms the spec is good enough:
spec-<feature-name>-MM-DD-YYYY.md (or as requested by the user)Below is the format for a product spec. Each section should be written with clear, actionable guidance.
Instructions: Provide a brief (1-2 sentences max) description of what we are building. This is the tl;dr that should explain the entire project and its benefits in a few sentences. A reader should understand the core value proposition from this title and description alone.
What to include:
Instructions: Describe the world the problem exists in and the problem in broad strokes. Set the stage for why this work matters. Explain the current state, what's happening in the market or user workflows, and why this problem has emerged or become important now.
What to include:
Instructions: Identify who we are solving this problem for. Be specific about user personas, roles, or user types. Map to common user personas if possible (e.g., doc writer, product engineer, devops/IT, customer's customer / reader of docs, etc.). If there are multiple audiences, list them and explain how each benefits.
What to include:
Instructions: List the specific problems we are solving. Use bullet format, one problem per bullet. Be succinct and direct—the background context has already been established. Each problem statement should be clear, specific, and actionable.
What to include:
Instructions: Explain why we believe solving these problems will help customers achieve their goals. This is the "why" behind the "what"—the reasoning that connects the problems to the proposed solution. Articulate the expected outcome and the logic that supports it.
What to include:
Instructions: Define how we will know that the problem is solved. These should be measurable, testable, or observable indicators of success. Include both quantitative metrics (if applicable) and qualitative validation steps.
What to include:
Instructions: List what is necessary for us to build in order to solve this problem. Be specific about functional requirements, technical requirements, and constraints. Organize by priority or category if helpful. Each requirement should be clear enough that an engineer can understand what needs to be built.
What to include:
Instructions: Explicitly state what we are not doing, what is out of scope, and what we don't have to do. This prevents scope creep and sets clear boundaries. Be specific about related features or capabilities that might seem related but are explicitly excluded.
What to include:
Instructions: When you write this section just include the placeholder below in italics.
Especially from engineering, what hard decisions will we have to make in order to implement this solution? What future problems might we have to solve because we chose to implement this?
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.