Back to Details

openspec-constitution-guard

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

OpenSpec Constitution Guard

OpenSpec 章程守卫

This skill ensures OpenSpec workflows enforce project-specific quality assurance criteria derived from AGENTS.md constitution files by injecting them into 
openspec/config.yaml
.
此Skill可通过将AGENTS.md章程文件中的项目特定质量保证标准注入
openspec/config.yaml
，确保OpenSpec工作流执行这些标准。

Purpose

用途

OpenSpec workflows (
/opsx:apply
, 
/opsx:verify
, 
/opsx:archive
, etc.) include generic validation. This skill enriches them with project-specific quality gates extracted from AGENTS.md files across the workspace, ensuring all artifacts pass the project's defined testing and QA criteria before handoff.
OpenSpec工作流（
/opsx:apply
、
/opsx:verify
、
/opsx:archive
等）包含通用验证逻辑。此Skill可通过提取工作区中AGENTS.md文件的内容，为工作流添加项目特定质量关卡，确保所有工件在移交前都能通过项目定义的测试和QA标准。

When to Use

使用场景

Trigger this skill when:
  • Initializing openspec for the first time in a project (
    openspec init
    )
  • An AGENTS.md file is created, modified, or deleted in the project
  • User explicitly requests to sync constitution quality gates with openspec config
  • Validating that openspec configuration is up-to-date with constitution requirements
在以下场景触发此Skill：
  • 首次在项目中初始化OpenSpec时（
    openspec init
    ）
  • 项目中创建、修改或删除AGENTS.md文件时
  • 用户明确要求将章程质量关卡与OpenSpec配置同步时
  • 验证OpenSpec配置是否符合章程要求时

Detection: When to Run

运行时机检测

To detect if guards need composition:
  1. Check if 
    openspec/config.yaml
    exists
  2. Look for 
    <!-- CONSTITUTION-GUARD:START
    marker in the config file
  3. If marker is missing → first-time setup needed
  4. If AGENTS.md files have changed since 
    Last Updated
    date → refresh needed
判断是否需要整合验证关卡的步骤：
  1. 检查
    openspec/config.yaml
    是否存在
  2. 查找配置文件中的
    <!-- CONSTITUTION-GUARD:START
    标记
  3. 若标记缺失 → 需要首次设置
  4. 若AGENTS.md文件自
    Last Updated
    日期后有变更 → 需要刷新配置

Workflow

工作流程

Step 1: Locate All Constitution Files

步骤1：定位所有章程文件

Find all AGENTS.md files in the workspace:
bash
find . -name "AGENTS.md" -type f | grep -v node_modules | grep -v .venv | grep -v target | grep -v openspec/AGENTS.md
Exclude 
openspec/AGENTS.md
as it contains OpenSpec usage instructions already referenced by the system, not project-specific quality criteria.
Read each remaining file to understand its scope (root project, backend, frontend, specific module, etc.).
在工作区中查找所有AGENTS.md文件：
bash
find . -name "AGENTS.md" -type f | grep -v node_modules | grep -v .venv | grep -v target | grep -v openspec/AGENTS.md
排除
openspec/AGENTS.md
，因为它包含的是OpenSpec使用说明，已被系统引用，不属于项目特定质量标准。
读取剩余的每个文件，明确其适用范围（根项目、后端、前端、特定模块等）。

Step 2: Read and Understand Quality Criteria

步骤2：读取并解析质量标准

For each AGENTS.md file, identify sections related to quality assurance. Look for:
  • Headings containing: "Quality", "Testing", "Checks", "Validation", "Assurance", "Checklist"
  • Command examples (typically in backticks or code blocks)
  • Goals or acceptance criteria (e.g., "Zero errors", "All tests pass")
  • Architecture patterns and coding standards that should be enforced
Key information to extract:
  1. Automated commands - What tools/commands must be run (e.g., 
    pytest
    , 
    npm run lint
    )
  2. Success criteria - What constitutes passing (e.g., "zero warnings")
  3. Architecture rules - Patterns that must be followed (e.g., "service layer separation")
  4. Testing requirements - Coverage expectations, test types needed
  5. Stack identification - What technology stack does this constitution govern
针对每个AGENTS.md文件，识别与质量保证相关的章节。重点查找：
  • 包含以下关键词的标题："Quality"、"Testing"、"Checks"、"Validation"、"Assurance"、"Checklist"
  • 命令示例（通常在反引号或代码块中）
  • 目标或验收标准（如："Zero errors"、"All tests pass"）
  • 需强制执行的架构模式和编码规范
需提取的关键信息：
  1. 自动化命令 - 必须运行的工具/命令（如：
    pytest
    、
    npm run lint
    ）
  2. 成功标准 - 判定通过的条件（如："zero warnings"）
  3. 架构规则 - 必须遵循的模式（如："service layer separation"）
  4. 测试要求 - 覆盖率预期、所需的测试类型
  5. 技术栈标识 - 该章程适用的技术栈

Step 3: Interpret Criteria for Artifacts

步骤3：将标准映射至工件

Map the extracted criteria to specific OpenSpec artifacts in the config.yaml rules:
将提取的标准映射至config.yaml规则中对应的OpenSpec工件：

For 
proposal
Artifact

针对
proposal
工件

Extract rules that validate design decisions:
  • Architecture patterns that must be followed
  • Type safety requirements
  • Naming conventions
  • What requires a proposal vs direct fix
  • Breaking change documentation requirements
提取验证设计决策的规则：
  • 必须遵循的架构模式
  • 类型安全要求
  • 命名规范
  • 哪些内容需要提案而非直接修复
  • 破坏性变更的文档要求

For 
specs
Artifact

针对
specs
工件

Extract rules that validate specification quality:
  • Required sections in specs
  • Format requirements (e.g., "Given/When/Then")
  • Edge cases that must be documented
  • API contract requirements
提取验证规格质量的规则：
  • 规格中必须包含的章节
  • 格式要求（如："Given/When/Then"）
  • 必须文档化的边缘情况
  • API契约要求

For 
design
Artifact

针对
design
工件

Extract rules that validate technical design:
  • Design patterns to follow
  • System architecture requirements
  • Integration points to consider
  • Technology choices and their justification
提取验证技术设计的规则：
  • 需遵循的设计模式
  • 系统架构要求
  • 需考虑的集成点
  • 技术选型及其理由

For 
tasks
Artifact

针对
tasks
工件

Extract rules that validate implementation planning:
  • Task breakdown requirements
  • Testing tasks that must be included
  • Documentation tasks
  • Deployment considerations
提取验证实施规划的规则：
  • 任务拆分要求
  • 必须包含的测试任务
  • 文档任务
  • 部署考量

For General Context

通用上下文

Extract information that should be available to all artifacts:
  • Tech stack information
  • Coding conventions
  • Team practices
  • Backwards compatibility requirements
提取需应用于所有工件的信息：
  • 技术栈信息
  • 编码规范
  • 团队实践
  • 向后兼容性要求

Step 4: Compose the config.yaml

步骤4：编写config.yaml

Create or update 
openspec/config.yaml
with the constitution guards. The file should include:
  1. Context section: Project-wide information injected into ALL artifacts
  2. Rules section: Per-artifact specific validation rules
  3. Constitution metadata: Source files and update timestamp
Template structure:
yaml
undefined
创建或更新
openspec/config.yaml
，加入章程守卫。文件应包含：
  1. Context章节：注入至所有工件的项目级信息
  2. Rules章节：针对各工件的特定验证规则
  3. 章程元数据：源文件路径和更新时间戳
模板结构：
yaml
undefined

openspec/config.yaml

openspec/config.yaml

Schema selection (if you have a preferred one)

选择Schema（若有偏好的Schema）

schema: spec-driven
schema: spec-driven

<!-- CONSTITUTION-GUARD:START - Auto-generated from AGENTS.md files -->

<!-- CONSTITUTION-GUARD:START - Auto-generated from AGENTS.md files -->

Context injected into ALL artifacts

注入至所有工件的上下文

context: | [PROJECT-WIDE CONTEXT]
context: | [项目级通用上下文]

Per-artifact validation rules

各工件的验证规则

rules: proposal: - [PROPOSAL-SPECIFIC RULES]
specs: - [SPECS-SPECIFIC RULES]
design: - [DESIGN-SPECIFIC RULES]
tasks: - [TASKS-SPECIFIC RULES]
rules: proposal: - [提案特定规则]
specs: - [规格特定规则]
design: - [设计特定规则]
tasks: - [任务特定规则]

Constitution metadata

章程元数据

Source Constitutions:

Source Constitutions:

- [List each AGENTS.md file path]

- [列出每个AGENTS.md文件路径]

Last Updated: [YYYY-MM-DD]

Last Updated: [YYYY-MM-DD]

<!-- CONSTITUTION-GUARD:END -->

<!-- CONSTITUTION-GUARD:END -->

undefined
undefined

Step 5: Update Configuration File

步骤5：更新配置文件

  1. Check if 
    openspec/config.yaml
    exists
    • If not, create it with initial configuration
    • If yes, read current content
  2. Locate the 
    <!-- CONSTITUTION-GUARD:START
    marker
  3. If existing guard block found, replace it entirely
  4. If no existing block, append to the file
  5. Preserve any existing 
    schema:
    declaration at the top
  6. Ensure proper YAML formatting is maintained
Critical: Always validate YAML syntax after generation to ensure the file is parseable.
  1. 检查
    openspec/config.yaml
    是否存在
    • 若不存在，创建初始配置
    • 若存在，读取当前内容
  2. 定位
    <!-- CONSTITUTION-GUARD:START
    标记
  3. 若找到现有守卫块，完全替换它
  4. 若无现有块，追加至文件末尾
  5. 保留文件顶部已有的
    schema:
    声明
  6. 确保YAML格式正确
关键注意事项：生成后务必验证YAML语法，确保文件可被解析。

Example Outputs

示例输出

Example: Basic Configuration

示例：基础配置

After reading constitutions with Python backend and TypeScript frontend:
yaml
undefined
读取包含Python后端和TypeScript前端的章程后生成的配置：
yaml
undefined

openspec/config.yaml

openspec/config.yaml

schema: spec-driven
schema: spec-driven

<!-- CONSTITUTION-GUARD:START - Auto-generated from AGENTS.md files -->

<!-- CONSTITUTION-GUARD:START - Auto-generated from AGENTS.md files -->

Context injected into ALL artifacts

注入至所有工件的上下文

context: | Tech stack: Python (FastAPI, Pydantic), TypeScript (React, Node.js), PostgreSQL Architecture: Service layer pattern - business logic in services/, API routes are thin Type safety: Strict typing required (no Any/any types) API style: RESTful with OpenAPI docs Testing: pytest + React Testing Library We value backwards compatibility for all public APIs
context: | 技术栈：Python（FastAPI、Pydantic）、TypeScript（React、Node.js）、PostgreSQL 架构：服务层模式 - 业务逻辑位于services/目录，API路由仅做转发 类型安全：要求严格类型（禁止使用Any/any类型） API风格：RESTful + OpenAPI文档 测试：pytest + React Testing Library 我们重视所有公共API的向后兼容性

Per-artifact validation rules

各工件的验证规则

rules: proposal: - Include rollback plan for breaking changes - Mark breaking changes with BREAKING prefix - Identify affected teams/systems - Verify alignment with service layer architecture
specs: - Use Given/When/Then format for scenarios - Document all edge cases and error conditions - Reference existing patterns before proposing new ones - Include API contract changes if applicable
design: - Maintain service layer separation (logic in services/, not api/) - Use Pydantic models for all new data structures - Ensure strict typing (no Any types in Python/TypeScript) - Document integration points with existing services
tasks: - Include unit test tasks for all new service logic - Include integration test tasks for API changes - Add type checking verification tasks - Include documentation update tasks
rules: proposal: - 包含破坏性变更的回滚方案 - 破坏性变更需添加BREAKING前缀 - 识别受影响的团队/系统 - 验证是否符合服务层架构
specs: - 场景使用Given/When/Then格式 - 文档化所有边缘情况和错误条件 - 提出新方案前先参考现有模式 - 若涉及API变更，需包含契约修改内容
design: - 遵循服务层分离（逻辑位于services/，而非api/） - 所有新数据结构使用Pydantic模型 - 确保严格类型（Python/TypeScript中禁止Any类型） - 文档化与现有服务的集成点
tasks: - 为所有新服务逻辑添加单元测试任务 - 为API变更添加集成测试任务 - 添加类型检查验证任务 - 包含文档更新任务

Source Constitutions:

章程元数据

- AGENTS.md

Source Constitutions:

- backend/AGENTS.md

- AGENTS.md

- frontend/AGENTS.md

- backend/AGENTS.md

Last Updated: 2026-02-09

- frontend/AGENTS.md

<!-- CONSTITUTION-GUARD:END -->

Last Updated: 2026-02-09

—

<!-- CONSTITUTION-GUARD:END -->

undefined
undefined

Example: With Automated Check Commands

示例：包含自动化检查命令

After reading constitutions with specific test commands:
yaml
undefined
读取包含特定测试命令的章程后生成的配置：
yaml
undefined

openspec/config.yaml

openspec/config.yaml

schema: spec-driven
schema: spec-driven

<!-- CONSTITUTION-GUARD:START - Auto-generated from AGENTS.md files -->

<!-- CONSTITUTION-GUARD:START - Auto-generated from AGENTS.md files -->

context: | Tech stack: Python (uv, FastAPI), TypeScript (Vite, React), PostgreSQL Automated checks required before completion:
  • Python: uv run pytest, uv run ruff check ., uv run pyright .
  • TypeScript: npm run lint, npm run tsc, npx playwright test Architecture: Microservices with event-driven communication All services must be independently deployable
rules: proposal: - Identify service boundaries affected - Document event schema changes - Include deployment strategy - Consider backwards compatibility for events
specs: - Document event payloads in Given/When/Then scenarios - Include failure/retry scenarios - Specify service dependencies
design: - Show event flow diagrams for cross-service changes - Use async/await patterns for I/O operations - Maintain service independence
tasks: - Before marking complete, run: uv run pytest (Python) - Before marking complete, run: npm run lint && npm run tsc (TypeScript) - Include E2E test tasks for cross-service scenarios - Add event contract validation tasks
context: | 技术栈：Python（uv、FastAPI）、TypeScript（Vite、React）、PostgreSQL 完成前需执行的自动化检查：
  • Python：uv run pytest, uv run ruff check ., uv run pyright .
  • TypeScript：npm run lint, npm run tsc, npx playwright test 架构：微服务 + 事件驱动通信 所有服务必须可独立部署
rules: proposal: - 识别受影响的服务边界 - 文档化事件 schema 变更 - 包含部署策略 - 考虑事件的向后兼容性
specs: - 场景中使用Given/When/Then格式文档化事件 payload - 包含失败/重试场景 - 指定服务依赖
design: - 跨服务变更需展示事件流图 - I/O操作使用async/await模式 - 保持服务独立性
tasks: - 标记完成前执行：uv run pytest（Python） - 标记完成前执行：npm run lint && npm run tsc（TypeScript） - 为跨服务场景添加E2E测试任务 - 加入事件契约验证任务

Source Constitutions:

章程元数据

- AGENTS.md

Source Constitutions:

- services/user/AGENTS.md

- AGENTS.md

- services/order/AGENTS.md

- services/user/AGENTS.md

Last Updated: 2026-02-09

- services/order/AGENTS.md

<!-- CONSTITUTION-GUARD:END -->

Last Updated: 2026-02-09

—

<!-- CONSTITUTION-GUARD:END -->

undefined
undefined

Example: Complex Multi-Stack Project

示例：复杂多栈项目

After reading constitutions from root, backend (Python), frontend (React), and mobile (Swift):
yaml
undefined
读取根目录、后端（Python）、前端（React）、移动端（Swift）的章程后生成的配置：
yaml
undefined

openspec/config.yaml

openspec/config.yaml

schema: spec-driven
schema: spec-driven

<!-- CONSTITUTION-GUARD:START - Auto-generated from AGENTS.md files -->

<!-- CONSTITUTION-GUARD:START - Auto-generated from AGENTS.md files -->

context: | Multi-platform project with shared API
Backend (Python):
  • FastAPI + SQLAlchemy + Alembic
  • Service layer required for all business logic
  • Commands: uv run pytest, uv run ruff check ., uv run mypy .
Web Frontend (TypeScript/React):
  • Vite + React + TanStack Query
  • Commands: npm run lint, npm run type-check, npm test
Mobile (Swift):
  • SwiftUI + Combine
  • Commands: swift test, swiftlint
Shared API contracts documented in docs/api/ Zero tolerance for breaking changes without migration plan
rules: proposal: - Mark platform scope (backend/web/mobile/api) - For API changes, document impact on all clients - Include migration strategy for breaking changes - Specify API versioning approach if needed
specs: - Use platform-specific scenario tags: [Backend], [Web], [Mobile] - Document API contract changes in OpenAPI format - Include backwards compatibility scenarios - Reference existing patterns from project codebase
design: - Show component/service interaction diagrams - Maintain service layer in backend (no logic in routes) - Use proper state management patterns per platform - Document data flow for cross-platform features
tasks: - Group tasks by platform with clear labels - Backend: Include pytest, ruff, mypy verification - Web: Include lint, type-check, unit test tasks - Mobile: Include SwiftLint and unit test tasks - For API changes, include contract validation task - Include platform-specific E2E test tasks
context: | 多平台项目，共享API
后端（Python）：
  • FastAPI + SQLAlchemy + Alembic
  • 所有业务逻辑必须位于服务层
  • 命令：uv run pytest, uv run ruff check ., uv run mypy .
Web前端（TypeScript/React）：
  • Vite + React + TanStack Query
  • 命令：npm run lint, npm run type-check, npm test
移动端（Swift）：
  • SwiftUI + Combine
  • 命令：swift test, swiftlint
共享API契约文档位于docs/api/ 无特殊迁移方案的破坏性变更一律禁止
rules: proposal: - 标记平台范围（后端/Web/移动端/API） - API变更需文档化对所有客户端的影响 - 破坏性变更需包含迁移策略 - 必要时指定API版本化方案
specs: - 使用平台特定场景标签：[Backend], [Web], [Mobile] - 用OpenAPI格式文档化API契约变更 - 包含向后兼容性场景 - 参考项目代码库中的现有模式
design: - 展示组件/服务交互图 - 后端保持服务层（路由中无业务逻辑） - 各平台使用合适的状态管理模式 - 文档化跨平台功能的数据流
tasks: - 按平台分组任务并添加清晰标签 - 后端：包含pytest、ruff、mypy验证任务 - Web：包含lint、类型检查、单元测试任务 - 移动端：包含SwiftLint和单元测试任务 - API变更需包含契约验证任务 - 加入平台特定E2E测试任务

Source Constitutions:

章程元数据

- AGENTS.md

Source Constitutions:

- backend/AGENTS.md

- AGENTS.md

- frontend/AGENTS.md

- backend/AGENTS.md

- mobile/AGENTS.md

- frontend/AGENTS.md

Last Updated: 2026-02-09

- mobile/AGENTS.md

<!-- CONSTITUTION-GUARD:END -->

Last Updated: 2026-02-09

—

<!-- CONSTITUTION-GUARD:END -->

undefined
undefined

Interpretation Guidelines

解析指南

When reading AGENTS.md files with varying structures:
  1. Look for imperative language: "MUST", "SHALL", "required", "always"
  2. Identify command patterns: Anything in backticks that looks like a shell command
  3. Find success criteria: Phrases like "zero errors", "all pass", "no warnings"
  4. Recognize stack indicators: Framework names, file extensions, folder names
  5. Extract checklists: Bullet points with checkboxes or numbered items
当读取结构各异的AGENTS.md文件时：
  1. 查找命令式语言："MUST"、"SHALL"、"required"、"always"
  2. 识别命令模式：反引号中类似Shell命令的内容
  3. 定位成功标准：如"zero errors"、"all pass"、"no warnings"等表述
  4. 识别技术栈标识：框架名称、文件扩展名、文件夹名称
  5. 提取检查清单：带复选框或编号的项目符号

Categorizing Extracted Information

提取信息分类

For Context (applies to all artifacts):
  • Technology stack descriptions
  • Architectural principles
  • Naming conventions
  • Team practices
  • Backwards compatibility requirements
  • General coding standards
For Rules (specific to artifacts):
  • Specific format requirements (e.g., "Use Given/When/Then")
  • Required sections in artifacts
  • Validation commands to run
  • Architecture patterns to enforce
  • Testing requirements
  • Documentation standards
If a constitution section is ambiguous, interpret conservatively—include the check rather than omit it.
All constitution items should be derived from project AGENTS.md files only, DO NOT include OpenSpec's own AGENTS.md or any common sense or best practices from other materials.
Context（适用于所有工件）：
  • 技术栈描述
  • 架构原则
  • 命名规范
  • 团队实践
  • 向后兼容性要求
  • 通用编码标准
Rules（特定于工件）：
  • 特定格式要求（如："Use Given/When/Then"）
  • 工件中必须包含的章节
  • 需执行的验证命令
  • 需强制执行的架构模式
  • 测试要求
  • 文档标准
若章程章节存在歧义，应保守解析——宁可包含检查项，也不要遗漏。
所有章程项必须仅来自项目的AGENTS.md文件，禁止包含OpenSpec自身的AGENTS.md或其他资料中的常识性内容或最佳实践。

How OpenSpec Uses the Configuration

OpenSpec如何使用该配置

When an OpenSpec command generates or works with an artifact, your configuration is automatically injected:
当OpenSpec命令生成或处理工件时，配置会自动注入：

Context Injection (ALL artifacts)

上下文注入（所有工件）

<context>
Tech stack: Python (FastAPI, Pydantic), TypeScript (React, Node.js), PostgreSQL
Architecture: Service layer pattern - business logic in services/, API routes are thin
Type safety: Strict typing required (no Any/any types)
...
</context>

<template>
[Schema's built-in template for this artifact]
</template>
<context>
技术栈：Python（FastAPI、Pydantic）、TypeScript（React、Node.js）、PostgreSQL
架构：服务层模式 - 业务逻辑位于services/目录，API路由仅做转发
类型安全：要求严格类型（禁止使用Any/any类型）
...
</context>

<template>
[该工件对应的Schema内置模板]
</template>

Rules Injection (matching artifact only)

规则注入（匹配对应工件）

For 
/opsx:continue proposal
or when generating a proposal:
<rules>
- Include rollback plan for breaking changes
- Mark breaking changes with **BREAKING** prefix
- Identify affected teams/systems
- Verify alignment with service layer architecture
</rules>
This ensures every artifact is generated with your project's specific requirements in mind.
执行
/opsx:continue proposal
或生成提案时：
<rules>
- 包含破坏性变更的回滚方案
- 破坏性变更需添加**BREAKING**前缀
- 识别受影响的团队/系统
- 验证是否符合服务层架构
</rules>
这确保每个工件的生成都符合项目的特定要求。

Related OpenSpec Commands

相关OpenSpec命令

Understanding which commands work with which artifacts:
CommandPurposeAffected Artifacts
/opsx:new
Start a changeCreates change directory
/opsx:continue
Create next artifactproposal → specs → design → tasks
/opsx:ff
Fast-forward (create all planning)proposal, specs, design, tasks
/opsx:apply
Implement tasksWorks from tasks.md
/opsx:verify
Validate implementationChecks against all artifacts
/opsx:sync
Merge specs to mainUpdates openspec/specs/
/opsx:archive
Complete changeFinalizes and archives
Your constitution rules in config.yaml affect the quality and validation of artifacts throughout this workflow.
了解各命令对应的工件：
命令用途影响的工件
/opsx:new
启动变更创建变更目录
/opsx:continue
创建下一个工件proposal → specs → design → tasks
/opsx:ff
快速推进（创建所有规划工件）proposal、specs、design、tasks
/opsx:apply
执行任务基于tasks.md操作
/opsx:verify
验证实现检查所有工件
/opsx:sync
将规格合并至主分支更新openspec/specs/
/opsx:archive
完成变更最终化并归档
config.yaml中的章程规则会影响整个工作流中工件的质量和验证。

Maintenance

维护

When updating guards:
  1. Re-read all AGENTS.md files
  2. Extract updated quality criteria
  3. Locate the 
    <!-- CONSTITUTION-GUARD:START
    block in config.yaml
  4. Replace the entire block with newly generated content
  5. Preserve any existing 
    schema:
    declaration at the top
  6. Validate YAML syntax
  7. Update the 
    Last Updated
    timestamp
  8. Test with 
    openspec new test-change
    to verify configuration loads correctly
更新守卫时：
  1. 重新读取所有AGENTS.md文件
  2. 提取更新后的质量标准
  3. 定位config.yaml中的
    <!-- CONSTITUTION-GUARD:START
    块
  4. 用新生成的内容完全替换该块
  5. 保留文件顶部已有的
    schema:
    声明
  6. 验证YAML语法
  7. 更新
    Last Updated
    时间戳
  8. 使用
    openspec new test-change
    测试配置是否加载正常

Validation After Update

更新后的验证

After updating config.yaml, verify it works:
bash
undefined
更新config.yaml后，验证其是否正常工作：
bash
undefined

Check YAML syntax

检查YAML语法

python -c "import yaml; yaml.safe_load(open('openspec/config.yaml'))"
python -c "import yaml; yaml.safe_load(open('openspec/config.yaml'))"

Test with a dummy change

用测试变更验证

openspec new test-validation
openspec new test-validation

Check if context and rules are properly injected in artifacts

检查工件中是否正确注入了上下文和规则


If you see errors about context or rules not being injected, check YAML indentation and structure.

若出现上下文或规则未注入的错误，请检查YAML的缩进和结构。",