drydock

Was macht drydock?

Lege den Kiel der Werft: ein Repository, eine gemeinsame Umgebung, jeder Mitwirkende erbt sie. Dieser Skill richtet die Umgebung ein, die aus „jeder liefert aus“ „jeder liefert in derselben Designsprache aus“ macht – er erstellt die 5 Oberflächen, befüllt sie minimal, verdrahtet sie mit den Prozessen, die sie füllen (Launch schreibt CONTEXT/ADR; der Launch C5-Sedimentationsdurchlauf und Code-Review sedimentieren Standards) und berichtet, was existiert, was erstellt wurde und was absichtlich leer bleibt.

Die vier Säulen und wo sie physisch leben:

Säule	Oberflächen
Kontext (gemeinsamer Hintergrund)	CONTEXT.md (Glossar) + docs/business/ + docs/adr/ + OMC Wiki
Regeln (Grenzen)	CLAUDE.md (dünner Einstieg: Konventionen, Prinzipien, Index) + docs/standards/
Werkzeuge (zusammensetzbare Fähigkeiten)	.omc/skills/ + .mcp.json + scripts/
Standards (die Klassifikationsgesellschaft)	design-system/ (Tokens, Komponenten, Patterns) + docs/standards/

Metaphernkarte: die Werft ist die gemeinsame Einrichtung; die Klassifikationsgesellschaft (docs/standards/ + design-system/) legt die Regeln fest, die ein Schiff bestehen muss, um seetüchtig zu sein; drydock legt den Kiel; launch schifft es aus.

Wann verwenden

• Starten eines Repos, auf dem Menschen und Agenten gemeinsam aufbauen werden
• Ein Repo, in dem Wissen in den Köpfen der Leute und im Chatverlauf statt in Dateien lebt
• Onboarding: Ein neues Teammitglied oder ein neuer Agent soll Kontext durch Lesen erben, nicht durch Fragen

Wann nicht verwenden

• Wegwerfprototypen ohne Zusammenarbeit
• Ein Repo, das diese Umgebung bereits verwendet (stattdessen --check verwenden)

Arbeitsablauf

1. Erkennen (niemals überschreiben)

Bestandsaufnahme, was existiert, bevor etwas geschrieben wird:

• CLAUDE.md vorhanden? AGENTS.md vorhanden? (Regel: wenn eine von beiden existiert, diese erweitern; die fehlende als einzeiligen Verweis auf die andere erstellen; niemals beide frisch erstellen)
• CONTEXT.md, docs/adr/, docs/standards/, docs/business/, design-system/, .omc/skills/, .mcp.json, scripts/, .gitattributes — welche existieren, welche fehlen?
• OMC installiert? — nur prüfenswert, wenn innerhalb einer OMC-Sitzung ausgeführt; außerhalb diese Prüfung stillschweigend überspringen (die Umgebung funktioniert mit oder ohne OMC)

Zuerst die Karte melden, dann handeln.

2. Dokumentsprache auflösen, dann nur das fragen, was die Erkennung nicht beantworten kann

Die Dokumentsprache für die generierten Umgebungsdateien ist eine dateibasierte Entscheidung, kein Gesprächszustand. Verwende genau diesen Vertrag:

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

Auflösungsreihenfolge:

1. Eine explizite menschliche Wahl im aktuellen Aufruf gewinnt, wenn sie gültig ist. Normalisiere sie zu einem stabilen BCP-47-ähnlichen Tag: Kleinbuchstaben für Sprache, Title-Case für Schrift, Großbuchstaben für Region. Ungültige explizite Eingabe muss einmal nachgefragt werden, anstatt geraten zu werden.
2. Andernfalls lies documentLanguage aus dem YAML-Frontmatter am Anfang von CONTEXT.md. Ein gültiger, schrift-eindeutiger Tag ist maßgeblich für frische Drydock- und Launch-Aufrufe. Wenn der persistierte Tag ein bloßes oder regionsreines Chinesisch ist, frage einmal auf dieser Autoritätsebene nach; umgehe sie niemals durch Quelleninferenz.
3. Wenn das Merkmal fehlt oder ungültig ist, inspiziere kanonische Quellen in dieser Reihenfolge: CLAUDE.md, dann README.md. Schließe nur, wenn jede verwendbare Quelle genau eine eindeutige dominante Sprache hat und alle verwendbaren Quellen demselben normalisierten Tag zustimmen. Eine eindeutige Quelle ist ausreichend, wenn die andere fehlt oder leer ist.
4. Chinesisch muss zu einem expliziten schriftqualifizierten Tag aufgelöst werden: zh-Hans oder zh-Hant (optional gefolgt von einer Region). Bloßes zh und regionsreine chinesische Tags sind schriftmehrdeutig und müssen einmal nachgefragt werden, anstatt einen Begleittext auszuwählen. Die Begleittextauswahl verwendet das längste Sprach-/Schriftpräfix: zh-Hans-* wählt den zh-Hans-Begleittext aus und zh-Hant-* wählt zh-Hant; den vollständigen normalisierten Tag (z.B. zh-Hans-CN) in CONTEXT.md beibehalten.
5. Fehlende verwendbare Quellen, mehrsprachiger Inhalt, widersprüchliche Tags, Inferenz mit geringem Vertrauen, ungültige explizite Eingabe oder schriftmehrdeutiges Chinesisch müssen eine einzige gebündelte Sprachfrage auslösen. Nicht raten. Wenn keine Antwort verfügbar ist, anhalten, bevor lokalisierte Artefakte geschrieben werden.
6. Vor dem Gerüstbau den aufgelösten Tag in den exakten stabilen Frontmatter-Schlüssel documentLanguage in CONTEXT.md schreiben (Frontmatter erstellen oder erweitern, ohne den Schlüssel zu übersetzen). Diese sichtbare Datei ist die Sprachautorität des Init-Berichts; es wird kein Dämon, verstecktes Hauptbuch oder Laufzeitzustand erstellt.

Nur Prosa und menschenlesbare Bezeichnungen/lokalisierbare Werte folgen der ausgewählten Sprache; strukturelle Schlüssel bleiben sprachstabil. Pfade, Schrägstrichbefehle, Flags, Code-Fences, Platzhalter, Frontmatter-Schlüssel und maschinensemantische Werte, YAML/JSON-Schlüssel, Lebenszyklus-Tokens, Status-Enums, IDs, blockedBy, öffentliches Team blocked_by sowie Parser-/Steuerungs-Tokens bleiben bytegenau stabil.

Die restlichen Fragen erst nach der Sprachauflösung stellen:

• Paket-/Technologie-Stack (für Standards und Designsystem-Vorlagen)
• Hat dieses Repo eine Benutzeroberfläche? (keine UI → design-system/ wird als Platzhalter mit einem Hinweis erstellt oder auf Wunsch übersprungen)
• Issue-Tracker-Standort (GitHub / GitLab / lokal .scratch/) — für V1-Werfteinlass wird nur GitHub unterstützt; auch die Kommunikationsautorität des Maintainers für den Einlass erfassen (Issue-Kommentare, Label-Änderungen) — vom Navigator und der Einlass-Warteschlange der Werft verwendet

3. Gerüst bauen (fehlende Oberflächen erstellen — Vorlagen in der Dokumentsprache rendern)

CLAUDE.md                      # dünner Einstieg — siehe Vorlage A
CONTEXT.md                     # Glossar — siehe Vorlage B
.gitattributes                 # * text=auto eol=lf  (unterdrückt CRLF-Warnungen unter Windows)
docs/adr/0001-adopt-shipyard-harness.md
docs/standards/architecture.md # Vorlage C
docs/standards/data.md
docs/standards/process.md
docs/business/README.md        # Vorlage D
design-system/README.md        # Vorlage E (nur UI-Repos; sonst Platzhalter)
design-system/tokens/README.md
.omc/skills/README.md          # Vorlage F
.mcp.json                      # {"mcpServers": {}}
scripts/README.md

Vorlagenbeispiele sind Referenz-Begleittexte, niemals eine kombinierte Lieferung. Wähle genau einen Begleittext nach Auflösung von documentLanguage aus; gib keine doppelten Überschriften oder Bezeichnungen aus einem anderen Begleittext aus. Verwende das längste passende Sprach-/Schriftpräfix: en-* verwendet Englisch, zh-Hans-* verwendet vereinfachtes Chinesisch und zh-Hant-* verwendet traditionelles Chinesisch, während Vorlage B den vollständig aufgelösten Tag in documentLanguage schreibt. Übersetze für jeden anderen gültigen Tag den englischen kanonischen Begleittext einmal, während jeder stabile Token oben erhalten bleibt.

Rufe vor dem Generieren der Vorlagenprosa das Skill-Tool mit agent-doc-discipline auf und wende seine Regeln an; Vorlagenprosa ist erst fertig, wenn jede Regel überprüfbar ist und ein „Warum“ trägt, jede Oberfläche sich selbst beschreibt, ohne Chatverlauf, und Quellen benannt statt angenommen werden. Ein Teammitglied oder Agent sollte in der Lage sein, allein durch Lesen auf die Inhalte der Vorlage zu reagieren.

Vorlage A — CLAUDE.md, en (dünner Einstieg; in Place erweitern, wenn die Datei existiert):

# <Project> — Agent & Human Shipyard

## Projektkonventionen
- <language/framework/package manager/naming — list what matters, skip the rest>

## Architekturprinzipien
- <die 3-5 Prinzipien, die in diesem Projekt am häufigsten verletzt werden>

## Normenindex (Volltext in docs/standards/)
- Architektur: docs/standards/architecture.md
- Daten: docs/standards/data.md
- Prozess: docs/standards/process.md

## Entscheidungsaufzeichnungen (Volltext in docs/adr/; tragende hier aufgeführt)
- ADR-0001: adopt shipyard harness

## Gemeinsamer Hintergrund
- Glossar: CONTEXT.md ｜ Geschäftswissen: docs/business/ ｜ Entscheidungskontext: docs/adr/

## Agenten-Leitfaden
- Die Auslieferung folgt dem kanonischen Workflow plan → execute → review → verify; `/oh-my-claudecode:launch` ist eine optionale, gesteuerte Auslieferungspipeline (opt-in, explizit aufrufen)
- Bei Begriffskonflikten gewinnt CONTEXT.md; neue Begriffe werden aufgezeichnet, sobald sie feststehen
- Wiederverwendbare Fähigkeiten gehen in .omc/skills/; UI-Muster gehen in design-system/

Vorlage A — zh-Hans-Begleittext (Struktur identisch, nach Dokumentsprache wählen):

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

Vorlage A — zh-Hant-Begleittext (Struktur identisch, nur diese Version rendern):

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

Vorlage B — CONTEXT.md (der stabile Frontmatter-Schlüssel ist die Sprachautorität):

en:

---
documentLanguage: en
---

# Glossar

Ein Eintrag pro Begriff: Definition, Grenzen, eine aufgelöste Mehrdeutigkeit. Agenten schreiben hier, sobald ein Begriff festgelegt ist. Das Vokabular hier ist Gesetz für alle Spezifikationen, Tickets und Code-Benennungen.

## <term>
- Definition:
- Grenze: (ist X, nicht Y)
- Aufgelöste Mehrdeutigkeit:

zh-Hans:

---
documentLanguage: zh-Hans
---

# 术语表

一条术语一个条目：定义、边界、一个已解决的歧义。术语敲定的当下写入。词汇对所有 spec、ticket、代码命名具有法律效力。

## <term>
- 定义:
- 边界: （是 X，不是 Y）
- 已解决的歧义:

zh-Hant:

---
documentLanguage: zh-Hant
---

# 詞彙表

每個術語一個條目：定義、邊界、一個已解決的歧義。術語確定時立即寫入。這裡的詞彙是所有 spec、ticket 與程式碼命名的準則。

## <term>
- 定義:
- 邊界: （是 X，不是 Y）
- 已解決的歧義:

Vorlage C — docs/standards/architecture.md (data.md / process.md gleiche Form; Prosa in der Dokumentsprache rendern):

# Architekturstandards

Regelgeförmtes, überprüfbares Schreiben; jede Regel trägt ein „Warum“. Leere Abschnitte sind zulässig — Sedimentation erfolgt schrittweise.

## Modulgrenzen
## Fehlerbehandlung
## Abhängigkeitsrichtung

Vorlage D — docs/business/README.md:

# Geschäftswissen

Entscheidungshintergrund und Geschäftsregeln. Formatvorschlag: Ein Artikel beantwortet eine Geschäftsfrage, der Eröffnungsabsatz erklärt, warum es wichtig ist. Ein neues Teammitglied (Mensch oder Agent), das dieses Verzeichnis liest, sollte die Frage beantworten können: „Warum existiert diese Produktrichtung?“

Vorlage E — design-system/README.md:

# Designsystem

## tokens/    Design-Tokens (Farben/Schrift/Abstände, maschinenlesbares JSON bevorzugt)
## components/ Komponentenverträge (Zweck, Varianten, Missbrauch)
## patterns/  Interaktionsmuster (Formulare, Feedback, Laden, Leerzustände — sedimentierte, wiederverwendete Muster)

Vorlage F — .omc/skills/README.md:

# Projekt-Fähigkeiten

Wiederverwendbare Fähigkeiten, die von diesem Projekt sedimentiert wurden: spezialisierte Werkzeuge, Prompt-Vorlagen, spezialisierte Praktiken. Eine Fähigkeit pro Datei `.omc/skills/<name>.md`, Frontmatter muss eine stabile ASCII `id` plus name + description + **nicht leere triggers** enthalten (Loader-Validierung: fehlende oder leere triggers bedeuten, dass die Fähigkeit nie geladen wird):

```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.
```
Die literalen YAML-Schlüssel `id`, `name`, `description` und `triggers` werden nie lokalisiert. `id` und andere maschinensemantische Werte bleiben ASCII und stabil; die skalaren Anzeigewerte für `name`, `description` und `triggers` sowie Markdown-Überschriften und Prosa können lokalisiert werden. Ein nicht-lateinischer Anzeigename bleibt ladbar, da die explizite ASCII `id` stabil ist. Die Aufnahmeschwelle entspricht skillify: Wenn es in 5 Minuten gegoogelt werden kann, ist es keine Fähigkeit; schreibe „die spezifische Entscheidungsdisziplin dieses Projekts“, keine generischen Tutorials.

.mcp.json-Vorlage: {"mcpServers": {}} — Server werden hinzugefügt, wenn eine Werkzeugintegration tatsächlich benötigt wird, nicht spekulativ.

4. Den Governance-Kreislauf verdrahten (das macht es zu einer Werft, nicht zu einem Ordner)

Teile dem Benutzer mit und verlasse dich auf diese Prozesse, um das Skelett zu füllen:

• launch schreibt CONTEXT.md-Vokabular, ADRs und docs/business/, sobald Entscheidungen getroffen werden (Papierpfad)
• launch C5-Sedimentation / Code-Review sedimentieren Standards (docs/standards/) und Designs (design-system/), sobald Muster auftauchen

5. Bericht (was existiert, was erstellt, was bewusst leer gelassen)

Statusbericht der Werftumgebung:
  Erkannt: CLAUDE.md (vorhanden, erweitert) · CONTEXT.md (erstellt) · docs/adr/ (erstellt mit 1 ADR) · docs/standards/ (erstellt) · docs/business/ (erstellt) · design-system/ (Platzhalter, keine UI) · .omc/skills/ (erstellt) · .mcp.json (erstellt) · scripts/ (erstellt)
  Absichtlich leer: design-system/components/ · .omc/skills/<fähigkeit>.md (keine Fähigkeiten sedimentiert) · .mcp.json (keine Server benötigt)
  Verwendete Sprache: de

--check (Abweichungsprüfung, keine Erstellung)

Führe den Erkennungsschritt aus, aber überschreibe nichts. Gib einen Abweichungsbericht aus:

+ FEHLT: docs/standards/data.md
  IST:   docs/standards/data.md (vorhanden, vollständig)
- ABWEICHUNG: .gitattributes fehlt (* text=auto eol=lf)
  HINWEIS: design-system/tokens/README.md (optional, fehlt, aber Repo hat keine UI)

Exit-Code 0, wenn vollständig und keine Abweichungen; Exit-Code 1, wenn etwas fehlt oder nicht übereinstimmt.

Verwandte Skills

• oh-my-claudecode:launch (die Auslieferungspipeline; schreibt die Entscheidungen, die drydocks Oberflächen füllen)
• oh-my-claudecode:harbor (der Auslieferungs-Eingang; liest das issue-tracker-Feld, das drydock setzt)
• skillify (die Aufnahmeschwelle für .omc/skills/)