drydock은(는) 무엇을 하나요?
조선소의 용골을 놓습니다: 하나의 리포지토리, 하나의 공유 하네스, 모든 기여자가 이를 상속합니다. 이 스킬은 '모두가 출시한다'를 '모두가 동일한 디자인 언어로 출시한다'로 바꾸는 환경을 구축합니다. 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/ |
비유 지도: 조선소는 공유 시설입니다. 분류 학회(docs/standards/ + design-system/)는 선박이 항해에 적합하려면 통과해야 하는 규칙을 설정합니다. drydock은 용골을 놓고, launch는 선박을 출시합니다.
사용 시기
- 인간과 에이전트가 함께 작업할 리포지토리를 시작할 때
- 지식이 파일이 아닌 사람들의 머리와 채팅 기록에 있는 리포지토리
- 온보딩: 새 팀원이나 에이전트가 질문하지 않고 읽어서 컨텍스트를 상속해야 할 때
사용하지 않을 때
- 협력자가 없는 임시 프로토타입
- 이미 이 하네스를 실행 중인 리포지토리 (
--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>"
]
}
해결 순서:
- 현재 호출에서 명시적인 인간의 선택이 유효하면 우선합니다. 소문자 언어, Title-Case 스크립트, 대문자 지역의 안정적인 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 하버 인테이크의 경우 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를 해결한 후 정확히 하나의 동반자를 선택하십시오. 다른 동반자에서 중복된 제목이나 레이블을 내보내지 마십시오. 가장 긴 일치하는 언어/스크립트 접두사를 사용하십시오: en-*는 영어, zh-Hans-*는 간체 중국어, zh-Hant-*는 번체 중국어를 사용하는 반면, 시드 B는 전체 해결된 태그를 documentLanguage에 씁니다. 다른 유효한 태그의 경우 위의 모든 안정적인 토큰을 보존하면서 영어 정식 동반자를 한 번 번역하십시오.
시드 산문을 생성하기 전에 agent-doc-discipline Skill 도구를 호출하고 해당 규칙을 적용하십시오. 모든 규칙이 확인 가능하고 '이유'를 가지며, 모든 표면이 채팅 기록 없이 자체 설명적이며, 소스가 가정되지 않고 명명된 경우에만 시드 산문이 준비됩니다. 팀원이나 에이전트는 읽기만으로 시드의 내용에 대해 행동할 수 있어야 합니다.
시드 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/
## 에이전트 가이드
- 전달은 정식 워크플로 plan → execute → review → verify를 따릅니다. `/oh-my-claudecode:launch`는 선택적 관리 전달 파이프라인입니다(opt-in, 명시적으로 호출)
- 용어 충돌 시 CONTEXT.md가 우선합니다. 새 용어는 결정되는 즉시 기록됩니다.
- 재사용 가능한 기능은 .omc/skills/에 퇴적합니다. UI 패턴은 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
---
# 용어집
용어당 하나의 항목: 정의, 경계, 하나의 해결된 모호성. 에이전트는 용어가 결정되는 즉시 여기에 씁니다. 여기의 어휘는 모든 스펙, 티켓 및 코드 명명에 대한 법칙입니다.
## <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:
# 비즈니스 지식
결정 배경 및 비즈니스 규칙. 형식 제안: 하나의 게시물이 하나의 비즈니스 질문에 답하고, 시작 단락은 그것이 왜 중요한지 설명합니다.
이 디렉토리를 읽는 새 팀원(인간 또는 에이전트)은 '이 제품 방향이 왜 존재하는지'에 답할 수 있어야 합니다.
시드 E — design-system/README.md:
# 디자인 시스템
## tokens/ 디자인 토큰 (색상/글꼴/간격, 기계 판독 가능 JSON 선호)
## components/ 컴포넌트 계약 (목적, 변형, 오용)
## patterns/ 상호작용 패턴 (양식, 피드백, 로딩, 빈 상태 — 재사용된 패턴 퇴적)
시드 F — .omc/skills/README.md:
# 프로젝트 스킬
이 프로젝트에 의해 퇴적된 재사용 가능한 기능: 특수 도구, 프롬프트 템플릿, 특수 관행.
파일당 하나의 스킬 `.omc/skills/<name>.md`, frontmatter는 안정적인 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분 안에 구글링할 수 있으면 스킬이 아닙니다. 일반적인 튜토리얼이 아닌 '이 프로젝트의 특정 결정 규율'을 작성하십시오.
.mcp.json 시드: {"mcpServers": {}} — 서버는 추측이 아닌 도구 통합이 실제로 필요할 때 추가됩니다.
4. 거버넌스 루프 연결 (이것이 폴더가 아닌 조선소가 되게 하는 것입니다)
사용자에게 알리고 다음 흐름이 골격을 채우도록 합니다:
- launch는 결정이 확정됨에 따라 CONTEXT.md 어휘, ADR 및 docs/business/를 씁니다(종이 기록)
- launch C5 퇴적 / 코드 리뷰는 docs/standards/에 퇴적합니다.
…
[번역을 위해 잘림]