원클릭으로 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