/drydock

name: drydock
description: Lay the keel of the shipyard harness in any repo — the 4-pillar shared environment (Context, Rules, Tools, Standards), seeded as two faces on day one (CLAUDE.md + GLOSSARY.md) with every other surface appearing on first use, so that every human and agent inherits the same design language and anyone can ship. Run once per repo; re-run with --check to audit drift.
argument-hint: "[--check]"
level: 3

Drydock

Lay the keel of the **shipyard**: one repo, one shared harness, every contributor inherits it. This skill seeds exactly two faces (CLAUDE.md and GLOSSARY.md), with a read-once migration for recognizable legacy glossary CONTEXT.md files, and defines the first-use moment when every other surface appears. It wires the flows that fill them (launch writes GLOSSARY.md vocabulary and decision records; launch C5 sediment and reviews sediment standards) and reports what was seeded, what is deferred and why, and what was skipped on purpose.

The four pillars and where they physically live:

| Pillar | Surfaces | |---|---| | Context (shared background) | `GLOSSARY.md` (glossary) + `docs/business/` + `docs/adr/` + OMC wiki | | Rules (boundaries) | `CLAUDE.md` (thin entry: conventions, principles, index) + `docs/standards/` | | Tools (composable capability) | `.omc/skills/` + `.mcp.json` + `scripts/` | | Standards (the classification society) | `design-system/` (tokens, components, patterns) + `docs/standards/` |

Metaphor map: the shipyard is the shared facility; the classification society (`docs/standards/` + `design-system/`) sets the rules a ship must pass to be seaworthy; drydock lays the keel; launch ships it.

When to Use

• starting a repo that humans and agents will both build on
• a repo where knowledge lives in people's heads and chat history instead of files
• onboarding: a new teammate or agent should inherit context by reading, not by asking

When Not to Use

• throwaway prototypes with no collaborators
• a repo already running this harness (use `--check` instead)

Workflow

1. Detect (never clobber)

Inventory what exists before writing anything:

• `CLAUDE.md` present? `AGENTS.md` present? (rule: if either exists, extend it in place; create the missing one as a one-line pointer to the other; **never create both fresh**)
• `GLOSSARY.md` (or a recognizable legacy glossary `CONTEXT.md`), `docs/adr/`, `docs/standards/`, `docs/business/`, `design-system/`, `.omc/skills/`, `.mcp.json`, `scripts/`, `.gitattributes` — which exist (adopted — their integrity is audited), which are absent (not adopted — each gets its first-use trigger below, never a speculative creation)?
• OMC installed? — only worth checking when running inside an OMC session; outside one, skip this check silently (the harness works with or without OMC)

Report the map first, then act.

2. Resolve document language, then ask only what detection cannot answer

The document language for the generated harness files is a file-backed decision, not conversation state. Use this contract exactly:

<!-- shipyard-document-language-contract:start -->

{
  "schemaVersion": 1,
  "authority": { "path": "GLOSSARY.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": [
    "GLOSSARY.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>"
  ]
}

<!-- shipyard-document-language-contract:end -->

Legacy glossary migration (full runs only; `--check` never renames or rewrites anything and just audits the legacy file in place): a `CONTEXT.md` is a legacy glossary only when its YAML frontmatter carries a `documentLanguage` key or its first visible non-blank line (after the frontmatter, ignoring a BOM and HTML comments) is a drydock glossary seed heading (`Glossary`, `术语表`, `詞彙表` — seeds that predate the language tag); any other `CONTEXT.md` is an unrelated agent-context document and is left alone. If the yard has a legacy glossary `CONTEXT.md` but no `GLOSSARY.md`, rename it to `GLOSSARY.md` (`git mv` when tracked) before resolving the language or scaffolding anything, preserving its content and frontmatter byte-for-byte. Never create a fresh `GLOSSARY.md` beside a legacy glossary `CONTEXT.md`; one yard has exactly one glossary authority. An unrelated `CONTEXT.md` does not block creating `GLOSSARY.md` and is never reported for removal. If both `GLOSSARY.md` and a legacy glossary `CONTEXT.md` exist, `GLOSSARY.md` is authoritative and the leftover `CONTEXT.md` is reported for the human to merge or remove.

**CLAUDE.md rewrite during migration**: Whenever `GLOSSARY.md` is the glossary authority (after the rename above, and also when `GLOSSARY.md` and a legacy glossary `CONTEXT.md` both exist), rewrite legacy `CLAUDE.md` references such as `Glossary: CONTEXT.md` or `On term conflicts CONTEXT.md wins` to `GLOSSARY.md`, so installed instructions never point at a file that is renamed or about to be removed. The rewrite belongs to the migration, not the scaffold step.

Resolution order:

1. An explicit human choice in the current invocation wins when valid. Normalize it to a stable BCP-47-style tag: lowercase language, Title-Case script, uppercase region. Invalid explicit input must be asked once rather than guessed. 2. Otherwise, read `documentLanguage` from the YAML frontmatter at the top of `GLOSSARY.md`. A valid, script-unambiguous tag is authoritative for fresh Drydo