cgraphx 1.1.0

package/dist/.claude-template/skills/write-prd/SKILL.md

@@ -0,0 +1,242 @@
+---
+name: write-prd
+description: 用户要求基于已确认的需求、业务边界、业务规则、流程说明、客户材料或当前上下文编写 PRD/业务需求文档时使用。用于产出给领导、客户、业务方审阅的业务需求文档,帮助能拍板的人确认业务决策、业务流程、范围、规则、权限、异常和验收口径是否符合预期。不写技术 spec、实现计划或代码;信息不足时只补问影响业务决策确认的关键问题,或将不确定内容标记为【待确认】。
+---
+
+# 编写 PRD (Write PRD)
+
+## 定位
+
+把当前上下文中已经确认或给定的需求信息,整理成**给领导、客户或业务方审阅的业务需求文档**。
+
+目标是让能拍板的人确认:业务决策是否符合预期,范围是否正确,流程是否完整,规则是否清楚,异常和验收口径是否可接受。PRD 不是给研发发挥的方案文档,而是把需要领导/业务方拍板的规则和口径摆清楚。
+
+<HARD-GATE>
+不要把 PRD 写成技术 spec、实现计划、数据库设计、接口设计或代码方案。
+不要主动调用或要求使用其他 skill。按当前上下文独立完成 PRD 编写。
+如果缺少会影响领导/业务方确认业务决策的关键信息,先补问 3-5 个关键问题;如果不阻塞成文,在 PRD 中标记为【待确认】。
+不要编造未确认的业务规则。如果必须依赖未确认规则,先向用户确认。
+</HARD-GATE>
+
+## 输入理解
+
+优先基于当前上下文中的以下信息写 PRD:
+
+- 用户已确认的需求描述
+- 已确认的业务目标、业务边界和非目标
+- clarify 阶段产出的已锁定业务决策、已排除方案、待拍板项和下游就绪判断
+- 已确认的角色、场景、流程、规则、异常和验收口径
+- 客户提供的业务背景、规则、流程、样例、截图或接口说明
+- 项目里已有的业务文档、页面、模型、接口、流程或数据口径
+
+如果当前上下文已经足够,直接写 PRD。不要重新澄清已经确认过的内容。
+
+如果只有一句模糊想法,不要硬写完整 PRD。先用 3-5 个问题补齐最影响业务决策确认的内容。
+
+## 受众和边界
+
+面向领导、客户、业务方、产品负责人、项目干系人。文档应当业务可读,不要求审阅者懂代码。
+
+可以写:
+
+- 业务背景和目标
+- 需求范围和非范围
+- 用户角色和使用场景
+- 业务流程
+- 功能需求
+- 业务规则
+- 数据口径的业务含义
+- 权限和可见性
+- 异常场景
+- 验收标准
+- 待确认项
+
+不要写:
+
+- 代码实现步骤
+- 数据库表结构和字段设计
+- 接口参数细节,除非客户需要用它确认业务含义
+- 类名、函数名、模块拆分
+- 开发排期和任务分解
+- 技术选型论证
+- 测试用例明细,除非作为客户可读验收口径
+
+## 工作流程
+
+1. **检查上下文完整性**
+    - 确认当前上下文是否已有明确需求范围。
+    - 识别缺失的业务目标、角色、范围、流程、规则、异常或验收口径。
+    - 只补问会影响领导/业务方拍板业务决策的问题。
+    - 如果 clarify 总结里有"必须在 PRD/spec/plan 前解决的问题",先处理这些问题,不要绕过。
+
+2. **确定 PRD 粒度**
+    - 简单需求写轻量 PRD。
+    - 跨流程、跨角色、跨系统或规则复杂的需求写完整 PRD。
+    - 不为了显得完整而堆砌无关章节。
+
+3. **转换语言**
+    - 把技术描述翻译成客户可理解的业务语言。
+    - 保留必要的业务名词、状态名、角色名、入口名、单据名、产品名。
+    - 避免内部实现术语干扰客户审阅。
+
+4. **编写 PRD**
+    - 先讲业务目标和范围,再讲流程和规则。
+    - 对领导/业务方最需要确认的业务决策使用清单、表格或流程说明。
+    - 明确区分"已确认规则"、"待拍板规则"、"明确不做"。
+    - 对未确认内容标记【待确认】,不要偷偷补齐。
+
+5. **自检**
+    - 检查客户是否能通过文档判断“是不是我要的”。
+    - 检查是否混入实现方案。
+    - 检查范围、非范围、异常、验收是否清楚。
+
+## 推荐输出结构
+
+根据需求复杂度裁剪。默认使用以下结构:
+
+```markdown
+# 业务需求文档: <需求名称>
+> feature-id: <feature-id>
+> 状态: 草稿
+> 日期: YYYY-MM-DD
+
+## 1. 背景与目标
+
+## 2. 需求范围
+### 2.1 本次包含
+### 2.2 本次不包含
+
+## 3. 用户角色与使用场景
+
+## 4. 业务流程
+
+## 5. 功能需求
+
+## 6. 业务规则
+
+## 7. 数据口径与状态说明
+
+## 8. 需拍板的业务决策
+
+## 9. 权限与可见性
+
+## 10. 异常与边界场景
+
+## 11. 验收标准
+
+## 12. 待确认项
+```
+简单需求可以合并章节,但至少保留:背景目标、范围、业务流程或功能说明、业务规则、验收标准、待确认项。
+
+## 产物位置
+
+在可写项目上下文中,默认创建或更新:
+
+`docs/features/<feature-id>/prd.md`
+
+如果没有可写项目上下文,或用户明确只需要正文,则直接在回复中输出 PRD 内容。
+
+## feature-id 规则
+
+格式:`YYYY-MM-DD-<short-slug>`。
+
+1. 日期使用当前日期。
+2. slug 从需求名称或业务目标中提炼,优先短、清晰、可识别。
+3. slug 可使用中文业务短语或英文短语,用连字符分隔,不强行翻译。
+4. 若当前上下文或用户已提供 feature-id,则复用。
+5. 写入前检查 `docs/features/` 下是否重名;重名时追加简短后缀。
+6. 默认创建 `docs/features/<feature-id>/prd.md`。
+
+## 章节写法
+
+### 背景与目标
+
+说明为什么要做,解决什么业务问题,客户期望得到什么业务结果。不要写技术原因作为主线。
+
+### 需求范围
+
+明确本次做什么和不做什么。非范围必须写清楚,防止客户误以为包含。
+
+### 用户角色与使用场景
+
+说明谁使用、谁受影响、在什么业务场景下触发。角色名称应使用客户或项目里的叫法。
+
+### 业务流程
+
+按客户能理解的步骤描述。从触发条件开始,到业务结果结束。复杂流程可用编号步骤、状态流转表或 Mermaid 流程图。
+
+### 功能需求
+
+按业务能力拆分。每条需求写清楚:
+
+- 用户动作或系统动作
+- 前置条件
+- 系统应表现出的业务行为
+- 业务结果
+
+### 业务规则
+
+写领导/业务方需要确认的判断规则、限制条件、计算口径、状态变化、优先级、冲突处理。规则必须可验证。
+
+### 数据口径与状态说明
+
+只写业务含义,不写数据库设计。说明关键字段、状态、数量、金额、时间、来源、统计口径等对业务决策有影响的内容。
+
+### 需拍板的业务决策
+
+集中列出只有领导、客户或业务方能决定的规则和口径,例如:
+
+- 统计维度、过滤条件、时间范围、去重规则
+- 状态含义、状态流转、例外处理
+- 权限边界、数据可见范围、审批权
+- 兼容历史数据或旧流程的取舍
+- 异常场景的业务处理方式
+
+已确认的写入"已确认";未确认但影响后续 spec/plan 的写入【待确认】,不要让研发或 agent 在实现期自行拍板。
+
+### 权限与可见性
+
+说明哪些角色能看、能操作、不能操作;不同组织、租户、部门、区域或客户范围是否隔离。
+
+### 异常与边界场景
+
+说明失败、重复、撤销、超时、空数据、无权限、数据不存在、部分成功、历史数据等客户可能关心的场景。
+
+### 验收标准
+
+用客户可判断的业务结果表达。避免“接口正常”“代码完成”这类开发视角表述。
+
+### 待确认项
+
+列出仍需客户或业务方确认的内容。不要把待确认项藏在正文里。
+
+## 写作原则
+
+- 面向客户确认业务逻辑,不是面向研发交付实现。
+- 面向领导/业务方确认业务决策,尤其是只有业务负责人能拍板的规则、口径和例外。
+- 先结论后细节,先范围后流程,先规则后例外。
+- 用业务语言表达,少用技术术语。
+- 必要技术边界只作为约束背景,不要展开设计。
+- 不确定就标【待确认】。
+- 已确认的非目标要明确写出。
+- 简单需求轻量写,复杂需求完整写。
+- 不要把用户没确认的头脑风暴选项写成正式需求。
+- 不要把需要领导拍板的业务规则留给 spec、plan 或 implementation 阶段临场决定。
+- 不要自动进入 spec、plan 或 implementation。
+
+## 质量检查
+
+输出前确认:
+
+- 领导/业务方能看懂这个需求要解决什么问题。
+- 领导/业务方能确认本次做什么、不做什么。
+- 领导/业务方能按文档检查业务流程是否符合预期。
+- 需要拍板的业务规则、口径、权限、异常和验收项没有被藏到技术文档或实现阶段。
+- 关键业务规则没有遗漏或被技术术语掩盖。
+- 异常和边界场景不会导致明显理解偏差。
+- 验收标准是业务结果,不是开发动作。
+- 所有未确认内容都标为【待确认】。
+
+## 收尾方式
+
+输出 PRD 后,只提示领导、客户或用户可以审阅业务决策并指出需要调整的地方。不要主动继续写技术 spec、实现计划或代码。

package/dist/.claude-template/skills/write-spec/SKILL.md

@@ -0,0 +1,278 @@
+---
+name: write-spec
+description: 用户要求基于已确认的需求、业务边界、技术方案边界、PRD、业务规则、接口影响、数据影响或当前上下文编写 spec/规格说明/技术规格归档时使用。用于产出研发或 Agent 可引用的系统规格契约,归档系统必须满足的业务行为、规则、数据、接口、权限、异常、兼容性、约束和验收口径,作为后续 plan/实现计划的稳定输入。不写客户 PRD、不写实现计划、不写代码;信息不足时只补问影响规格正确性或 plan 正确性的关键问题,或将不确定内容标记为【待确认】。
+---
+
+# 编写 Spec (Write Spec)
+
+## 定位
+
+把当前上下文中已经确认或给定的需求、业务要求和技术边界,整理成**研发或 Agent 可引用的系统规格契约**。
+
+Spec 的目标是归档系统应该满足什么行为和约束,为后续 plan 文件和实际编码提供稳定输入。Spec 之后,后续 agent 不应重新解释业务规则、数据口径、接口契约、权限边界或异常行为。
+
+<HARD-GATE>
+如果缺少会影响规格正确性或后续 plan 正确性的关键信息,先补问 3-5 个关键问题;如果不阻塞成文,在 spec 中标记为【待确认】。
+不要编造未确认的业务规则、接口行为、数据结构或技术约束。如果必须依赖未确认规则,先向用户确认。
+会影响 plan 写死或实现正确性的【待确认】不能伪装成已确认规格。
+</HARD-GATE>
+
+## 与其他产物的边界
+
+- PRD 说明客户或业务方要确认的业务逻辑。
+- Spec 说明系统必须满足的行为、规则、接口、数据、权限、异常和约束,是后续 plan 的契约来源。
+- Plan 说明如何分步骤修改代码来满足 spec,不得重新定义 spec。
+- Implementation 按 plan 编码,不得重新设计 spec 已锁定的契约。
+
+Spec 可以包含必要的技术边界和系统影响,但不要展开成任务列表、文件级修改步骤或代码实现细节。
+
+## 输入理解
+
+优先基于当前上下文中的以下信息写 spec:
+
+- 用户已确认的需求描述
+- clarify 阶段产出的已锁定业务决策、已锁定技术方向、已排除方案和下游就绪判断
+- 已确认的业务目标、业务边界和非目标
+- 已确认的技术方案边界
+- 已确认的角色、权限、流程、状态、规则、异常和验收口径
+- 已有 PRD、接口说明、业务文档、代码上下文、数据口径或影响分析
+- 项目里已有的模块、页面、接口、模型、任务、队列、权限系统或外部系统约束
+
+如果当前上下文已经足够,直接写 spec。不要重新澄清已经确认过的内容。
+
+如果只有一句模糊想法,不要硬写完整 spec。先用 3-5 个问题补齐最影响规格正确性的内容。
+
+## 受众和边界
+
+面向研发、技术负责人、Code Agent、测试和后续 plan 编写者。文档应当清楚、可引用、可验证。
+
+可以写:
+
+- 需求目标和范围
+- 非目标
+- 术语和业务对象
+- 业务规则和状态流转
+- 功能行为规格
+- 输入输出和数据口径
+- 权限、安全、审计和可见性要求
+- 接口、页面、任务、队列、缓存、外部系统的影响边界
+- 同步/异步、幂等、重试、超时、一致性和兼容性要求
+- 数据迁移、回填、存量数据处理要求
+- 错误、异常和边界场景
+- 验收标准和测试关注点
+- 后续 plan 必须遵守的约束
+- 待确认项
+
+## 工作流程
+
+1. **检查上下文完整性**
+  - 确认当前上下文是否已有明确需求、业务边界和技术边界。
+  - 识别缺失的行为、规则、数据、接口、权限、异常、兼容性或验收信息。
+  - 只补问会影响规格正确性或后续 plan 正确性的问题。
+  - 如果 clarify/PRD 中存在需要领导或业务方拍板但未确认的规则,不得把它写成已确认规格。
+
+2. **确定 spec 粒度**
+  - 简单需求写轻量 spec。
+  - 跨模块、跨系统、涉及数据/权限/异步/兼容性的需求写完整 spec。
+  - 不为了显得完整而展开无关技术细节。
+
+3. **归档系统规格**
+  - 把业务描述转换成系统应满足的行为和约束。
+  - 明确输入、输出、状态、规则、数据、权限、异常和验收。
+  - 对后续 plan 必须遵守的内容使用明确措辞。
+  - 明确哪些契约不允许 implementation 阶段自行调整。
+
+4. **标记不确定项**
+  - 未确认但不阻塞成文的内容标记为【待确认】。
+  - 不把推测写成已确认规格。
+  - 如果待确认项会影响 plan 任务拆分、数据结构、接口契约、权限或验收,标明"不解决前不可写死 plan"。
+
+5. **自检**
+  - 检查 spec 是否足以指导后续 plan。
+  - 检查是否混入实现步骤或代码方案。
+  - 检查业务规则、数据影响、权限、异常、兼容性和验收是否清楚。
+
+## 结构选择
+
+不要把下面内容当成固定模板。Spec 的结构必须根据项目既有规范、需求复杂度、上下文信息和后续 plan 的需要动态组织。
+
+优先级:
+
+1. 如果项目已有 `docs/features/`、历史 spec、团队模板或命名习惯,优先沿用项目格式。
+2. 如果需求简单,使用轻量结构,只保留能指导 plan 的内容。
+3. 如果需求复杂,按业务流程、模块、接口、数据、权限、异步、迁移等实际风险组织章节。
+4. 如果某类内容与当前需求无关,不要为了模板完整而保留空章节。
+5. 如果某类内容对后续 plan 很关键,即使默认模板没有,也要新增项目特定章节。
+
+最小结构建议:
+
+```markdown
+# 规格说明: <需求名称>
+> feature-id: <feature-id>
+> 状态: 草稿
+> 日期: YYYY-MM-DD
+
+## 1. 目标与范围
+
+## 2. 已确认规格
+
+## 3. 关键约束
+
+## 4. 不可留到实现期的决策
+
+## 5. 验收与验证关注点
+
+## 6. 待确认项
+```
+
+复杂需求可按需扩展为:
+
+```markdown
+# 规格说明: <需求名称>
+> feature-id: <feature-id>
+> 状态: 草稿
+> 日期: YYYY-MM-DD
+
+## 1. 目标与范围
+## 2. 术语与业务对象
+## 3. 业务规则
+## 4. 系统行为
+## 5. 数据、状态与口径
+## 6. 权限、安全与审计
+## 7. 接口、页面与系统边界
+## 8. 异步、幂等、重试与一致性
+## 9. 兼容性、迁移与存量数据
+## 10. 异常与边界场景
+## 11. 验收标准与测试关注点
+## 12. 不可留到实现期的决策
+## 13. Plan 编写约束
+## 14. 待确认项
+```
+
+这些只是候选结构。最终输出应选择最能表达当前需求的章节名称、顺序和粒度。
+
+## 内容模块池
+
+按需取用以下内容模块。不要逐项填表,不要保留无内容的章节。
+
+### 目标与范围
+
+说明系统要满足的目标、包含范围和明确不包含范围。范围应能约束后续 plan,防止计划扩张。
+
+### 术语与业务对象
+
+当项目概念会影响理解或实现时,列出后续实现和测试必须理解的概念,例如角色、单据、状态、产品、订单、账户、套餐、任务等。
+
+### 业务规则
+
+归档经过确认的业务判断、限制、计算、状态变化、优先级、冲突处理和例外规则。每条规则应可验证。
+
+### 系统行为
+
+描述系统在不同触发条件下必须表现出的行为。可按业务场景、用户动作、系统事件、接口调用或状态流转组织。
+
+常用表达维度:
+
+- 前置条件
+- 触发动作
+- 系统行为
+- 输出结果
+- 失败或不满足条件时的行为
+
+### 数据、状态与口径
+
+说明需要读取、创建、更新、删除、导入、导出、迁移或回填的数据及其业务含义。可以描述模型/字段/状态的预期,但不要展开成完整数据库设计。
+
+### 权限、安全与审计
+
+当相关时,说明角色权限、数据可见性、租户/组织/区域隔离、安全约束、审计日志、敏感数据处理等要求。
+
+### 接口、页面与系统边界
+
+当相关时,说明受影响的页面、接口、外部系统、后台任务、队列、缓存或模块边界。可以写业务级输入输出和系统边界,不要写代码级实现步骤。
+
+### 异步、幂等、重试与一致性
+
+当相关时,说明同步/异步要求、幂等要求、失败重试、超时处理、最终一致性、进度查询、通知和可观测性要求。
+
+### 兼容性、迁移与存量数据
+
+当相关时,说明是否要兼容已有用户、旧接口、历史数据、旧流程;是否涉及迁移、回填、默认值或灰度。
+
+### 异常与边界场景
+
+说明无权限、数据不存在、重复请求、并发、部分成功、回滚、空数据、外部系统失败等场景的预期行为。
+
+### 验收标准与测试关注点
+
+写可验证的系统行为和业务结果。可以给测试关注点,但不要写详细测试用例脚本。
+
+### Plan 编写约束
+
+列出后续 plan 必须遵守的约束,例如不能改动的旧行为、必须复用的机制、不能引入的依赖、必须兼容的接口、必须覆盖的风险点。
+
+### 不可留到实现期的决策
+
+列出后续 implementation/subagent-implement 不得自行决定或重新设计的内容,例如:
+
+- 业务规则、统计口径、过滤维度、时间范围、去重规则
+- 状态含义、状态流转、异常处理
+- API 输入输出、错误语义、兼容性
+- 权限、安全、审计、数据可见性
+- 数据迁移、回填、默认值、灰度策略
+- 同步/异步、幂等、重试、一致性要求
+
+如果这些内容尚未确认,不要把它们藏在正文中;写入待确认项并说明不解决前不能进入严格 plan。
+
+### 待确认项
+
+列出仍需用户、业务方或技术负责人确认的内容。不要把待确认项藏在正文里。
+
+## 产物位置
+
+在可写项目上下文中,默认创建或更新:
+
+`docs/features/<feature-id>/spec.md`
+
+如果没有可写项目上下文,或用户明确只需要正文,则直接在回复中输出 spec 内容。
+
+## feature-id 规则
+
+格式:`YYYY-MM-DD-<short-slug>`。
+
+1. 日期使用当前日期。
+2. slug 从需求名称或业务目标中提炼,优先短、清晰、可识别。
+3. slug 可使用中文业务短语或英文短语,用连字符分隔,不强行翻译。
+4. 若当前上下文或用户已提供 feature-id,则复用。
+5. 如果同一目录下已有 PRD 或其他需求文档,优先复用同一个 feature-id。
+6. 写入前检查 `docs/features/` 下是否重名;重名时追加简短后缀。
+7. 默认创建 `docs/features/<feature-id>/spec.md`。
+
+## 写作原则
+
+- 面向研发和 Agent,不是面向客户展示。
+- 写系统必须满足的规格,不是写实施步骤。
+- 把业务要求转成可实现、可验证、可计划的约束。
+- 必要时保留项目术语、接口名、状态码、模块名或数据对象名。
+- 不确定就标【待确认】。
+- 已确认的非目标要明确写出。
+- 简单需求轻量写,复杂需求完整写。
+- 不要把未确认的方案选项写成正式规格。
+- 不要把需要业务拍板或技术确认的关键决策留给 plan/implementation 阶段临场决定。
+- 不要自动进入 plan 或 implementation。
+
+## 质量检查
+
+输出前确认:
+
+- 后续 plan 编写者能据此拆解实现工作。
+- 业务规则、系统行为和技术边界没有混在一起变得含糊。
+- 数据、状态、权限、异常、兼容性和验收口径足够明确。
+- 文档没有滑向客户 PRD、任务计划或代码方案。
+- 所有未确认内容都标为【待确认】。
+- 不可留到实现期的决策已经列出。
+- Plan 编写约束足以防止后续实现跑偏。
+
+## 收尾方式
+
+输出 spec 后,只提示用户可以审阅规格并指出需要调整的地方。不要主动继续写 plan 或代码。

package/dist/bin/codegraph.d.ts

@@ -0,0 +1,26 @@
+#!/usr/bin/env node
+/**
+ * cgraphx CLI
+ *
+ * Command-line interface for cgraphx code intelligence.
+ *
+ * Usage:
+ *   cgraphx                      Run interactive installer (when no args)
+ *   cgraphx install              Run interactive installer
+ *   cgraphx uninstall            Remove cgraphx from your agents
+ *   cgraphx init [path]          Initialize cgraphx in a project
+ *   cgraphx uninit [path]        Remove cgraphx from a project
+ *   cgraphx index [path]         Index all files in the project
+ *   cgraphx sync [path]          Sync changes since last index
+ *   cgraphx status [path]        Show index status
+ *   cgraphx query <search>       Search for symbols
+ *   cgraphx files [options]      Show project file structure
+ *   cgraphx context <task>       Build context for a task
+ *   cgraphx callers <symbol>     Find what calls a function/method
+ *   cgraphx callees <symbol>     Find what a function/method calls
+ *   cgraphx impact <symbol>      Analyze what code is affected by changing a symbol
+ *   cgraphx affected [files]     Find test files affected by changes
+ *   cgraphx upgrade [version]    Update cgraphx to the latest release
+ */
+export {};
+//# sourceMappingURL=codegraph.d.ts.map

package/dist/bin/codegraph.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"codegraph.d.ts","sourceRoot":"","sources":["../../src/bin/codegraph.ts"],"names":[],"mappings":";AACA;;;;;;;;;;;;;;;;;;;;;;GAsBG"}