核心用法
OpenSpec Workflow 是一套「规格驱动开发」的自动化协作框架，核心在于人机角色分工：用户作为 Orchestrator（编排者）使用 OpenSpec CLI 起草变更规格文档（proposal/design/specs/tasks），而 Claude Code 担任 Reviewer 和 Implementer——前者基于真实代码库进行深度评审挑战，后者直接执行代码实现与提交。
完整生命周期覆盖：Issue 触发 → OpenSpec 变更创建 → 多轮 Artifact 起草与评审循环 → Claude Code 任务实现 → PR 提交 → 合并后自动归档。关键指令包括 openspec new change、openspec instructions 获取模板，以及通过 claude --dangerously-skip-permissions 调用子代理。
评审质量门控是显著设计亮点：非琐碎变更必须经 Claude Code 评审，且评审者获得 repo 路径独立探索代码库，而非被动接收文本。这有效降低了"幻觉式评审"风险。
显著优点
- 结构化强制：Proposal/Design/Specs/Tasks 四层 Artifact 强制梳理需求，避免直接编码的隐性债务
- AI 原生设计：Claude Code 的深度上下文访问能力被充分利用，评审和实现质量显著高于通用 LLM
- 自动化闭环：GitHub Action 实现 PR 合并后的自动归档与规格同步，减少人工维护
- 灵活门控：允许跳过琐碎变更的评审（需显式记录理由），平衡效率与严谨
潜在局限与风险
- 工具链依赖重：需同时安装 openspec CLI、Claude CLI、gh CLI，且要求 Node/npm 环境
- 权限模式激进：
--dangerously-skip-permissions标志意味着 Claude Code 可无交互执行命令，误操作风险较高 - 超时配置敏感：15-20 分钟的子代理超时对复杂变更可能不足，需人工预估调整
- 目录名严格匹配：PR body 中的
OpenSpec change: <name>必须与目录名完全一致，否则归档静默失败，易踩坑
适合人群
中大型团队、需要严格需求追溯的 B 端产品、或已采纳 OpenSpec 规范的代码库维护者。特别适合变更影响面评估复杂、需要跨文件协调的场景。小型项目或快速原型阶段可能觉得流程过重。
常规风险提示
权限 bypass 模式需确保运行环境隔离（如 git worktree）；评审跳过决策需留痕审计；自动归档 Action 建议配合分支保护规则防止误删。