Hai Prd

Hai PRD

For Chinese readers, see SKILL.zh_CN.md. The English SKILL.md is the execution source of truth.

Overview

Handle all PRD-related work: deciding whether a PRD is even needed, choosing PRD granularity, splitting or merging PRDs, drafting a PRD from a product problem, and refining an existing one.

The non-obvious framing: a PRD is not the default artifact. Not every idea, field, API, configuration change, or technical decision earns one. Pick the mode that fits the request and do not wrap work in a PRD when there is no product boundary or acceptance to prove.

Core Principle

A PRD is a product argument with verifiable acceptance — not a feature list. Three rules carry the rest:

• Acceptance must be provable. One PRD should resolve one clear outcome, one main user journey

or product boundary, and acceptance criteria that prove it shipped.

• Boundary follows the user's mental model, not the tech. Granularity tracks user journeys and

independent acceptance — not technical layers, teams, or files.

• Fix the boundary before the wording. If the PRD boundary is wrong, split, merge, or reframe

it before polishing local sentences; edit an existing PRD as a system where goal, scope, behavior, acceptance, risks, and rollout must agree.

Modes

1. Need PRD

First decide the artifact type — a PRD is one option among several:

Ask:

• Is there a user-, buyer-, operator-, maintainer-, or business-visible behavior change?
• Does the work need explicit in-scope and out-of-scope boundaries?
• Does it need acceptance criteria to prove it was done correctly?
• Are there product-level options, risks, constraints, or rollout concerns to record?
• Would the team disagree on goal, scope, or acceptance without a PRD?

If most answers are no, do not force a PRD. When auditing a set of PRDs, also check for duplicate boundaries, circular dependencies, or broken user journeys across them.

2. Design PRD

Turn a feature idea or product problem into PRD-level requirements:

1. Gather context. Target user, product surface, current behavior, desired outcome, constraints, assumptions; plus existing PRDs, docs, screenshots, user flows, issues, data, or adjacent specs. 2. Frame the requirement. Write the problem in product language; define the target outcome and non-goals; identify the user journey or workflow boundary; separate facts, assumptions, and open questions. 3. Shape scope. Decide what belongs in this PRD versus another PRD, design doc, goal, or task. Do not bundle unrelated cleanup, platform work, or refactors unless they directly affect product behavior or acceptance. 4. Define behavior and acceptance. Describe expected behavior by scenario; add observable acceptance criteria; include edge cases, failure states, permissions, empty states, data dependencies, and rollout only when relevant.

3. Craft PRD

Refine an existing PRD as a whole product argument:

1. Read the full document first. Identify title, target user, goal, journey, scope, non-goals, acceptance, risks, and open questions; mark contradictions, duplication, stale sections, local patches, and unreasonable content. 2. Diagnose document drift using this taxonomy:

• Goal drift: sections optimize for different outcomes.
• Scope drift: requirements pull in unrelated work.
• Conflict drift: behavior, state, permissions, data, or rollout disagree across sections.
• Acceptance drift: acceptance criteria cannot prove the target outcome.
• Solution drift: implementation choices replace product requirements.
• Local-edit drift: one section improves while the whole PRD becomes worse.

3. Reframe before rewriting. State the corrected target outcome and the PRD boundary; decide whether to preserve, reorganize, split, merge, or rewrite. 4. Craft the document. Edit directly when the user provides a file; preserve useful content but move it to the right section; remove unsupported, duplicated, obsolete, or out-of-scope content; explain why removal beats rewriting or moving when content is deleted.

4. Scope PRD

Judge PRD granularity by user mental model and independent acceptance, not technical modules or teams. Run the six tests — this is the decision core:

When the tests point toward split or merge, read references/scope-tiers.md to pick a concrete cut: the preferred split dimensions, the splits to avoid (technical layer / CRUD / team ownership, because no such fragment is independently acceptable), the three-tier classification (entity lifecycle / aggregate view / platform extension), and the new-feature decision flow.

Workflow

1. Pick the mode from the request: necessity check → Need PRD; draft from a problem → Design PRD; refine an existing doc → Craft PRD; split/merge/granularity → Scope PRD. A request may span modes (e.g. necessity then scope). 2. Run that mode's procedure above. Apply the Core Principle throughout — fix the boundary before the wording. 3. For split/merge questions, run the six tests, then consult references/scope-tiers.md for the concrete cut and classification. 4. Produce the output for the active mode (see below). When a worked run helps, read references/worked-example.md for an end-to-end split decision and an end-to-end craft/diagnosis.

Output

Map the active mode to its template section, then fill only the relevant sections:

# Hai PRD: <topic or document name>
## Mode               (Need PRD / Design PRD / Craft PRD / Scope PRD)
## PRD Necessity       — Need PRD: recommend PRD / hai-goal / design doc / task / no separate artifact
## PRD Draft           — Design PRD: target outcome, problem, users, scope, requirements, acceptance
## Existing PRD Diagnosis — Craft PRD: main drift, conflicts, remove/keep/rewrite, acceptance repairs
## PRD Scope Assessment — Scope PRD: six-test signals, split/merge recommendation, suggested boundaries
## Remaining Open Questions
## Next Step

Read references/output-template.md before finalizing. Do not mechanically emit every section — output only the mode(s) relevant to the question.

Use a different skill when

Routing away from a PRD is the Need-PRD decision itself — see the table in Mode 1. In short: settle execution phases/todos in hai-goal, module boundaries and tradeoffs in hai-architecture, whether the idea is worth doing in hai-idea, a code/bugfix/test-first task in hai-tdd, what fields an entity should have and where they live in entity-model-auditor, documentation consistency in the doc-audit skills, and an anchor-first rewrite of a drifted non-PRD document in hai-rewrite-doc. Return to PRD work only when a product boundary and provable acceptance actually need to exist.

What this skill is NOT

• Not project management — do not assign owners or dates unless asked.
• Not a wrapper that turns every idea into a PRD — if there is no product boundary or acceptance

need, recommend the right artifact from the Need-PRD table instead of forcing a PRD.

Hai PRD Output Template

根据任务选择对应模板。不要机械输出全部 section；只输出和当前问题相关的模式。

# Hai PRD: <topic or document name>

## Mode
Need PRD / Design PRD / Craft PRD / Scope PRD

## PRD Necessity
Use when deciding whether a PRD is needed.

- **Recommendation**: PRD / hai-goal / design doc / task / no separate artifact
- **Reason**: <why this artifact type fits>
- **User-visible behavior change**: yes / no / unknown
- **Scope alignment needed**: yes / no
- **Acceptance needed**: yes / no
- **If not PRD, where it belongs**: <goal/design doc/task/existing PRD/etc.>

## PRD Draft
Use when designing a new PRD.

### Target Outcome
<What should be true for users or the business when this ships.>

### Problem
<Current pain, gap, or opportunity.>

### Users and Scenarios
- **User / actor**: <who>
- **Scenario**: <when they need this>
- **Current workaround**: <if known>

### Scope
#### In Scope
- <behavior or product surface>

#### Out of Scope
- <explicit non-goal that prevents scope creep>

### Requirements
| Requirement | User value | Verification |
|-------------|------------|--------------|
| <requirement> | <why it matters> | <how to prove it works> |

### Acceptance Criteria
- [ ] <observable pass/fail criterion>

### Risks and Open Questions
- <question that could change scope or acceptance>

### Rollout / Migration
<Only include when product behavior, data, or existing users are affected.>

## Existing PRD Diagnosis
Use when auditing, rewriting, or refining an existing PRD.

- **Current target outcome**: <as written>
- **Corrected target outcome**: <if changed>
- **Main drift**: goal drift / scope drift / conflict drift / acceptance drift / solution drift / local-edit drift

### Internal Conflicts
| Conflict | Sections | Why it matters | Resolution |
|----------|----------|----------------|------------|
| <incompatible claims> | <section refs> | <impact> | keep / rewrite / remove / split |

### Remove / Keep / Rewrite Decisions
| Content | Decision | Reason | Follow-up |
|---------|----------|--------|-----------|
| <requirement/section/claim> | remove / keep / rewrite / move | <why> | <none or action> |

### Coherence Repairs
- <contradiction, duplicate, stale claim, or misplaced content repaired>

### Acceptance Improvements
- <criterion that became more observable or measurable>

## PRD Scope Assessment
Use when deciding split / merge / keep as-is.

### Recommendation
<Split / Merge / Keep as-is> — <one paragraph reasoning>

### Six-Dimension Test
| Test | Signal | Evidence |
|------|--------|----------|
| Press Release | split / merge / neutral | <reason> |
| Independent Value | split / merge / neutral | <reason> |
| Independent Acceptance | split / merge / neutral | <reason> |
| Domain Language | split / merge / neutral | <reason> |
| User Journey | split / merge / neutral | <reason> |
| Time Appetite | split / merge / neutral | <reason> |

### Suggested Boundary
#### PRD A: <name>
- **Scope**: <included behavior>
- **Acceptance anchor**: <how it can be accepted independently>

#### PRD B: <name>
- **Scope**: <included behavior>
- **Dependency**: <none or what must ship first>

### What Not To Split
- <work that belongs in an existing PRD, design doc, or acceptance criteria>

## Remaining Open Questions
- <question that could change need, scope, behavior, or acceptance>

## Next Step
<The smallest edit to the PRD set or the next artifact to create.>

Hai PRD: Scope Dimensions, Tiers, and New-Feature Flow

Read this when the six-test in SKILL.md points toward split / merge and you need to choose a concrete cut, classify a PRD, or decide where a new feature lands. The six-test table in SKILL.md is the decision core; this file holds the supporting apparatus.

Preferred split dimensions

Split a PRD along a dimension where each fragment still carries independently acceptable user value:

• User journey stage — distinct stages of one journey can be accepted separately.
• Core path vs enhancement — the must-have flow can ship and be accepted before the nice-to-have.
• User role — different actors have different acceptance and value.
• Risk or complexity — isolating a high-risk slice lets it be validated on its own.
• Platform or channel — a distinct platform experience is independently usable.

Do not split by

These cuts fragment one user-acceptable journey across documents that nobody can accept independently:

• Technical layer (API PRD + frontend PRD + DB PRD) — because no single layer delivers

user-visible value or can be accepted on its own; the value only exists when the stack works end to end.

• CRUD action (separate create / read / delete PRDs) — because the operations are one

lifecycle and splitting them leaves each fragment without a complete, acceptable behavior.

• Team ownership — because org structure is not user value; splitting by team scatters one

journey across docs that mirror the org chart, not the product boundary.

Three-tier classification

New-feature decision flow

1. Is it a new core entity with an independent lifecycle? If yes, likely a new PRD. 2. Is it a cross-entity aggregate view? If yes, likely a new PRD. 3. Is it a new platform or channel? If yes, likely a new PRD. 4. If none apply, it usually belongs inside an existing PRD.

Hai PRD: Worked Examples

Two end-to-end runs showing how the modes and the six-test produce a concrete answer. Read this when you want to see how the judgment lands before applying it to the user's case.

---

Example A — Scope PRD: a split decision

Request: "We have one big PRD called User Profiles that covers viewing a profile, editing your own profile, and an admin moderation queue for reported profiles. Should this be one PRD or several?"

Run the six-test:

Choose the cut (see `scope-tiers.md`): split by user role + core-path-vs-enhancement, not by CRUD. Keep view + edit together — they are one self-service journey for one role.

Recommendation: Split into two PRDs.

• PRD A — Profile self-service (Tier 1, entity lifecycle of Profile): view + edit your own profile.
• PRD B — Profile moderation (Tier 2, aggregate view over reported profiles; owns the Report flow, depends on A's Profile existing).

Do not split view from edit (would break one journey) and do not split into API/frontend/DB PRDs (no fragment is independently acceptable).

---

Example B — Craft PRD: diagnose and repair an existing PRD

Request: "Here's our Checkout PRD, clean it up." (user provides the file)

Read the full document, then diagnose drift:

• Scope drift — the PRD bundles a payment-provider migration that has no user-visible

behavior change; it belongs in a separate technical effort (route to hai-goal).

• Acceptance drift — "checkout should feel fast" is not provable; no observable criterion.
• Conflict drift — the Behavior section says guest checkout is supported; the Permissions

section says login is required.

Reframe before rewriting:

• Corrected target outcome: "A returning or guest user can complete a purchase in one session with a confirmed order."
• PRD boundary: the checkout journey only; provider migration is out.
• Decision: reorganize + repair, not rewrite — the journey and scope are mostly sound.

Repairs applied:

• Moved the provider migration to a non-goal and noted it as a separate effort.
• Rewrote "feel fast" into "order confirmation renders within 2s of payment success (observable)."
• Resolved the guest-vs-login conflict by stating guest checkout is in scope and login is optional, and aligned the Permissions section to match.

Output: an Existing PRD Diagnosis (main drift = scope drift), a remove/keep/rewrite table, and the repaired acceptance criteria — per references/output-template.md.

Hai PRD 中文版

本文件是中文阅读版；执行规则以 SKILL.md 为准。

概览

处理所有 PRD 相关问题：是否需要 PRD、PRD 应该多大、一个需求该拆还是合、从产品问题写成 PRD、以及打磨已有 PRD。

不那么显然的视角：PRD 不是默认产物。不是每个想法、字段、接口、配置或技术决策都值得一份 PRD。先按请求选对模式，没有产品边界或验收需要时不要硬套 PRD。

核心原则

PRD 是带可验证验收的产品论证，不是功能清单。下面三条规则统领其余：

• 验收必须可证明。 一个 PRD 应解决一个清晰目标、一个主要用户旅程或产品边界，以及能证明它已交付的验收标准。
• 边界跟随用户心智，不跟随技术。 粒度按用户旅程和可独立验收来切，不按技术层、团队或文件切。
• 先修边界，再修文字。 如果 PRD 边界错了，先拆、合或重定边界，再打磨局部句子；把已有 PRD 当成系统来改——目标、范围、行为、验收、风险和 rollout 必须一致。

四种模式

1. Need PRD：是否需要 PRD

先判断产物类型——PRD 只是若干选项之一：

要问：

• 有没有用户、买方、运营、维护者或业务可见的行为变化？
• 这件事需不需要明确的范围内/范围外边界？
• 需不需要验收标准来证明做对了？
• 有没有产品级的选项、风险、约束或 rollout 需要记录？
• 没有 PRD 团队会不会在目标、范围或验收上产生分歧？

如果多数答案是否，就不要硬写 PRD。审计一组 PRD 时，还要检查彼此之间是否有重复边界、循环依赖或被打断的用户旅程。

2. Design PRD：从 0 写 PRD

把功能想法或产品问题写成 PRD 级需求：

1. 收集上下文。 目标用户、产品界面、当前行为、期望结果、约束、假设；以及已有 PRD、文档、截图、用户流、issue、数据或相邻 spec。 2. 框定需求。 用产品语言写清问题；定义目标结果和非目标；识别用户旅程或工作流边界；区分事实、假设和待解问题。 3. 设计范围。 决定什么放进这份 PRD，什么放进另一份 PRD、design doc、goal 或任务。不要捆绑无关的清理、平台工作或重构，除非它们直接影响产品行为或验收。 4. 定义行为和验收。 按场景描述预期行为；加上可观察的验收标准；只在相关时加入边界情况、失败状态、权限、空状态、数据依赖和 rollout。

3. Craft PRD：打磨已有 PRD

把已有 PRD 当成完整产品论证来打磨：

1. 先通读全文。 识别标题、目标用户、目标、旅程、范围、非目标、验收、风险和待解问题；标出矛盾、重复、过时段落、局部补丁和不合理内容。 2. 诊断文档漂移，用这套术语：

• 目标漂移：各段落在为不同结果做优化。
• 范围漂移：需求拉进了无关工作。
• 冲突漂移：行为、状态、权限、数据或 rollout 在不同段落互相矛盾。
• 验收漂移：验收标准无法证明目标结果。
• 方案漂移：实现选择替代了产品需求。
• 局部编辑漂移：某一段变好，但整份 PRD 变差。

3. 先重定框架再重写。 写出修正后的目标结果和 PRD 边界；决定保留、重组、拆分、合并还是重写。 4. 打磨文档。 用户给了文件就直接改；保留有用内容但移到正确段落；删掉无支撑、重复、过时或越界的内容；删除内容时说明为什么删除优于重写或移动。

4. Scope PRD：拆分/合并/粒度判断

按用户心智和可独立验收判断粒度，不按技术模块或团队。跑这六维测试——这是判断核心：

当测试指向拆或合时，读 references/scope-tiers.md 选具体切法：优先的拆分维度、要避免的拆法（技术层 / CRUD / 团队归属，因为这类碎片都无法独立验收）、三层分类（实体生命周期 / 聚合视图 / 平台扩展）以及新功能决策流。

工作流

1. 从请求里选模式：是否需要 → Need PRD；从问题写草案 → Design PRD；打磨已有文档 → Craft PRD；拆/合/粒度 → Scope PRD。一个请求可能跨多个模式（如先判断是否需要再判断粒度）。 2. 跑该模式上面的流程。 全程套用核心原则——先修边界，再修文字。 3. 拆/合问题先跑六维测试，再查 references/scope-tiers.md 选具体切法和分类。 4. 产出当前模式的输出（见下）。需要完整示例时，读 references/worked-example.md，里面有一个端到端拆分决策和一个端到端打磨/诊断。

输出

把当前模式对应到模板段落，只填相关段落：

# Hai PRD: <主题或文档名>
## Mode                  （Need PRD / Design PRD / Craft PRD / Scope PRD）
## PRD Necessity          — Need PRD：推荐 PRD / hai-goal / design doc / 任务 / 不单独产物
## PRD Draft              — Design PRD：目标结果、问题、用户、范围、需求、验收
## Existing PRD Diagnosis  — Craft PRD：主要漂移、冲突、删/留/重写、验收改进
## PRD Scope Assessment    — Scope PRD：六维测试信号、拆/合建议、建议边界
## Remaining Open Questions
## Next Step

定稿前读 references/output-template.md。不要机械输出全部 section，只输出和当前问题相关的模式。

何时改用别的 skill

路由到非 PRD 产物，本身就是 Need PRD 的判断——见 模式 1 的表。简言之：执行阶段/todo 用 hai-goal，模块边界与权衡用 hai-architecture，值不值得做用 hai-idea，代码/bugfix/测试 先行任务用 hai-tdd，实体该有哪些字段、字段放哪里用 entity-model-auditor，文档一致性用 文档审计 skill，漂移的非 PRD 文档要按锚点重写用 hai-rewrite-doc。只有当确实需要一个产品边界和可证明的验收时， 才回到 PRD 工作。

这个 skill 不是什么

• 不是项目管理——除非要求，不分配负责人或日期。
• 不是把每个想法都包成 PRD 的壳——没有产品边界或验收需要时，从 Need PRD 表里推荐对的产物，而不是硬写 PRD。