AgentSkillsCN

ai-led-onboarding

生成 AI 开始与人类协作时的入职引导。AI 不再扮演“讲解员”角色，而是作为“推进者”，推动探索→假设→验证→总结→明确未确定事项的过程，使人类能够在短时间内重建最小化模型（因果、边界、不变条件、破坏方式、观测）。 触发条件： - 在开始新任务或修改代码之前（“修复这个功能”、“解决这个Bug”） - 需要理解未知的代码库时 - “进行入职引导”、“做好工作准备”、“理解代码” - 在开始复杂任务前需要理解上下文时 - “制定作战简报”、“确保安全开始”

SKILL.md
--- frontmatter
name: ai-led-onboarding
context: fork
description: |
  生成AIが人間に対して行う作業開始時オンボーディング。AIが"説明係"ではなく"進行役"として、探索→仮説→検証→要約→未確定の明示を回し、人間が最小スキーマ（因果・境界・不変条件・壊れ方・観測）を短時間で再構築できる状態に導く。

  トリガー条件:
  - 新しいタスクやコード変更に着手する前（「この機能を修正して」「このバグを直して」）
  - 未知のコードベースを理解する必要がある時
  - 「オンボーディングして」「作業開始の準備をして」「コードを理解したい」
  - 複雑なタスクを始める前の文脈理解が必要な時
  - 「作戦ブリーフを作成して」「安全に始められるようにして」

AI-Led Onboarding

作業開始時に人間が「全部を知る」のではなく、意思決定が破綻しないだけの最小スキーマを短時間で再構築できる状態に導く。

合格条件（Onboarding Done）

オンボーディングが完了した状態とは、人間が以下6点を自力で説明できる（または根拠リンク付きでAIが提示し、人間が納得できる）状態:

#項目内容
1目的この作業で何を成立させたいか（何が"成功"か）
2境界どこを触り、どこは触らないか（責務と依存の境界）
3不変条件壊してはいけない条件（最大3つに圧縮）
4壊れ方仮説起きやすい/致命的/気づきにくい の3種
5観測・検証壊れたらどこで検知し、着手前に何を確かめるか
6未確定リストまだ分かっていないことと、その解消手段

この6点が揃うとスキーマが立つ。大量のドキュメントを読んでも6点が揃っていなければ理解は成立していない。

ワークフロー

code
1. 契約確立 → 2. 意図抽出 → 3. 入口発見 → 4. 境界マップ → 5. 不変条件 → 6. 壊れ方仮説 → 7. 検証計画 → 8. 理解確認 → 9. ブリーフ生成

Step 1: オンボーディング契約の確立

オンボーディングを"雑談"ではなく"検査工程"として成立させる。

AIがやること:

  • •合格条件（上記6点）を宣言し、タイムボックス（10〜15分）を固定
  • •「根拠がない断言をしない」「不確実性は明示する」を先に約束

人間から受け取る最小入力:

  • •タスクの目的（1〜2文）
  • •触る予定の入口（ファイル/クラス/関数名が1つでも）
  • •参照してほしいドキュメント（あればリンク/ID）

Step 2: タスク意図の抽出

コード理解に入る前に「何のために触るのか」を固定。

AIがやること:

  • •目的・成功条件・制約（期限、互換性、性能、セキュリティ）を短問で引き出す
  • •"要求"と"解決策"を分離して書き直す

出力:

  • •目的（1文）
  • •成功条件（最大3項目、可能なら数値）
  • •制約（最大5項目）

Step 3: ソース・オブ・トゥルース選別

参照優先度を決め、誤誘導を避ける。

AIがやること:

  • •参照優先度を明文化（例：仕様・設計→コード→テスト→運用ログ）
  • •ドキュメントの更新日・対象バージョンを確認し「古い可能性」を明示
  • •"意図（should）"と"現状（is）"を分けて記述

出力:

  • •正本候補のリスト（最大3）と各信頼度
  • •ドリフト（ズレ）の疑い点

Step 4: 入口発見

AIがやること:

  • •変更対象に近い"起点"を特定（エントリポイント、UseCase、Controller等）
  • •「読む順番」を提示（最大5ステップ）

Step 5: 境界マップ作成

AIがやること:

  • •対象モジュールの責務・依存先・外部I/F・副作用を列挙
  • •"触るべき境界"と"触らない境界"を区別

出力:

yaml
boundary_map:
  in: 何が入力か
  out: 何が出力か（副作用含む）
  depends: 依存（DB/外部API/他モジュール）
  owns: 自分が保証すること

Step 6: 不変条件の抽出

AIがやること:

  • •ドキュメント/テスト/コードから不変条件を候補として抽出
  • •今回の作業に関係が深いものを3つまでに圧縮
  • •各不変条件に「破ったときの症状」を添える

Step 7: 壊れ方仮説生成

AIがやること: 壊れ方を3種類に分類して提示:

  1. •起きやすい: 頻繁に発生しうる失敗パターン
  2. •致命的: 発生すると重大な影響がある失敗
  3. •気づきにくい: 検出が遅れやすい失敗

各壊れ方に「検知手段（テスト/ログ/メトリクス）」を1つ以上添える。

Step 8: 着手前の最小検証計画

AIがやること:

  • •15〜30分以内でできる検証を設計
    • •既存テストの実行範囲
    • •代表入力での挙動確認
    • •主要ログの確認
  • •"何が起きたら仮説を捨てるか"を明文化（反証条件）

Step 9: 人間の理解確認（問い返しテスト）

AIがやること:

  • •人間に対して、合格条件に対応する短問を投げる
  • •人間が詰まった箇所を"未知リスト"へ移し、検証計画に接続

Step 10: 作戦ブリーフ生成

合格条件の6点を1〜2画面にまとめる。詳細は references/briefing-template.md を参照。

ガードレール（絶対禁止事項）

  1. •根拠なしの断言をしない: 断言するならコード・テスト・ドキュメントの参照を必須に
  2. •不確実性を隠さない: 分からないことは未知リストへ送る
  3. •長文で安心させない: 長文は注意を散らす。簡潔に
  4. •"正しい設計"を押し付けない: まず境界・不変条件・壊れ方を確定し、設計提案は後段に
  5. •ドキュメント＝真実を前提にしない: DocDDでもドリフトは起こりうる。検証計画が必須

詳細は references/guardrails.md を参照。

スキル詳細

各ステップの詳細な実行方法と品質チェックは references/skills-catalog.md を参照。

使用例

code
User: src/auth/login.ts のバグを修正したい

Claude:
オンボーディングを開始します。

## オンボーディング契約
- 目標: 作業開始に必要な最小スキーマ（目的・境界・不変条件・壊れ方・観測・未確定）を10〜15分で構築
- 約束: 根拠のない断言はしません。不確実な点は明示します

## 確認させてください
1. このバグの具体的な症状は？（何が期待と異なるか）
2. 修正後の成功条件は？（どうなれば完了か）
3. 参照すべきドキュメントやIssueはありますか？

[回答を受けて、Step 2以降を進行...]