drydock

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>"
  ]
}

解決の優先順位：

1. 現在の実行で明示された人間による選択が有効な場合は、それを優先します。安定した BCP-47 形式のタグ（言語は小文字、スクリプトは先頭大文字、地域は大文字）に正規化します。明示的な入力が無効な場合は、推測せずに一度だけ尋ねます。
2. それ以外の場合は、CONTEXT.md の先頭にある YAML フロントマターから documentLanguage を読み取ります。有効でスクリプトが曖昧でないタグは、新しい Drydock と Launch の実行において確定値となります。保存済みのタグが言語のみ、または地域のみの中国語の場合は、この優先順位で一度だけ尋ねます。ソースからの推定でこれを回避してはいけません。
3. マーカーが存在しない、または無効な場合は、正規ソースを次の順序で調べます。CLAUDE.md、次に README.md。使用可能なすべてのソースで、曖昧さのない優勢な言語が一つだけであり、かつ使用可能なすべてのソースで正規化後のタグが一致する場合に限り推定します。もう一方のソースが存在しない、または空の場合は、曖昧さのないソースが一つあれば十分です。
4. 中国語は、スクリプトを明示したタグ zh-Hans または zh-Hant（地域を続けてもかまいません）に解決する必要があります。言語のみの zh と地域のみの中国語タグはスクリプトが曖昧なため、対応するタグを選ぶのではなく、一度だけ尋ねる必要があります。対応するタグの選択には最長の言語／スクリプトのプレフィックスを使います。zh-Hans-* は zh-Hans の対応タグを選び、zh-Hant-* は zh-Hant の対応タグを選びます。完全な正規化タグ（例：zh-Hans-CN）は CONTEXT.md に保持してください。
5. 使用可能なソースがない、内容が複数言語にわたる、タグが競合する、推定の確信度が低い、明示的な入力が無効、中国語のスクリプトが曖昧、のいずれかに該当する場合は、言語についてまとめて一度質問する必要があります。推測してはいけません。回答が得られない場合は、ローカライズされた成果物を書き込む前に停止します。
6. 足場を作成する前に、解決したタグを CONTEXT.md の固定フロントマターキー documentLanguage に書き込みます（フロントマターがない場合は作成し、ある場合は拡張します。キーは翻訳しません）。この表示可能なファイルが、初期化レポートにおける言語の確定元です。デーモン、隠し台帳、ランタイム状態は作成しません。

翻訳対象となるのは、文章と人間向けのラベル／ローカライズ可能な値のみです。構造キーは言語に依存しない状態に保ちます。パス、スラッシュコマンド、フラグ、コードフェンス、プレースホルダー、フロントマターキー、機械的な意味を持つ値、YAML／JSON キー、ライフサイクルトークン、ステータス列挙値、ID、blockedBy、公開 Team の blocked_by、パーサー／制御トークンは、バイト単位で変更しないでください。

言語が解決されてから、残りの質問のみを尋ねます。

• パッケージ／技術スタック（標準とデザインシステムの初期データ用）
• このリポジトリに UI があるか（UI がない場合は、注記付きのスタブとして design-system/ を作成するか、希望に応じて作成を省略します）
• イシュートラッカーの場所（GitHub／GitLab／ローカルの .scratch/）— V1 の harbor 受付でサポートされるのは GitHub のみです。また、受付でメンテナーが行う連絡の権限（イシューコメント、ラベル変更）も記録します。これは navigator の map home と harbor の受付キューで使用されます。

3. スキャフォールド（不足している面を作成 — シードはドキュメントの言語で描画されます）

CLAUDE.md                      # thin entry — see seed A
CONTEXT.md                     # glossary — see seed B
.gitattributes                 # * text=auto eol=lf  (kills CRLF warning noise on Windows)
docs/adr/0001-adopt-shipyard-harness.md
docs/standards/architecture.md # seed C
docs/standards/data.md
docs/standards/process.md
docs/business/README.md        # seed D
design-system/README.md        # seed E (UI repos only; stub otherwise)
design-system/tokens/README.md
.omc/skills/README.md          # seed F
.mcp.json                      # {"mcpServers": {}}
scripts/README.md

シードの例は参照用の補助資料であり、結合したペイロードではありません。documentLanguageを解決した後、補助資料を必ず1つだけ選択してください。別の補助資料から見出しやラベルを重複して出力しないでください。最長一致する言語／スクリプトのプレフィックスを使用します。en-*は英語、zh-Hans-*は簡体字中国語、zh-Hant-*は繁体字中国語を使用し、Seed Bでは解決済みの完全なタグをdocumentLanguageに記述します。それ以外の有効なタグの場合は、すべての固定トークンを保持しながら、英語の標準版を1度だけ翻訳してください。

シードの文章を生成する前に、Skill ツールをagent-doc-disciplineで呼び出し、そのルールを適用してください。すべてのルールが確認可能で、各ルールに理由が付され、すべての面がチャット履歴なしでも自己完結しており、情報源が推測ではなく明記されている場合にのみ、シードの文章は完成です。チームメイトやエージェントが、読むだけでシードの内容に基づいて行動できる必要があります。

Seed 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/

Seed 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/

Seed 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/

Seed B — CONTEXT.md（安定したフロントマターキーが言語を決定します）：

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. Ship-specific terms only: a concept any sea chart carries does not get an entry.

## <term>
- Definition:
- Boundary: (is X, not Y)
- Avoid: (near-synonyms this ship does not use)
- Resolved ambiguity:

zh-Hans：

---
documentLanguage: zh-Hans
---

# 术语表

一条术语一个条目：定义、边界、一个已解决的歧义。术语敲定的当下写入。词汇对所有 spec、ticket、代码命名具有法律效力。只收本船特有的词；海图上都有的通用词不立条目。

## <term>
- 定义:
- 边界: （是 X，不是 Y）
- 禁用: （本船不用的近义词）
- 已解决的歧义:

zh-Hant：

---
documentLanguage: zh-Hant
---

# 詞彙表

每個術語一個條目：定義、邊界、一個已解決的歧義。術語確定時立即寫入。這裡的詞彙是所有 spec、ticket 與程式碼命名的準則。只收本船特有的詞；海圖上都有的通用詞不立條目。

## <term>
- 定義:
- 邊界: （是 X，不是 Y）
- 禁用: （本船不用的近義詞）
- 已解決的歧義:

Seed C — docs/standards/architecture.md（data.mdも同じ形式です。process.mdではTestingボリュームもシードします。Seed C2を参照してください。文章はドキュメントの言語で描画されます）：

# Architecture Standards

Rule-shaped, checkable writing; every rule carries a "why". Empty sections are legal — sediment is gradual.

## Module boundaries
## Error handling
## Dependency direction
## Seams and depth

- A seam is a real boundary two modules already cross in both directions. One adapter is a hypothetical seam; two adapters make it real. (Checkable: count the callers. Why: speculative abstraction is a tax paid before the need exists.)
- A deep module puts much behavior behind a small interface; deepen before widening. (Why: the interface is the permanent tax.)
- Logic lives behind the seam that owns its data; stable dependencies point inward. (Why: logic that reaches across a boundary it does not own couples every caller to the wrong neighbor.)

Seed C2 — docs/standards/process.md、Testingボリューム（リポジトリでコードをテストする場合に描画されます。文章はドキュメントの言語で描画されます）：

## Testing

- Tests enter through the interface only: assert observable behavior at the seam. Reaching past the seam — querying the store directly, reading internal state — is false confidence. (Why: a test that survives refactors describes behavior, not plumbing.)
- Expected values come from an independent source of truth: a known-good literal or a worked example from the spec. (Why: a test that recomputes its expectation the way the code does can never disagree with the code.)
- One slice at a time: one failing test, one minimal implementation, repeat. Bulk-writing all tests first tests the imagination, not the behavior. (Why: the loop is a feedback engine; batching cuts the feedback.)
- Refactoring happens at the review axis, not inside the red-green loop. (Why: the loop answers "is the behavior right"; mixing redesign in hides regressions.)
- Tests open only at seams the reviewing captain approved. (Why: unapproved seams spend effort where the risk is not.)

Seed 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".

Seed 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)

Seed 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": {}} — サーバーは、ツール連携が実際に必要になったときに追加します。推測で追加することはありません。

破壊的操作のガードレールプリセット。 要望に応じて、drydockは破壊的なGit操作（push、force-push、hard reset、clean、ブランチ削除）を明示的な承認のもとでのみ実行できるようにするフックプリセットをシードします。これは通常の、確認・監査可能なリポジトリ設定としてインストールされます（リポジトリが読み取って監査できるフックエントリであり、エージェントハーネスのsettings hooksやgit pre-push hookなど、リポジトリの他のフックと同じ場所に置かれます）。隠れた強制レイヤーとしてインストールされることはありません。ルールはレポートに記載され、エントリの削除は人間が明示的に行います。このプリセットが保護するのは配置済みのハーネスであり、エージェントではありません。誤ってエージェントセッションがリポジトリの履歴を消し去ることはありません。シードの形式：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": "<confirm-before-destructive-git>",
        "description": "Block push, force-push, reset --hard, clean, and branch -D behind explicit approval"
      }
    ]
  }
}

マッチャーとコマンドには、リポジトリ独自のフック機構を選択します。drydockがシードするのは形式とルール一覧であり、確認コマンドはToolsピラー（scripts/）に置かれ、リポジトリが読み取って監査できます。

コミット時の品質ゲートプリセット。 要望に応じて、drydockはコミットが確定する前にリポジトリ独自のチェック（lint、typecheck、テストスイート）を実行するコミット時フックプリセットもシードします。各チェックは、リポジトリにすでにあるエントリーポイント（Toolsピラーのscripts/や、パッケージマネージャーの標準コマンド）に接続します。ガードレールプリセットと同じ形式の通常の、確認・監査可能なリポジトリ設定であり、レポートに記載され、人間が明示的に操作した場合にのみ削除できます。ゲートには、リポジトリに既存のチェックをコミット境界に接続して使います。drydockが独自のチェッカーを追加することはありません。また、確立済みのチェックコマンドがないリポジトリでは、コマンドを人間が指定できる状態でスキャフォールドを用意します。

4. ガバナンスループを組み込む（これにより、単なるフォルダーではなく造船所になります）

ユーザーに伝え、次のフローで骨組みを埋めてもらいます。

• launch は、決定が固まるたびに CONTEXT.md の用語、ADR、docs/business/ を記録します（経緯を残します）。
• launch C5 sediment / code-review は、繰り返し発生する修正を docs/standards/ と CLAUDE.md の原則に反映します。
• 誰でも .omc/skills/ にプロジェクトスキルを追加できます。障壁となるのは権限ではなく、skillify の品質ゲートです。
• wiki（OMC）はセッションの知識を蓄積します。2 回参照されたものはすべて docs/business/ に昇格させます。

先に動くことを整合させるルールは次のとおりです。着手に許可は不要ですが、着地先は造船所のスロットに入れます。 どのスロットに着地するのか（または、明示的にスロットなし）を示せない変更は要注意です。

5. 報告

• 作成／拡張／意図的にスキップしたもの（それぞれ理由も記載）
• 解決したドキュメントの言語を CONTEXT.md のフロントマター documentLanguage: <tag> として記載し、明示的な選択、保存済みのマーカー、全員一致の推定のどれに基づくかも含めます。
• 次に人手で内容を補う必要性が最も高い 3 つの領域（通常は CLAUDE.md の規約、architecture.md、CONTEXT.md の最初の用語）
• リマインダー：ファイルシステムとハーネスのずれを確認するには、いつでも --check を再実行してください。

--check モード

実際のリポジトリの状態と造船所マップを比較し、不足している領域、CONTEXT.md フロントマターの documentLanguage タグの欠落または無効、存在しないパスを指す CLAUDE.md のセクション、コード内で使われていない CONTEXT.md の用語、参照されていない標準を報告します。指摘ごとに、確信度（機械的に確認できる場合は high、ヒューリスティックな場合は low）と、ユーザーが明示的に使い捨て／スクラッチリポジトリと宣言したものを除外したうえで対応可能かどうかを示します。Launch の造船所ゲートでは、確信度が高く対応可能な指摘はブロッキングとして扱います。確信度が低い指摘、明示的に誤検出と分類された指摘、およびユーザーがスクラッチ／使い捨ての対象範囲と宣言した範囲内の指摘は、意図的な呼び出しごとの指定がある場合に限り上書きできます（/oh-my-claudecode:launch を参照）。/oh-my-claudecode:ask-navigator でも、不確かな取り組みの進路を定める際に、この監査を報告のみのモードで実行できます。指摘はマップの Notes にそのまま記録され（決して取り込まれずに消えることはありません）、Launch の造船所ゲートでは有効な指摘として扱われます。

構造化された終了契約。 この監査の機械的に確認できる部分は実行可能です。node scripts/shipyard-audit.mjs [repoRoot] は確信度の高い項目のみを確認します。対象は、不足している領域、documentLanguage タグの欠落／無効、CLAUDE.md 内の存在しないパス、プロジェクトスキルのトリガーの有無、文書化された語彙に含まれる意図ステータスです。lookout CLI と同じ指摘語彙で、安定した指摘 ID、根拠、助言とともに、severity（high/medium/low/info）、confidence（high/low）、actionable を stdout に JSON で出力し、人間向けの要約を stderr に出力します。終了コード 0 = 問題なし、1 = 確信度が高く対応可能な指摘あり、2 = 呼び出しエラーです。ヒューリスティックな項目（コード内で使われていない用語、参照されていない標準）は意図的にこの説明文の範囲にとどめます。これらは構造上 low の確信度であり、スクリプトが機械的に検証できない指摘を作り出すことはありません。読み取り専用です。