コードベース全体のレビュー・監査。perf/sec/test/arch/cq/docs の6観点を並列委譲し、優先度付き issue ファイルと観点サマリをメモリディレクトリに生成する。コードベース全体の監査・定期レビュー・リリース前品質確認の依頼時、/codebase-review 実行時に使用。境界: PR 単位は pr-review、自ブランチの提出前確認は self-review。
project-sync
PJ ドキュメントの同期。PJ CLAUDE.md の更新依頼、ドキュメント整理依頼、コード変更後の CLAUDE.md・README・API 仕様への反映依頼(npm script・環境変数・API 追加等)の時に使用。user-level 設定との整合性確認も行う。境界: CLAUDE.md が未整備の新規 PJ は組み込みの /init。
インストール方法を見る含まれるファイル(1)
- SKILL.md8.6 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
PJドキュメント同期
トリガー条件
- PJ CLAUDE.mdの更新を依頼された場合
- ドキュメント構造の整理を依頼された場合
- 「user-level CLAUDE.md / AGENTS.mdに合わせて」と指示された場合
- コード変更後にドキュメント更新が必要な場合(npm script追加・環境変数追加・APIエンドポイント追加/変更・アーキテクチャ変更を検出した場合)
コード変更起点のドキュメント同期(旧documentationスキル統合)
コード変更後の依頼では、フル同期でなく変更起点の差分同期を行う:
- 変更内容の確認:
git diff <base-branch> --name-onlyとgit diff <base-branch> - 更新対象のマッピング:
| カテゴリ | 例 | 更新対象 |
|---|---|---|
| コマンド変更 | npm script追加 | CLAUDE.md, README.md |
| API変更 | エンドポイント追加 | API仕様書 |
| 設定変更 | 環境変数追加 | README.md |
| アーキテクチャ変更 | 新規レイヤー | CLAUDE.md |
- 更新不要の判断: 内部実装のみの変更・テストコードのみの変更・機能変更のないリファクタリングは更新不要
- 更新提案を提示し、承認後に反映
ドキュメント分離原則
| 対象 | 配置場所 | 用途 |
|---|---|---|
| 人間向け | README.md, docs/ | プロジェクト説明、API仕様、アーキテクチャ図 |
| エージェント向け | CLAUDE.md, .claude/context/, .claude/rules/ | AI向け指示、作業ルール |
実行手順
1. 現状把握
# PJ CLAUDE.mdの確認
cat CLAUDE.md 2>/dev/null || echo "CLAUDE.md not found"
wc -l CLAUDE.md 2>/dev/null
# ドキュメント構造の確認
ls -la .claude/ 2>/dev/null
ls -la .claude/rules/ 2>/dev/null
ls -la docs/ 2>/dev/null
# コンテキスト除外設定の確認(permissions.deny の Read ルール / claudeMdExcludes)
cat .claude/settings.json 2>/dev/null || echo ".claude/settings.json not found"
# user-level設定の確認(実体はAGENTS.md。CLAUDE.mdは互換symlink)
cat ~/.claude/AGENTS.md
ls ~/.claude/context/
2. 差分分析
以下を確認:
| 項目 | 確認内容 |
|---|---|
| CLAUDE.mdのサイズ | 肥大せず簡潔か(@context/claude-customization-guide.md §3参照) |
| 変数定義 | MEMORY_DIR, BASE_BRANCHがあるか |
| 品質チェック | lint/format/typecheck/testコマンドがあるか |
| 検証方針 | テスト/E2E/スクショ/期待出力の指針があるか |
| レビュー方針 | critical不変条件・検証境界・エラーハンドリング方式・却下類型があるか(無ければ追加を提案) |
| @参照 | 詳細をcontext/に委譲しているか |
| 分離原則 | 人間向け/エージェント向けが分離されているか |
| コンテキスト除外 | 秘匿・不要パスがpermissions.denyのReadルールで除外されているか(.claudeignoreは公式機能に存在しない。残存していれば削除提案) |
| .claude/rules/ | パス固有ルールが活用されているか |
| user-level設定との重複 | 「サブエージェント呼び出し時の追加情報」「委譲必須」等、user-level AGENTS.md/context/に既にある内容が重複していないか |
| 過度な指示 | 「こまめに」「必ず」「逐次」等の過度な強制表現がないか(自律実行ベストプラクティス参照) |
3. 更新提案の作成
## 更新提案
### CLAUDE.md
**現状:** XX行
**提案:** 以下に簡素化
```markdown
# <PJ名>
## 変数
MEMORY_DIR=.local/
BASE_BRANCH=develop
## 品質チェック
```bash
npm run lint
npm run format
npm run typecheck
npm test
検証方針
- テストコード: <test command>
- E2Eテスト: <e2e command>(あれば)
- スクリーンショット: docs/screenshots/ に変更前後を保存
- 期待出力: tests/fixtures/ 等に主要コマンド/APIのfixture
- Stop Hook: 必要なら .claude/settings.jsonで設定
レビュー方針
- critical不変条件: [...] / 検証境界: [...] / エラーハンドリング方式: [...] / 却下類型: [...]
PJ固有ルール
- [PJ固有ルール - サブエージェント呼び出しの強制は記載しない]
### コンテキスト除外(必要な場合のみ)
**提案:** 秘匿・不要パスを `.claude/settings.json` の `permissions.deny` に追加
```json
{ "permissions": { "deny": ["Read(secrets/**)", "Read(*.pem)"] } }
(.claudeignoreは公式機能に存在しない。残存していれば削除を提案する)
.claude/rules/(パス固有ルールがある場合)
提案: 以下を作成
---
paths:
- "src/api/**/*.ts"
---
# API開発ルール
削除対象
- <不要ファイル1>(理由: ...)
移動対象
- <ファイル> → <移動先>(理由: ...)
### 4. ユーザー確認
ユーザーに選択肢を提示して以下を確認(Claude Code: AskUserQuestion):
1. 更新提案の承認
2. 削除対象の確認(誤削除防止)
3. PJ固有の追加要件
### 5. 実行
承認後、以下を実行:
1. CLAUDE.mdの更新(肥大させず簡潔に。@context/claude-customization-guide.md §3参照)
2. コンテキスト除外設定の更新(必要な場合。permissions.denyのReadルール)
3. .claude/rules/の作成(必要な場合)
4. 不要ファイルの削除
5. ファイルの移動・リネーム
6. .claude/context/の作成(必要な場合)
### 6. 検証
```bash
# 行数確認
wc -l CLAUDE.md
# 構造確認
ls -la .claude/
CLAUDE.md設計原則
サイズ・記述の原則
- CLAUDE.mdのサイズ・強調・命令形・理由付け等の設計原則は @context/claude-customization-guide.md §3に従う(公式目標は1ファイル200行未満。肥大させず、詳細は
@.claude/context/へ委譲する)
必須セクション
# <PJ名>
## 変数
MEMORY_DIR=<path>
BASE_BRANCH=<branch>
## 品質チェック
[コマンド一覧]
## 検証方針
[テスト/E2E/スクショ/期待出力の指針]
## レビュー方針
[critical不変条件 / 検証境界 / エラーハンドリング方式 / 却下類型]
## PJ固有ルール
[PJ固有ルール - 簡潔に。サブエージェント呼び出しの強制は記載しない]
オプションセクション(必要な場合のみ)
- アーキテクチャ概要(簡潔に)
- 命名規則
- 禁止事項
記載してはいけない内容
- サブエージェント呼び出しの強制 (
quality-checker / pr-reviewer 等を必ず呼び出せ等): user-levelの~/.claude/context/tool-claude-code.md「委譲判断」と重複・矛盾するため - Phase 0-5の重複定義: user-levelのworkflow-rules.mdに委譲
- 過度な強制表現 (
こまめに、必ず、絶対に等の多用): 自律実行前提に反する
不要ファイルの判断基準
| 判断 | 条件 |
|---|---|
| 削除 | 古いagent定義、重複ドキュメント、空ファイル、user-level重複指示(サブエージェント呼び出しの追加情報等) |
| 移動 | エージェント向け内容がdocs/にある場合 → .claude/context/ |
| 統合 | 類似内容の複数ファイル → 1ファイルに |
| 保持 | 人間向けドキュメント(README, docs/)、PJ固有設定 |
チェックリスト
- CLAUDE.mdが肥大せず簡潔(@context/claude-customization-guide.md §3準拠)
- 変数(MEMORY_DIR, BASE_BRANCH)が定義済み
- 品質チェックコマンドが記載済み
- 検証方針セクションがある(テスト/E2E/スクショ/期待出力)
- レビュー方針セクションがある(critical不変条件/検証境界/エラーハンドリング方式/却下類型)
- ドキュメント分離原則に従っている
- 不要ファイルが削除済み
- @参照が正しく設定済み
- コンテキスト除外(必要な場合のpermissions.deny Readルール)を確認済み
- .claude/rules/が活用されている(パス固有ルールがある場合)
- user-level設定との重複指示がない
- 「こまめに」「必ず」等の過度な強制表現がない
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
変更をコミットする。/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。