drydock は何をしますか？
シップヤードのキールを敷く：1つのリポジトリに1つの共有ハーネス、すべてのコントリビューターがそれを継承する。このスキルは、「みんなが出荷する」を「みんなが同じデザイン言語で出荷する」に変える環境をスキャフォールディングします。5つのサーフェスを作成し、最小限のシードを植え、それらを埋めるフローに配線します（launch が CONTEXT/ADR を書き、launch C5 セディメントパスとレビューがセディメント基準をレビューします）。そして、何が存在しているか、何が作成されたか、何が意図的に空のままかを報告します。
4本柱とその物理的な配置場所：
| 柱 | サーフェス |
|---|---|
| コンテキスト（共有背景） | CONTEXT.md（用語集）+ docs/business/ + docs/adr/ + OMC wiki |
| ルール（境界） | CLAUDE.md（薄いエントリ：規約、原則、索引）+ docs/standards/ |
| ツール（構成可能な機能） | .omc/skills/ + .mcp.json + scripts/ |
| 標準（分類協会） | design-system/（トークン、コンポーネント、パターン）+ docs/standards/ |
メタファーマップ：シップヤードは共有施設であり、分類協会（docs/standards/ + design-system/）は船舶が航行可能であるために通過すべきルールを設定します。drydock がキールを敷き、launch が出荷します。
使用すべき場合
- 人間とエージェントの両方が構築するリポジトリを開始するとき
- 知識がファイルではなく、人の頭やチャット履歴にしかないリポジトリ
- オンボーディング：新しいチームメイトやエージェントが、聞くことなく読むことでコンテキストを継承すべきとき
使用すべきでない場合
- コラボレーターのいない使い捨てプロトタイプ
- すでにこのハーネスを実行しているリポジトリ（代わりに
--checkを使用）
ワークフロー
1. 検出（決して上書きしない）
何かを書き込む前に、存在するものをインベントリします：
CLAUDE.mdは存在するか？AGENTS.mdは存在するか？（ルール：どちらかが存在すれば、それをインプレースで拡張する；存在しない方を作成し、もう一方への1行ポインタとする；両方を新規作成してはいけない）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 スタイルのタグに正規化する：小文字の言語、Title-Case のスクリプト、大文字の地域。無効な明示的入力は、推測せずに一度尋ねること。
- それ以外の場合、
CONTEXT.mdの先頭にある YAML フロントマターからdocumentLanguageを読み取る。有効でスクリプトがあいまいでないタグは、新しい Drydock および Launch の呼び出しに対して権威を持つ。持続化されたタグがベアまたはリージョンのみの中国語である場合、この権威層で一度尋ねること；ソース推論でバイパスしてはいけない。 - マーカーが存在しないか無効な場合、正規のソースをこの順序で検査する：
CLAUDE.md、次にREADME.md。すべての使用可能なソースが1つの明確な支配的な言語を持ち、すべての使用可能なソースが同じ正規化されたタグに同意する場合にのみ推論する。もう一方が存在しないか空の場合、1つの明確なソースで十分である。 - 中国語は明示的なスクリプト修飾タグ（
zh-Hansまたはzh-Hant、オプションで地域が続く）に解決されなければならない。ベアのzhおよびリージョンのみの中国語タグはスクリプトがあいまいであり、コンパニオンを選択する代わりに一度尋ねること。コンパニオンの選択は最も長い言語/スクリプト接頭辞を使用する：zh-Hans-*はzh-Hansコンパニオンを選択し、zh-Hant-*はzh-Hantコンパニオンを選択する；完全な正規化タグ（例えばzh-Hans-CN）をCONTEXT.mdに保持する。 - 使用可能なソースがない、コンテンツが混在している、タグが競合している、信頼性の低い推論、無効な明示的入力、またはスクリプトがあいまいな中国語は、1回にまとめた言語質問をトリガーする。推測してはいけない。回答が利用できない場合、ローカライズされたアーティファクトを書き込む前に停止する。
- スキャフォールディングの前に、解決されたタグを
CONTEXT.mdの正確な安定フロントマターキーdocumentLanguageに書き込む（フロントマターを作成または拡張するが、キーは翻訳しない）。この可視ファイルが init レポートの言語権威である；デーモン、非表示の台帳、またはランタイム状態は作成されない。
プローズおよび人間向けのラベル/ローカライズ可能な値のみが選択された言語に従う；構造キーは言語安定を保つ。パス、スラッシュコマンド、フラグ、コードフェンス、プレースホルダー、フロントマターキーと機械意味値、YAML/JSON キー、ライフサイクルトークン、ステータス enum、ID、blockedBy、パブリック Team blocked_by、パーサー/コントロールトークンはバイト単位で安定に保つ。
残りの質問は、言語が解決された後にのみ尋ねる：
- パッケージ/テクノロジースタック（標準と design-system のシード用）
- このリポジトリに UI はあるか？（UI なし → design-system/ はメモ付きのスタブとして作成されるか、リクエストによりスキップされる）
- イシュートラッカーの場所（GitHub / GitLab / ローカルの
.scratch/）— V1 ハーバーインテークでは GitHub のみサポートされる；また、メンテナーのコミュニケーション権限をインテーク用に記録する（イシューコメント、ラベル変更）— ナビゲーターのマップホームとハーバーのインテークキューによって消費される
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 を解決した後、正確に1つのコンパニオンを選択する；別のコンパニオンからの重複する見出しやラベルを発行しない。最も長い言語/スクリプト接頭辞を使用する：en-* は英語を使用し、zh-Hans-* は簡体字中国語を使用し、zh-Hant-* は繁体字中国語を使用する。一方、シード B は解決された完全なタグを documentLanguage に書き込む。他の有効なタグについては、上記のすべての安定トークンを保持しながら、英語の正規コンパニオンを一度翻訳する。
シードのプローズを生成する前に、agent-doc-discipline スキルツールを呼び出し、そのルールを適用する；すべてのルールがチェック可能で「なぜ」を伴い、すべてのサーフェスがチャット履歴なしで自己記述的であり、ソースが想定ではなく名前指定されている場合にのみ、シードプローズは準備完了となる。チームメイトまたはエージェントは、読むだけでシードの内容に基づいて行動できるべきである。
シード A — CLAUDE.md、en（薄いエントリ；ファイルが存在する場合はインプレースで拡張）：
# <Project> — Agent & Human Shipyard
## プロジェクト規約
- <language/framework/package manager/naming — 重要なものをリストアップし、残りはスキップ>
## アーキテクチャ原則
- <このプロジェクトで最も頻繁に違反される3〜5の原則>
## 標準索引（全文は docs/standards/）
- アーキテクチャ: docs/standards/architecture.md
- データ: docs/standards/data.md
- プロセス: docs/standards/process.md
## 決定記録（全文は docs/adr/；ここでは負荷のかかるもののみリスト）
- ADR-0001: adopt shipyard harness
## 共有背景
- 用語集: CONTEXT.md ｜ ビジネス知識: docs/business/ ｜ 決定背景: docs/adr/
## エージェントガイド
- 配信は canonical ワークフロー plan → execute → review → verify に従う；`/oh-my-claudecode:launch` はオプションのガバナンス配信パイプライン（opt-in、明示的に呼び出す）
- 用語の競合では CONTEXT.md が優先される；新しい用語は確定した時点で記録する
- 再利用可能な機能は .omc/skills/ に、UI パターンは design-system/ に
シード A — zh-Hans コンパニオン（構造は同じ、ドキュメント言語に従って1つだけレンダリング）：
# <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（安定フロントマターキーが言語権威）：
en：
---
documentLanguage: en
---
# 用語集
用語ごとに1エントリ：定義、境界、1つの解決されたあいまいさ。エージェントは用語が確定した時点でここに書き込む。ここでの語彙は、すべての spec、ticket、およびコード命名に対して法的効力を持つ。
## <term>
- 定義：
- 境界：（X であり、Y ではない）
- 解決されたあいまいさ：
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 も同様の形状；プローズはドキュメント言語でレンダリングする）：
# アーキテクチャ標準
ルール形式で、チェック可能な記述；すべてのルールには「なぜ」が付随する。空のセクションは許容される — セディメントは段階的である。
## モジュール境界
## エラーハンドリング
## 依存関係の方向
シード D — docs/business/README.md：
# ビジネス知識
決定背景とビジネスルール。フォーマット提案：1つの記事が1つのビジネス質問に答え、冒頭の段落でその重要性を述べる。
このディレクトリを読んだ新しいチームメイト（人間またはエージェント）が、「なぜこのプロダクトの方向性が存在するのか」に答えられるべきである。
シード E — design-system/README.md：
# デザインシステム
## tokens/ デザイントークン（色/タイポグラフィ/間隔、機械可読な JSON 推奨）
## components/ コンポーネント契約（目的、バリアント、誤用）
## patterns/ インタラクションパターン（フォーム、フィードバック、ローディング、空の状態 — 再利用されたパターンをセディメント）
シード F — .omc/skills/README.md：
# プロジェクトスキル
このプロジェクトによって堆積された再利用可能な機能：専門ツール、プロンプトテンプレート、専門プラクティス。
1ファイル1スキル `.omc/skills/<name>.md`、フロントマターには安定した ASCII の `id` と name + description +
**空でない triggers** を含める必要がある（ローダー検証のハード要件：欠落または空はそのスキルが決してロードされないことを意味する）：
```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.
```
リテラル YAML キー `id`、`name`、`description`、および `triggers` はローカライズされない。`id` およびその他の機械意味値は ASCII で安定している；`name`、`description`、および `triggers` のスカラー表示値、ならびに Markdown 見出しとプローズはローカライズされ得る。非ラテン文字の表示名も、明示的な ASCII `id` が安定しているためロード可能である。
参入基準は skillify と同じ：5分で Google 検索できるものはスキルではない；
「このプロジェクト固有の決定規律」を書き、汎用チュートリアルは書かない。
.mcp.json シード：{"mcpServers": {}} — サーバーは、ツール統合が実際に必要になったときに追加され、投機的には追加されない。
4. ガバナンスループの配線（これが単なるフォルダではなくシップヤードにするもの）
ユーザーに伝え、以下のフローがスケルトンを満たすことに依存する：
- launch は決定が固まるにつれて CONTEXT.md 語彙、ADR、および docs/business/ を書き込む（証跡）
- launch C5 セディメント / code-review はセディメント基準と設計システムの標準をレビューする
- navigator は CLAUDE.md で索引付けされた標準マップを使用する
- harbor は CONTEXT.md で索引付けされた用語と背景を使用する
- カスタムスキル、MCP ツール、およびスクリプトは、体系化された機能のためにそれぞれのサーフェスに住む
5. レポート
要約を印刷：
🌊 Drydock complete — shipyard harness laid for <project>
─────────────────────────────────────────
Found surfaces:
✓ CLAUDE.md (extended)
✗ docs/adr/ → created
✗ docs/standards/ → created
✓ CONTEXT.md (created)
… (full inventory)
Remaining gaps (intentional — will be filled by launch flows):
- CONTEXT.md has no glossary entries yet
- docs/adr/ has only the harness ADR
- design-system/ has tokens/ stub (UI repo)
Next recommended step: run `/oh-my-claudecode:launch` or a code review to start sedimenting.
--check モード
drydock --check は書き込み操作を行わない。検出を実行し、整合性をチェックし、逸脱（存在すべきだが作成されなかったサーフェス、予期せず変更されたサーフェス、または紛失したサーフェス）を報告し、終了コード0（整合）または1（非整合）で終了する。これは CI パイプラインまたはプリフックで実行できる。