什么是 OGT Docs？

OGT Docs 是专为 Openclaw Skills 生态系统设计的专业技能，它实现了“文档即单一事实来源”（Doc-SoT）的理念。其运作原则是：文档定义系统的本质，而代码仅仅是这些定义的实现。如果两者发生冲突，文档始终被视为准则。

该技能通过将请求路由到特定的子技能（如业务定义、编码规则和任务管理）来提供管理技术项目的结构化框架。它确保在开始实现之前，每项决策都已记录在文档中，从而创建一个稳健、可验证的开发生命周期。

下载入口:https://github.com/openclaw/skills/tree/main/skills/eduardou24/ogt-docs

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

OGT Docs 应用场景

• 使用结构化的文档优先架构初始化新项目。
• 将业务模型、产品功能和技术规范定义为主要事实来源。
• 在前端、后端和基础设施中建立并执行编码标准。
• 使用“文件夹即实体”模式管理复杂的任务生命周期。
• 审计任务完成情况，确保代码准确反映文档要求。

1. 使用 Openclaw Skills 初始化文档结构，创建基础目录层级。
2. 通过在 definitions 目录中创建文件夹来定义项目实体，包括业务和技术规范。
3. 通过创建编码标准和版本控制规则来建立规范。
4. 通过创建基于文件夹的待办事项来执行具体任务，跟踪从待处理到完成的进度。
5. 通过运行审计检查来验证实现情况，将生成的代码与源文档进行对比。

OGT Docs 配置指南

要在您的环境中使用此工作流，请使用初始化子技能生成所需的目录结构：

# 初始化文档即单一事实来源结构
ogt-docs-init

# 配置您的文档工作流设置
ogt-docs-config

OGT Docs 数据架构与分类体系

该技能使用“文件夹即实体”模式组织数据，其中每个项目都是包含特定文件的目录：

name: ogt-docs
description: Documentation-as-Source-of-Truth workflow. Use when working with projects that use docs/ as the canonical source for definitions, rules, and tasks. Routes to specialized sub-skills for specific documentation types.

OGT Docs - Documentation as Source of Truth

Philosophy

Documentation is the database of decisions. Code is merely its implementation.

┌─────────────────────────────────────────────────────────────────┐
│                    THE DOC-FIRST PRINCIPLE                      │
├─────────────────────────────────────────────────────────────────┤
│  1. Documentation DEFINES what something IS                     │
│  2. Code IMPLEMENTS what documentation specifies                │
│  3. Conflicts RESOLVE in favor of documentation                 │
│                                                                 │
│  If docs say X and code does Y → CODE IS WRONG                  │
└─────────────────────────────────────────────────────────────────┘

When to Use This Skill

Use ogt-docs when you need to:

• Understand the docs/ folder structure
• Find the right sub-skill for a specific task
• Initialize a new docs-first project
• Navigate between definition types

For specific tasks, use the specialized sub-skills listed below.

Documentation Structure Overview

docs/
├── definitions/              # WHAT things ARE
│   ├── business/             # Business model, pricing, users
│   ├── features/             # Product features and specs
│   ├── technical/            # Architecture, services, data
│   └── domain/               # Domain-specific concepts
│
├── rules/                    # HOW to IMPLEMENT
│   ├── code/                 # Coding standards
│   │   ├── frontend/
│   │   ├── backend/
│   │   └── infra/
│   ├── git/                  # Version control rules
│   └── domain/               # Domain-specific rules
│
├── todo/                     # TASK management
│   ├── pending/              # Not started
│   ├── in_progress/          # Being worked on
│   ├── review/               # Awaiting review
│   ├── blocked/              # Cannot proceed
│   ├── done/                 # Completed & verified
│   └── rejected/             # Declined tasks
│
├── guides/                   # HOW-TO documents
│   └── {topic}/
│
└── social/                   # Marketing & communications
    ├── campaigns/
    ├── content/
    └── branding/

The Folder-as-Entity Pattern

Every documentable item is a folder containing:

{item_slug}/
├── {type}.md                 # Primary document (task.md, feature.md, etc.)
├── {supporting_files}.md     # Additional documentation
└── .{signal_files}           # Status markers and metadata

Benefits:

• Move entire folder between workflow stages
• Attach unlimited supporting files
• Signal status via dot-files
• Version and track changes atomically

Sub-Skills Reference

Definitions (WHAT things ARE)

Rules (HOW to IMPLEMENT)

Tasks (WHAT to DO)

Other

Workflow Overview

flowchart TB
    subgraph define ["1. DEFINE"]
        D1[Create Definition]
        D2[Get Approval]
    end

    subgraph regulate ["2. REGULATE"]
        R1[Create Rules]
        R2[Add Examples]
    end

    subgraph implement ["3. IMPLEMENT"]
        I1[Create Task]
        I2[Write Code]
        I3[Review]
    end

    subgraph verify ["4. VERIFY"]
        V1[Run Checks]
        V2[Confirm Match]
    end

    define --> regulate --> implement --> verify
    verify -->|Mismatch| implement
    verify -->|Docs Wrong| define

Quick Start

"I need to define something new"

→ Use ogt-docs-define to understand types, then the specific sub-skill

"I need to create a task"

→ Use ogt-docs-create-task

"I need to check if a task is really done"

→ Use ogt-docs-audit-task

"I need to add coding rules"

→ Use ogt-docs-rules-code or the specific frontend/backend/infra variant

"I need to set up docs for a new project"

→ Use ogt-docs-init

Naming Conventions

Signal Files Reference

Signal files are dot-files that indicate status or metadata.

The Golden Rules

1. If it's not documented, it doesn't exist
2. If code contradicts docs, code is wrong
3. Never trust "done" status without verification
4. Move folders, don't copy files
5. Signal with dot-files, don't edit status fields