Merge pull request #22 from shinpr/remove-citations

refactor: Remove redundant reference sections and improve rule-adviso…

Author: shinpr

.claude/agents-en/rule-advisor.md

@@ -36,9 +36,9 @@ Before starting work, you must read:
    - Prioritize by importance and relevance
 
 4. **Optimized Ruleset Construction**
-   - Select and include necessary sections from CLAUDE.md
-   - Comprehensively collect sections from rule files
-   - After collection, narrow down to task-relevant sections
+   - Always include basic rule sections (e.g., mandatory execution process) from CLAUDE.md
+   - Broadly collect sections from rule files
+   - Comprehensively select sections for high-quality task completion
    - Thoroughly follow the flow: proactive information collection → structured provision
 
 ## Workflow
@@ -69,6 +69,7 @@ graph TD
 
 ### Coordination with rules-index.yaml
 - Based on yaml tags while considering aspects not listed
+- Utilize key-references source information to judge rule importance
 - Pay special attention to implicit relationships:
   - Error handling → debugging + testing
   - New features → design + implementation + documentation
@@ -154,14 +155,14 @@ Always return structured response in the following JSON format:
 4. **Supplementary/reference rules**
 
 ### Optimization Criteria
-- **Relevance**: Direct relevance to task
+- **Comprehensiveness**: Holistic view for high-quality task completion
+- **Quality Assurance**: Always include testing/quality checks for code modifications
 - **Specificity**: Concrete procedures over abstract principles
-- **Practicality**: Frequency of reference in actual work
 - **Dependencies**: Prerequisites for other rules
 
 ### Section Selection Guidelines
-- Only necessary parts for task, not all sections
-- "Basic Principles" useful in many cases
+- Include sections needed not only for direct task requirements but also for high-quality completion
+- Basic rules from CLAUDE.md are mandatory for all tasks
 - Prioritize concrete procedures/checklists
 - Exclude redundant explanations
 
@@ -190,4 +191,4 @@ The `mandatoryChecks` section in output supports items 2-4 of "4 Mandatory Check
 
 - Set confidence to "low" when uncertain
 - Proactively collect information and broadly include potentially related rules
-- Only reference files under `docs/rules/` (referencing `docs/rules-ja/` etc. is prohibited)
+- Only reference files under `docs/rules/`

.claude/agents-ja/rule-advisor.md

@@ -36,9 +36,9 @@ tools: Read, Grep, LS
    - 重要度と関連性で優先順位付け
 
 4. **最適化されたルールセット構築**
-   - CLAUDE.mdから必要なセクションを選択して含める
-   - ルールファイルからセクションを包括的に収集
-   - 収集後、タスクに関連するセクションに絞り込み
+   - CLAUDE.mdから基本ルールセクション（必須実行プロセス等）を必ず含める
+   - ルールファイルからセクションを幅広く収集
+   - タスクを高品質に完遂するためのセクションを包括的に選択
    - 積極的情報収集 → 構造化提供の流れを徹底
 
 ## 作業フロー
@@ -69,6 +69,7 @@ graph TD
 
 ### rules-index.yamlとの連携
 - yamlのタグを基本としつつ、記載されていない観点も考慮
+- key-referencesの出典情報を活用してルールの重要性を判断
 - 特に以下の暗黙的な関連性に注意：
   - エラー対応 → debugging + testing
   - 新機能 → design + implementation + documentation
@@ -154,14 +155,14 @@ graph TD
 4. **補助的・参考的なルール**
 
 ### 最適化の基準
-- **関連性**: タスクとの直接的な関連度
+- **包括性**: タスクを高品質に完遂するための全体的な視点
+- **品質保証**: コード修正には必ずテスト・品質チェックを含める
 - **具体性**: 抽象的な原則より具体的な手順
-- **実用性**: 実際の作業で参照する頻度
 - **依存関係**: 他のルールの前提となるもの
 
 ### セクション選択の指針
-- 全セクションではなく、タスクに必要な部分のみ
-- 「基本原則」は多くの場合で有用
+- タスクの直接的な要求だけでなく、高品質な完成に必要なセクションも含める
+- CLAUDE.mdの基本ルールは全タスクで必須
 - 具体的な手順・チェックリストを優先
 - 冗長な説明部分は除外
 
@@ -190,4 +191,4 @@ graph TD
 
 - 不確実な場合はconfidenceを"low"に設定
 - 積極的に情報収集し、関連する可能性があるルールは広めに含める
-- 必ず`docs/rules/`配下のファイルのみを参照（`docs/rules-ja/`等は参照禁止）
+- 必ず`docs/rules/`配下のファイルのみを参照

docs/rules-en/ai-development-guide.md

@@ -180,11 +180,4 @@ npm run lint:fix      # Lint fixes
 
 - **Humility**: Perfect code doesn't exist, welcome feedback
 - **Courage**: Execute necessary refactoring boldly
-- **Transparency**: Clearly document technical decision reasoning
-
-## Referenced Methodologies and Principles
-- **Rule of Three**: Martin Fowler "Refactoring"
-- **Single Responsibility Principle (SRP)**: Robert C. Martin "Clean Code"
-- **5 Whys**: Toyota Production System
-- **YAGNI Principle**: Kent Beck "Extreme Programming Explained"
-- **DRY Principle**: Andy Hunt & Dave Thomas "The Pragmatic Programmer"
+- **Transparency**: Clearly document technical decision reasoning

docs/rules-en/architecture-decision-process.md

@@ -42,9 +42,4 @@ This document defines the architecture decision process for this project and pro
 
 - Propose ADR creation for changes to 5+ files
 - Always check existing ADRs before implementation
-- Post-creation of ADR allowed in emergencies (production failures, security vulnerabilities)
-
-## Referenced Methodologies and Principles
-- **ADR Methodology**: Michael Nygard "Documenting Architecture Decisions" (2011)
-- **Design Doc Culture**: Google Engineering Practices Documentation
-- **Trade-off Analysis**: Software Architecture in Practice (Bass, Clements, Kazman)
+- Post-creation of ADR allowed in emergencies (production failures, security vulnerabilities)

docs/rules-en/rules-index.yaml

@@ -10,6 +10,8 @@ rules:
     key-references:
       - "YAGNI Principle - Kent Beck"
       - "Clean Code - Robert C. Martin"
+      - "DRY Principle - The Pragmatic Programmer"
+      - "Refactoring - Martin Fowler"
     sections:
       - "Basic Principles"
       - "Comment Writing Rules"
@@ -27,6 +29,8 @@ rules:
     key-references:
       - "Test-Driven Development - Kent Beck"
       - "Rule of Three - Martin Fowler"
+      - "Red-Green-Refactor - Kent Beck"
+      - "AAA Pattern - Arrange-Act-Assert"
     sections:
       - "Test Framework"
       - "Basic Testing Policy"
@@ -44,6 +48,8 @@ rules:
       - "Rule of Three - Martin Fowler"
       - "5 Whys - Toyota Production System"
       - "DRY Principle - The Pragmatic Programmer"
+      - "Single Responsibility Principle (SRP) - Clean Code"
+      - "YAGNI Principle - Extreme Programming"
     sections:
       - "Technical Anti-patterns (Red Flag Patterns)"
       - "Rule of Three - Criteria for Code Duplication"
@@ -60,6 +66,8 @@ rules:
     size: medium
     key-references:
       - "ADR Format - Michael Nygard"
+      - "Single Data Source Principle - Single Source of Truth"
+      - "Dependency Injection (DI) - Martin Fowler"
     sections:
       - "Basic Technology Stack Policy"
       - "Environment Variable Management and Security"
@@ -88,6 +96,8 @@ rules:
     key-references:
       - "ADR Methodology - Michael Nygard"
       - "Documenting Architecture Decisions"
+      - "Design Doc Culture - Google Engineering Practices"
+      - "Trade-off Analysis - Software Architecture in Practice"
     sections:
       - "Purpose"
       - "Cases Requiring ADR Creation"

docs/rules-en/technical-spec.md

@@ -75,8 +75,4 @@ Record important technical decisions to enable future implementers to understand
 
 Define build commands and test execution methods for each project.
 
-## Referenced Methodologies and Principles
-- **ADR (Architecture Decision Record)**: Michael Nygard "Documenting Architecture Decisions"
-- **Single Data Source Principle**: Single Source of Truth (data management best practice)
-- **Dependency Injection (DI)**: Martin Fowler "Inversion of Control Containers and the Dependency Injection pattern"
 Quality checks are mandatory upon implementation completion.

docs/rules-en/typescript-testing.md

@@ -149,10 +149,4 @@ describe('ComponentName', () => {
     expect(result).toBe('expected')
   })
 })
-```
-
-## Referenced Methodologies and Principles
-- **Test-Driven Development**: Kent Beck "Test-Driven Development: By Example"
-- **Red-Green-Refactor**: Basic TDD cycle by Kent Beck
-- **Rule of Three**: Martin Fowler "Refactoring" (criteria for test helper consolidation)
-- **AAA Pattern**: Arrange-Act-Assert (standard pattern for test structure)
+```

docs/rules-en/typescript.md

@@ -100,11 +100,4 @@ Never include sensitive information (password, token, apiKey, secret, creditCard
 ## Performance Optimization
 
 - Streaming Processing: Process large datasets with streams
-- Memory Leak Prevention: Explicitly release unnecessary objects
-
-## Referenced Methodologies and Principles
-- **YAGNI Principle**: Kent Beck "Extreme Programming Explained"
-- **DRY Principle**: Andy Hunt & Dave Thomas "The Pragmatic Programmer"
-- **Single Responsibility Principle**: Robert C. Martin "Clean Code"
-- **Refactoring**: Martin Fowler "Refactoring"
-- Simplicity Priority: Prioritize maintainability over excessive optimization
+- Memory Leak Prevention: Explicitly release unnecessary objects

docs/rules-ja/ai-development-guide.md

@@ -180,11 +180,4 @@ npm run lint:fix      # Lint修正
 
 - **謙虚**: 完璧なコードは存在しない、フィードバック歓迎
 - **勇気**: 必要なリファクタリングは大胆に実行
-- **透明性**: 技術的な判断理由を明確に記録
-
-## 参照した手法・原則
-- **Rule of Three**: Martin Fowler「Refactoring」
-- **単一責任原則（SRP）**: Robert C. Martin「Clean Code」
-- **5 Whys**: トヨタ生産方式
-- **YAGNI原則**: Kent Beck「Extreme Programming Explained」
-- **DRY原則**: Andy Hunt & Dave Thomas「The Pragmatic Programmer」
+- **透明性**: 技術的な判断理由を明確に記録

docs/rules-ja/architecture-decision-process.md

@@ -42,9 +42,4 @@
 
 - 5ファイル以上の変更時はADR作成を提案
 - 既存ADRを必ず確認してから実装
-- 緊急時（本番障害、セキュリティ脆弱性）は事後ADR作成可
-
-## 参照した手法・原則
-- **ADR手法**: Michael Nygard「Documenting Architecture Decisions」（2011）
-- **Design Doc文化**: Google Engineering Practices Documentation
-- **トレードオフ分析**: Software Architecture in Practice（Bass, Clements, Kazman）
+- 緊急時（本番障害、セキュリティ脆弱性）は事後ADR作成可