mirror of
https://github.com/affaan-m/ECC.git
synced 2026-08-23 16:02:22 +02:00
fd1b11cfc7
Model-routing guidance across the rules, skills, and harness-steering docs still recommends Sonnet 4.6 / Opus 4.5-4.6 by name. Readers on the current generation have to map those onto Sonnet 5 / Opus 5 themselves, and the recommendation reads as pinned to a superseded generation. Renames the recommended models in guidance tables and updates two pinned model IDs in code samples: - rules/steering guidance: .cursor, .kiro, and the seven translated performance.md copies (ja-JP, zh-CN, zh-TW, ko-KR, pt-BR, es, tr) - skills/prompt-optimizer complexity-routing table (+ zh-CN copy) - skills/cost-aware-llm-pipeline MODEL_SONNET constant (+ zh-CN, ja-JP) - docs/examples project-guidelines template, which pinned the invalid ID claude-sonnet-4-5-20250514 (+ zh-TW, ja-JP copies) Deliberately left alone: - The "Pricing Reference (2025-2026)" table in cost-aware-llm-pipeline. Renaming those rows while keeping the existing per-token figures would assert Claude 5 pricing this change has not verified. - Executable model config (.opencode/opencode.json, agent.yaml). Those pins change real agent behavior and belong in their own reviewed change. - Historical and illustrative references: the-shortform-guide session transcripts, the ECC-PRO roadmap log entry, gan-style-harness's "Opus 4.5-class"/"Opus 4.6-class" capability tiers, and strategic-compact's deliberately generic "400k Opus 4.x" example. - docs/ATLAS-CLOUD-GUIDE.md, which lists a third-party provider's catalog. Documentation wording only; no behavioral change. Co-authored-by: Phumchai Tanonsi <274848436+phumchai1515-prog@users.noreply.github.com>
ルール
構造
ルールは 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: インストールスクリプト（推奨）
# common + 1つ以上の言語固有ルールセットをインストール
./install.sh typescript
./install.sh python
./install.sh golang
# 複数の言語を一度にインストール
./install.sh typescript python
オプション 2: 手動インストール
重要: ディレクトリ全体をコピーしてください。
/*でフラット化しないでください。 Common と言語固有ディレクトリには同じ名前のファイルが含まれています。 それらを1つのディレクトリにフラット化すると、言語固有ファイルが common ルールを上書きし、 言語固有ファイルが使用する相対パス../common/の参照が壊れます。
# 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/）のサポートを追加するには:
rules/rust/ディレクトリを作成- common ルールを拡張するファイルを追加:
coding-style.md— フォーマットツール、イディオム、エラーハンドリングパターンtesting.md— テストフレームワーク、カバレッジツール、テスト構成patterns.md— 言語固有の設計パターンhooks.md— フォーマッタ、リンター、型チェッカー用の PostToolUse フックsecurity.md— シークレット管理、セキュリティスキャンツール
- 各ファイルは次の内容で始めてください:
> このファイルは [common/xxx.md](../common/xxx.md) を <言語> 固有のコンテンツで拡張します。 - 利用可能な既存のスキルを参照するか、
skills/配下に新しいものを作成してください。