name: rule-making description: ユーザーから「ルール化してください」というリクエストがあった場合に使用するスキルです。ルールの内容に応じて適切な記載箇所を特定し、エージェントが参照できるようにします。

ルール化スキル

このスキルは、ユーザーから提示されたルールや規約を適切なドキュメントに記載し、GitHub Copilot Agentが参照できる状態にします。

利用可能なツール

view: ファイル内容の確認
edit: ファイル内容の編集
grep: ファイル内容の検索
bash: Git操作やビルド・テストの実行

使用すべきタイミング

以下の場合にこのスキルを使用してください:

ユーザーが「ルール化してください」とリクエストした場合
「これをルールにしたい」「今後はこうしてください」といった要望があった場合
プロジェクトの規約や方針として定めたい内容が提示された場合

実行手順

1. ルールの内容を分析

ユーザーから提示されたルールの内容を分析し、以下のカテゴリに分類します:

プロジェクトガイドライン: 開発方針、設計思想、重要な意思決定基準
Copilot固有の指示: Copilot Agentの動作、コミット形式、PRの書き方
コーディング規約: 言語固有のスタイル、命名規則、ベストプラクティス
運用ルール: デプロイ手順、レビュー基準、セキュリティ要件

2. 記載場所の特定

ルールのカテゴリに応じて、以下のドキュメントから適切な記載場所を特定します:

.github/copilot-instructions.md

対象: GitHub Copilot Agent固有の動作指示、プロジェクトガイドライン

記載セクション:

言語ポリシー - 日本語/英語の使い分け
コミットID提示のルール - コミットメッセージやリンク形式
変更時の確認手順 - ビルド、テスト、検証手順
ドキュメント配置の原則 - ドキュメント構造関連
Mermaid図の活用 - 図の作成方針
セキュリティ要件 - セキュリティ関連の指示
コスト最適化 - AWSコスト管理

追加時の注意:

Copilotが実行時に参照する内容であることを確認
具体的なコマンドや例を含める
既存のフォーマット（箇条書き、コードブロック）に従う

プロジェクト固有のドキュメント

対象: 特定の機能や領域に関するルール

docs/architecture/*.md - アーキテクチャ関連
docs/business/*.md - ビジネスルール関連
infrastructure/README.md - インフラ関連
.github/workflows/README.md - CI/CD関連

3. エージェントのアクセス性確認

ルールを記載した後、以下を確認します:

リンクの確認

# 記載場所のファイルから既存ドキュメントへのリンクを検索（bashツールを使用）
grep -n '\[.*\](.*\.md)' <記載場所のファイルパス>

参照可能性の確認

GitHub Copilot Agentが参照できる状態を確認:

copilot-instructions.md からの導線
- 重要なドキュメントへのリンクがあるか
- 「このドキュメントに記載された指示に加えて...」のセクションに含まれているか
メモリへの記録（必要に応じて）
- store_memory ツールで重要なルールを記録
- カテゴリ: general, file_specific, user_preferences
- 短い事実として記録（200字以内）

4. 記載内容の作成

ルールを既存のドキュメントフォーマットに従って記述します:

フォーマットのガイドライン

箇条書きを活用
- 可読性を高めるため、長文は避ける
- 重要なポイントを箇条書きで列挙
具体例を含める
- コマンド例、コード例を含める
- 「良い例」「悪い例」を示す
理由を明記
- なぜそのルールが必要かを説明
- Rationale や「理由」セクションを含める
Mermaid図の使用
- フローやプロセスを図で示す場合はMermaidを使用
- 複雑な構造は図で視覚化

5. 変更の検証

ルールを記載した後、以下を確認します:

# リンク切れチェック（bashツールを使用）
# 対象: 更新したドキュメント内のMarkdownリンク
grep '\[.*\](.*\.md)' <更新したファイルパス>

# Markdownフォーマットチェック（ヘッダー、リスト構造）
view <更新したファイルパス>

# 言語ポリシー準拠確認（日本語で記述されているか）
# 技術用語は英語で保持されているか

記載場所の判断フローチャート

graph TD
    A[ルール内容を分析] --> B{カテゴリは?}
    B -->|プロジェクトガイドライン| C[copilot-instructions.md]
    B -->|Copilot固有の動作| C
    B -->|特定機能のルール| F[対象ドキュメント]
    
    C --> G[適切なセクションを特定]
    F --> G
    
    G --> H[既存フォーマットに従って記述]
    H --> I[リンクと導線を確認]
    I --> J{エージェントから参照可能?}
    J -->|No| K[copilot-instructions.mdに追加]
    J -->|Yes| L[変更をコミット]
    K --> L

例

例1: コミットメッセージのルール化

ユーザー要望: 「コミットメッセージは必ず日本語で書いてください」とルール化してください

分析:

カテゴリ: Copilot固有の動作
記載場所: .github/copilot-instructions.md

手順:

copilot-instructions.md の「言語ポリシー」セクションを確認
既に記載があるか確認
なければ、日本語使用箇所に「コミットメッセージ」を追加
理由を記載（一貫性、チーム理解の容易さ）

例2: 開発原則のルール化

ユーザー要望: 「すべての機能は必ずテストを書いてください」をルール化してください

分析:

カテゴリ: プロジェクトガイドライン
記載場所: .github/copilot-instructions.md

手順:

copilot-instructions.md の適切なセクションを確認
テスト要件に関するセクションがあるか確認
なければ、新しいセクション「テスト要件」を追加
理由を記載（品質保証、リグレッション防止）

例3: AWS命名規則のルール化

ユーザー要望: 「AWS リソースには必ず attendance-kit- のプレフィックスを付けてください」をルール化してください

分析:

カテゴリ: インフラ関連の規約
記載場所: infrastructure/README.md または docs/architecture/aws-resources.md

手順:

インフラ関連ドキュメントを確認
適切なセクション（例: 命名規則）を探す
なければ新規セクションを作成
命名規則とその理由を記載
または docs/architecture/ に専用ドキュメントを作成（例: aws-naming-conventions.md）
インフラやアーキテクチャに関連する場合、copilot-instructions.md から参照可能にするか、docs/architecture/README.md に索引を追加

ベストプラクティス

ルールの記載時

重複を避ける
- 既存のルールを確認し、重複する内容は統合
- 複数箇所に同じ内容を書かない
具体性を持たせる
- 抽象的なルールではなく、実行可能な指示を記載
- コマンド例やコードサンプルを含める
理由を明記する
- なぜそのルールが必要かを説明
- チームの理解と納得を促進
メンテナンス性を考慮
- 変更が必要になった時に見つけやすい場所に記載
- ドキュメント間のリンクを適切に設定

エージェントのアクセス性向上

copilot-instructions.mdを起点にする
- 重要なルールは必ずcopilot-instructions.mdから辿れるようにする
- リンクまたは直接記載で参照可能にする
store_memoryの活用
- 頻繁に参照されるルールはメモリに記録
- エージェントのコンテキストに含まれやすくする
階層的な構造
- 概要はcopilot-instructions.md
- 詳細は個別のドキュメント
- リンクで接続

注意事項

影響範囲の確認: ルールの追加が既存の動作に影響しないか確認
チームへの周知: 重要なルール追加はPRで説明し、レビューを受ける
定期的な見直し: ルールが陳腐化していないか定期的に確認

参考資料

Copilotカスタムインストラクション: .github/copilot-instructions.md
GitHub Agent Skills: 公式ドキュメント

rule-making

SKILL.md