doc-ctr

Name: doc-ctr
Author: vladm3105

github.com/vladm3105开发1748 次安装1 天前更新

代码仓库

关于 doc-ctr

用于在 SDD 工作流中编写数据契约的技能，以 Markdown 和 YAML 配对文件定义 API 接口与数据架构。它提供模板、追溯规则和质量门禁，支持从需求推进到技术规格。

主要功能

01创建 Markdown 与 YAML 配对契约
02定义 API 与数据架构
03支持 OpenAPI 3.0 和 JSON Schema
04应用追溯与 ID 规则
05检查文档质量门禁

适用场景

01根据上游需求编写 API 契约
02在团队或服务间共享接口定义
03为技术规格准备契约文档

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/vladm3105/aidoc-flow-framework --skill doc-ctr

安装后在 Claude Code 中输入/doc-ctr确认已加载。

详细介绍

doc-ctr

目的

创建 数据契约（CTR）——SDD 工作流中的可选第 8 层产物，采用双文件格式（Markdown + YAML）定义 API 契约、数据模式和接口规范。

层级：8（可选）

上游：BRD（第 1 层）、PRD（第 2 层）、EARS（第 3 层）、BDD（第 4 层）、ADR（第 5 层）、SYS（第 6 层）、REQ（第 7 层）

下游产物：SPEC（第 9 层）、TSPEC（第 10 层）、TASKS（第 11 层）、代码（第 12 层）

前置条件

上游产物验证（重要）

创建本文档之前，必须：

列出已有的上游产物：

ls docs/01_BRD/ docs/02_PRD/ docs/03_EARS/ docs/04_BDD/ docs/05_ADR/ docs/06_SYS/ docs/07_REQ/ 2>/dev/null

在可追溯性标签中仅引用已有文档
仅当某类上游产物确实不存在时，才使用 null
绝不要使用 BRD-XXX 或 TBD 之类的占位符
不要创建缺失的上游产物——改为跳过相关功能

创建 CTR 之前，请阅读：

共享标准：.claude/skills/doc-flow/SHARED_CONTENT.md
上游 REQ：阅读原子需求（尤其是第 3 节：接口规范、第 4 节：数据模式）
模板：ai_dev_ssd_flow/08_CTR/CTR-MVP-TEMPLATE.md 和 CTR-MVP-TEMPLATE.yaml
创建规则：ai_dev_ssd_flow/08_CTR/CTR-MVP-TEMPLATE.md
验证规则：ai_dev_ssd_flow/08_CTR/CTR_MVP_SCHEMA.yaml
验证脚本：./ai_dev_flow/scripts/validate_ctr.sh

保留 ID 豁免（CTR-00_*）

范围：ID 为 000 的文档完全免于验证。

模式：CTR-00_*.md、CTR-00_*.yaml

文档类型：

索引文档（CTR-00_index.md）
可追溯性矩阵模板（CTR-00_TRACEABILITY_MATRIX-TEMPLATE.md）
术语表、注册表、检查清单

原因：保留 ID 为 000 的文档属于框架基础设施（索引、模板、参考资料），并非需要可追溯性或质量门禁的项目产物。

验证行为：文件名匹配 CTR-00_* 模式时，跳过所有检查。

何时使用此技能

以下情况使用 doc-ctr：

已完成 BRD 至 REQ（第 1～7 层）
需要定义 API 契约或数据模式
多个团队或服务需要共享契约
正在构建微服务或分布式系统
REQ 第 3 节（接口规范）需要正式契约
此层为可选（第 8 层）——如果契约简单，可跳过

CTR 专属指南

1. 强制采用双文件格式

每个契约都必须包含两个文件（强制采用双文件格式：.md 文件 + 配套的 .yaml 文件）：

Markdown 文件（.md）：

文档控制部分
契约概述
业务背景
使用示例
可追溯性

YAML 文件（.yaml）：

OpenAPI 3.0 或 JSON Schema
正式的契约定义
验证规则
示例载荷

示例：

ai_dev_ssd_flow/08_CTR/CTR-01_data_validation.md
ai_dev_ssd_flow/08_CTR/CTR-01_data_validation.yaml

2. 文档控制字段（必填 9 项）

字段	必填	说明
CTR ID	是	CTR-NN 格式
标题	是	契约名称
状态	是	草稿/审核中/生效/已弃用
版本	是	语义化版本（Major.Minor.Patch）
创建日期	是	YYYY-MM-DD
作者	是	文档作者
所有者	是	契约所有者
最后更新日期	是	YYYY-MM-DD
SPEC-Ready 分数	是	✅ NN%（目标：≥90%）

3. 必需章节（Markdown 文件）

文档控制（强制要求——必须是所有编号章节之前的首个章节）

必需章节（12 章节 MVP 结构）：

#	章节	目的
1	文档控制	元数据、SPEC 就绪度评分
2	背景	问题陈述、约束、权衡
3	合约定义	接口概览、参与方、模式
4	已满足的需求	链接上游需求
5	接口定义	架构引用、端点
6	错误处理	错误代码、故障模式
7	质量属性	性能、安全性、可靠性
8	版本策略	版本政策、兼容性
9	示例	请求/响应对
10	验证	合约测试、BDD 引用
11	可追溯性	上游/下游、标签
12	参考资料	内部/外部链接

可选附录：

附录 A：已考虑的替代方案
附录 B：实现说明

4. 元素 ID 格式（强制要求）

模式：CTR.{DOC_NUM}.{HASH}（3 个段，以点分隔）

元素类型	代码	示例
接口	16	CTR.02.1601
数据模型	17	CTR.02.1701
合约条款	20	CTR.02.2001

已移除的模式 - 请勿使用旧格式：

INT-XXX - 改用 CTR.NN.16.SS

MODEL-XXX - 改用 CTR.NN.17.SS

CLAUSE-XXX - 改用 CTR.NN.20.SS

IF-XXX - 改用 CTR.NN.16.SS

DM-XXX - 改用 CTR.NN.17.SS

CC-XXX - 改用 CTR.NN.20.SS

参考：ID_NAMING_STANDARDS.md - 交叉引用链接格式

5. YAML 合约格式

OpenAPI 3.0 格式（用于 API）：

openapi: 3.0.3
info:
  title: Data Validation API
  version: 1.0.0
  description: Contract for data validation

paths:
  /api/v1/data/validate:
    post:
      summary: Validate data record
      operationId: validateDataRecord
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/DataRequest'
      responses:
        '200':
          description: Validation successful
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ValidationResponse'
        '400':
          description: Invalid request
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'

components:
  schemas:
    DataRequest:
      type: object
      required:
        - record_type
        - record_id
        - data
        - account_id
      properties:
        record_type:
          type: string
          pattern: ^[A-Z]{1,10}$
          example: "METRIC"
        record_id:
          type: string
          format: uuid
          example: "abc123"
        data:
          type: object
          example: {}
        account_id:
          type: string
          format: uuid
          example: "123e4567-e89b-12d3-a456-426614174000"

    ValidationResponse:
      type: object
      required:
        - valid
        - order_id
      properties:
        valid:
          type: boolean
          example: true
        order_id:
          type: string
          format: uuid
          example: "987f6543-e21c-43d2-b654-426614174111"
        warnings:
          type: array
          items:
            type: string
          example: ["Price near market close"]

    ErrorResponse:
      type: object
      required:
        - error_code
        - message
      properties:
        error_code:
          type: string
          example: "INVALID_SYMBOL"
        message:
          type: string
          example: "Symbol 'XYZ' not found in approved list"
        details:
          type: object
          additionalProperties: true

JSON Schema 格式（用于数据模型）：

$schema: "http://json-schema.org/draft-07/schema#"
name: DataProcessingConfig
description: Configuration schema for data processing

type: object
required:
  - max_batch_size
  - timeout_seconds
  - check_frequency

properties:
  max_batch_size:
    type: integer
    minimum: 1
    maximum: 10000
    description: Maximum records per batch
    example: 1000

  timeout_seconds:
    type: integer
    minimum: 1
    maximum: 300
    description: Processing timeout in seconds
    example: 60

  check_frequency:
    type: string
    enum: ["realtime", "1min", "5min", "15min"]
    description: How often to check processing status
    example: "1min"

  alert_threshold:
    type: number
    minimum: 0
    maximum: 1.0
    description: Alert when queue depth exceeds this fraction
    default: 0.80
    example: 0.80

6. 使用示例章节

格式：

## Usage Examples

### Example 1: Successful Validation

**Request**:
```json
{
  "record_type": "METRIC",
  "record_id": "abc123",
  "data": {"value": 100},
  "account_id": "123e4567-e89b-12d3-a456-426614174000"
}

响应：

{
  "valid": true,
  "order_id": "987f6543-e21c-43d2-b654-426614174111",
  "warnings": []
}

示例 2：无效记录类型

请求：

{
  "record_type": "invalid",
  "record_id": "abc123",
  "data": {"value": 100},
  "account_id": "123e4567-e89b-12d3-a456-426614174000"
}

响应（400 Bad Request）：

{
  "error_code": "INVALID_RECORD_TYPE",
  "message": "Record type 'invalid' not found in approved list",
  "details": {
    "record_type": "invalid",
    "approved_types": ["METRIC", "EVENT", "LOG"]
  }
}


### 7. Contract Versioning

**Semantic Versioning**: Major.Minor.Patch

**Version Policy**:
- **Major**: Breaking changes (incompatible)
- **Minor**: New features (backward compatible)
- **Patch**: Bug fixes (backward compatible)

**Example**:
```yaml
openapi: 3.0.3
info:
  title: Data Validation API
  version: 2.1.0  # Major.Minor.Patch
  description: |
    Version 2.1.0 (2025-01-15)
    - Added: optional 'warnings' field in response (minor)
    - Fixed: validation error for edge case data (patch)

    Breaking changes from v1.x:
    - Changed: account_id now requires UUID format (was string)

8. SPEC 就绪度评分系统

目的：衡量 CTR 的成熟度，以及进入技术规格说明（SPEC）阶段的就绪程度。

文档控制中的格式：

| **SPEC-Ready Score** | ✅ 95% (Target: ≥90%) |

状态与 SPEC 就绪度评分对应关系：

SPEC 就绪度评分	必需状态
≥90%	Active
70-89%	In Review
<70%	Draft

评分标准：

架构完整性（35%）：定义所有端点/模型，通过 JSON Schema/OpenAPI 验证，并提供示例
错误处理（25%）：记录所有错误代码，指定重试策略，涵盖故障模式
质量属性（20%）：指定性能目标、SLA 要求和幂等性
可追溯性（10%）：链接上游 REQ/ADR，识别消费者/提供方
文档（10%）：使用示例、版本政策、弃用策略

质量门禁：评分 <90% 时，将阻止创建 SPEC 产物。

9. 按服务类型组织目录

目的：对于大型项目（30+ 个合约），按服务类型组织合约。

结构：

CTR/
├── agents/              # Agent-to-agent communication
├── mcp/                 # MCP server contracts
├── infra/               # Infrastructure services
└── shared/              # Cross-cutting contracts

适用场景：

建议：从平铺目录开始；当每种服务类型有 3+ 个合约时，再迁移到子目录。

标签格式约定（设计如此）

SDD 框架使用两种不同的交叉引用标记系统：

标记	格式	工件	用途
连字符	TYPE-NN	ADR、SPEC、CTR	技术工件——引用文件/文档
点号	TYPE.NN.xxxx	BRD、PRD、EARS、BDD、SYS、REQ、IMPL、TASKS	层级工件——引用文档内的元素

关键区别：

@adr: ADR-033 → 指向文档 ADR-033_risk_limit_enforcement.md
@brd: BRD.17.0101 → 指向文档 BRD-017.md 中的元素 01.01

统一元素 ID 格式（强制）

对于层级需求（BRD、PRD、EARS、BDD、SYS、REQ、IMPL）：

始终使用：TYPE.NN.xxxx（点号分隔符，3 段统一格式）
切勿使用：TYPE-NN:NNN（冒号分隔符——已弃用）
切勿使用：TYPE.NN.TT.SS（旧的 4 段格式——已弃用）

示例：

@brd: BRD.17.0101 ✅
@brd: BRD.017.001 ❌（旧的 3 段格式）

累积标签要求

第 8 层（CTR）：必须包含第 1–7 层（BRD 至 REQ）的标签

标签数量：7 个标签

累积标签的元素类型代码：

标签	工件	元素类型	代码
@brd	BRD	业务需求	01
@prd	PRD	产品功能	07
@ears	EARS	EARS 声明	25
@bdd	BDD	场景	14
@adr	ADR	文档引用	（连字符标记）
@sys	SYS	系统需求	26
@req	REQ	原子需求	27

格式：

## Traceability

**Required Tags** (Cumulative Tagging Hierarchy - Layer 8):
```markdown
@brd: BRD.01.0103
@prd: PRD.01.0702
@ears: EARS.01.2501
@bdd: BDD.01.1401
@adr: ADR-033, ADR-045
@sys: SYS.01.2601
@req: REQ.01.2703

上游/下游工件

上游来源：

BRD（第 1 层）- 业务需求
PRD（第 2 层）- 产品功能
EARS（第 3 层）- 形式化需求
BDD（第 4 层）- 测试场景
ADR（第 5 层）- 架构决策
SYS（第 6 层）- 系统需求
REQ（第 7 层）- 原子需求（主要来源——尤其是第 3 节）

下游工件：

SPEC（第 9 层）- 技术规范
TSPEC（第 10 层）- 测试规范
TASKS（第 11 层）- 任务拆分
Code（第 12 层）- 实现代码

同类型文档关系（有条件）：

@related-ctr: CTR-NN - 共享 API 上下文的 CTR
@depends-ctr: CTR-NN - 必须先完成的 CTR

验证检查

第 1 级：错误（阻断）

检查项	描述
CHECK 1	必填文档控制字段（9 个字段）
CHECK 2	双文件格式（.md 和 .yaml 均存在）
CHECK 3	SPEC 就绪度评分格式（✅ 表情符号 + 百分比 + 目标）
CHECK 4	YAML 架构验证（OpenAPI/JSON Schema 有效）
CHECK 5	累积标签（7–8 个上游标签）
CHECK 6	元素 ID 格式（`CTR.NN.xxxx`）

第 2 级：警告（建议）

检查项	描述
CHECK 7	使用示例（请求/响应对）
CHECK 8	错误处理（已记录错误代码）
CHECK 9	版本策略（语义化版本控制）
CHECK 10	验证规则（已指定架构验证）

第 3 级：信息

检查项	描述
CHECK 11	目录组织（为 30 个以上的契约设置子目录）
CHECK 12	已识别使用方/提供方

提交前钩子

CTR 验证通过提交前钩子自动执行：

# .pre-commit-config.yaml
- id: ctr-core-validator
  name: Validate CTR core checks (validator, framework library)
  entry: bash ai_dev_ssd_flow/08_CTR/scripts/ctr_core_validator_hook.sh ai_dev_ssd_flow/08_CTR
  language: system
  pass_filenames: false
  stages: [pre-commit]

- id: ctr-quality-gate
  name: Validate CTR quality gates
  entry: bash ai_dev_ssd_flow/08_CTR/scripts/ctr_quality_gate_hook.sh ai_dev_ssd_flow/08_CTR
  language: system
  pass_filenames: false
  stages: [pre-commit]

- id: ctr-spec-ready-score
  name: Validate CTR SPEC-Ready score (≥90%)
  entry: bash ai_dev_ssd_flow/08_CTR/scripts/ctr_spec_ready_score_hook.sh ai_dev_ssd_flow/08_CTR
  language: system
  pass_filenames: false
  stages: [pre-commit]

强制质量门禁：

✅ 双文件格式（成对的 .md + .yaml 文件）
✅ 活跃状态的 SPEC-Ready 评分 ≥90%
✅ OpenAPI 3.0 或 JSON Schema 验证
✅ 文档控制字段（9 个必填字段）
✅ 累积标签（@brd 至 @req，共 7 个标签）
✅ 元素 ID 格式（接口／模型／条款使用 CTR.NN.xxxx）
✅ 使用示例（请求／响应对）
✅ 错误处理规范
✅ 版本策略（语义化版本）
✅ 已记录验证规则
✅ 消费者／提供者标识
✅ 质量属性（性能、安全性、可靠性）

钩子脚本：

ctr_core_validator_hook.sh - CTR 核心结构和双文件验证
ctr_quality_gate_hook.sh - 完整性质量门禁检查
ctr_spec_ready_score_hook.sh - SPEC-Ready 评分计算（要求 ≥90%）

创建流程

步骤 1：阅读上游制品

重点查看 REQ 第 3 节（接口规范）和第 4 节（数据架构）。

步骤 2：预留 ID 编号

检查 ai_dev_ssd_flow/08_CTR/，确定下一个可用的 ID 编号。

ID 编号约定：从 2 位数字开始，仅在需要时扩展。

✅ 正确：CTR-01、CTR-99、CTR-102
❌ 错误：CTR-001、CTR-009（无需额外的前导零）

步骤 3：创建 CTR 文件（双格式）

嵌套文件夹规则（强制）：无论文档大小如何，所有 CTR 文档都必须使用嵌套文件夹。

位置：

标准：docs/08_CTR/CTR-NN_{slug}/CTR-NN_{slug}.md + .yaml
基于服务：docs/08_CTR/{service_type}/CTR-NN_{slug}/CTR-NN_{slug}.md + .yaml

按需创建文件夹：保存前，创建目标目录：

# Create nested folder (ALWAYS required)
mkdir -p docs/08_CTR/CTR-NN_{slug}/
# OR for service-type subdirectory
mkdir -p docs/08_CTR/{service_type}/CTR-NN_{slug}/

服务类型（合同达到 10 个或以上时）：

agents/ - Agent 间通信
mcp/ - MCP 服务合同
infra/ - 基础设施服务
shared/ - 横切合同

示例：

标准：docs/08_CTR/CTR-01_data_validation/CTR-01_data_validation.md + .yaml
基于服务：docs/08_CTR/agents/CTR-01_data_validation/CTR-01_data_validation.md + .yaml

重要：绝不要在 docs/08_CTR/ 中直接创建 CTR 文件，必须使用嵌套文件夹结构。

步骤 4：填写文档控制部分（Markdown）

填写全部 9 个必填字段，包括 SPEC-Ready 评分。

步骤 5：编写合同概述（Markdown）

概述用途、范围和版本。

步骤 6：定义 YAML 合同

选择格式：

OpenAPI 3.0，用于 REST API
JSON Schema，用于数据模型
AsyncAPI，用于事件驱动系统（如适用）

步骤 7：添加使用示例（Markdown）

提供请求／响应示例并附上说明。

步骤 8：记录验证规则（Markdown）

说明架构验证和业务规则。

步骤 9：指定错误处理（Markdown）

记录错误代码和响应。

步骤 10：添加累积标签

包含全部 7–8 个上游标签（@brd 至 @req/impl）。

步骤 11：创建／更新可追溯性矩阵

强制：更新 ai_dev_ssd_flow/08_CTR/CTR-00_TRACEABILITY_MATRIX-TEMPLATE.md

步骤 12：验证 CTR

# YAML schema validation
yamllint ai_dev_ssd_flow/08_CTR/CTR-01_*.yaml

# OpenAPI validation
openapi-spec-validator ai_dev_ssd_flow/08_CTR/CTR-01_*.yaml

# Cumulative tagging
python ai_dev_flow/scripts/validate_tags_against_docs.py --artifact CTR-01 --expected-layers brd,prd,ears,bdd,adr,sys,req,impl --strict

步骤 13：提交更改

提交两个文件（.md 和 .yaml）以及可追溯性矩阵。

验证

自动验证

# Quality gates
scripts/validate_quality_gates.sh ai_dev_ssd_flow/08_CTR/CTR-01_*.md

# YAML validation
yamllint ai_dev_ssd_flow/08_CTR/CTR-01_*.yaml

# OpenAPI validation (if using OpenAPI)
openapi-spec-validator ai_dev_ssd_flow/08_CTR/CTR-01_*.yaml

# CTR-specific validation (includes dual-file check)
./ai_dev_flow/scripts/validate_ctr.sh CTR-01

# Cumulative tagging
python ai_dev_flow/scripts/validate_tags_against_docs.py \
  --artifact CTR-01 \
  --expected-layers brd,prd,ears,bdd,adr,sys,req,impl \
  --strict

手动检查清单

图表标准

所有图表 MUST 使用 Mermaid 语法。禁止使用基于文本的图表（ASCII 艺术、框线图）。参见：ai_dev_ssd_flow/DIAGRAM_STANDARDS.md 和 mermaid-gen 技能。

常见陷阱

仅创建单个文件：必须同时创建 .md 和 .yaml 文件
YAML 无效：必须使用 yamllint 和 openapi-spec-validator 进行验证
缺少示例：使用示例章节对推广采用至关重要
验证含糊：架构验证必须精确且可测试
缺少累积标签：第 9 层必须包含所有 7-8 个上游标签
需要时跳过：如果多个团队需要共享契约，请勿跳过
元素 ID 错误：使用 CTR.NN.xxxx，不要使用旧版 INT-XXX、MODEL-XXX、CLAUSE-XXX
累积标签代码错误：使用正确的元素类型代码（EARS=25、BDD=14、SYS=26、REQ=27、IMPL=29）

创建后验证（MANDATORY - NO CONFIRMATION）

关键：创建文档后立即执行此验证循环。在验证通过前，不要继续处理下一份文档。

自动验证循环

LOOP:
  1. Run: python ai_dev_flow/scripts/validate_cross_document.py --document {doc_path} --auto-fix
  2. IF errors fixed: GOTO LOOP (re-validate)
  3. IF warnings fixed: GOTO LOOP (re-validate)
  4. IF unfixable issues: Log for manual review, continue
  5. IF clean: Mark VALIDATED, proceed

验证命令

# Per-document validation (Phase 1)
python ai_dev_flow/scripts/validate_cross_document.py --document docs/CTR/CTR-NN_slug.md --auto-fix

# Layer validation (Phase 2) - run when all CTR documents complete
python ai_dev_flow/scripts/validate_cross_document.py --layer CTR --auto-fix

各层上游要求

此层	必需的上游标签	数量
CTR（第 8 层）	@brd、@prd、@ears、@bdd、@adr、@sys、@req	7 个标签

自动修复操作（无需确认）

问题	修复操作
缺少上游标签	添加上游文档引用
标签格式无效	更正为 TYPE.NN.xxxx（3 段）或 TYPE-NN 格式
链接失效	根据当前位置重新计算路径
缺少可追溯性章节	根据模板插入

验证代码参考

代码	描述	严重程度
XDOC-001	未找到引用的需求 ID	ERROR
XDOC-002	缺少累积标签	ERROR
XDOC-003	未找到上游文档	ERROR
XDOC-006	标签格式无效	ERROR
XDOC-007	累积标签链存在缺口	ERROR
XDOC-009	缺少可追溯性章节	ERROR

质量门禁

阻塞：是——只有在第 1 阶段验证通过且错误数为 0 后，才能继续处理下一份文档。

下一项技能

创建 CTR（或跳过此可选层）后，使用：

doc-spec - 创建技术规范（第 9 层）

SPEC 将：

引用 CTR（如果已创建）或 REQ 作为上游来源
包含全部 7-8 个上游标签
使用 YAML 格式
定义实现细节
达到 100% 实现就绪状态

参考文档

CTR 工件的补充文档：

格式：CTR-REF-NNN_{slug}.md
技能：使用 doc-ref 技能
验证：最小化（非阻塞）
示例：API 风格指南、契约版本控制策略

快速参考

CTR 用途：定义 API 契约和数据架构

层级：8（可选）

元素 ID 格式：CTR.NN.xxxx

接口 = 16
数据模型 = 17
契约条款 = 20

已移除的模式：INT-XXX、MODEL-XXX、CLAUSE-XXX、IF-XXX、DM-XXX、CC-XXX

文档控制字段：必填 9 项

必需标签：@brd 至 @req（7 个标签）

格式：双文件（.md + .yaml）

SPEC 就绪度评分：「Active」状态要求 ≥90%

YAML 标准：

REST API 使用 OpenAPI 3.0
数据模型使用 JSON Schema
事件驱动场景使用 AsyncAPI（如适用）

主要章节：

契约概述
业务背景（链接到 REQ 第 3 节）
YAML 契约定义
使用示例
验证规则
错误处理

目录组织：契约达到 30 个以上时，建议使用子目录

可选：如果契约较简单或已嵌入 REQ，可跳过此层

下一步：doc-spec

版本历史

版本	日期	变更	作者
1.2	2026-03-06	新增包含 12 个质量门禁的提交前钩子小节；新增钩子脚本说明和 YAML 配置；更新版本元数据	System
1.1.0	2026-02-08	根据 LAYER_REGISTRY v1.6 将层级分配从 9 更新为 8；更新下游工件（SPEC 第 9 层、TSPEC 第 10 层、TASKS 第 11 层）；从上游移除 IMPL	System
1.0.0	2025-01-15	初始技能定义	System

支持 Markdown

登录后评论

基本信息

作者: vladm3105
仓库: vladm3105/aidoc-flow-framework
分类: 开发
安装次数: 48
GitHub Stars: 17

报告问题

doc-ctr

关于 doc-ctr

主要功能

适用场景

安装

详细介绍

doc-ctr

目的

前置条件

上游产物验证（重要）

保留 ID 豁免（CTR-00_*）

何时使用此技能

CTR 专属指南

1. 强制采用双文件格式

2. 文档控制字段（必填 9 项）

3. 必需章节（Markdown 文件）

4. 元素 ID 格式（强制要求）

5. YAML 合约格式

6. 使用示例章节

示例 2：无效记录类型

8. SPEC 就绪度评分系统

9. 按服务类型组织目录

标签格式约定（设计如此）

统一元素 ID 格式（强制）

累积标签要求

上游/下游工件

验证检查

第 1 级：错误（阻断）

第 2 级：警告（建议）

第 3 级：信息

提交前钩子

创建流程

步骤 1：阅读上游制品

步骤 2：预留 ID 编号

步骤 3：创建 CTR 文件（双格式）

步骤 4：填写文档控制部分（Markdown）

步骤 5：编写合同概述（Markdown）

步骤 6：定义 YAML 合同

步骤 7：添加使用示例（Markdown）

步骤 8：记录验证规则（Markdown）

步骤 9：指定错误处理（Markdown）

步骤 10：添加累积标签

步骤 11：创建／更新可追溯性矩阵

步骤 12：验证 CTR

步骤 13：提交更改

验证

自动验证

手动检查清单

图表标准

常见陷阱

创建后验证（MANDATORY - NO CONFIRMATION）

自动验证循环

验证命令

各层上游要求

自动修复操作（无需确认）

验证代码参考

质量门禁

下一项技能

参考文档

相关资源

快速参考

版本历史

评论