How to use the Product Capability Planner agent skill

What is an agent skill and what does this one do?

An agent skill is a folder of instructions that an AI agent loads when a task matches the skill's description. This skill is defined in a SKILL.md file and is named product-capability.

Its job is to make hidden assumptions explicit before implementation starts. The agent restates the ask as one precise capability statement, then lists the constraints that must hold, such as business rules, scope boundaries, invariants, trust boundaries, data ownership, lifecycle transitions and rollout or migration requirements.

• Restates the capability: who the user is, what new capability exists, and what outcome changes.
• Lists constraints, invariants and interfaces, and separates user-visible promises from implementation details.
• Marks what is fixed policy, what is architecture preference, and what is still open.
• Names explicit non-goals and open questions that block implementation.
• Ends with a handoff: ready for direct implementation, needs architecture review, or needs product clarification.
• Saves the result as a durable artifact in the repository rather than in chat notes.

Install the product-capability skill

Download the ZIP for the skill from this page and unzip it. Then place the resulting folder in one of two locations, depending on how you want to use it.

For a personal install available across your projects, put it in ~/.claude/skills/. For a project-specific install, put it in the project's .claude/skills/ folder so it applies only to that repository.

If you use the Claude apps instead, upload the skill under Settings → Capabilities → Skills.

• Personal: ~/.claude/skills/
• Project: .claude/skills/ inside your repository
• Claude apps: Settings → Capabilities → Skills, then upload

Check what the skill needs before you start

The skill reads your repository, so the agent needs access to the repo's documentation and architecture files. Output quality depends on how much of the current product and architecture context is written down. If the repo has few docs, expect more open questions.

The handoff points to other ECC lanes such as tdd-workflow and verification-loop, so the ECC skill set is recommended for the full workflow.

• Access to repository docs and architecture files (for example PRODUCT.md, docs/product/, RFCs, schemas and routes)
• The ECC skill set, since the handoff refers to other ECC lanes
• The skill runs no scripts and uses no network access

How to trigger the skill with a natural request

You do not need a special command. Describe the planning work you need in plain language, and mention that you want a capability plan or an implementation-ready spec. The skill is designed for cases where the constraints are still implicit.

Good requests name the source material and the outcome you want, for example a PRD file, a roadmap note or a discussion summary, and a plan you can review before coding.

• "Turn this PRD into a capability plan with constraints and open questions before we start building."
• "Here is the roadmap item for team billing. Write a product capability spec that lists invariants and interfaces."
• "Our design review keeps repeating the same assumptions about tenant data. Capture them in a reusable capability artifact."
• "I need an SRS-style plan for this feature that spans the API and the worker service."

Where the output is saved

If the repo already has a durable product-context file such as PRODUCT.md, docs/product/ or a program-spec directory, the skill updates it there. If no capability manifest exists yet, it creates one from the template at docs/examples/product-capability-template.md.

The output follows a fixed order: CAPABILITY, CONSTRAINTS, IMPLEMENTATION CONTRACT, NON-GOALS, OPEN QUESTIONS and HANDOFF.

• Update an existing product-context file when one exists.
• Otherwise create a capability manifest from docs/examples/product-capability-template.md.
• Review the OPEN QUESTIONS section first; those are the blockers.

Safety notes and tips

The skill is written not to invent product truth. Unresolved questions are marked explicitly, and conflicts with existing repo constraints are reported rather than smoothed over. It runs no scripts and makes no network calls, so its effects are limited to reading files and writing the planning artifact.

For best results, give it the documents it needs rather than asking it to guess. Keep the artifact in the repo so it survives across sessions and tools.

• Runs no scripts and uses no network, per the skill's declared settings.
• Does not resolve open questions; it lists them as blockers.
• Provide existing architecture and product docs so it can check constraints against them.
• Keep the output in the repository so the team can reuse it in review.