agentleFS
Sign inStart free
fnayoufnayou/dotfiles/.claude/skills/create-prd/SKILL.md

create-prd

Skill2 starsChanged 5 months agoMITView on GitHub

Produces a numbered PRD document under docs/prd/. Ask the user: Do not proceed until the objective is clear. List what success looks like. Be specific and verifiable. List what this PRD explicitly does not cover. This prevents scope creep. Write 1–5 user stories in format: List known constraints: Explicitly state what must not happen: List explicit, verifiable conditions that define "done": Repeat and expand the non-goals list with any additional exclusions that came up during steps 2–7. Write the PRD…

44 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use prioritize-features, brainstorm-okrs and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • skytiger6724Skill

    prioritize-features

    Prioritize a backlog of feature ideas based on impact, effort, risk, and strategic alignment with top 5 recommendations. Use when prioritizing a feature backlog, making scope decisions, or ranking product ideas.

    Also in 4 projects that use this

  • skytiger6724Skill

    brainstorm-okrs

    Brainstorm team-level OKRs aligned with company objectives — qualitative objectives with measurable key results. Use when setting quarterly OKRs, aligning team goals with company strategy, drafting objectives, or learning how to write effective OKRs.

    Also in 4 projects that use this

  • miovragSkill

    strategy-red-team

    Red-team a PRD, roadmap, or strategy by attacking its load-bearing assumptions before reality does. Steelmans then attacks each claim, ranks failure modes by impact × likelihood × cheapness-to-test, and returns the cheapest test and kill criteria for each. Use when stress-testing a plan, pressure-testing a strategy, challenging assumptions, or preparing a doc for executive review.

    Also in 3 projects that use this

  • launchapp-devSkill

    interview-script

    Create a structured user interview script with warm-up, core exploration, and wrap-up sections. Use when preparing for user research interviews to ensure consistent, insightful conversations.

    Also in 4 projects that use this

  • About-IntelligenceSkill

    beachhead-segment

    Identify the first beachhead market segment for a product launch.

    Also in 4 projects that use this

  • nandanosqlSkill

    customer-journey-map

    Map the complete customer experience across all touchpoints using the NNGroup framework. Identifies pain points, emotions, and opportunities at every stage of the user journey.

    Also in 5 projects that use this

  • +5 more from skytiger6724

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 42 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not proceed until the objective is clear.

    line 22
  2. Distinctive:

    Write 1–5 user stories in format:

    line 34
  3. Distinctive:

    Must not delete existing files.

    line 53
  4. Very specific:

    Must not overwrite existing dotfiles.

    line 54
  5. Distinctive:

    Must provide dry-run before install.

    line 55
  6. Distinctive:

    Write the PRD to a numbered file:

    line 73
  7. Distinctive:

    Use the next available number in the sequence.

    line 80

“Common” is measured: kept by at least 6 in 10 of the 42 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Skill: create-prd

Produces a numbered PRD document under docs/prd/.

When to use

  • User wants to start a significant new feature or package.
  • User wants to formalize a request before architecture or planning begins.
  • Any change that affects dotfiles, home directory structure, or repository layout.

Process

Step 1 — Clarify objective

Ask the user:

  • What is the goal of this change?
  • What problem does it solve?
  • Is this macOS-specific, Arch-specific, or common?
  • What is explicitly out of scope?

Do not proceed until the objective is clear.

Step 2 — Define goals

List what success looks like. Be specific and verifiable.

Step 3 — Define non-goals

List what this PRD explicitly does not cover. This prevents scope creep.

Step 4 — Define user stories

Write 1–5 user stories in format:

As a [user], I want [action] so that [outcome].

Step 5 — Define constraints

List known constraints:

  • Platform constraints (macOS only? Arch only? Both?)
  • Safety constraints (home directory? existing files?)
  • Privacy constraints (any sensitive config involved?)
  • Dependency constraints (tools required?)

Step 6 — Define safety requirements

Explicitly state what must not happen:

  • Must not delete existing files.
  • Must not overwrite existing dotfiles.
  • Must provide dry-run before install.
  • (add more as applicable)

Step 7 — Define acceptance criteria

List explicit, verifiable conditions that define "done":

- [ ] Criterion one
- [ ] Criterion two

Step 8 — Define out-of-scope items

Repeat and expand the non-goals list with any additional exclusions that came up during steps 2–7.

Step 9 — Produce the PRD

Write the PRD to a numbered file:

docs/prd/0001-dotfiles-foundation.md
docs/prd/0002-zsh-package.md

Use the next available number in the sequence.

PRD template

# PRD: [Title]

**Number:** 0001
**Status:** Draft | Approved | Superseded
**Date:** YYYY-MM-DD

## Goals

- [goal]

## Non-Goals

- [non-goal]

## User Stories

- As a user, I want [X] so that [Y].

## Constraints

- [constraint]

## Safety Requirements

- [safety requirement]

## Acceptance Criteria

- [ ] [criterion]

## Out of Scope

- [exclusion]

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free