关于 contextualizar-negocio
用于梳理棕地系统现有业务行为的 Skill,面向缺少 PRD、需要从代码还原业务规则的产品负责人和团队。它以证据记录能力与规则,整理术语,并将歧义留给业务确认,不修改代码。
主要功能
- 01基于证据绘制能力地图
- 02发现隐藏业务规则
- 03整理业务与代码术语
- 04设置人工审批关卡
- 05不改代码或提议新功能
适用场景
- 01为缺少 PRD 的旧系统编写文档
- 02查找未记录的校验与限制
- 03整理有歧义行为的业务问题
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ adminoryslabs/ armory --skill contextualizar-negocio安装后在 Claude Code 中输入/contextualizar-negocio确认已加载。
附带文件assets/capacidades-template.mdassets/glosario-template.md
详细介绍
梳理业务背景(brownfield)
目标
用业务语言并提供证据,回答系统目前做什么、遵循哪些规则,以及各项内容的名称是什么。在 brownfield 项目中,没有 PRD 或 backlog:系统的行为写在代码里,而许多规则在其他地方都没有记录。
此 skill 涵盖功能背景(第 3、4 层)。技术背景由 ARCH 使用 contextualizar-repo 生成。
**此 skill 不修改代码,也不提出新功能。**它负责收集信息、记录文档、提出问题,然后停止。
原则
- **使用业务语言。**每项能力和规则都要以 PO 能理解的方式描述;技术证据要附在旁边,而不是代替说明。
- **凡事都要有证据。**每项能力和规则都要注明来源(endpoint、屏幕、测试或
archivo:línea),否则标记为NO VERIFICADO。 - **代码的实际行为不一定符合业务期望。**如果某项规则看起来像错误或含义模糊,不要修正或自行解读;将其转化为业务问题。
输入
- ARCH 提供的
docs/contexto/ARQUITECTURA.md(或通知CONTEXTO TÉCNICO LISTO):指出应查看的位置。如果不存在,询问 ARCH 是否会先运行;只有在人类确认后才能在没有它的情况下继续,并告知收集过程会更慢、准确度也会更低。 - 如有现成的用户文档。
- 可选:正在运行的应用,以便浏览各个屏幕。
工作流
1. 来源
按以下顺序查看描述系统行为的内容:
- **公共接口:**API endpoints、屏幕、命令。
- **现有测试:**通过具体示例描述预期行为。
- **配置:**会改变用户所见行为的选项和 flags。
- 用户文档。
- 代码,用于确认,并查找以上来源中没有体现的内容。
2. 能力地图(第 3 层)
按业务能力分组,而不是按文件或 endpoint 分组。每项能力记录:
- 允许用户执行什么操作,用一句业务语言描述;
- 使用者(角色);
- 证据(endpoint、屏幕、测试或
archivo:línea); - 状态:启用 · 受配置选项控制 · 已弃用。
使用 assets/capacidades-template.md。
3. 隐藏的业务规则(第 3 层)
在代码中查找影响用户操作的校验、限制、转换、权限和默认值。每项规则记录:
- 用业务语言描述(“文档创建时不能超过 100,000 个字符”);
- 证据
archivo:línea; - 是否在其他地方有文档记录(是 / 否);
- 如果含义模糊或看起来像错误:作为业务问题提出,不要自行解决。
4. 术语表(第 4 层)
使用 assets/glosario-template.md 创建 docs/contexto/GLOSARIO.md:
- 汇总界面、API 和代码中出现的领域术语。
- 每个术语都要记录:业务定义、同义词,以及不同情况下代码使用的名称;如果有标识符格式,也要一并记录。
- **“Dónde vive”**列由 ARCH 填写:向其发送
GLOSARIO: TÉRMINOS NUEVOS: <ruta> — <cantidad de términos>。 如果本次会话中没有 ARCH,则根据证据填写,并标记为pendiente de revisión técnica。 - 如果同一个术语在不同地方含义不同,应记录为冲突,而不是选定一个定义。
5. 编写文档
| 文件 | 内容 |
|---|---|
docs/contexto/CAPACIDADES.md | 能力地图 + 业务规则 + 业务问题 |
docs/contexto/GLOSARIO.md | 业务 ↔ 代码术语表 |
如果 AGENTS.md 已指向这些文件(由 ARCH 留下),则不要修改。如果没有,则建议添加链接。
6. 自我验证
- 重新打开每份引用的证据,并确认其支持所述内容。
- 确认没有任何能力或规则被写成全新内容或提案。
- 确认词汇表中的每个术语都有业务定义。
7. 人工关卡
提交摘要和业务问题,最好交给 PO。等待明确批准后,才能将功能上下文标记为完成。
与 ARCH 协调
- 等待
CONTEXTO TÉCNICO LISTO后再开始(除非人工另有指示)。 - 出现代码中没有对应位置的术语时,发送
GLOSARIO: TÉRMINOS NUEVOS。 - 收到
GLOSARIO COMPLETO后,检查每个位置是否与业务定义相符;如不符,指出具体差异。 - 同一分歧最多沟通两轮;之后由人工决定。
约束
- 不修改 ARCH 的代码或技术文档。
- 不提出新功能:只记录现有功能。
- 不解决含糊的规则:只提出问题。
- 未经人工批准,不将功能上下文标记为完成。
评论
支持 Markdown