prd

Name: prd
Author: golbin

207stars27forks

How to install prd?

golbin/agent-skills/prd

$npx -y skills add golbin/agent-skills --skill prd

Installs into the current project.

Summary

Create or update an evidence-backed living Product Requirements Document (PRD) and, when useful, linked context and phase execution files under tasks/. Use for feature planning, implementation scoping, autonomous agent work, or checked-off PRDs that must be validated, reviewed, a

Files · 1

View on GitHub

SKILL.md

1	# Evidence-Backed Living PRD Generator
2
3	Create compact PRD file(s) that are grounded in the existing system, explicit
4	enough for a junior developer or fresh AI agent to execute, and structured as a
5	living source of truth. Work is checked off in the PRD, later phases are revised
6	as implementation reveals new information, and every phase ends with structured
7	validation and review.
8
9	Do not implement the feature unless the user explicitly asks. This skill creates
10	or updates PRD, context, and phase files only.
11
12	## Core Rules
13
14	- Always create or update markdown files under `tasks/`; do not only answer in
15	chat.
16	- Start from evidence. Inspect relevant code, tests, docs, configs, APIs, and
17	official external references before designing the plan when such context is
18	available.
19	- Use phases as the execution structure. Use scenarios or user stories only
20	for product context.
21	- Keep the master PRD compact. Split large plans into linked context and phase
22	files.
23	- Use markdown checkboxes (`- [ ]`, `- [x]`) for discovery, implementation,
24	validation, reviews, and completion.
25	- Make every requirement and checklist item concrete, verifiable, and small
26	enough to become one focused execution task.
27	- Prefer autonomous progress. Ask only for material unknowns; otherwise make the
28	best reasonable decision, record the assumption, and continue.
29	- Preserve completed checkboxes and meaningful user edits when updating existing
30	PRDs.
31	- Use the real current date for `Last Updated` and change log entries.
32
33	## Discovery Policy
34
35	A good PRD starts with a fast but serious discovery pass. Do not invent the plan
36	from the prompt alone when relevant project context is available.
37
38	Before writing or materially updating a PRD:
39
40	1. Read related PRDs, tasks, issues, README files, architecture notes, API docs,
41	product notes, and implementation notes.
42	2. Inspect affected code surfaces: routes, screens, components, services,
43	models, schemas, migrations, jobs, permissions, config, tests, fixtures,
44	observability, and existing patterns.
45	3. Identify current behavior, extension points, naming conventions, data flows,
46	integration boundaries, dependency/framework versions, and likely blast
47	radius.
48	4. Review available validation paths: static checks, unit tests, integration
49	tests, API-level E2E, browser/UI checks, app simulator checks, screenshots,
50	manual smoke checks, and observability checks.
51	5. Use official external docs or web sources when third-party APIs, framework
52	behavior, platform limits, recent rules, or current product behavior affect
53	the design.
54	6. Record what was reviewed, what could not be reviewed, material constraints,
55	risks, unknowns, and design implications.
56	7. Ask the user only if material ambiguity remains after this discovery pass.
57
58	For small PRDs, include a compact `Discovery Summary` in the master PRD. For
59	larger plans, create:
60
61	- `tasks/prd-[feature-name]/context.md`
62
63	The context file is a source map, not a code dump. Include reviewed inputs,
64	current system summary, validation surface, existing patterns, constraints,
65	risks, unknowns, and design implications.
66
67	Every phase must also include a Phase Discovery Gate that tells the executor
68	which files, docs, commands, APIs, tools, and assumptions to re-check before
69	editing code.
70
71	## Question Policy
72
73	Ask at most 3 questions, and only when the answer materially changes scope,
74	architecture, user-visible behavior, data impact, compliance, security, cost, or
75	an irreversible decision.
76
77	Ask after discovery whenever possible. Do not ask about preferences the agent can
78	reasonably decide. Use numbered questions with lettered options, for example
79	`1B, 2D, 3A`.
80
81	## File Mode Selection
82
83	Choose the layout automatically unless the user explicitly requests one.
84
85	### Single-File Mode
86
87	Use one file when the feature remains easy to scan:
88
89	- 1-3 short phases
90	- one primary domain or workflow
91	- no long phase checklist
92	- discovery notes fit comfortably in the master PRD
93
94	Path: `tasks/prd-[feature-name].md`
95
96	### Split-File Mode
97
98	Use split-file mode by default when any condition is true:
99
100	- the plan has 4 or more phases
101	- any phase has more than about 10-12 implementation items
102	- discovery notes would distract from the master PRD
103	- multiple domains are involved, such as data model, backend, frontend,
104	migration, permissions, async jobs, observability, rollout, or billing
105	- the feature is likely to change while being implemented
106	- the master PRD would become long enough that developers may stop rea

People who liked this also viewed

6 picks

Type

prd

207stars27forks

View on GitHub

How to install prd?

golbin/agent-skills/prd

$npx -y skills add golbin/agent-skills --skill prd

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Evidence-Backed Living PRD Generator
2
3	Create compact PRD file(s) that are grounded in the existing system, explicit
4	enough for a junior developer or fresh AI agent to execute, and structured as a
5	living source of truth. Work is checked off in the PRD, later phases are revised
6	as implementation reveals new information, and every phase ends with structured
7	validation and review.
8
9	Do not implement the feature unless the user explicitly asks. This skill creates
10	or updates PRD, context, and phase files only.
11
12	## Core Rules
13
14	- Always create or update markdown files under `tasks/`; do not only answer in
15	chat.
16	- Start from evidence. Inspect relevant code, tests, docs, configs, APIs, and
17	official external references before designing the plan when such context is
18	available.
19	- Use phases as the execution structure. Use scenarios or user stories only
20	for product context.
21	- Keep the master PRD compact. Split large plans into linked context and phase
22	files.
23	- Use markdown checkboxes (`- [ ]`, `- [x]`) for discovery, implementation,
24	validation, reviews, and completion.
25	- Make every requirement and checklist item concrete, verifiable, and small
26	enough to become one focused execution task.
27	- Prefer autonomous progress. Ask only for material unknowns; otherwise make the
28	best reasonable decision, record the assumption, and continue.
29	- Preserve completed checkboxes and meaningful user edits when updating existing
30	PRDs.
31	- Use the real current date for `Last Updated` and change log entries.
32
33	## Discovery Policy
34
35	A good PRD starts with a fast but serious discovery pass. Do not invent the plan
36	from the prompt alone when relevant project context is available.
37
38	Before writing or materially updating a PRD:
39
40	1. Read related PRDs, tasks, issues, README files, architecture notes, API docs,
41	product notes, and implementation notes.
42	2. Inspect affected code surfaces: routes, screens, components, services,
43	models, schemas, migrations, jobs, permissions, config, tests, fixtures,
44	observability, and existing patterns.
45	3. Identify current behavior, extension points, naming conventions, data flows,
46	integration boundaries, dependency/framework versions, and likely blast
47	radius.
48	4. Review available validation paths: static checks, unit tests, integration
49	tests, API-level E2E, browser/UI checks, app simulator checks, screenshots,
50	manual smoke checks, and observability checks.
51	5. Use official external docs or web sources when third-party APIs, framework
52	behavior, platform limits, recent rules, or current product behavior affect
53	the design.
54	6. Record what was reviewed, what could not be reviewed, material constraints,
55	risks, unknowns, and design implications.
56	7. Ask the user only if material ambiguity remains after this discovery pass.
57
58	For small PRDs, include a compact `Discovery Summary` in the master PRD. For
59	larger plans, create:
60
61	- `tasks/prd-[feature-name]/context.md`
62
63	The context file is a source map, not a code dump. Include reviewed inputs,
64	current system summary, validation surface, existing patterns, constraints,
65	risks, unknowns, and design implications.
66
67	Every phase must also include a Phase Discovery Gate that tells the executor
68	which files, docs, commands, APIs, tools, and assumptions to re-check before
69	editing code.
70
71	## Question Policy
72
73	Ask at most 3 questions, and only when the answer materially changes scope,
74	architecture, user-visible behavior, data impact, compliance, security, cost, or
75	an irreversible decision.
76
77	Ask after discovery whenever possible. Do not ask about preferences the agent can
78	reasonably decide. Use numbered questions with lettered options, for example
79	`1B, 2D, 3A`.
80
81	## File Mode Selection
82
83	Choose the layout automatically unless the user explicitly requests one.
84
85	### Single-File Mode
86
87	Use one file when the feature remains easy to scan:
88
89	- 1-3 short phases
90	- one primary domain or workflow
91	- no long phase checklist
92	- discovery notes fit comfortably in the master PRD
93
94	Path: `tasks/prd-[feature-name].md`
95
96	### Split-File Mode
97
98	Use split-file mode by default when any condition is true:
99
100	- the plan has 4 or more phases
101	- any phase has more than about 10-12 implementation items
102	- discovery notes would distract from the master PRD
103	- multiple domains are involved, such as data model, backend, frontend,
104	migration, permissions, async jobs, observability, rollout, or billing
105	- the feature is likely to change while being implemented
106	- the master PRD would become long enough that developers may stop rea

People who liked this also viewed

6 picks

Type