C✳CODEZ.WIN
🌐 English

Localized reading guide

write-specPurpose, usage and source

Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.

Source retrieved:

Source repository
anthropics/knowledge-work-plugins
SKILL.md
product-management/skills/write-spec/SKILL.md
Repository stars
34,049
Repository updated
2026-10-30
Categories
Documents
Last collected

License: License file needs review

Workflow excerpts are reading aids, not executable instructions from Codez. No third-party Skill was run to produce this page.

The purpose and workflow passages below are upstream material, organized and translated for reading. They are distinct from the separately labeled Codez editorial analysis.

What this Skill does

Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.

How the upstream workflow works

Write Spec

> If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md. Write a feature specification or product requirements document (PRD).

Upstream passage · L7 ↗

1. Understand the Feature

Ask the user what they want to spec. Accept any of: A feature name ("SSO support")

Upstream passage · L21 ↗

2. Gather Context

Ask the user for the following. Be conversational — do not dump all questions at once. Ask the most important ones first and fill in gaps as you go: User problem: What problem does this solve? Who experiences it?

Upstream passage · L29 ↗
Upstream passage · ↗
/write-spec $ARGUMENTS

Requirements and setup

Requirements

Must-Have (P0): The feature cannot ship without these. These represent the minimum viable version of the feature. Ask: "If we cut this, does the feature still solve the core problem?" If no, it is P0. Nice-to-Have (P1): Significantly improves the experience but the core use case works without them. These often become fast follow-ups after launch.

Upstream passage · L113 ↗

Limits and quality checks

No separate limits passage was selected from this file. This does not mean the Skill is safe for every input or environment. Review the complete source and validate your own result.

Start with a safe trial

  1. Check the supported host and the repository installation instructions. Keep the Skill directory and its referenced scripts, assets and documentation together; SKILL.md alone may omit dependencies.
  2. Give the agent your real input, desired output and acceptance criteria. Invocation syntax and available tools depend on the host; this site does not assume a universal install command.
  3. Try the source workflow in a disposable project or on a copy. Review operations that change files, remote services or billable resources before allowing them.
  4. Validate the output against the source quality checks and your own requirements. A successful trigger or a high repository Star count does not establish a correct result.

Skill format and directory specification ↗

Read further in the source

Translation and scope

This reading guide selects passages from the pinned upstream SKILL.md. Translation is assisted. It is not a complete manual or a claim of tested compatibility. Read the original and its referenced files before use.

This introduction refers to the pinned version below; current repository activity and collection time are shown separately.

Source retrieved
Source commit
2574e29377c7173d0cecffef29a6ecbd7f8ccb5d
Source SHA-256
ca6670913878b4ac4582727562bfced5271492a5a800d934f68c9e7bc1cd4dcc
Back to the full Skill catalog