agentleFS
Sign inStart free
brpazbrpaz/agent-skills/skills/bspec-prd-discovery/SKILL.md

bspec-prd-discovery

Skill1 starsChanged 6 months agoMITView on GitHub

Discovery skill for Bruno's personal spec workflow. Shapes project-level or feature-level product requirements directly in the PRD with a single question-driven loop.

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 9 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this skill when shaping product requirements directly in prd_document.

    line 8
  2. Distinctive:

    Use when the request is broad, early, or shapes the overall product.

    line 30
  3. Distinctive:

    Use when the request targets one feature or feature-sized slice.

    line 45
  4. Very specific:

    read the relevant parts of prd_document first

    line 60
  5. Distinctive:

    ask one question at a time

    line 62
  6. Distinctive:

    ask only questions that materially change scope, priority, user value, acceptance criteria, or non-goals

    line 63
  7. Very specific:

    update the relevant PRD file inside prd_document after each meaningful clarification

    line 64
  8. Distinctive:

    prefer the smallest clarification that unlocks forward progress

    line 65
  9. Distinctive:

    stop when the relevant scope is clear enough for issue decomposition or architecture follow-up

    line 66
  10. Distinctive:

    keep project-level content in the PRD index

    line 70
  11. Distinctive:

    create or update one feature file when the request is feature-sized

    line 71
  12. Distinctive:

    avoid scattering one feature across many PRD files

    line 72

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “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

PRD Discovery

Use this skill when shaping product requirements directly in prd_document.

Purpose

Handle both:

  • project-level discovery
  • feature-level refinement

using one discovery loop and one product artifact.

prd_document is the working and canonical product artifact.

It may be:

  • one file, or
  • a PRD index plus feature section files

Modes

Project Mode

Use when the request is broad, early, or shapes the overall product.

Focus on:

  • project scope
  • target users
  • user problems
  • product goals
  • success measures
  • major constraints
  • candidate features
  • sequencing and priorities at a product level

Feature Mode

Use when the request targets one feature or feature-sized slice.

Focus on:

  • user value
  • scope
  • acceptance criteria
  • non-goals
  • UX notes
  • assumptions
  • constraints
  • open questions

Discovery Method

  • read the relevant parts of prd_document first
  • decide whether the request is project mode or feature mode
  • ask one question at a time
  • ask only questions that materially change scope, priority, user value, acceptance criteria, or non-goals
  • update the relevant PRD file inside prd_document after each meaningful clarification
  • prefer the smallest clarification that unlocks forward progress
  • stop when the relevant scope is clear enough for issue decomposition or architecture follow-up

In multi-file mode:

  • keep project-level content in the PRD index
  • create or update one feature file when the request is feature-sized
  • avoid scattering one feature across many PRD files

Avoid

  • technical architecture
  • implementation plans
  • story decomposition
  • issue labels or GitHub workflow
  • line-by-line wording polish that does not change product clarity

Recommended Project Structure

# Product Requirements Document

## Overview

## Goals

## Target Audience

## Success Metrics

## Features
- Feature A
- Feature B

## Constraints

## Open Questions
- ...

In multi-file mode, keep this structure in the PRD index and place feature-level sections in separate files under the configured PRD sections directory.

Recommended Feature Structure

### Feature: <name>

#### User Value

#### Scope

#### Acceptance Criteria
- ...

#### Non-Goals
- ...

#### UX Notes
- ...

#### Assumptions
- ...

#### Constraints
- ...

#### Additional Notes
- product notes only

#### Open Questions
- ...

In multi-file mode, this structure can be the entire contents of one feature file.

Definition Of Ready

The discovered scope is ready when:

  • the relevant project or feature outcome is clear
  • acceptance criteria are concrete when the work is feature-sized
  • non-goals prevent accidental scope creep
  • the remaining open questions do not block issue decomposition
  • the PRD can support issue creation without more product discovery

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.

Reviews can't be read right now.

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