onboard

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

自動化モード：modes.automation を解決します（project.local.yaml → project.yaml → デフォルトの collaborative）。すべての AskUserQuestion 呼び出しと すべてのファイル書き込みは、.claude/docs/automation-modes.md （collaborative は常に質問 · guided は主要な項目のみ質問 · autonomous は記録して続行； automation_always_ask カテゴリは常に質問）に従います。

オンボーディング

入力が不十分な場合 — レポートを作成する前に確認してください

このスキルに必要な入力が存在しない場合、回答は「実行できません」です — 記入済みのレポートではありません。 最初に確認し、確認に失敗した場合は停止してください。

1. このスキルが読み取る入力（データファイル、過去のレポート、プロファイラーの出力、 テスト結果、レジストリ、ソースコード）を一覧にします。
2. それぞれについて「存在すると仮定」ではなく、FOUND または ABSENT を記録します。
3. セクションに必要な入力が1つでも ABSENT の場合、そのセクションは NOT ASSESSED — NO DATA です。推定したり、隣接する成果物から推論したり、 次にテンプレートを読む人が記入するよう必須項目を空欄にしたりしないでください。
4. 必要な入力がすべて ABSENT の場合は、停止して、 不足していたものと、それを生成するスキルを明記したうえで、全体の判定として NOT ASSESSED — NO DATA を報告します。

NOT ASSESSED という判定は成功です。 データがないときに「データは何を示していますか？」と尋ねられた場合の、正しく有用な回答です。これによって防げる失敗の形は明確です。判定の列挙値に「実行できません」の状態がないレポートは、 誤った合格判定を生みます。たとえば、アセットも基準もないプロジェクトのアセット監査が COMPLIANT を返したり、プロファイラーデータがなく予算も設定されていないのに、パフォーマンスプロファイルが「16.67ms の予算に対して 99% 超の余裕あり」と報告したりするケースです。

証拠がないことは、存在しない証拠にはなりません。 スキャン対象のファイルがないために一致が見つからなかったスキャンは、何も検証していません。どちらの状況だったのかを明記してください。緑色の結果だけでは、読み手には区別できません。

---

フェーズ 1：プロジェクトのコンテキストを読み込む

プロジェクトの概要と基準を把握するため、CLAUDE.md を読みます。

特定の役割が指定されている場合は、.claude/agents/ から該当するエージェント定義を読みます。

CLAUDE.md と .claude/agents/ はフレームワークに含まれており、スキルによって作成されるものではありません。どちらかが存在しない場合は、インストール時に欠落しているものとして報告します。

---

フェーズ 2：関連領域をスキャンする

• プログラマーの場合：アーキテクチャ、パターン、主要ファイルを把握するため、コードルート（.claude/docs/code-root-resolution.md に従って解決）をスキャンします。ルートを解決できない場合、スキャンは実行されていません。その情報を使うセクションには推測で src/ を指定せず、NOT ASSESSED — code root unresolved と記載します
• デザイナーの場合：既存のデザイン文書を探すため、design/ をスキャンします
• ナラティブ担当の場合：世界観設定とストーリーの文書を探すため、design/narrative/ をスキャンします
• QA の場合：既存のテストカバレッジを探すため、tests/ をスキャンします（/test-setup が作成します）
• プロダクション担当の場合：現在のスプリントとマイルストーンを確認するため、production/ をスキャンします
• 役割も領域も指定されていない場合：全般的な概要として、design/、 docs/architecture/、production/、コードルートの最上位を一覧表示し、 存在する場合は production/session-state/active.md を読みます。また、次回の確認では役割を指定すると焦点を絞れることを伝えます（例：/onboard programmer）

最近の変更（利用できる場合は git log）を読み、現在の進捗状況を把握します。

---

フェーズ 3：オンボーディング文書を作成する

# Onboarding: [Role/Area]

## Project Summary
[2-3 sentence summary of what this game is and its current state]

## Your Role
[What this role does on this project, key responsibilities, who you report to]

## Project Architecture
[Relevant architectural overview for this role]

### Key Directories
| Directory | Contents | Your Interaction |
|-----------|----------|-----------------|

### Key Files
| File | Purpose | Read Priority |
|------|---------|--------------|

## Current Standards and Conventions
[Summary of conventions relevant to this role from CLAUDE.md and agent definition]

## Current State of Your Area
[What has been built, what is in progress, what is planned next. Name what
Phase 2 found by path — for a designer, each existing GDD and design doc — or
say it found none]

## Current Sprint Context
[What the team is working on now and what is expected of this role]

## Key Dependencies
[What other roles/systems this role interacts with most]

## Common Pitfalls
[Things that trip up new contributors in this area]

## First Tasks
[Suggested first tasks to get oriented and productive]

1. [Read these documents first]
2. [Review this code/content]
3. [Start with this small task]

## Questions to Ask
[Questions the new contributor should ask to get fully oriented]

---

フェーズ 4：文書を保存する

オンボーディング文書をユーザーに提示します。

「これを production/onboarding/onboard-[role]-[date].md に書き込んでもよいですか？」と尋ねます。

許可された場合は、必要に応じてディレクトリを作成してファイルを書き込みます。

---

フェーズ 5：次のステップ

判定：COMPLETE — オンボーディング文書を生成しました。

• 新しい貢献者の初回セッション前に、オンボーディング文書を共有します。
• /sprint-status を実行して、新しい貢献者に現在の進捗状況を示します。
• 次に何に取り組むべきか、新しい貢献者が案内を必要としている場合は /help を実行します。