本文へ移動
cccskills
無料GitHub で公開

prd-writer

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

インストール方法を見る

含まれるファイル(1)

  • SKILL.md2.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Build a new holaOS app using @holaboss/app-builder-sdk (5 backend primitives + optional shadcn dashboard UI). The canonical path for vibe-coded apps — integration modules AND dashboard apps both live here.

日本語の概要は準備中です。原文の説明を表示しています。

holaboss-ai/holaOS1.1万2026年8月21日 更新

Analyze your audience demographics, behavior, and preferences for targeted content.

日本語の概要は準備中です。原文の説明を表示しています。

holaboss-ai/holaOS1.1万2026年8月21日 更新

Use when working in the embedded browser and you want the cheapest reliable interaction loop.

日本語の概要は準備中です。原文の説明を表示しています。

holaboss-ai/holaOS1.1万2026年8月21日 更新

Use when validating or debugging a workflow in the embedded browser and you need a reproducible, evidence-first loop.

日本語の概要は準備中です。原文の説明を表示しています。

holaboss-ai/holaOS1.1万2026年8月21日 更新

Build the visual layer of a holaOS dashboard app — TanStack Start + @holaboss/ui + workspace tokens. Use when an app has SDK primitives wired (via app-builder-sdk) AND needs a `src/client/` UI surface. NOT for marketing pages, NOT for snapshot HTML reports.

日本語の概要は準備中です。原文の説明を表示しています。

holaboss-ai/holaOS1.1万2026年8月21日 更新

Guide for assembling a workspace capability (skills + integrations). Use when the user wants to create a capability.

日本語の概要は準備中です。原文の説明を表示しています。

holaboss-ai/holaOS1.1万2026年8月21日 更新

holaboss-ai のスキルをすべて見る

このスキルの問題を報告する