Prd writer
Skill stark-ai-de/agent-skills/incubator/skills/engineering-workflows/prd-writer
Public Agent Skills for Codex operations, Cursor operations, Claude operations, repo maintenance, skill maintenance, productivity, and engineering workflows.
npx -y skills add stark-ai-de/agent-skills --skill prd-writerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Write a concise PRD or implementation brief from current context, separating problem, solution, user stories, decisions, testing, rollout, and out of scope. Use when the user asks for a PRD, product brief, implementation brief, or spec handoff.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.9 KB, as published. Nobody here has run it
PRD Writer
Goal
Create a clear product or implementation brief that preserves decisions, unresolved questions, scope, validation, and non-goals.
When to use
- The user asks for a PRD, implementation brief, product spec, or handoff spec.
- Current conversation context needs to become a durable planning artifact.
- Engineering, product, validation, and rollout expectations need one shared document.
When not to use
- The user only needs an ADR for a narrow repo-level decision.
- The task is ready for implementation and does not need a planning artifact.
- The user asks for a marketing document rather than product or engineering scope.
Inputs to inspect
- Current conversation, existing specs, issues, roadmap items, ADRs, and domain docs.
- User goals, constraints, target users, non-goals, and known decisions.
- Existing validation commands and release process when relevant.
Workflow
- Identify the audience and artifact type: PRD, implementation brief, or handoff spec.
- Separate problem, goals, non-goals, proposed solution, decisions, and open questions.
- Write user stories or use cases only when they clarify behavior.
- Include acceptance criteria and validation commands.
- Add rollout, migration, observability, docs, or support notes only when relevant.
- Keep unresolved questions explicit instead of pretending decisions are final.
- Ask before writing files unless the user requested a file update.
Safety rules
- Do not invent product decisions to make the brief look complete.
- Do not bury out-of-scope items in footnotes.
- Do not include private customer data, internal hostnames, or secrets.
- Do not turn implementation details into requirements unless the user decided them.
References
No bundled references. Use local domain docs and ADRs when present so terminology and decisions match the repository.
Scripts
No bundled scripts.
Output format
Return or write:
- Problem
- Goals
- Non-goals
- Users or stakeholders
- Proposed solution
- User stories or workflows
- Decisions
- Open questions
- Acceptance criteria
- Validation and rollout
Completion criteria
- The document distinguishes facts, decisions, and open questions.
- Scope and out-of-scope items are visible.
- Acceptance criteria are testable.
- The artifact is short enough for future agents to use.
Failure modes
- If the problem is unclear, ask for the target user and failed current workflow.
- If solution and requirements are mixed, separate them before drafting.
- If decisions conflict with ADRs or domain docs, surface the conflict.