duck-adapt

スキルアダプター 🦆。外部スキルをアヒル哲学に変換します。

目的

外部スキルやワークフローを、意図を保ちながら次の要素を加えた、ラバーダックの原則に基づくバージョンに変換します。

• ソクラテス式の質問フロー
• 証拠を最優先する規律
• Duck Ladder による最小変更の考え方
• 実行承認ゲート
• プロンプト順序標準への準拠

既存の duck-* スキルも検証し、不要な重複を検出します。

哲学上のガードレール（スキル固有）

共有ガードレールは references/GUARDRAILS.md から引き継ぎます。

• コンテキストが不完全な場合は、焦点を絞った確認質問を1～3個します
• 証拠がない場合は、前提を明示します

スキル固有の追加事項：

• メタスキル：コードベースではなく、スキル定義を対象にします
• 出力は実装ではなく、スキルの草案です
• 重複が検出された場合は、スキルの却下を推奨します

有効化

次の場合に使用します。

• ユーザーが外部スキルを変換するために提示した場合
• ユーザーがスキルに変換するワークフローやプロセスを説明した場合
• ユーザーが既存スキルの哲学への準拠を監査するよう依頼した場合
• ユーザーが「このスキルを追加すべきか」または「これは重複しているか」と尋ねた場合

方法

1. インテークと分類

次の点を明らかにするため、確認質問を（最大3個）します。

外部スキルの変換の場合：

• 入力形式：スキルの Markdown 全文、ワークフロー文書、またはコンセプトの説明のどれですか？
• 意図：このスキルはどのような問題を解決しますか？
• 範囲：変更を伴う操作（編集／コマンド）ですか、それとも変更を伴わない操作（分析／アドバイス）ですか？
• 対象読者：ユーザーはどのようなコンテキストを想定していますか？

スキル監査の場合：

• 監査対象のスキルはどれですか？（名前またはパス）
• 監査の深さ：簡易な準拠チェックですか、それとも完全な重複分析ですか？

重複検出の場合：

• スキルのコンセプトの要約
• 想定されるワークフローの手順
• 既存スキルとの比較を依頼されていますか？

2. 証拠の収集

外部スキルの場合：

• 入力を解析し、手順、制約、出力、例を抽出します
• 意思決定ポイント（ユーザーの選択が重要となる箇所）を特定します
• 変更を伴う操作（承認ゲートが必要）を特定します
• 証拠の不足箇所（コード、差分、ログの確認が必要な箇所）を特定します

スキル監査の場合：

• .agents/skills/<name>/SKILL.md からスキルのソースを読み込みます
• 哲学上のガードレールに照らして確認します
• プロンプト順序標準（04-prompt-order-standard.md）に照らして確認します
• 変更を伴う操作に実行承認ゲートがあるか確認します
• アセット規約への準拠状況を確認します（07-skill-asset-convention.md）

重複検出の場合：

• .agents/skills/*/SKILL.md のフロントマターから既存スキルの概要を読み込みます
• 意図、範囲、ワークフローのパターンを比較します
• 意味上の重複と、相互補完的な組み合わせを特定します

3. 哲学のマッピング

哲学関連のアセットを読み込みます。

• assets/philosophy-core.md — ダック哲学の完全なリファレンス
• assets/socratic-patterns.md — 10 個の変換パターン（命令から質問へ、自動実行から承認へ、など）
• assets/approval-gate-spec.md — 6 ステップの実行承認仕様
• assets/adaptation-checklist.md — 包括的な変換チェックリスト

読み込んだパターンを使って、ラバーダック哲学に基づく変換を適用します。

意思決定の主体性：

• 意思決定の要所に、明確化するための質問を挿入します
• ユーザーの選択を明示します（「X を選びます」ではなく「どの選択肢にしますか？」）
• 推奨する前に、トレードオフを示します
• パターン：命令から質問へ（socratic-patterns.md #1）

証拠を優先：

• 結論を出す前に、証拠を収集する手順を追加します
• コードベースを読み取るパターン（定義／参照／呼び出し元／テスト）に対応付けます
• 主張を成果物に基づかせます
• パターン：ブラックボックスから証拠優先へ（socratic-patterns.md #3）

ダック・ラダー：

• 実装手順に、最小変更の原則を追加します
• 「新しいコードを追加する」手順の前に、6 段階のラダーによる確認を挿入します
• 症状へのパッチより、根本原因の修正を優先します
• パターン：複雑な手順からダック・ラダーへ（socratic-patterns.md #6）

実行承認：

• 変更を伴うすべてのアクション（編集、コマンド、タスクの委任）を特定します
• 6 ステップの承認ゲート（approval-gate-spec.md）を挿入します
• 事前確認（ファイル、動作、検証）を追加します
• スコープ変更の検出を追加します
• パターン：自動実行から承認ゲートへ（socratic-patterns.md #2）

ソクラテス式の流れ：

• 適切な場合、命令形の手順を質問形式の手順に変換します
• 前提を明らかにする手順を追加します
• 制約を見直す機会を追加します
• パターン：単一の選択肢から複数の選択肢へ（socratic-patterns.md #4）、指示から選択肢の提示へ（#8）

4. 構成の変換

プロンプトの順序に関する標準を適用します。

スキルのセクション（順序どおり）：

1. ## Purpose — 1 文で示す目的と主な変換内容
2. ## Philosophy Guardrails — 標準とスキル固有の差分を含めます
3. ## Activation — 使用するタイミングとユーザーのシグナル
4. ## Method — インラインの出力形式を含む番号付き手順
5. ## Boundaries — 制約、引き継ぎ、スコープの制限

アセットの特定：

• assets/ の候補：常に読み込むデータ（チェックリスト、テンプレート、マトリックス）
• references/ の候補：条件付きで参照するドキュメント（例、パターン、エッジケース）

フロントマター：

---
name: duck-<name>
description: >
  One-line purpose. Key capabilities. Use when: "signal phrases".
---

5. 重複分析

重複検出アセットを読み込みます。

• assets/overlap-patterns.md — 全 12 個のスキルの意図マップとスコアリングルール

読み込んだパターンを使って、既存のスキルと照合します。

重複スコアリング（overlap-patterns.md より）：

• 重複度が高い（意図の一致率が 70% 超）： 却下または統合を推奨します
• 重複度が中程度（40〜70%）： 既存スキルの拡張を提案します
• 重複度が低い（40% 未満）： 明確に異なる価値があれば、新しいスキルを作成できます
• 相補的： 新しいスキルではなく、組み合わせパターンを使います

危険信号（overlap-patterns.md より）：

• 自動実行（ユーザーの意思決定ポイントがない）
• 無断での実装（承認ゲートがない）
• ブラックボックスの助言（証拠に基づいていない）
• 安全策の回避（信頼境界／セキュリティを弱める）
• 高い重複度（90% 超）

組み合わせパターン（overlap-patterns.md より）：

• デバッグ→パッチ、レビュー→リスク→簡素化、設計→トリアージ、指導→デバッグ

6. 出力の生成

スキルの適応の場合：

ディレクトリ構造全体を出力します。

.agents/skills/duck-<name>/
├── SKILL.md (full skill definition)
├── assets/ (if always-loaded data needed)
│   └── <template/checklist>.md
├── references/ (if conditional docs needed)
│   └── EXAMPLES.md
└── evals/ (skeleton)
    └── evals.json

出力形式：

## 🦆 Skill Adaptation: duck-<name>

### Adaptation Overlap Analysis
- **Semantic overlap:** [None | Low | Medium | High] with [existing skills]
- **Recommendation:** [Add as new skill | Extend existing | Reject (use X instead) | Composition pattern]
- **Rationale:** [one-line justification]

### Philosophy Transformations Applied
- ✅ Decision ownership: [what changed]
- ✅ Evidence-first: [what changed]
- ✅ Duck Ladder: [what changed]
- ✅ Execution approval: [what changed]
- ✅ Socratic flow: [what changed]

### Skill Definition
[Full SKILL.md content]

### Assets (if any)
[Asset file contents with metadata headers]

### Next Steps
1. Review adaptation for intent preservation
2. Confirm overlap assessment
3. If approved: run `make build-skills` to generate artifacts

スキルの監査の場合：

## 🦆 Skill Audit: <skill-name>

### Compliance Check
- ✅/❌ Philosophy guardrails present
- ✅/❌ Prompt order standard followed
- ✅/❌ Execution approval gates on mutating actions
- ✅/❌ Asset convention compliance
- ✅/❌ Duck Ladder discipline included

### Findings
**High priority:**
- [H1] [issue description + fix suggestion]

**Medium priority:**
- [M1] [issue description + fix suggestion]

**Low priority:**
- [L1] [issue description + fix suggestion]

### Overlap Analysis
- Semantic overlap with: [other skills]
- Composition opportunities: [patterns]
- Redundancy risk: [None | Low | Medium | High]

### Audit Recommendations
[Prioritized list of changes or "No changes needed"]

重複検出の場合：

## 🦆 Overlap Analysis: <concept>

### Existing Coverage
- **Primary match:** [skill name] — [overlap %] — [why]
- **Secondary match:** [skill name] — [overlap %] — [why]

### Gap Analysis
- **Unique value:** [what this concept adds that existing skills don't cover]
- **Composition alternative:** [how existing skills could be chained instead]

### Recommendation
[Add new skill | Extend existing | Use composition | Not needed]

**Rationale:** [2-3 sentence justification]

境界

• 安全上の留保（信頼境界、セキュリティ、データ保護、アクセシビリティ）を弱めるスキルを生成しないでください
• 明示的な承認ゲートなしに、ユーザーが意思決定の主導権を持つことを自動化によって奪うスキルに適応させないでください
• 外部のスキル哲学が duck の原則とどうしても相容れない場合は、理由を添えて却下を推奨してください
• 重複の分析はあくまで参考情報です。スキルを追加するかどうかの最終判断はユーザーが行います
• 生成されたスキルはドラフトです。ユーザーが確認してからコミットします
• make build-skills を自動実行しないでください。承認後にユーザーが実行します

引き継ぎ：

• ユーザーが新しいスキルを承認した場合 -> 「アーティファクトを生成するには make build-skills を実行してください」
• 監査で問題が見つかった場合 -> 小規模な修正には duck-patch、再構成には duck-refactor の使用を提案してください
• 重複が多い場合 -> 明示的なワークフローを定めて既存のスキルを使用するよう提案してください