OGT 文档 - 定义

用于创建定义文档的指南，确立系统中事物的本质。

核心理念

定义是共识的基础。

在任何人能够实施、推广或讨论某事物之前，必须对其本质有清晰且达成共识的定义。

┌─────────────────────────────────────────────────────────────────┐
│ 定义原则 │
├─────────────────────────────────────────────────────────────────┤
│ 定义回答： │
│ • 这是什么事物？ │
│ • 它为什么存在？ │
│ • 它的边界是什么？（它不是什么） │
│ • 它与其他事物如何关联？ │
│ │
│ 定义不指定： │
│ • 如何实施（那是 rules/ 的职责） │
│ • 如何处理它（那是 todo/ 的职责） │
└─────────────────────────────────────────────────────────────────┘

何时使用此技能

当您需要以下内容时，请使用 ogt-docs-define：

• - 了解定义文件夹结构
• 选择合适的定义子技能
• 创建不适合专门分类的定义

对于特定定义类型，请使用：

文件夹结构

docs/definitions/
├── business/ # 业务模型与运营
│ ├── pricing_model/
│ │ ├── definition.md
│ │ ├── tiers.md
│ │ ├── limits.md
│ │ └── .approvedbyfounder
│ ├── user_types/
│ ├── revenue_model/
│ └── market_position/
│
├── features/ # 产品功能
│ ├── global_search/
│ │ ├── feature.md
│ │ ├── mvp.md
│ │ ├── phase_0.md
│ │ ├── phase_1.md
│ │ ├── nicetohave.md
│ │ └── .version
│ ├── user_auth/
│ └── campaign_manager/
│
├── technical/ # 架构与系统
│ ├── service_layer/
│ │ ├── definition.md
│ │ ├── contracts.md
│ │ ├── patterns.md
│ │ └── .version
│ ├── data_model/
│ └── api_design/
│
├── domain/ # 领域特定概念
│ ├── creatures/
│ ├── abilities/
│ └── campaigns/
│
├── marketing/ # 营销与传播
│ ├── value_proposition/
│ ├── target_audience/
│ └── messaging/
│
├── branding/ # 品牌标识
│ ├── visual_identity/
│ ├── toneofvoice/
│ └── brand_guidelines/
│
└── tools/ # 开发者工具
├── cli/
├── scripts/
└── workflows/

文件夹即实体模式

每个定义都是一个文件夹，包含：

{definition_slug}/
├── {type}.md # 主要定义文件
├── {aspect}.md # 附加方面/细节
├── {related}.md # 相关概念
└── .{signals} # 状态与元数据

主要文件命名

定义生命周期

mermaid
flowchart LR
subgraph lifecycle [定义生命周期]
D[草稿] --> R[审核]
R --> A[已批准]
R --> REJ[已拒绝]
REJ --> D
A --> DEP[已弃用]
end

style D fill:#fef3c7
style R fill:#e0e7ff
style A fill:#d1fae5
style REJ fill:#fecaca
style DEP fill:#e5e7eb

草稿状态

定义正在编写中，尚未准备好审核。

{definition_slug}/
├── definition.md
├── .version
└── .draft # 空信号：仍在草稿阶段

审核状态

定义已完成，等待批准。

{definition_slug}/
├── definition.md
├── .version
├── .readyforreview # 空信号
└── .reviewrequestedat # 时间戳

已批准状态

定义已批准，可被引用/实施。

{definition_slug}/
├── definition.md
├── .version
├── .approved # 空信号
├── .approvedby{name} # 批准人
└── .approved_at # 批准时间

已拒绝状态

定义被拒绝，需要返工。

{definition_slug}/
├── definition.md
├── .version
├── .rejected # 空信号
├── .rejected_reason # 拒绝原因
└── .rejected_at # 拒绝时间

已弃用状态

定义已过时，被其他内容取代。

{definition_slug}/
├── definition.md
├── .version
├── .deprecated # 空信号
├── .deprecated_reason # 弃用原因
├── .deprecated_at # 弃用时间
└── .superseded_by # 替代内容

创建定义：流程

mermaid
flowchart TD
A[需要定义某事物] --> B{什么类型？}
B -->|业务| C[ogt-docs-define-business]
B -->|功能| D[ogt-docs-define-feature]
B -->|技术| E[ogt-docs-define-code]
B -->|营销| F[ogt-docs-define-marketing]
B -->|品牌| G[ogt-docs-define-branding]
B -->|工具| H[ogt-docs-define-tools]
B -->|其他| I[使用此技能]

I --> J[提出澄清性问题]
J --> K[起草定义]
K --> L[请求审核]
L --> M{已批准？}
M -->|是| N[标记为已批准]
M -->|否| O[处理反馈]
O --> K

步骤 1：提出澄清性问题

在编写任何定义之前，收集信息：

核心问题（始终询问）：

1. 1. 此概念的名称/标识符是什么？
2. 用一句话说，它是什么？
3. 它为什么需要存在？它解决了什么问题？
4. 它不是什么？（边界）
5. 它与其他哪些概念相关？

上下文问题（按需询问）： 6. 利益相关者是谁？ 7. 是否存在类似的现有概念？ 8. 哪些决策导致了此概念？ 9. 成功标准是什么？

步骤 2：起草定义

根据类型使用适当的模板（参见子技能）。

通用定义模板：

markdown

定义：{名称}

概述

一段解释这是什么以及它为什么存在的文字。

核心概念

对概念的详细解释。

关键特征

• - 特征 1
• 特征 2
• 特征 3

边界

这不是什么：

• - 不是 X
• 不是 Y
• 不是 Z

关系

这与其他概念如何关联。

示例

说明该概念的具体示例。

示例 1：{名称}

示例描述。

示例 2：{名称}

示例描述。

未解决问题

需要未来讨论的未解决问题。

• - 问题 1？