pmflow-cli 0.1.0__tar.gz → 0.1.1__tar.gz

{pmflow_cli-0.1.0 → pmflow_cli-0.1.1}/.gitignore

@@ -24,5 +24,8 @@ out/
 # OS
 .DS_Store
 
+# Claude Code (installed via `pmflow skill install`)
+.claude/commands/
+
 # uv
 uv.lock

{pmflow_cli-0.1.0 → pmflow_cli-0.1.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: pmflow-cli
-Version: 0.1.0
+Version: 0.1.1
 Summary: CLI for pmflow — project management for AI-assisted development
 Project-URL: Repository, https://github.com/zhanglaixian/pmflow
 Author-email: zhanglaixian <zhanglaixian@zhuanzhuan.com>
@@ -11,7 +11,7 @@ Classifier: License :: OSI Approved :: MIT License
 Classifier: Programming Language :: Python :: 3
 Requires-Python: >=3.12
 Requires-Dist: httpx>=0.27
-Requires-Dist: pmflow-shared>=0.1.0
+Requires-Dist: pmflow-shared>=0.1.1
 Requires-Dist: rich>=13.0
 Requires-Dist: tomli-w>=1.0
 Requires-Dist: tomli>=2.0; python_version < '3.11'

{pmflow_cli-0.1.0 → pmflow_cli-0.1.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "pmflow-cli"
-version = "0.1.0"
+version = "0.1.1"
 description = "CLI for pmflow — project management for AI-assisted development"
 requires-python = ">=3.12"
 readme = "README.md"
@@ -13,7 +13,7 @@ classifiers = [
     "Environment :: Console",
 ]
 dependencies = [
-    "pmflow-shared>=0.1.0",
+    "pmflow-shared>=0.1.1",
     "typer>=0.12",
     "httpx>=0.27",
     "rich>=13.0",

{pmflow_cli-0.1.0 → pmflow_cli-0.1.1}/skills/plan-task/SKILL.md

@@ -8,7 +8,17 @@ user-invocable: true
 
 执行以下步骤：
 
-## 1. 获取 Issue 的所有上下文内容
+## 1. 将 Issue 状态更新为 DOING
+
+运行命令：
+
+```
+pmflow issue status {seq_num} doing --workspace {slug}
+```
+
+如果命令失败，将错误信息告知用户但继续执行后续步骤（状态变更失败不应阻塞工作流）。
+
+## 2. 获取 Issue 的所有上下文内容
 
 运行命令：
 
@@ -18,7 +28,7 @@ pmflow ctx dump {seq_num} --workspace {slug}
 
 如果命令失败，将错误信息告知用户并停止。
 
-## 2. 进入 Plan 模式
+## 3. 进入 Plan 模式
 
 成功获取上下文内容后，进入 plan 模式。基于上下文中的需求文档（PRD、设计文档等），制定详细的技术实现方案：
 

pmflow_cli-0.1.1/skills/prd/SKILL.md

@@ -0,0 +1,236 @@
+---
+name: pmflow:prd
+description: 为新功能生成产品需求文档（PRD），梳理用户痛点和产品价值。用法：/pmflow:prd 功能描述
+user-invocable: true
+---
+
+# PRD 生成器
+
+为产品功能创建清晰、可执行的产品需求文档，聚焦用户痛点与产品价值。
+
+**重要：** 不要涉及任何技术实现细节或代码，这是一份面向产品的文档。
+
+---
+
+## 工作流程
+
+1. 接收用户的功能描述（来自 `$ARGUMENTS`）
+2. 提出 3-5 个关键澄清问题（带字母选项）
+3. 根据回答生成结构化 PRD
+4. 保存至 `tasks/prd-[功能名].md`
+
+---
+
+## 第一步：澄清问题
+
+仅在初始描述有歧义时提问，聚焦以下方面：
+
+- **问题/目标：** 解决什么用户痛点？
+- **目标用户：** 谁会使用这个功能？
+- **核心场景：** 用户的关键操作流程是什么？
+- **范围边界：** 这个功能不做什么？
+- **成功标准：** 怎样算做好了？
+
+### 问题格式示例：
+
+```
+1. 这个功能主要解决什么问题？
+   A. 新用户上手困难
+   B. 老用户留存下降
+   C. 客服工单量过高
+   D. 其他：[请说明]
+
+2. 目标用户是谁？
+   A. 仅新用户
+   B. 仅现有用户
+   C. 所有用户
+   D. 管理员
+
+3. 期望的功能范围？
+   A. 最小可用版本（MVP）
+   B. 完整功能
+   C. 先做核心流程，后续迭代
+```
+
+用户可以用 "1A, 2C, 3B" 快速回复。选项要缩进对齐。
+
+---
+
+## 第二步：PRD 结构
+
+生成包含以下章节的 PRD：
+
+### 1. 概述
+简要描述功能及其解决的用户问题。用 1-2 段话说清楚：现状是什么、痛点在哪、这个功能如何改善。
+
+### 2. 目标
+具体、可衡量的产品目标（项目符号列表）。
+
+### 3. 目标用户与场景
+- 明确目标用户画像
+- 描述典型使用场景
+
+### 4. 用户故事
+每个故事包含：
+- **标题：** 简短描述
+- **描述：** "作为[角色]，我希望[功能]，以便[价值]"
+- **验收标准：** 可验证的完成清单
+
+每个故事应足够小，可在一个迭代周期内完成。
+
+**格式：**
+```markdown
+### US-001: [标题]
+**描述：** 作为[角色]，我希望[功能]，以便[价值]。
+
+**验收标准：**
+- [ ] 具体可验证的标准
+- [ ] 另一个标准
+```
+
+**要求：**
+- 验收标准必须可验证，不能模糊。"功能正常"是坏的。"点击删除按钮后弹出确认对话框"是好的。
+- 从用户视角描述，避免技术术语。
+
+### 5. 功能需求
+编号列表，描述具体功能行为：
+- "FR-1: 用户可以..."
+- "FR-2: 当用户执行X操作时，系统应..."
+
+要明确、无歧义，但用产品语言而非技术语言。
+
+### 6. 非目标（不在范围内）
+明确列出本次不做的事情。这对控制范围至关重要。
+
+### 7. 交互与体验设计
+- 关键页面/流程的交互说明
+- 信息架构与导航
+- 异常状态的用户提示（空状态、错误提示等）
+- 如有原型或设计稿，附上链接
+
+### 8. 成功指标
+如何衡量功能是否成功？
+- "用户完成X操作的时间减少 50%"
+- "转化率提升 10%"
+- "相关客服工单减少 30%"
+
+### 9. 待定问题
+仍需讨论或澄清的问题。
+
+---
+
+## 写作原则
+
+PRD 的读者可能是设计师、开发者或其他产品经理，因此：
+
+- 用产品语言，避免技术术语
+- 聚焦用户痛点和价值，不涉及实现方式
+- 明确具体，避免模糊表述
+- 需求编号方便引用和讨论
+- 适当举例帮助理解
+
+---
+
+## 输出
+
+- **格式：** Markdown（`.md`）
+- **位置：** `tasks/`
+- **文件名：** `prd-[功能名].md`（kebab-case，英文命名）
+
+---
+
+## 示例 PRD
+
+```markdown
+# PRD: 任务优先级
+
+## 概述
+
+当前任务列表中所有任务平铺展示，用户无法快速识别哪些事情更紧急、更重要。随着任务数量增长，用户经常遗漏高优任务，导致关键工作延误。
+
+本功能为任务增加优先级标记（高/中/低），通过视觉区分和筛选能力，帮助用户聚焦重要事项，提升工作效率。
+
+## 目标
+
+- 用户可以为任何任务标记优先级（高/中/低）
+- 不同优先级有清晰的视觉区分
+- 支持按优先级筛选和排序
+- 新任务默认为中优先级
+
+## 目标用户与场景
+
+**目标用户：** 日常使用任务管理功能的所有用户，特别是同时管理 10+ 任务的用户。
+
+**典型场景：**
+- 用户在周一早上打开任务列表，快速筛选出高优先级任务，规划本周工作重点
+- 用户创建新任务时，标记为高优先级以确保团队关注
+- 用户在任务回顾时，将已降低紧迫性的任务调整为低优先级
+
+## 用户故事
+
+### US-001: 查看任务优先级
+**描述：** 作为用户，我希望在任务列表中一眼看出每个任务的优先级，以便快速判断哪些事情需要优先处理。
+
+**验收标准：**
+- [ ] 每个任务卡片显示彩色优先级标签（红色=高、黄色=中、灰色=低）
+- [ ] 无需悬停或点击即可看到优先级
+
+### US-002: 修改任务优先级
+**描述：** 作为用户，我希望在编辑任务时能修改其优先级，以便根据实际情况灵活调整。
+
+**验收标准：**
+- [ ] 任务编辑界面包含优先级选择器
+- [ ] 显示当前优先级为已选状态
+- [ ] 选择后立即保存
+
+### US-003: 按优先级筛选任务
+**描述：** 作为用户，我希望按优先级筛选任务列表，以便在专注工作时只看高优先级事项。
+
+**验收标准：**
+- [ ] 提供筛选项：全部 | 高 | 中 | 低
+- [ ] 筛选结果为空时显示友好提示
+- [ ] 刷新页面后筛选条件保持不变
+
+## 功能需求
+
+- FR-1: 每个任务支持设置优先级，可选值为高、中、低，默认中
+- FR-2: 任务卡片上显示彩色优先级标签
+- FR-3: 任务编辑界面包含优先级选择器
+- FR-4: 任务列表头部提供优先级筛选下拉框
+- FR-5: 同一状态列内，任务按优先级从高到低排序
+
+## 非目标
+
+- 不做基于优先级的通知或提醒
+- 不做根据截止日期自动调整优先级
+- 不做子任务的优先级继承
+
+## 交互与体验设计
+
+- 优先级标签使用语义化颜色（红/黄/灰），色弱用户可通过文字辅助区分
+- 优先级选择器使用下拉菜单，操作不超过 2 次点击
+- 筛选状态通过 URL 参数保持，支持分享链接
+
+## 成功指标
+
+- 用户修改优先级操作不超过 2 次点击
+- 高优先级任务在列表顶部，用户无需翻滚即可看到
+- 功能上线后，任务延误率下降
+
+## 待定问题
+
+- 优先级是否影响看板列内的排序？
+- 是否需要支持键盘快捷键修改优先级？
+```
+
+---
+
+## 保存前检查
+
+- [ ] 已提出带选项的澄清问题
+- [ ] 已将用户回答融入文档
+- [ ] 用户故事小而具体，从用户视角描述
+- [ ] 功能需求有编号且无歧义
+- [ ] 非目标章节明确划定了范围边界
+- [ ] 全文不包含技术实现细节或代码
+- [ ] 已保存至 `tasks/prd-[功能名].md`

{pmflow_cli-0.1.0/src/pmflow_cli → pmflow_cli-0.1.1}/skills/prdfix/SKILL.md

@@ -24,14 +24,24 @@ user-invocable: true
 
 ## 2. 创建飞书文档并关联 Issue
 
-将上述总结内容写入临时文件 `/tmp/prdfix-summary.md`，然后运行命令：
+将上述总结内容用 Bash `cat <<'EOF'` 写入临时文件 `/tmp/prdfix-{slug}-{seq_num}.md`（不要先读取任何已有文件），然后运行命令：
 
 ```
-pmflow ctx add-doc {seq_num} --workspace {slug} --title "PRD 实现总结 - {slug上大写}-{seq_num}" --content-file /tmp/prdfix-summary.md
+pmflow ctx add-doc {seq_num} --workspace {slug} --title "[{slug上大写}-{seq_num}] 实现总结" --content-file /tmp/prdfix-{slug}-{seq_num}.md
 ```
 
 如果命令失败，将错误信息告知用户并停止。
 
-## 3. 确认完成
+## 3. 将 Issue 状态更新为 DONE
 
-命令成功后，将飞书文档链接展示给用户，确认总结已保存到对应 Issue 的上下文中。
+运行命令：
+
+```
+pmflow issue status {seq_num} done --workspace {slug}
+```
+
+如果命令失败，将错误信息告知用户但继续执行后续步骤（状态变更失败不应阻塞工作流）。
+
+## 4. 确认完成
+
+命令成功后，将飞书文档链接展示给用户，确认总结已保存到对应 Issue 的上下文中，并告知 Issue 状态已更新为 DONE。

pmflow_cli-0.1.1/skills/snapshot-space/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: pmflow:snapshot-space
+description: 收集 Space 基本信息、原始 PRD 和 Issue 列表，结合代码库骨架信息生成 Space 快照文档并同步到飞书。用法：/pmflow:snapshot-space {slug}
+user-invocable: true
+---
+
+从参数 `$ARGUMENTS` 中获取 workspace slug。
+
+执行以下步骤：
+
+## 1. 获取 Space 服务端上下文
+
+运行命令：
+
+```
+pmflow ctx dump-space {slug} --exclude "Space 快照"
+```
+
+如果命令失败，将错误信息告知用户但继续执行后续步骤。将获取到的内容保存为变量，供后续写入文档使用。这里面包含 Space 的原始 PRD 和关联的上下文文档。
+
+## 2. 获取产品规划数据
+
+运行命令获取 workspace 中的所有 Issue：
+
+```
+pmflow issue list --workspace {slug} --format json
+```
+
+如果命令失败，将错误信息告知用户但继续后续步骤（注明"产品规划数据不可用"）。
+
+成功获取后，按以下规则处理（**仅使用 JSON 中的字段，不要再调用 `ctx dump` 读取飞书文档**）：
+
+1. **解析 Issue 层级**：从 JSON 中提取所有 Issue，按 `type` 分组（feature / task / bug）。通过 `parent_id` 字段匹配 Feature 的 `id`，构建 Feature → 子任务层级关系。
+2. **提取摘要**：每个 Issue 的摘要直接使用其 `description` 字段（截取前 1-2 句），无需读取 PRD 文档。如果 `description` 为空，标注"无描述"。
+3. **区分独立任务与子任务**：`parent_id` 为空的 Task/Bug 为独立 Issue，有 `parent_id` 的为某个 Feature 的子任务。独立 Issue 需要在快照中单独列出（含序号、标题、状态、描述），子任务只在所属 Feature 行中统计数量。
+4. **统计汇总**：按 type（feature / task / bug）× status（todo / doing / done / blocked）分别统计数量。
+
+## 3. 从记忆中提取项目关键信息
+
+检查你的 memory 文件（如果有），提取以下类型的信息供写入快照：
+
+- **项目进展与里程碑**：开发阶段、关键时间节点
+- **设计决策与理念**：架构选型的原因、UI/UX 风格偏好、核心设计原则
+- **踩过的坑与经验**：开发中遇到的关键技术问题和解决方式
+
+这些"软信息"是代码扫描无法获取的，但对 PRD 生成至关重要——它们帮助 AI 理解项目的风格和决策偏好。
+
+## 4. 深度理解代码库
+
+不要只读声明层，而是要**理解项目的设计体系和产品语言**。分三层逐步深入：
+
+### 4.1 项目骨架（快速扫描）
+
+1. **项目描述文件**: 读取 `CLAUDE.md`、`README.md`（如存在），提取项目概述和技术栈
+2. **依赖与元数据**: 读取根目录的 `pyproject.toml`、`package.json` 等，提取依赖列表
+3. **目录结构**: 列出根目录及核心目录的文件树（2-3 层深度即可）
+
+### 4.2 功能梳理（端点 + 页面）
+
+- **后端路由文件**: 找到 routers 目录，读取每个路由文件的端点定义（装饰器 + 函数签名 + docstring），归纳出系统提供的 API 能力
+- **前端页面文件**: 找到 App Router 的页面目录，根据 `page.tsx` 的路径和页面组件名，归纳出用户可见的功能页面
+- 只读端点/页面的声明层（装饰器、路径、函数名、docstring），不读函数实现体
+
+### 4.3 设计体系与产品语言（深度理解）
+
+这一步是区别于简单罗列的关键——你需要**主动探索**以下内容，理解产品的"气质"：
+
+1. **视觉设计体系**：
+   - 读取 `globals.css` 或 Tailwind 配置，提取主题色系（主色、强调色、语义色）、圆角体系、阴影层次
+   - 识别是否有自定义设计系统（如 Glass UI、Neumorphism 等特殊效果类名）
+   - 记录明/暗主题配置
+
+2. **UI 组件库风格**：
+   - 读取 `components.json` 或等效配置，了解组件库风格（如 shadcn 的 style/theme）
+   - 快速浏览 `components/ui/` 目录，了解已安装的基础组件集合
+   - 注意组件底层依赖（如 Radix、Base UI、Headless UI），这影响交互风格
+
+3. **产品表述风格**：
+   - 读取 1-2 个关键页面（如登录页、帮助页、首页），提取产品 slogan、描述文案、按钮文字的语气风格（正式/轻松/技术向）
+   - 注意中英文混用的习惯（如"AI Coding"而非"人工智能编码"）
+
+4. **品牌元素**：
+   - 检查 logo 文件和 favicon，了解品牌形象（如 logo 是吉祥物还是文字 logo）
+   - 记录字体选择（display font vs body font）
+
+**注意**：不要深入阅读业务逻辑代码，这一步的目标是提取"产品长什么样、说什么话"的信息。
+
+## 5. 提炼与总结
+
+这是最重要的一步。不要简单罗列信息，而是像产品经理一样**提炼**：
+
+- **功能描述**要从用户视角出发，说明"解决什么问题"，而不只是"有什么 API"。例如：不写"Issue CRUD + 三种类型 + 状态流转"，而写"Issue 全生命周期管理：支持 Feature/Task/Bug 三种类型，workspace 内自增序号，状态从 TODO 到 DONE 清晰流转"
+- **按产品模块分组**功能，而不是按代码分层（不要分"认证路由""Issue 路由"，而是分"认证与用户""项目管理""AI 能力"等）
+- **设计语言章节**要用文字描述产品的视觉印象，不只是列出 CSS 变量值
+
+## 6. 生成快照文档
+
+将分析结果综合写入 `docs/SPACE_SNAPSHOT.md` 文件（如 `docs/` 目录不存在则先创建）。如果该文件已存在则覆盖。
+
+文档必须包含以下章节，使用中文撰写：
+
+```markdown
+# {项目名称} — Space 快照
+
+> 生成时间：{通过 `date '+%Y-%m-%d %H:%M'` 获取的本地时间}
+
+## 项目概述
+
+这个项目是什么、解决什么问题、目标用户是谁。（来自 CLAUDE.md / README.md / Space PRD）
+
+## 设计理念与关键决策
+
+项目的核心设计原则、架构选型理由等。（来自记忆和项目文档）
+这些信息帮助后续 PRD 保持与项目整体风格一致。
+
+## 技术栈
+
+使用的语言、框架、核心库、部署模式。简要列表即可。
+
+## 设计语言
+
+产品的视觉风格和交互特征。包括：
+- 色彩体系（主色调、明/暗主题风格）
+- UI 框架与组件风格（如 shadcn base-nova + Liquid Glass）
+- 字体与排版
+- 品牌元素（logo 形象、吉祥物等）
+- 产品文案风格（语气、中英混用习惯等）
+
+这个章节帮助后续设计和开发保持视觉一致性。
+
+## 主要功能
+
+基于后端 API 端点和前端页面梳理出的功能模块。按产品模块分组，每个模块用一句话概括其产品价值，下面列出具体能力。
+这是快照中最重要的章节之一，它为后续 PRD 生成提供"系统已有什么"的上下文。
+
+## 产品规划与进展
+
+来自步骤 2 获取的产品规划数据。包含以下子章节：
+
+### Feature 概览
+
+表格形式列出所有 Feature，每行包含序号、标题、状态、描述摘要（取 description 前 1-2 句）、子任务统计。示例：
+
+| # | Feature | 状态 | 描述 | 子任务 |
+|---|---------|------|------|--------|
+| 28 | 创建 Issue 时自动创建 PRD 模版 | done | 创建 Feature/Issue 时自动创建一个 PRD 模版文档 | 2个任务(2完成) |
+
+### 独立任务
+
+表格形式列出所有 `parent_id` 为空的 Task（即不属于任何 Feature 的独立任务）。示例：
+
+| # | 任务 | 状态 | 描述 |
+|---|------|------|------|
+| 53 | Space 全局快照 cli/skill | doing | 为 Agent 提供 Space 全局信息感知 |
+
+### Bug 列表
+
+表格形式列出所有 Bug（如果有）。格式同独立任务。如果没有 Bug，注明"暂无 Bug"。
+
+### 统计汇总
+
+按类型和状态汇总数量：
+- Feature: X个待办 / X个进行中 / X个已完成
+- Task: X个待办 / X个进行中 / X个已完成（含子任务）
+- Bug: X个待办 / X个进行中 / X个已完成
+
+如果步骤 2 获取失败，整个章节注明"产品规划数据不可用"。
+
+## 目录结构
+
+项目关键目录的注释树，帮助快速定位代码。
+
+## 外部依赖
+
+主要第三方服务、API、SDK 依赖列表。
+
+## 开发命令
+
+如何构建、运行、测试本项目。
+
+## Space 上下文文档
+
+来自 pmflow 服务端的 PRD、设计文档等上下文内容（完整保留原文）。
+如果步骤 1 获取失败，注明"服务端上下文不可用"。
+```
+
+写作要求：
+- **只描述事实**，不写愿景、规划或改进建议
+- **概括总结**，不要粘贴大段代码
+- 每个章节保持简洁（几段话或要点列表）
+- Space 上下文文档章节保留完整原文，不做删减
+- **功能描述用产品语言**，不用技术术语堆砌
+
+## 7. 同步到飞书并关联 Space
+
+将生成的快照文档同步为飞书文档，关联到 Space 的 contexts 中。
+
+用 Bash `cp docs/SPACE_SNAPSHOT.md /tmp/snapshot-{slug}.md` 将文件复制到临时位置，然后运行命令：
+
+```
+pmflow ctx add-space-doc {slug} --title "[{slug大写}] Space 快照" --content-file /tmp/snapshot-{slug}.md
+```
+
+如果命令失败，将错误信息告知用户但不影响整体流程（本地文档已生成）。
+
+## 8. 确认完成
+
+告知用户：
+1. `docs/SPACE_SNAPSHOT.md` 已生成
+2. 飞书文档已创建/更新并关联到 Space（附上文档链接）
+3. 简要列出文档涵盖的关键信息摘要