ワンクリックでManusで任意のスキルを実行

product-manager

Writes and reviews product requirements documents (PRD), user stories, and release plans for software projects. Use when authoring or rewriting requirements, design.md, feature specs, acceptance criteria, or when the user asks for PM-style documentation, PRD, or 需求文档.

Manusで実行

概要

インストールコマンド

npx skills add https://github.com/Max1122Chen/BUPT_ComputerNetworkCourse --skill product-manager

このコマンドをClaude Codeにコピー＆ペーストしてスキルをインストール

ソース

Max1122Chen/BUPT_ComputerNetworkCourse

スター0

フォーク2

更新日2026年5月18日 05:44

ファイルエクスプローラー

2 ファイル

SKILL.md

readonly

name	product-manager
description	Writes and reviews product requirements documents (PRD), user stories, and release plans for software projects. Use when authoring or rewriting requirements, design.md, feature specs, acceptance criteria, or when the user asks for PM-style documentation, PRD, or 需求文档.

Product Manager（需求文档）

目标读者

需求文档的读者包括：未参与讨论的开发者、课程助教/验收教师、同组成员、未来的自己。默认对方 不了解 项目背景与内部分期代号。

写作原则

先讲清「是什么、为谁、解决什么」，再讲阶段与细节。
用户语言优先：用「用户 / 客户端 / 本程序 / 上游 DNS」，少用未解释的缩写（首次出现写全称）。
每条需求可验收：功能描述必须附带 验收标准（可测试、可观察）。
场景驱动：用「当…则…」或用户故事描述行为，避免只列内部模块名。
分期对外可理解：阶段用 用户可感知的能力 命名（如「仅转发」），内部编号（P1.x）放附录。
边界明确：单独列出「不做 / 后续版本」，避免读者误以为已承诺。
技术细节分层：PRD 写 行为与约束；模块、数据结构、API 放到 design-technical.md 或 ADR。

禁止

假设读者知道「一期方案 B」「id_map」等内部用语而不解释。
只有里程碑表格、没有完整功能说明。
把 ADR 编号当作需求正文（可链接，不可代替叙述）。

PRD 输出结构

撰写或重写需求时，使用 prd-template.md 章节顺序。保存路径默认为项目 docs/design.md，版本号递增。

工作流

收集已定决策（口头、ADR、旧文档）。
用模板生成 PRD 正文（产品语言 + 验收标准）。
将实现级内容剥离到 design-technical.md（若存在）。
同步 test-plan.md：每个功能至少一条对应用例 ID。
在文档开头写 修订记录 与 一句话摘要。

质量自检（发布前）

陌生人读摘要能在 2 分钟内说清产品做什么
每个功能有验收标准
三期/发布范围各有「用户能做什么」描述
术语表覆盖 DNS、NXDOMAIN、上游等
与 ADR/decisions 无矛盾；矛盾时以 PRD 为准并更新 ADR

このリポジトリの他の Skills

同じリポジトリ

network-engineer

Max1122Chen/BUPT_ComputerNetworkCourse

Authors and reviews low-level network software technical design documents: protocol fields, socket architecture, data structures, module APIs, sequence diagrams, error handling, and PRD traceability. Use when writing design-technical.md, implementing DNS/TCP/UDP services, or when the user asks for network architecture, 技术设计, RFC-aligned design, or interface specifications.

2026-05-180

ソース

Max1122Chen

Max1122Chen/BUPT_ComputerNetworkCourse

GitHub リポジトリを開く Creator のリポジトリを見る

インストールコマンド

ダウンロード

Manusで実行

役立つ用途SOC

プロジェクト管理専門家ビジネス・金融業務職13-1082L4

name	product-manager
description	Writes and reviews product requirements documents (PRD), user stories, and release plans for software projects. Use when authoring or rewriting requirements, design.md, feature specs, acceptance criteria, or when the user asks for PM-style documentation, PRD, or 需求文档.

Product Manager（需求文档）

目标读者

写作原则

先讲清「是什么、为谁、解决什么」，再讲阶段与细节。
用户语言优先：用「用户 / 客户端 / 本程序 / 上游 DNS」，少用未解释的缩写（首次出现写全称）。
每条需求可验收：功能描述必须附带 验收标准（可测试、可观察）。
场景驱动：用「当…则…」或用户故事描述行为，避免只列内部模块名。
分期对外可理解：阶段用 用户可感知的能力 命名（如「仅转发」），内部编号（P1.x）放附录。
边界明确：单独列出「不做 / 后续版本」，避免读者误以为已承诺。
技术细节分层：PRD 写 行为与约束；模块、数据结构、API 放到 design-technical.md 或 ADR。

禁止

假设读者知道「一期方案 B」「id_map」等内部用语而不解释。
只有里程碑表格、没有完整功能说明。
把 ADR 编号当作需求正文（可链接，不可代替叙述）。

PRD 输出结构

撰写或重写需求时，使用 prd-template.md 章节顺序。保存路径默认为项目 docs/design.md，版本号递增。

工作流

收集已定决策（口头、ADR、旧文档）。
用模板生成 PRD 正文（产品语言 + 验收标准）。
将实现级内容剥离到 design-technical.md（若存在）。
同步 test-plan.md：每个功能至少一条对应用例 ID。
在文档开头写 修订记录 与 一句话摘要。

质量自检（发布前）

陌生人读摘要能在 2 分钟内说清产品做什么
每个功能有验收标准
三期/发布范围各有「用户能做什么」描述
术语表覆盖 DNS、NXDOMAIN、上游等
与 ADR/decisions 无矛盾；矛盾时以 PRD 为准并更新 ADR