用途：把用户意图（例如“我需要一个做某事的团队”）转化为可启动运行的完整 rig，包括拓扑规格、智能体规格、指导文件、文化文件与启动内容；同时诊断 rig 启动后智能体行为不符合预期的问题。
设计前先选定相关来源：从用户目标、当前项目权威与该格式中要编写的部分入手，从公共 onboarding 载入选定路径，并按触发器查阅其他技能。选择新标识前阅读 topology-naming.md（rig=用途、pod=领域、member=角色），名称需在运行期选择间保持稳定，所有边、预设与工作流目标需匹配已声明的 ID。编写声明前阅读 rig-spec.md 与 agent-spec.md 的相关章节；启动/装备工作查阅 agent-startup-guide.md，选关系时查阅 edge-types.md。参考根目录需从实际 OpenRig 安装解析，~/.openrig/reference/ 只是默认而非固定位置；若不存在，用对应源仓库文档或报告缺失。阅读不需要启动或更改守护进程。命令形态用 rig <command> --help；通过已安装的技能/上下文目录载入 openrig-user。用 rig specs ls 查看相关起始规格，并将其作为需在当前环境验证的示例。
设计流程：1）理解用户意图——目标、工作流、项目、可用运行时、自治程度，含糊时先提问。2）识别限界上下文形成 pod，常见有编排、开发、评审、研究、设计、专家；规模从单人、结对、3-5 人小队到 6-10 人及更大团队，设计应考虑可用性而非持续占用。3）设计角色成员，内置智能体包括 orchestrator、implementer、qa、independent-reviewer、product-designer、pm、analyst、synthesizer、vault-specialist 等；用 rig specs ls 核对当前内置集合。local: 前缀相对于 rig 规格文件目录解析；在安装目录外编写时可用自己的 local: 规格，或用 path: 加绝对路径引用内置。4）选择运行时与模型，依据已安装已认证运行时与项目执行策略，必要时固定模型并在使用前确认。5）设计边拓扑，工作 pod 至少有一条来自编排者的 delegates_to，评审 pod 对被评审 pod 用 can_observe，先保持简单。6）设计启动内容策略：每个智能体需 guidance/role.md，rig 需 CULTURE.md，并确保 onboarding 路径与可发现的命令/技能引用；严肃 rig 还应加入每智能体 startup/context.md、pod SOP 技能与项目文档。7）如需托管软件（数据库、API 服务器等）则添加 services 块，服务先于智能体启动，健康检查失败则不启动智能体。
文件创建：目录含 rig.yaml（必需）、culture/CULTURE.md、agents/<名字>/agent.yaml 与 guidance、startup、skills 等。工作流为编写 rig spec、编写或引用 agent spec、编写 CULTURE.md、写角色指导与启动上下文、用 rig spec validate rig.yaml 与 rig agent validate agents/*/agent.yaml 验证、确认运行时 cwd、用 rig up rig.yaml --cwd /path/to/project 启动、用 rig ps --nodes 与 rig capture 验证。验证不可省略，可再运行 rig spec audit rig.yaml 做咨询性检查。
诊断常见问题：智能体不知角色（缺 role.md）；无法与同伴协调（未获 openrig-user 技能或 openrig-start 覆盖）；在 rig 命令上遇审批提示（Claude Code 权限未配置）；智能体闲置（缺 CULTURE.md 或 pod SOP）；服务无法启动（Compose、健康检查或端口冲突）；从错误项目上下文启动（误把规格目录当作 cwd）；启动内容未送达（路径解析或 delivery_hint 错误）；启动已送达但不去用技能（未在指导中说明加载）。
限制：资料未提供收费与价格信息；模型可用性、钩子、审批行为与续跑支持因运行时不同，需查已安装接口而非永久排名；路径、命令与内置集合需以实际安装为准核验。