drydock（干船坞） 是做什么的？
为 shipyard 铺设基础：一个仓库，一套共享框架，每个贡献者自然继承。该技能搭建了将“每个人都交付”转变为“每个人都基于同一套设计语言交付”的环境 —— 它创建 5 个表面，对其进行最小化填充，将它们连接到负责填充的流程（launch 写入 CONTEXT/ADR；launch C5 沉淀和审查沉淀标准），并报告哪些已存在、哪些已创建、以及哪些有意保持为空。
四大支柱及其物理位置：
| 支柱 | 表面 |
|---|---|
| 上下文（共享背景） | CONTEXT.md（词汇表）+ docs/business/ + docs/adr/ + OMC 维基 |
| 规则（边界） | CLAUDE.md（薄入口：约定、原则、索引）+ docs/standards/ |
| 工具（可组合能力） | .omc/skills/ + .mcp.json + scripts/ |
| 标准（分级社） | design-system/（令牌、组件、模式）+ docs/standards/ |
隐喻映射：shipyard 是共享设施；分级社（docs/standards/ + design-system/）设定船舶必须满足的适航规则；drydock 铺设龙骨；launch 将其投入运营。
何时使用
- 启动一个人类和 Agent 都将同时构建的仓库
- 仓库中的知识存在于人的头脑和聊天历史中，而不是文件中
- 新成员入职：新队友或 Agent 应通过阅读继承上下文，而不是通过询问
何时不使用
- 没有协作者的临时原型
- 已运行该框架的仓库（应使用
--check）
工作流
1. 检测（绝不覆盖）
在写入任何内容之前，清点已存在的内容：
CLAUDE.md存在？AGENTS.md存在？（规则：如果任一存在，就地扩展；将缺失的那个创建为指向另一个的单行指针；绝不同时创建两个新文件）CONTEXT.md、docs/adr/、docs/standards/、docs/business/、design-system/、.omc/skills/、.mcp.json、scripts/、.gitattributes—— 哪些存在，哪些缺失？- OMC 是否已安装？—— 仅在运行于 OMC 会话内部时有检查价值；在会话外部，静默跳过此检查（框架无论是否使用 OMC 均可工作）
先报告图谱，再执行操作。
2. 解析文档语言，然后仅询问检测无法回答的问题
所生成框架文件的文档语言是基于文件的决策，而非对话状态。请精确使用以下合约：
{
"schemaVersion": 1,
"authority": { "path": "CONTEXT.md", "frontmatterKey": "documentLanguage" },
"canonicalSources": ["CLAUDE.md", "README.md"],
"askOn": ["missing", "mixed", "conflict", "low-confidence", "invalid-explicit", "script-ambiguous"],
"tagPattern": "^[a-z]{2,3}(?:-[A-Z][a-z]{3})?(?:-(?:[A-Z]{2}|[0-9]{3}))?$",
"scriptVariants": ["zh-Hans", "zh-Hant"],
"seedCompanionPrefixes": { "en": "en", "zh-Hans": "zh-Hans", "zh-Hant": "zh-Hant" },
"stableTokens": [
"CONTEXT.md", "documentLanguage", "/oh-my-claudecode:launch", "--serial",
"plan", "execute", "review", "verify", "blockedBy", "blocked_by",
"pending", "in_progress", "completed", "failed", "ready-for-agent",
"id", "name", "description", "triggers", "mcpServers", "```",
"<Project>", "<term>", "<feature-slug>"
]
}
解析顺序：
- 当前调用中的显式用户选择，如果有效则优先。将其规范化为稳定的 BCP-47 样式标签：小写语言、首字母大写的书写系统、大写地区。无效的显式输入必须询问一次而非猜测。
- 否则，从
CONTEXT.md顶部的 YAML frontmatter 中读取documentLanguage。有效的、书写系统明确的标签对于全新的 Drydock 和 Launch 调用具有权威性。如果持久化的标签是裸的或仅限地区的简体中文，在此权威层询问一次；绝不能通过源推断绕过。 - 如果标记缺失或无效，按顺序检查规范源：
CLAUDE.md，然后README.md。仅当每个可用源都有一种明确的优势语言且所有可用源都同意相同的规范化标签时，才进行推断。当另一个源缺失或为空时，一个明确的源即为足够。 - 中文必须解析为明确的书写系统限定标签：
zh-Hans或zh-Hant（可选后跟地区）。裸的zh和仅限地区的中文标签是书写系统模糊的，必须询问一次而非选择伴侣。伴侣选择使用最长的语言/书写系统前缀：zh-Hans-*选择zh-Hans伴侣，zh-Hant-*选择zh-Hant伴侣；保留完整的规范化标签（例如zh-Hans-CN）在CONTEXT.md中。 - 缺少可用源、混合语言内容、冲突标签、低置信度推断、无效显式输入或书写系统模糊的中文必须触发一次批量语言问题。不要猜测。如果没有可用答案，在编写本地化工件之前停止。
- 在脚手架搭建之前，将已解析的标签写入
CONTEXT.md中精确的稳定 frontmatter 键documentLanguage（创建或扩展其 frontmatter，但不翻译该键）。这个可见文件是初始化报告的语言权威；不创建守护进程、隐藏分类账或运行时状态。
只有散文和面向人类的标签/可本地化值跟随所选语言；结构化键保持语言稳定。保持路径、斜杠命令、标志、代码块、占位符、frontmatter 键和机器语义值、YAML/JSON 键、生命周期令牌、状态枚举、ID、blockedBy、公共团队 blocked_by 以及解析器/控制令牌字节级稳定。
仅在语言解析后提出剩余问题：
- 包/技术栈（用于标准和设计系统种子）
- 此仓库是否有 UI？（无 UI → design-system/ 创建为带有注释的存根，或根据请求跳过）
- 问题跟踪器位置（GitHub / GitLab / 本地
.scratch/）—— 对于 V1 harbor 接入仅支持 GitHub；同时记录维护者的通信权威以用于接入（问题评论、标签更改）—— 由导航器的地图主页和 harbor 的接入队列消费
3. 脚手架搭建（创建缺失的表面 —— 种子以文档语言渲染）
CLAUDE.md # 薄入口 —— 见种子 A
CONTEXT.md # 词汇表 —— 见种子 B
.gitattributes # * text=auto eol=lf （在 Windows 上消除 CRLF 警告噪音）
docs/adr/0001-adopt-shipyard-harness.md
docs/standards/architecture.md # 种子 C
docs/standards/data.md
docs/standards/process.md
docs/business/README.md # 种子 D
design-system/README.md # 种子 E（仅限有 UI 的仓库；否则为存根）
design-system/tokens/README.md
.omc/skills/README.md # 种子 F
.mcp.json # {"mcpServers": {}}
scripts/README.md
种子示例是参考伴侣，而不是组合的有效载荷。解析 documentLanguage 后精确选择一个伴侣；不要输出来自另一个伴侣的重复标题或标签。使用最长的匹配语言/书写系统前缀：en-* 使用英语，zh-Hans-* 使用简体中文，zh-Hant-* 使用繁体中文，同时种子 B 将完整的已解析标签写入 documentLanguage。对于任何其他有效标签，将英语规范伴侣翻译一次，同时保留上述每个稳定令牌。
在生成种子散文之前，调用具有 agent-doc-discipline 的技能工具并应用其规则；只有当每个规则都可检查并带有原因，每个表面无需聊天历史即可自我描述，并且源被命名而非假设时，种子散文才算就绪。队友或 Agent 应能够仅通过阅读就能处理种子的内容。
种子 A —— CLAUDE.md，en（薄入口；如果文件存在，就地扩展）：
# <Project> — Agent & Human Shipyard
## Project conventions
- <language/framework/package manager/naming — list what matters, skip the rest>
## Architecture principles
- <the 3-5 principles most often violated in this project>
## Standards index (full text in docs/standards/)
- Architecture: docs/standards/architecture.md
- Data: docs/standards/data.md
- Process: docs/standards/process.md
## Decision records (full text in docs/adr/; load-bearing ones listed here)
- ADR-0001: adopt shipyard harness
## Shared background
- Glossary: CONTEXT.md ｜ Business knowledge: docs/business/ ｜ Decision context: docs/adr/
## Agent guide
- Delivery follows the canonical workflow plan → execute → review → verify; `/oh-my-claudecode:launch` is an optional governed delivery pipeline (opt-in, invoke explicitly)
- On term conflicts CONTEXT.md wins; new terms are recorded the moment they settle
- Reusable capability goes to .omc/skills/; UI patterns go to design-system/
种子 A —— zh-Hans 伴侣（结构一致，按文档语言二选一渲染）：
# <Project> — Agent & Human Shipyard
## 项目约定
- <language/framework/package manager/naming — list what matters, skip the rest>
## 架构原则
- <the 3-5 principles most often violated in this project>
## 规范索引（全文在 docs/standards/）
- 架构规范: docs/standards/architecture.md
- 数据规范: docs/standards/data.md
- 流程规范: docs/standards/process.md
## 决策记录（全文在 docs/adr/，此处只列 load-bearing 的）
- ADR-0001: adopt shipyard harness
## 共享背景
- 术语: CONTEXT.md ｜ 业务知识: docs/business/ ｜ 决策背景: docs/adr/
## Agent 指南
- 交付遵循 canonical 工作流 plan → execute → review → verify；`/oh-my-claudecode:launch` 是可选的受治理交付管道（opt-in，需要时显式调用）
- 术语冲突以 CONTEXT.md 为准；新术语当场补录
- 可复用能力沉淀到 .omc/skills/；UI 模式沉淀到 design-system/
种子 A —— zh-Hant 伴侣（结构一致，只渲染此版本）：
# <Project> — Agent & Human Shipyard
## 專案約定
- <language/framework/package manager/naming — list what matters, skip the rest>
## 架構原則
- <the 3-5 principles most often violated in this project>
## 規範索引（全文在 docs/standards/）
- 架構規範: docs/standards/architecture.md
- 資料規範: docs/standards/data.md
- 流程規範: docs/standards/process.md
## 決策記錄（全文在 docs/adr/，此處只列 load-bearing 項目）
- ADR-0001: adopt shipyard harness
## 共享背景
- 詞彙: CONTEXT.md ｜ 業務知識: docs/business/ ｜ 決策背景: docs/adr/
## Agent 指南
- 交付遵循 canonical 工作流 plan → execute → review → verify；`/oh-my-claudecode:launch` 是可選的治理交付管道（opt-in，必須明確呼叫）
- 術語衝突以 CONTEXT.md 為準；新術語確定時立即補錄
- 可重用能力沉澱到 .omc/skills/；UI 模式沉澱到 design-system/
种子 B —— CONTEXT.md（稳定的 frontmatter 键是语言权威）：
en：
---
documentLanguage: en
---
# Glossary
One entry per term: definition, boundaries, one resolved ambiguity. Agents write here the moment a term is settled. Vocabulary here is law for all specs, tickets, and code naming.
## <term>
- Definition:
- Boundary: (is X, not Y)
- Resolved ambiguity:
zh-Hans：
---
documentLanguage: zh-Hans
---
# 术语表
一条术语一个条目：定义、边界、一个已解决的歧义。术语敲定的当下写入。词汇对所有 spec、ticket、代码命名具有法律效力。
## <term>
- 定义:
- 边界: （是 X，不是 Y）
- 已解决的歧义:
zh-Hant：
---
documentLanguage: zh-Hant
---
# 詞彙表
每個術語一個條目：定義、邊界、一個已解決的歧義。術語確定時立即寫入。這裡的詞彙是所有 spec、ticket 與程式碼命名的準則。
## <term>
- 定義:
- 邊界: （是 X，不是 Y）
- 已解決的歧義:
种子 C —— docs/standards/architecture.md（data.md / process.md 形状相同；散文以文档语言渲染）：
# Architecture Standards
Rule-shaped, checkable writing; every rule carries a "why". Empty sections are legal — sediment is gradual.
## Module boundaries
## Error handling
## Dependency direction
种子 D —— docs/business/README.md：
# Business Knowledge
Decision background and business rules. Format suggestion: one article answers one business question, opening paragraph states why it matters.
A new teammate (human or agent) reading this directory should be able to answer "why does this product direction exist".
种子 E —— design-system/README.md：
# Design System
## tokens/ Design tokens (colors/type/spacing, machine-readable JSON preferred)
## components/ Component contracts (purpose, variants, misuse)
## patterns/ Interaction patterns (forms, feedback, loading, empty states — sediment reused patterns)
种子 F —— .omc/skills/README.md：
# Project Skills
Reusable capabilities sedimented by this project: specialized tools, prompt templates, specialized practices.
One skill per file `.omc/skills/<name>.md`, frontmatter must contain a stable ASCII `id` plus name + description +
**non-empty triggers** (loader validation hard requirement: missing or empty means the skill is never loaded):
```markdown
---
id: project-release-check
name: project-release-check
description: Apply this repository's release readiness rules
triggers:
- "project release check"
---
# Project Release Check
Follow the repository-specific release checklist and report evidence.
```
The literal YAML keys `id`, `name`, `description`, and `triggers` never localize. `id` and other machine-semantic values stay ASCII and stable; the scalar display values for `name`, `description`, and `triggers`, plus Markdown headings and prose, may localize. A non-Latin display name remains loadable because the explicit ASCII `id` is stable.
Bar for admission matches skillify: if it can be Googled in 5 minutes it is not a skill;
write "this project's specific decision discipline", not generic tutorials.
.mcp.json 种子：{"mcpServers": {}} —— 仅当实际需要工具集成时才添加服务器，而非投机性添加。
4. 连接治理循环（这才是使其成为 shipyard 而非文件夹的关键）
告知用户，并依赖以下流程来填充骨架：
- launch 在决策确定时写入 CONTEXT.md 词汇表、ADR 和 docs/business/（书面记录）
- launch C5 沉淀 / code-review 沉淀
…
[已截断以进行翻译]