mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-07 17:53:32 +08:00
Revert "feat(ecc): prune plugin 43→12 items, promote 7 rules to .claude/rules/ (#245)"
This reverts commit 1bd68ff534.
This commit is contained in:
Affaan Mustafa
81
docs/ja-JP/rules/README.md
Normal file
81
docs/ja-JP/rules/README.md
Normal file
@@ -0,0 +1,81 @@
|
||||
# ルール
|
||||
|
||||
## 構造
|
||||
|
||||
ルールは **common** レイヤーと **言語固有** ディレクトリで構成されています:
|
||||
|
||||
```
|
||||
rules/
|
||||
├── common/ # 言語に依存しない原則（常にインストール）
|
||||
│ ├── coding-style.md
|
||||
│ ├── git-workflow.md
|
||||
│ ├── testing.md
|
||||
│ ├── performance.md
|
||||
│ ├── patterns.md
|
||||
│ ├── hooks.md
|
||||
│ ├── agents.md
|
||||
│ └── security.md
|
||||
├── typescript/ # TypeScript/JavaScript 固有
|
||||
├── python/ # Python 固有
|
||||
└── golang/ # Go 固有
|
||||
```
|
||||
|
||||
- **common/** には普遍的な原則が含まれています。言語固有のコード例は含まれません。
|
||||
- **言語ディレクトリ** は common ルールをフレームワーク固有のパターン、ツール、コード例で拡張します。各ファイルは対応する common ファイルを参照します。
|
||||
|
||||
## インストール
|
||||
|
||||
### オプション 1: インストールスクリプト（推奨）
|
||||
|
||||
```bash
|
||||
# common + 1つ以上の言語固有ルールセットをインストール
|
||||
./install.sh typescript
|
||||
./install.sh python
|
||||
./install.sh golang
|
||||
|
||||
# 複数の言語を一度にインストール
|
||||
./install.sh typescript python
|
||||
```
|
||||
|
||||
### オプション 2: 手動インストール
|
||||
|
||||
> **重要:** ディレクトリ全体をコピーしてください。`/*` でフラット化しないでください。
|
||||
> Common と言語固有ディレクトリには同じ名前のファイルが含まれています。
|
||||
> それらを1つのディレクトリにフラット化すると、言語固有ファイルが common ルールを上書きし、
|
||||
> 言語固有ファイルが使用する相対パス `../common/` の参照が壊れます。
|
||||
|
||||
```bash
|
||||
# common ルールをインストール（すべてのプロジェクトに必須）
|
||||
cp -r rules/common ~/.claude/rules/common
|
||||
|
||||
# プロジェクトの技術スタックに応じて言語固有ルールをインストール
|
||||
cp -r rules/typescript ~/.claude/rules/typescript
|
||||
cp -r rules/python ~/.claude/rules/python
|
||||
cp -r rules/golang ~/.claude/rules/golang
|
||||
|
||||
# 注意！実際のプロジェクト要件に応じて設定してください。ここでの設定は参考例です。
|
||||
```
|
||||
|
||||
## ルール vs スキル
|
||||
|
||||
- **ルール** は広範に適用される標準、規約、チェックリストを定義します（例: 「80% テストカバレッジ」、「ハードコードされたシークレットなし」）。
|
||||
- **スキル** （`skills/` ディレクトリ）は特定のタスクに対する詳細で実行可能な参考資料を提供します（例: `python-patterns`、`golang-testing`）。
|
||||
|
||||
言語固有のルールファイルは必要に応じて関連するスキルを参照します。ルールは *何を* するかを示し、スキルは *どのように* するかを示します。
|
||||
|
||||
## 新しい言語の追加
|
||||
|
||||
新しい言語（例: `rust/`）のサポートを追加するには:
|
||||
|
||||
1. `rules/rust/` ディレクトリを作成
|
||||
2. common ルールを拡張するファイルを追加:
|
||||
- `coding-style.md` — フォーマットツール、イディオム、エラーハンドリングパターン
|
||||
- `testing.md` — テストフレームワーク、カバレッジツール、テスト構成
|
||||
- `patterns.md` — 言語固有の設計パターン
|
||||
- `hooks.md` — フォーマッタ、リンター、型チェッカー用の PostToolUse フック
|
||||
- `security.md` — シークレット管理、セキュリティスキャンツール
|
||||
3. 各ファイルは次の内容で始めてください:
|
||||
```
|
||||
> このファイルは [common/xxx.md](../common/xxx.md) を <言語> 固有のコンテンツで拡張します。
|
||||
```
|
||||
4. 利用可能な既存のスキルを参照するか、`skills/` 配下に新しいものを作成してください。
|
||||
49
docs/ja-JP/rules/agents.md
Normal file
49
docs/ja-JP/rules/agents.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# Agent オーケストレーション
|
||||
|
||||
## 利用可能な Agent
|
||||
|
||||
`~/.claude/agents/` に配置:
|
||||
|
||||
| Agent | 目的 | 使用タイミング |
|
||||
|-------|---------|-------------|
|
||||
| planner | 実装計画 | 複雑な機能、リファクタリング |
|
||||
| architect | システム設計 | アーキテクチャの意思決定 |
|
||||
| tdd-guide | テスト駆動開発 | 新機能、バグ修正 |
|
||||
| code-reviewer | コードレビュー | コード記述後 |
|
||||
| security-reviewer | セキュリティ分析 | コミット前 |
|
||||
| build-error-resolver | ビルドエラー修正 | ビルド失敗時 |
|
||||
| e2e-runner | E2Eテスト | 重要なユーザーフロー |
|
||||
| refactor-cleaner | デッドコードクリーンアップ | コードメンテナンス |
|
||||
| doc-updater | ドキュメント | ドキュメント更新 |
|
||||
|
||||
## Agent の即座の使用
|
||||
|
||||
ユーザープロンプト不要:
|
||||
1. 複雑な機能リクエスト - **planner** agent を使用
|
||||
2. コード作成/変更直後 - **code-reviewer** agent を使用
|
||||
3. バグ修正または新機能 - **tdd-guide** agent を使用
|
||||
4. アーキテクチャの意思決定 - **architect** agent を使用
|
||||
|
||||
## 並列タスク実行
|
||||
|
||||
独立した操作には常に並列 Task 実行を使用してください:
|
||||
|
||||
```markdown
|
||||
# 良い例: 並列実行
|
||||
3つの agent を並列起動:
|
||||
1. Agent 1: 認証モジュールのセキュリティ分析
|
||||
2. Agent 2: キャッシュシステムのパフォーマンスレビュー
|
||||
3. Agent 3: ユーティリティの型チェック
|
||||
|
||||
# 悪い例: 不要な逐次実行
|
||||
最初に agent 1、次に agent 2、そして agent 3
|
||||
```
|
||||
|
||||
## 多角的分析
|
||||
|
||||
複雑な問題には、役割分担したサブ agent を使用:
|
||||
- 事実レビュー担当
|
||||
- シニアエンジニア
|
||||
- セキュリティエキスパート
|
||||
- 一貫性レビュー担当
|
||||
- 冗長性チェック担当
|
||||
48
docs/ja-JP/rules/coding-style.md
Normal file
48
docs/ja-JP/rules/coding-style.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# コーディングスタイル
|
||||
|
||||
## 不変性（重要）
|
||||
|
||||
常に新しいオブジェクトを作成し、既存のものを変更しないでください:
|
||||
|
||||
```
|
||||
// 疑似コード
|
||||
誤り: modify(original, field, value) → original をその場で変更
|
||||
正解: update(original, field, value) → 変更を加えた新しいコピーを返す
|
||||
```
|
||||
|
||||
理由: 不変データは隠れた副作用を防ぎ、デバッグを容易にし、安全な並行処理を可能にします。
|
||||
|
||||
## ファイル構成
|
||||
|
||||
多数の小さなファイル > 少数の大きなファイル:
|
||||
- 高い凝集性、低い結合性
|
||||
- 通常 200-400 行、最大 800 行
|
||||
- 大きなモジュールからユーティリティを抽出
|
||||
- 型ではなく、機能/ドメインごとに整理
|
||||
|
||||
## エラーハンドリング
|
||||
|
||||
常に包括的にエラーを処理してください:
|
||||
- すべてのレベルでエラーを明示的に処理
|
||||
- UI 向けコードではユーザーフレンドリーなエラーメッセージを提供
|
||||
- サーバー側では詳細なエラーコンテキストをログに記録
|
||||
- エラーを黙って無視しない
|
||||
|
||||
## 入力検証
|
||||
|
||||
常にシステム境界で検証してください:
|
||||
- 処理前にすべてのユーザー入力を検証
|
||||
- 可能な場合はスキーマベースの検証を使用
|
||||
- 明確なエラーメッセージで早期に失敗
|
||||
- 外部データ（API レスポンス、ユーザー入力、ファイルコンテンツ）を決して信頼しない
|
||||
|
||||
## コード品質チェックリスト
|
||||
|
||||
作業を完了とマークする前に:
|
||||
- [ ] コードが読みやすく、適切に命名されている
|
||||
- [ ] 関数が小さい（50 行未満）
|
||||
- [ ] ファイルが焦点を絞っている（800 行未満）
|
||||
- [ ] 深いネストがない（4 レベル以下）
|
||||
- [ ] 適切なエラーハンドリング
|
||||
- [ ] ハードコードされた値がない（定数または設定を使用）
|
||||
- [ ] 変更がない（不変パターンを使用）
|
||||
45
docs/ja-JP/rules/git-workflow.md
Normal file
45
docs/ja-JP/rules/git-workflow.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# Git ワークフロー
|
||||
|
||||
## コミットメッセージフォーマット
|
||||
|
||||
```
|
||||
<type>: <description>
|
||||
|
||||
<optional body>
|
||||
```
|
||||
|
||||
タイプ: feat, fix, refactor, docs, test, chore, perf, ci
|
||||
|
||||
注記: Attribution は ~/.claude/settings.json でグローバルに無効化されています。
|
||||
|
||||
## Pull Request ワークフロー
|
||||
|
||||
PR を作成する際:
|
||||
1. 完全なコミット履歴を分析（最新のコミットだけでなく）
|
||||
2. `git diff [base-branch]...HEAD` を使用してすべての変更を確認
|
||||
3. 包括的な PR サマリーを作成
|
||||
4. TODO 付きのテスト計画を含める
|
||||
5. 新しいブランチの場合は `-u` フラグで push
|
||||
|
||||
## 機能実装ワークフロー
|
||||
|
||||
1. **まず計画**
|
||||
- **planner** agent を使用して実装計画を作成
|
||||
- 依存関係とリスクを特定
|
||||
- フェーズに分割
|
||||
|
||||
2. **TDD アプローチ**
|
||||
- **tdd-guide** agent を使用
|
||||
- まずテストを書く（RED）
|
||||
- テストをパスするように実装（GREEN）
|
||||
- リファクタリング（IMPROVE）
|
||||
- 80%+ カバレッジを確認
|
||||
|
||||
3. **コードレビュー**
|
||||
- コード記述直後に **code-reviewer** agent を使用
|
||||
- CRITICAL と HIGH の問題に対処
|
||||
- 可能な限り MEDIUM の問題を修正
|
||||
|
||||
4. **コミット & プッシュ**
|
||||
- 詳細なコミットメッセージ
|
||||
- Conventional Commits フォーマットに従う
|
||||
30
docs/ja-JP/rules/hooks.md
Normal file
30
docs/ja-JP/rules/hooks.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Hooks システム
|
||||
|
||||
## Hook タイプ
|
||||
|
||||
- **PreToolUse**: ツール実行前（検証、パラメータ変更）
|
||||
- **PostToolUse**: ツール実行後（自動フォーマット、チェック）
|
||||
- **Stop**: セッション終了時（最終検証）
|
||||
|
||||
## 自動承認パーミッション
|
||||
|
||||
注意して使用:
|
||||
- 信頼できる、明確に定義された計画に対して有効化
|
||||
- 探索的な作業では無効化
|
||||
- dangerously-skip-permissions フラグを決して使用しない
|
||||
- 代わりに `~/.claude.json` で `allowedTools` を設定
|
||||
|
||||
## TodoWrite ベストプラクティス
|
||||
|
||||
TodoWrite ツールを使用して:
|
||||
- 複数ステップのタスクの進捗を追跡
|
||||
- 指示の理解を検証
|
||||
- リアルタイムの調整を可能に
|
||||
- 細かい実装ステップを表示
|
||||
|
||||
Todo リストが明らかにすること:
|
||||
- 順序が間違っているステップ
|
||||
- 欠けている項目
|
||||
- 不要な余分な項目
|
||||
- 粒度の誤り
|
||||
- 誤解された要件
|
||||
31
docs/ja-JP/rules/patterns.md
Normal file
31
docs/ja-JP/rules/patterns.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# 共通パターン
|
||||
|
||||
## スケルトンプロジェクト
|
||||
|
||||
新しい機能を実装する際:
|
||||
1. 実戦テスト済みのスケルトンプロジェクトを検索
|
||||
2. 並列 agent を使用してオプションを評価:
|
||||
- セキュリティ評価
|
||||
- 拡張性分析
|
||||
- 関連性スコアリング
|
||||
- 実装計画
|
||||
3. 最適なものを基盤としてクローン
|
||||
4. 実証済みの構造内で反復
|
||||
|
||||
## 設計パターン
|
||||
|
||||
### Repository パターン
|
||||
|
||||
一貫したインターフェースの背後にデータアクセスをカプセル化:
|
||||
- 標準操作を定義: findAll, findById, create, update, delete
|
||||
- 具象実装がストレージの詳細を処理（データベース、API、ファイルなど）
|
||||
- ビジネスロジックはストレージメカニズムではなく、抽象インターフェースに依存
|
||||
- データソースの簡単な交換を可能にし、モックによるテストを簡素化
|
||||
|
||||
### API レスポンスフォーマット
|
||||
|
||||
すべての API レスポンスに一貫したエンベロープを使用:
|
||||
- 成功/ステータスインジケーターを含める
|
||||
- データペイロードを含める（エラー時は null）
|
||||
- エラーメッセージフィールドを含める（成功時は null）
|
||||
- ページネーションされたレスポンスにメタデータを含める（total, page, limit）
|
||||
55
docs/ja-JP/rules/performance.md
Normal file
55
docs/ja-JP/rules/performance.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# パフォーマンス最適化
|
||||
|
||||
## モデル選択戦略
|
||||
|
||||
**Haiku 4.5**（Sonnet 機能の 90%、コスト 3 分の 1）:
|
||||
- 頻繁に呼び出される軽量 agent
|
||||
- ペアプログラミングとコード生成
|
||||
- マルチ agent システムのワーカー agent
|
||||
|
||||
**Sonnet 4.5**（最高のコーディングモデル）:
|
||||
- メイン開発作業
|
||||
- マルチ agent ワークフローのオーケストレーション
|
||||
- 複雑なコーディングタスク
|
||||
|
||||
**Opus 4.5**（最も深い推論）:
|
||||
- 複雑なアーキテクチャの意思決定
|
||||
- 最大限の推論要件
|
||||
- 調査と分析タスク
|
||||
|
||||
## コンテキストウィンドウ管理
|
||||
|
||||
次の場合はコンテキストウィンドウの最後の 20% を避ける:
|
||||
- 大規模なリファクタリング
|
||||
- 複数ファイルにまたがる機能実装
|
||||
- 複雑な相互作用のデバッグ
|
||||
|
||||
コンテキスト感度の低いタスク:
|
||||
- 単一ファイルの編集
|
||||
- 独立したユーティリティの作成
|
||||
- ドキュメントの更新
|
||||
- 単純なバグ修正
|
||||
|
||||
## 拡張思考 + プランモード
|
||||
|
||||
拡張思考はデフォルトで有効で、内部推論用に最大 31,999 トークンを予約します。
|
||||
|
||||
拡張思考の制御:
|
||||
- **トグル**: Option+T（macOS）/ Alt+T（Windows/Linux）
|
||||
- **設定**: `~/.claude/settings.json` で `alwaysThinkingEnabled` を設定
|
||||
- **予算上限**: `export MAX_THINKING_TOKENS=10000`
|
||||
- **詳細モード**: Ctrl+O で思考出力を表示
|
||||
|
||||
深い推論を必要とする複雑なタスクの場合:
|
||||
1. 拡張思考が有効であることを確認（デフォルトで有効）
|
||||
2. 構造化されたアプローチのために **プランモード** を有効化
|
||||
3. 徹底的な分析のために複数の批評ラウンドを使用
|
||||
4. 多様な視点のために役割分担したサブ agent を使用
|
||||
|
||||
## ビルドトラブルシューティング
|
||||
|
||||
ビルドが失敗した場合:
|
||||
1. **build-error-resolver** agent を使用
|
||||
2. エラーメッセージを分析
|
||||
3. 段階的に修正
|
||||
4. 各修正後に検証
|
||||
29
docs/ja-JP/rules/security.md
Normal file
29
docs/ja-JP/rules/security.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# セキュリティガイドライン
|
||||
|
||||
## 必須セキュリティチェック
|
||||
|
||||
すべてのコミット前:
|
||||
- [ ] ハードコードされたシークレットなし（API キー、パスワード、トークン）
|
||||
- [ ] すべてのユーザー入力が検証済み
|
||||
- [ ] SQL インジェクション防止（パラメータ化クエリ）
|
||||
- [ ] XSS 防止（サニタイズされた HTML）
|
||||
- [ ] CSRF 保護が有効
|
||||
- [ ] 認証/認可が検証済み
|
||||
- [ ] すべてのエンドポイントにレート制限
|
||||
- [ ] エラーメッセージが機密データを漏らさない
|
||||
|
||||
## シークレット管理
|
||||
|
||||
- ソースコードにシークレットをハードコードしない
|
||||
- 常に環境変数またはシークレットマネージャーを使用
|
||||
- 起動時に必要なシークレットが存在することを検証
|
||||
- 露出した可能性のあるシークレットをローテーション
|
||||
|
||||
## セキュリティ対応プロトコル
|
||||
|
||||
セキュリティ問題が見つかった場合:
|
||||
1. 直ちに停止
|
||||
2. **security-reviewer** agent を使用
|
||||
3. 継続前に CRITICAL 問題を修正
|
||||
4. 露出したシークレットをローテーション
|
||||
5. 同様の問題がないかコードベース全体をレビュー
|
||||
29
docs/ja-JP/rules/testing.md
Normal file
29
docs/ja-JP/rules/testing.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# テスト要件
|
||||
|
||||
## 最低テストカバレッジ: 80%
|
||||
|
||||
テストタイプ（すべて必須）:
|
||||
1. **ユニットテスト** - 個々の関数、ユーティリティ、コンポーネント
|
||||
2. **統合テスト** - API エンドポイント、データベース操作
|
||||
3. **E2E テスト** - 重要なユーザーフロー（フレームワークは言語ごとに選択）
|
||||
|
||||
## テスト駆動開発
|
||||
|
||||
必須ワークフロー:
|
||||
1. まずテストを書く（RED）
|
||||
2. テストを実行 - 失敗するはず
|
||||
3. 最小限の実装を書く（GREEN）
|
||||
4. テストを実行 - パスするはず
|
||||
5. リファクタリング（IMPROVE）
|
||||
6. カバレッジを確認（80%+）
|
||||
|
||||
## テスト失敗のトラブルシューティング
|
||||
|
||||
1. **tdd-guide** agent を使用
|
||||
2. テストの分離を確認
|
||||
3. モックが正しいことを検証
|
||||
4. 実装を修正、テストは修正しない（テストが間違っている場合を除く）
|
||||
|
||||
## Agent サポート
|
||||
|
||||
- **tdd-guide** - 新機能に対して積極的に使用、テストファーストを強制
|
||||
Reference in New Issue
Block a user