manage-prd

name	manage-prd
description	创建和维护 Cat 项目的 PRD。用于按 domain 总览 + 粗粒度 feature 文档组织 docs/prds，包括 docs/prds/{domain}/overview.md、data_model.md、features/{feature_title}.md；也用于判断 feature 粒度、迁移旧版 aspect PRD，或生成可按 feature 复制到其他系统的产品规格。

管理 PRD

本 skill 用于管理 Cat 项目的 PRD，核心结构是 domain 总览 + feature 垂直切片。Feature 不是页面、API、数据表、按钮、CRUD 动作或 worker，而是一个值得复制到另一个系统的业务能力包。

目录结构

docs/prds/
└── {domain}/
    ├── overview.md
    ├── data_model.md
    └── features/
        └── {feature_title}.md

• overview.md：domain 级定位、职责边界、核心概念、feature 列表、feature 相对路径链接，以及与其他 domain 的关系。
• data_model.md：domain 级实体图、共享表、全局约束和完整模块数据关系。
• features/{feature_title}.md：主要阅读单元，应尽量自包含，方便复制到另一个系统。feature_title 以中文为主，约定俗成的英文技术 / 产品术语可保留英文；文件名中不使用空格，feature 展示名中的空格在文件名里用 - 替代。

编写具体 PRD 文件时阅读 references/templates.md。

Feature 粒度

优先使用这个判断标准：

Feature 是一个值得复制到另一个系统的业务能力包。

不要按实现产物切分：

• 不按页面、按钮、Dialog、字段、数据表、接口、CRUD 动作、worker 或配置项切分。
• 不要把别人很快就能轻松实现的小功能单独做成 feature。
• 优先保持较少、较粗的 feature。只有两个能力能被独立复制、独立理解、独立采用时，才拆开。

判断候选 feature 时回答：

1. 另一个系统是否可以只复制这个 feature，而不复制同 domain 下的大多数其他 feature？
2. 它是否产生明确的业务结果，而不是只暴露一个技术动作？
3. 它是否需要有意义的数据模型、流程、边界或状态设计？
4. 如果继续拆小，读者是否会被迫跨多个文件才能理解一个完整能力？

如果 1-3 大多是否，把它合并进更大的 feature。如果 4 是，倾向保持为一个 feature。

已有 feature 的稳定性

如果目标目录中已经存在 overview.md 或 features/ 文档，优先尊重文件中已经划分好的 feature 名称和粒度。

• 不轻易重命名、拆分、合并或删除已有 feature。
• 只有用户明确要求调整 feature 名称 / 粒度，或现有划分明显无法承载新增内容时，才改变已有 feature。
• 从旧版 aspect PRD 迁移到新版 PRD 时，若目标 overview.md 已经列出 feature，应按现有 feature 回填内容，不要重新设计 feature 列表。
• 新增 feature 时，应先检查是否可以并入已有 feature；只有它能独立复制、独立理解、独立采用时，才新增。

数据模型重复

允许 domain data_model.md 和 feature ## data_model 存在有意重复。

• Domain data_model.md 提供完整模块视角。
• Feature ## data_model 提供单个 feature 独立阅读、复制所需的数据模型。
• 两边的表名、字段类型、状态值和关系必须保持一致。
• Feature ## data_model 中列出的字段需要附带简短语义说明；不要因为 domain data_model.md 已经解释过就只列字段名。

工作流：创建或更新 Domain

1. 如果已有 docs/prds/{domain}/overview.md 和 data_model.md，先阅读。
2. 确认 domain 边界，以及用户是否要从旧版 aspect 布局迁移。
3. 创建或更新 overview.md：domain 定位、职责边界、概念、feature 列表、feature 相对路径链接、domain 关系；已有 feature 名称和粒度默认保持稳定。
4. 创建或更新 data_model.md：共享实体、完整 domain 实体关系和全局约束。
5. 只为业务能力包级别的内容在 features/ 下创建 feature 文档。
6. 检查 feature 名称、表、API、UI 术语是否与 domain 文档一致。

工作流：创建或更新 Feature

1. 先确认该 feature 是值得复制的业务能力包。
2. 拒绝或合并那些只是实现任务的候选项。
3. 使用以下 H2 小节编写 features/{feature_title}.md，没有实际内容的小节直接省略：
   • overview
   • data_model
   • api
   • api_admin
   • ui
   • ui_admin
   • commands
   • jobs
   • others
4. 让 feature 尽量自包含：包含复制它所需的最小数据模型、流程、API、UI 行为、jobs、权限、配置和约束。
5. 如果 feature 新增或改变共享实体，同步更新 domain overview.md 的 feature 索引和 domain data_model.md。

写作规则

• PRD 内容使用中文。
• Domain overview.md 的「模块职责」只写整体定位和边界，不重复枚举 feature 能力。
• Domain 文件名使用小写 snake_case；feature 文件名使用中文为主的 feature_title，例如 features/账号自助注销.md。
• Bot、API、CLI、OAuth、TOTP、RBAC、Token、staff、superuser 等约定俗成术语可在 feature 名称和标题中保留英文，不强行翻译。
• Feature 文件名不使用空格；如果 feature 展示名包含空格，文件名用 - 替代，例如 Bot Token 与本地 API CLI 对应 features/Bot-Token-与本地-API-CLI.md。
• Feature 文档标题必须使用两段格式：# {Domain} — {Feature}，其中 {Domain} 使用 domain 展示名，{Feature} 使用中文为主、必要术语保留英文的 feature 名称。
• 不要在 feature 标题里重复 feature 名称；禁止写成 # {Domain} — {Feature} — {Feature}，例如应写 # Actions — 帖子与评论的点赞收藏，不要写 # Actions — 帖子与评论的点赞收藏 — 帖子与评论的点赞收藏。
• overview.md 的 feature 列表使用自然展示名，并链接到对应的无空格 features/{feature_title}.md 文件名。
• Feature 文档的 H2 小节名称固定使用上面列出的小写名称。
• Feature 文档不再创建 ## current_status 小节；已有内容应合并进 ## overview 或对应能力小节。
• 不创建空小节、空占位文件。
• 含下划线的标识符必须用反引号包裹，例如 user_id。
• API 文档遵守 Cat 的 RPC 风格：/api/<context>/<action>，读操作 GET，写操作 POST。
• Cat 实现细节引用 DSL 路径，例如 lib/cat_api_spec/{context}.ex；面向可复制 feature 的说明仍需描述足够的业务请求/响应语义。