ogt-docs-define

核心用法

ogt-docs-define 是一个系统化的文档定义指南，旨在帮助团队建立"事物本质"的共享理解。它通过规范化的方法论指导用户创建定义文档（Definition Documents），回答"这是什么、为什么存在、边界在哪里、与其他事物的关系"等核心问题。该 Skill 采用"文件夹即实体"（Folder-as-Entity）模式，将每个概念、实体或系统组织为独立文件夹，内部包含主定义文件、补充说明及信号文件（Signal Files），并通过草稿、审核、批准、弃用等生命周期状态管理文档演进。

显著优点

首先，该 Skill 提供了完整的分类体系，涵盖商业概念、产品功能、技术架构、营销定位、品牌标识及开发工具六大领域，确保不同类型的定义都有据可依。其次，其生命周期管理机制通过 .draft、.ready_for_review、.approved 等信号文件实现状态流转，强制引入审核流程，有效防止未经充分讨论的定义进入生产环境。第三，强调"边界定义"（What it is NOT），通过明确排除范围来预防概念蔓延。第四，内置关系映射表格，强制要求定义间关联，避免知识孤岛。最后，提供的模板与检查清单（Quality Checklist）大幅降低了文档编写的认知负担。

潜在缺点与局限性

该 Skill 的主要局限在于其较重的流程负担。信号文件系统虽然严谨，但增加了文件系统操作的复杂性，对于习惯简单 Markdown 文档的团队可能显得过度工程化。其次，严格的分类体系（business/features/technical 等）可能无法适配所有组织的独特知识结构，灵活性不足。此外，维护定义文档本身需要持续投入，在快速迭代的初创环境中，文档过时风险较高。最后，纯文本的定义方式缺乏交互性，对于复杂系统的可视化表达能力有限。

适合的目标群体

此 Skill 最适合中大型技术团队、采用文档优先（Docs-as-Code）文化的组织、以及需要维护复杂领域知识库（Domain Knowledge Base）的项目。特别适合那些面临"概念混淆、术语不统一、知识传承困难"问题的团队，或需要建立企业架构标准（Enterprise Architecture）的场景。对于个人开发者或小型短期项目，该规范可能过于繁重。

使用风险

作为纯文档型 Skill，其技术安全风险极低，无代码执行、网络通信或数据收集行为。主要风险集中在组织层面：流程采纳阻力（团队可能抵触严格的审核流程）、模板僵化风险（过度依赖模板可能抑制创新）、以及与现有 Wiki 或文档系统的整合成本。建议渐进式采用，先从关键核心概念开始试点。