コードベース全体のレビュー・監査。perf/sec/test/arch/cq/docs の6観点を並列委譲し、優先度付き issue ファイルと観点サマリをメモリディレクトリに生成する。コードベース全体の監査・定期レビュー・リリース前品質確認の依頼時、/codebase-review 実行時に使用。境界: PR 単位は pr-review、自ブランチの提出前確認は self-review。
instructions-audit
CLAUDE.md / AGENTS.md・skills・context・rules 等の指示ファイルの静的監査。指示ファイルの「レビューして」「監査して」「スリム化して」等の依頼時、/instructions-audit 実行時に使用。
rubric で削除候補・hook/deny 移管・skill 化/Read-when 化・description 強化の4分類の指摘を修正案付きで出す。user-level と project-level 両対応。
境界: 指摘の適用や個別追記は update-inst、セッション知見の反映は update-inst の retro モード、コードの監査は codebase-review。
含まれるファイル(1)
- SKILL.md5.4 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Instructions Audit
指示ファイル(CLAUDE.md / skills / context / rules / settings.jsonのガード設定)を @context/claude-customization-guide.mdのrubric(§7)で監査し、4分類の指摘を修正案付きで報告する。このスキルは指摘のみを行い、修正はユーザー承認後に別途実施する(read-only)。
使い方
/instructions-audit # 自動判定(./CLAUDE.md or ./.claude があればproject、なければuser)
/instructions-audit --user # user-level(~/.claude/)を監査
/instructions-audit --project # project-level(./CLAUDE.md, ./.claude/)を監査
/instructions-audit <path> # 指定ディレクトリを監査
既存設定との関係
- rubricの真実源: @context/claude-customization-guide.md §7(本スキルはrubricを重複記載しない)
- Phase 0-5(@context/workflow-rules.md): 独立(監査は単発タスク。指摘の適用が複雑タスク化する場合のみPhase 0-5を適用する)
ワークフロー
Step 1: 対象決定
引数から監査スコープを確定する。
- 完了基準: 監査対象のルートパスと、監査対象ファイル群(CLAUDE.md / context/ / skills/ / rules/ / settings.json)のリストが確定している。user-levelの実体は
~/.claude/AGENTS.md(CLAUDE.mdは互換symlink。修正提案の編集対象は実体側にする)
Step 2: インベントリ作成
対象の全指示ファイルを列挙し、規模を把握する:
- CLAUDE.mdと、そこから
@importされるファイルを再帰的に辿る(@importは毎セッション常駐のため、常駐行数はimport先を全て合算して計算する) skills/*/SKILL.mdの一覧・各行数・frontmatter(description長、allowed-tools有無)・references/の有無context/・rules/の一覧と行数、どこから参照されているか(@import / プレーンパス / 未参照)settings.jsonのhooks / permissions.deny・allow
- 完了基準: 「常駐合計行数」「skill数とdescription合計」「未参照ファイル一覧」が数値で出ている
Step 3: rubric適用(監査本体)
@context/claude-customization-guide.mdの§7 rubric(4分類)と§1-5の原則を対象に適用する。
対象が大きい場合(合計500行超)はサブエージェントに委譲する(コンテキスト保護。分割例: CLAUDE.md+context系 / skills系)。経路はAgent tool: 委譲先は指摘をleadに返すだけでファイルを書かない(報告のファイル生成はユーザーが求めた場合のみleadが行う)ため、委譲の既定であるherdr paneに当たらない(@context/herdr-delegation.md「経路の選択」)。サブエージェントへの指示に含めること:
-
監査rubricとしてclaude-customization-guide.mdを読むこと
-
指摘ごとに「対象ファイル:行」「4分類のどれか」「根拠となる原則(§番号)」「具体的な修正案」を返すこと
-
下記Gotchasを遵守すること
-
完了基準: 全対象ファイルが監査済みで、各指摘に分類・根拠・修正案が揃っている
Step 4: 報告
以下の構成で報告する(ファイル生成はユーザーが求めた場合のみ):
- サマリ: 常駐行数・skill数・指摘件数(分類別)
- 指摘一覧: 4分類ごとに、影響の大きい順。各指摘は「対象 / 内容 / 根拠原則 / 修正案(diffまたは書き換え文)」
- 適用の提案: どの指摘から適用すべきかの推奨順。適用はユーザー承認後(個別の適用は
/update-instスキルを実行する)
- 完了基準: ユーザーが各指摘にyes/noで判断できる粒度になっている
Gotchas(監査時の誤指摘防止)
- @importは毎セッション常駐(必要時ロードではない)。常駐行数の計算はimport再帰を含める
- allowed-toolsは事前承認であって制限ではない。「セキュリティのため制限せよ」という指摘は誤り。read-only skillへの指摘は「事前承認の欠如(permission prompt増)」として出し、実際の制限が必要な場合のみdisallowed-tools/denyを提案する
- コミュニティ由来の数値(行数上限等)を規範として指摘しない。目安として提示し、公式原則(「消したら間違えるか」)を判断基準にする
- 重複に見える記述が意図的な場合がある(冒頭・末尾への重要ルール再掲等)。削除提案時は意図の可能性を添える
- 監査対象に本スキルやclaude-customization-guide.md自身が含まれる場合も除外しない
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
変更をコミットする。/commit 実行時、「コミットして」「pushして」等の依頼時に使用。--push 引数または「pushして」の依頼で push も行う。
PR を Draft で作成する。PR テンプレートを全セクション埋め、対象 repo の既存 PR の分量に合わせて書きすぎを削る。PR 作成の依頼時、実装が一段落して PR 化する時、/create-draft-pr 実行時に使用(gh pr create を直接実行しない)。引数でベースブランチを指定できる。境界: 個別レビューコメントへの対応は pr-comment。
スキルを新規作成する。「スキルを作って」「この手順をスキル化して」等の依頼時、/create-skill 実行時に使用。AGENTS.md・context・既存スキルと整合させ、重複・競合を避ける。境界: 既存スキル・指示ファイルの修正は update-inst、指示ファイル全体の監査は instructions-audit。
抽象的な要件・事業側の要求を深掘りし、既存実装との整合を確認して実装マスタとシステム要件書を作成する。「こういう機能を作りたい」「この要求を満たす機能を設計して」等の抽象要件の提示時、既存機能の拡張や Phase 分割の要件定義開始時、/design-feature 実行時に使用。境界: 要件確定後の実装計画書・PR 分割と実装進行は plan-feature-prs。
画面の設計判断(ナビゲーション・重ね方・通知と空状態と読み込み・外枠とトークンと状態表現)の型を決定表で選び、アプリ内の全画面で揃える。画面・ページ・レイアウト・ナビゲーション・ダイアログ・コンポーネントを新しく作る・作り直す時、モックやダッシュボードを作る時、サイドバー・タブ・モーダル・シート・toast・バナー・空状態のどれを使うか決める時に使用。PJ に components.json があれば shadcn の部品とトークンへの対応も扱う。主要なデザインシステム(Material・HIG・Carbon・Primer・Atlassian・Fluent・GOV.UK・NN/g・WAI-ARIA APG・WCAG)の一致点を規則にし、食い違いの採否を定めてある。境界: 画面の文言は writing-ui-text、画面に何を出すかと提示前の完了基準は context/ui-artifact-standards.md、コードの実装原則は writing-code、shadcn 部品の API と組み立ては shadcn。