mcpField
W
writing-prd

writing-prd

github.com/satanlittlehelper文档处理043 次安装1 天前更新
代码仓库

关于 writing-prd

用于根据已有讨论和决定起草 PRD 的技能，适用于不同代码库。它规定 PRD 使用俄语，并提供模板、文档存储和审批规则。

主要功能

  1. 01PRD 内容仅使用俄语
  2. 02可复用的 PRD 模板
  3. 03可衡量的成功指标
  4. 04保存前需审批
  5. 05持久化 docs/ 存储规则

适用场景

  1. 01根据已确定的范围起草需求
  2. 02将获批的 PRD 保存到代码库
  3. 03将未知工单信息标记为 TBD

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/satanlittlehelper/ai-dev-kit --skill writing-prd

安装后在 Claude Code 中输入/writing-prd确认已加载。

详细介绍

编写 PRD

概述

适用于任何仓库的 PRD 模板和格式规则。这不是访谈——根据对话中已有的信息整理文档；只有在必填章节确实无法填写时才提问。

适用场景

  • 用户要求编写／起草 PRD、“продуктовые требования”或“product requirements document”。
  • 尚未决定目标／范围？先运行 superpowers:brainstorming——PRD 用于记录决策，而不是做出决策。

存储与命名

沿用路线图的 docs/ 约定（参见 roadmap/SKILL.md，该约定本身与项目无关）：

  • 在仓库根目录使用 docs/<feature-slug>/YYYY-MM-DD-<feature-slug>-prd.md。
  • 纳入 Git 跟踪并永久保留——绝不放入 tmp/，发布后也绝不删除。
  • 如果当前环境提供原生 Plan Mode（EnterPlanMode/ExitPlanMode），则像使用 brainstorming/writing-plans 一样使用它：在 Plan Mode 的服务文件中起草，执行 ExitPlanMode，仅在获得批准后保存到 docs/。如果无法使用 Plan Mode（例如，当前环境是一个已分派的子 Agent），先在聊天中起草内容，并在保存前获得用户明确批准。
  • 绝不自动提交——只有收到明确请求时才提交。

模板

# <Feature name> — PRD

**Тикет:** `TBD` (реальный номер сообщает пользователь, в трекере проекта — не угадывать)
**Дата:** YYYY-MM-DD
**Статус:** Draft / In Review / Approved

## Проблема и контекст

Какая проблема существует сейчас, у кого, почему это важно решить именно сейчас.

## Цели

Что должно стать правдой в результате. Измеримо, где возможно.

## Не цели

Что сознательно остаётся вне рамок этой задачи — предотвращает расползание скоупа.

## Юзкейсы

Формат `Действие → Результат`, один на строку. Пример: `Пользователь открывает заявку с новым комментарием → видит уведомление о комментарии и переходит к нему`.

## Требования

### Функциональные

Пронумерованный список конкретных, проверяемых требований. Без «быстро»/«удобно»/«современно» — только измеримое:

```diff
- Поиск должен быть быстрым и удобным.
+ Поиск должен возвращать результат за ≤200мс на 10k записей.
非功能性需求

性能、安全性、可访问性、兼容性——仅列出实际适用的内容。

成功指标

3-5 个可衡量的 KPI，不要使用“改善 UX”之类含糊的表述。

风险与未决问题

未知事项或可能出错的地方；以及应由谁负责解答。

不在范围内／后续步骤

明确推迟到未来处理的事项。


## Formatting rules

- **Hard rule, no exceptions: the PRD body is written entirely in Russian** — headings, prose, and requirements alike — regardless of what language the request came in. No project-file lookup needed to decide this. Code blocks, identifiers, and technical terms stay in their original form.
- Section inapplicable? Keep the heading, write `Не применимо` — don't delete it.
- Unknown fact (ticket, stack, deadline, integration detail) → literal `TBD`, never guess. Ticket number specifically: only the user supplies the real one, in whatever format their tracker uses — never invent a prefix or number.
- No filler — facts and decisions only, not a narrative of the conversation.

## Common mistakes

| Mistake | Fix |
|---|---|
| Writing the PRD before the goal/scope is actually decided | Run `brainstorming` first; PRD documents a decision, it doesn't discover one |
| Saving straight to `docs/` without approval | Draft first (Plan Mode if available, chat otherwise), save only after explicit approval |
| Guessing a ticket number/prefix or any unstated fact (stack, deadline, integration) | Use `TBD` until the user supplies it |
| Dropping a template section instead of marking it not applicable | Keep the heading, write `Не применимо` with a one-line reason |
| Assuming a project-specific storage path or ticket format from a project's CLAUDE.md | This skill doesn't read project rule files — ask the user if a project convention should override the defaults above |

评论

支持 Markdown