CtrlK
BlogDocsLog inGet started
Tessl Logo

prd-writer

Turn a feature idea into a clear PRD — problem, users, requirements, and success metrics.

60

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./apps/desktop/electron/default-skills/prd-writer/SKILL.md
SKILL.md
Quality
Evals
Security

Product Spec

Write the spec that gets a team building the right thing. A good PRD isn't a feature list — it's a shared understanding of the problem, who has it, what "done" means, and how you'll know it worked. It closes the gaps where projects usually go sideways.

When to use this skill

Use Product Spec to turn a feature idea, request, or rough notes into a product requirements document (PRD) or one-pager. For client-facing scope and pricing use Proposal Writer; for meeting recaps use Meeting Notes.

What a PRD needs to answer

  • Problem — what user pain or business need this addresses, and why now. If you can't state the problem, the feature isn't ready.
  • Users & context — who it's for and the situation they're in when they hit this.
  • Goals & non-goals — what this explicitly will and won't do. Non-goals prevent scope creep as much as goals drive it.
  • Requirements — the behavior, written so an engineer and a designer read them the same way. Separate must-haves from nice-to-haves.
  • Success metrics — how you'll measure whether it worked.
  • Open questions & risks — the unknowns, surfaced rather than buried.

Principles

  • Problem before solution. Anchor on the user's pain; a solution with no stated problem is a guess.
  • Unambiguous requirements. If a requirement can be read two ways, pick one and make it explicit.
  • Right altitude. Enough detail to build confidently, not so much that it dictates implementation. State intent and constraints; leave the "how" to the builders where you can.
  • Name the unknowns. List open questions instead of pretending certainty.

How to work

  1. Pin down the problem and the user before anything else.
  2. Set goals and non-goals; they bound everything after.
  3. Write requirements grouped by priority (must / should / could), each testable.
  4. Add success metrics, then list risks and open questions honestly.

Output format

A structured doc: Summary, Problem, Users & Context, Goals / Non-goals, Requirements (prioritized), Success Metrics, Risks & Open Questions. Keep it as short as the problem allows.

Repository
holaboss-ai/holaOS
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.