Agent-Skills.md

Agent Skills: Suggest Agent Rules

Suggest agent rules analyzing the session history and the current repository.

UncategorizedID: dotneet/claude-code-marketplace/suggest-agent-rules

Install this agent skill to your local

pnpm dlx add-skill https://github.com/dotneet/claude-code-marketplace/tree/HEAD/agent-session/skills/suggest-agent-rules

Skill Files

Browse the full folder contents for suggest-agent-rules.

Download Skill

Loading file tree…

agent-session/skills/suggest-agent-rules/SKILL.md

Skill Metadata

Name
suggest-agent-rules
Description
Suggest agent rules analyzing the session history and the current repository.

Suggest Agent Rules

あなたは「このリポジトリ専用のCoding Agentルール」を設計するテックリードです。 以下の情報を根拠に、エージェントが将来の作業で迷わず高品質に動けるよう、実務的で検証可能なルールを提案してください。

セッション情報へのアクセス

セッションファイルの場所

| Agent | Path | File Format | |-------|------|-------------| | Claude Code | ~/.claude/projects/<project-path-encoded>/ | <UUID>.jsonl | | Codex CLI | ~/.codex/sessions/YYYY/MM/DD/ | rollout-<datetime>-<UUID>.jsonl |

プロジェクトパスのエンコード: /Users/username/projects/myapp → -Users-username-projects-myapp

提供ツール

このスキルでは以下のツールを利用できます（tools/ディレクトリ参照）:

  1. list-sessions.sh - セッション一覧を取得

    ./tools/list-sessions.sh -p /path/to/project -n 10

  2. analyze-session.sh - 単一セッションを詳細分析

    ./tools/analyze-session.sh <session-file> --all

    オプション: --summary, --user-messages, --tools, --errors, --preferences

  3. extract-patterns.sh - 複数セッションからパターンを抽出

    ./tools/extract-patterns.sh -p /path/to/project -n 5

セッションデータ構造の詳細

詳細は references/session-structure.md を参照。主要なポイント:

  • Claude Code: parentUuid/uuidで会話ツリーを構築、typeフィールドでuser/assistantを判別
  • message.content: thinking, text, tool_use, tool_resultのブロックを含む
  • サブエージェント: <session-uuid>/subagents/agent-<id>.jsonlに保存、isSidechain: true

セッション解析で抽出すべき情報

  1. ユーザーの明示的な指示・好み - 「必ず〜」「〜しないで」などのパターン
  2. 繰り返し発生した手戻り - エラー→修正の連続パターン
  3. よく使用されるツールとファイル - 作業パターンの把握
  4. エラーパターン - tool_resultでのエラー応答

利用できる情報源（優先順）

  1. Agentのセッション履歴（直近の指示・好み・繰り返し発生した手戻り・決定事項）
    • 上記ツールを使用してセッションデータを分析
  2. 現在のリポジトリの内容（README/CONTRIBUTING/ディレクトリ構造/設定ファイル/CI設定/テスト構成）
  3. ローカルGit履歴（コミットメッセージ規約・変更頻度の高い領域・リバート/ホットフィックス傾向）
  4. GitHub履歴（PR/Issue/レビューコメントの傾向、指摘が多い論点、CI落ちパターン）
    • gh が使えるなら gh pr list/view, gh issue list/view 等を用いて良い
    • 使えない場合はローカルで取れる範囲（git log等）で推定し、不確実性を明示する

ゴール

  • “一般論”ではなく このリポジトリ固有の ルールにする
  • ルールは「守れば成果が上がる」ものだけに絞り、過剰に増やさない
  • すべてのルールに 根拠 と 確認方法（verify） を付ける
  • 不明点は断定せず、最小の追加調査で確かめる手順を添える

作業手順（必ずこの順で）

1) リポジトリ概観の把握

  • 主要言語/フレームワーク/ビルドツール/パッケージマネージャを推定
  • ルート直下、README / CONTRIBUTING / CODEOWNERS / Makefile / package.json / pyproject.toml / go.mod / Cargo.toml / .github/workflows 等を優先して確認
  • 既に「ルール」「コーディング規約」「レビュー観点」があるならそれを最優先で尊重（重複ルールは作らない）

2) 失敗パターン・手戻りパターンの抽出

  • セッション履歴：繰り返し注意された点、好み（例：テスト先行、差分最小、ログ方針、命名規約）を抽出
  • Git/PR/レビュー：同じ種類の指摘が複数回出る領域を優先（lint、境界条件、例外、型、N+1、依存更新、Migration等）

3) “エージェント向け”に翻訳してルール化

  • 人間向け規約を、エージェントが実行できる行動（Do/Don’t）へ落とす
  • ルールは次のいずれかに分類する：
    • 安全（破壊的操作・秘密情報・本番影響）
    • 変更方針（差分最小、リファクタ範囲、互換性、移行）
    • 品質（テスト、静的解析、型、例外、境界条件）
    • リポジトリ慣習（命名、ディレクトリ、レイヤー、依存、ログ）
    • PR運用（粒度、説明、チェックリスト、レビュー対応）

4) ルールの優先度付け

  • 最重要（Must）: 破ると事故/大幅手戻りになる
  • 重要（Should）: 品質や速度に効く
  • 任意（Could）: 余裕がある時に

出力フォーマット（厳守）

以下の順番でMarkdownを出力してください。

A. リポジトリの前提（短く）

  • 推定スタック / 実行すべき基本コマンド（分かる範囲）
  • CIの主要チェック（分かる範囲）
  • 不明点（あれば）

B. 観測された傾向（箇条書き・最大10個）

  • セッション履歴由来 / Git由来 / PRレビュー由来 を区別して書く

C. 提案ルール（最大12個、優先度順）

各ルールは必ず次のテンプレで書く：

  • [Priority: Must/Should/Could] ルール名（短く）
    • Rule:（エージェントが取るべき行動を命令形で。曖昧語を避ける）
    • Why (evidence):（観測された根拠。ファイル名/設定/レビュー傾向など。推測なら推測と明記）
    • Verify:（実行コマンド、見るべきファイル、CIで確認、再現手順のいずれか）
    • Scope:（常に/特定条件のとき。例：DB変更時、API変更時、依存更新時）
    • Confidence:（High/Medium/Low）

D. “貼り付け用”の最終ルール本文

  • .claude/agent-rules.md 等に貼れる体裁で、Cのルールを簡潔版に再掲する
  • 余計な解説は入れず、Do/Don’t中心にする

制約・禁止事項

  • リポジトリで確認できないコマンドや規約を断定しない（例：存在しない npm test を推奨しない）
  • 破壊的操作（reset/force push/大量削除/マイグレーション適用等）は “事前確認ルール” を必ず含める
  • 秘密情報（鍵、トークン、顧客情報）を出力しない。ログや設定値を貼る場合はマスキングする
  • ルール数は増やしすぎない（最大12）。必要なら「次点ルール（Optional）」として別枠にする

Usage

このSkillは次のタイミングで使う：

  • 初回オンボーディング時
  • レビュー指摘が増えたとき
  • リファクタや大規模移行の前
  • CI/運用ルールが変わったとき

実行後、出力の「貼り付け用ルール本文」をリポジトリの所定ファイルに反映して運用する。