refactor: optimize agent prompts for LLM precision and maintenance

Remove skip information tracking from acceptance-test-generator:
- Remove skip report from test files and generation reports
- Remove skip tracking from mandatory compliance section
- Remove maxSkippedROI from roiMetrics
- Focus only on selected tests to reduce context pollution

Simplify technical-designer AC scoping section:
- Remove verbose 3-check process (duplicated with acceptance-test-generator)
- Remove domain-specific examples (bcrypt, Redis, authentication)
- Use generic, domain-agnostic examples
- Remove upstream/downstream references (violates agent independence)

Unify latest information research guidelines:
- Add Mandatory/Recommended distinction for better decision-making
- Dynamically fetch current year with date command
- Replace hardcoded "2024" with {current_year} placeholder
- Apply to technical-designer and document-reviewer

Benefits:
- Reduced token consumption and context pollution
- Eliminated redundancy between agent files
- Future-proof search queries (no year hardcoding)
- Improved LLM generation precision

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

Author: shinpr

.claude/agents-en/acceptance-test-generator.md

@@ -39,12 +39,14 @@ Before starting work, you MUST read and strictly follow these rule files:
 - **Implementation Timing**: Created alongside feature implementation
 
 ### E2E Tests (End-to-End Tests)
-- **Purpose**: Verify complete user journeys (revenue-critical only)
+- **Purpose**: Verify critical user journeys
 - **Scope**: Full system behavior validation
 - **Generated Files**: `*.e2e.test.ts`
 - **Budget**: MAX 1-2 tests per feature (only if ROI > threshold)
 - **Implementation Timing**: Executed only in final phase after all implementations complete
 
+**Critical User Journey Definition**: User flows that are business-essential, including revenue-impacting (payment, checkout), legally required (GDPR, data protection), or high-frequency core functionality (>80% users).
+
 ## 4-Phase Generation Process
 
 ### Phase 1: AC Validation (Behavior-First Filtering)
@@ -57,7 +59,7 @@ Before starting work, you MUST read and strictly follow these rule files:
 | **System Context** | Requires full system integration? | Skip | [UNIT_LEVEL] |
 | **Upstream Scope** | In Include list? | Skip | [OUT_OF_SCOPE] |
 
-**Upstream AC Scoping** (from technical-designer):
+**AC Include/Exclude Criteria**:
 
 **Include** (High automation ROI):
 - Business logic correctness (calculations, state transitions, data transformations)
@@ -73,17 +75,7 @@ Before starting work, you MUST read and strictly follow these rule files:
 
 **Principle**: AC = User-observable behavior verifiable in isolated CI environment
 
-**Example Filtering**:
-
-```
-AC: "Hash passwords using bcrypt with salt rounds=10"
-→ Skip [IMPLEMENTATION_DETAIL] - hashing algorithm not user-observable
-
-AC: "After successful payment, user receives order confirmation"
-→ PASS (observable + system-level + in scope)
-```
-
-**Output**: Filtered AC list with skip rationale for each excluded AC
+**Output**: Filtered AC list
 
 ### Phase 2: Candidate Enumeration (Two-Pass #1)
 
@@ -153,13 +145,9 @@ ROI Score = (Business Value × User Frequency + Legal Requirement × 10 + Defect
 2. Select top N within budget:
    - Integration: Pick top 3 highest-ROI
    - E2E: Pick top 1-2 IF ROI score > 50
-3. Generate skip report for unselected candidates:
-   - Test name
-   - ROI score
-   - Skip reason (budget exceeded / low ROI / covered by lower-level test)
 ```
 
-**Output**: Final test set + comprehensive skip report
+**Output**: Final test set
 
 ## Output Format
 
@@ -168,13 +156,12 @@ ROI Score = (Business Value × User Frequency + Legal Requirement × 10 + Defect
 ```typescript
 // [Feature Name] Integration Test - Design Doc: [filename]
 // Generated: [date] | Budget Used: 2/3 integration, 0/2 E2E
-// Skipped: 5 candidates (see generation report below)
 
 import { describe, it } from '[detected test framework]'
 
 describe('[Feature Name] Integration Test', () => {
   // AC1: "After successful payment, order is created and persisted"
-  // ROI: 85 | Business Value: 10 (revenue-critical) | Frequency: 9 (90% users)
+  // ROI: 85 | Business Value: 10 (business-critical) | Frequency: 9 (90% users)
   // Behavior: User completes payment → Order created in DB + Payment recorded
   // @category: core-functionality
   // @dependency: PaymentService, OrderRepository, Database
@@ -203,7 +190,7 @@ import { describe, it } from '[detected test framework]'
 
 describe('[Feature Name] E2E Test', () => {
   // User Journey: Complete purchase flow (browse → add to cart → checkout → payment → confirmation)
-  // ROI: 95 | Business Value: 10 (revenue) | Frequency: 10 (core flow) | Legal: true (PCI compliance)
+  // ROI: 95 | Business Value: 10 (business-critical) | Frequency: 10 (core flow) | Legal: true (PCI compliance)
   // Verification: End-to-end user experience from product selection to order confirmation
   // @category: e2e
   // @dependency: full-system
@@ -241,41 +228,8 @@ describe('[Feature Name] E2E Test', () => {
   },
   "roiMetrics": {
     "avgSelectedROI": 84,
-    "minSelectedROI": 72,
-    "maxSkippedROI": 45
+    "minSelectedROI": 72
   },
-  "skippedTests": [
-    {
-      "name": "Null input validation for user name field",
-      "roi": 15,
-      "reason": "Unit test level - no system integration required",
-      "recommendedLevel": "unit"
-    },
-    {
-      "name": "Button layout matches design mockup",
-      "roi": 8,
-      "reason": "Out of scope - UI layout specifics excluded per upstream scoping",
-      "recommendedLevel": "visual regression test"
-    },
-    {
-      "name": "API response time < 200ms",
-      "roi": 12,
-      "reason": "Out of scope - performance metrics non-deterministic in CI",
-      "recommendedLevel": "performance test suite"
-    },
-    {
-      "name": "Edge case: Order with 10000+ items",
-      "roi": 22,
-      "reason": "Budget exceeded - lower ROI than selected tests",
-      "note": "Consider if business value increases"
-    },
-    {
-      "name": "Successful payment flow (E2E duplicate)",
-      "roi": 68,
-      "reason": "Already covered by integration test",
-      "note": "E2E version unnecessary - integration test sufficient"
-    }
-  ],
   "acValidation": {
     "total": 12,
     "passed": 6,
@@ -290,21 +244,20 @@ describe('[Feature Name] E2E Test', () => {
 
 ## Test Meta Information Assignment
 
-Each test case MUST have the following standard annotations for downstream process utilization:
+Each test case MUST have the following standard annotations for test implementation planning:
 
 - **@category**: core-functionality | integration | edge-case | ux
 - **@dependency**: none | [component names] | full-system
 - **@complexity**: low | medium | high
 
-These annotations are utilized when downstream planning tools perform phase placement and prioritization.
+These annotations are used when planning and prioritizing test implementation.
 
 ## Constraints and Quality Standards
 
 **Mandatory Compliance**:
 - Output only `it.todo` (prohibit implementation code, expect, mock implementation)
 - Clearly state verification points, expected results, and pass criteria for each test
 - Preserve original AC statements in comments (ensure traceability)
-- Record skip rationale for all filtered candidates
 - Stay within test budget; report if budget insufficient for critical tests
 
 **Quality Standards**:
@@ -319,11 +272,11 @@ These annotations are utilized when downstream planning tools perform phase plac
 ### Auto-processable
 - **Directory Absent**: Auto-create appropriate directory following detected test structure
 - **No High-ROI Tests**: Valid outcome - report "All ACs below ROI threshold or covered by existing tests"
-- **Budget Exceeded by Critical Test**: Include in skip report with escalation flag
+- **Budget Exceeded by Critical Test**: Report to user
 
 ### Escalation Required
 1. **Critical**: AC absent, Design Doc absent → Error termination
-2. **High**: All ACs filtered out but feature is revenue-critical → User confirmation needed
+2. **High**: All ACs filtered out but feature is business-critical → User confirmation needed
 3. **Medium**: Budget insufficient for critical user journey (ROI > 90) → Present options
 4. **Low**: Multiple interpretations possible but minor impact → Adopt interpretation + note in report
 
@@ -350,41 +303,7 @@ These annotations are utilized when downstream planning tools perform phase plac
   - ROI calculations documented
   - Budget compliance monitored
 - **Post-execution**:
-  - Complete AC → test case correspondence (or skip rationale)
+  - Completeness of selected tests
   - Dependency validity verified
   - Integration tests and E2E tests generated in separate files
   - Generation report completeness
-
-## Implementation Examples
-
-### Example: User Authentication Feature
-
-**Input ACs**:
-1. "After entering valid credentials, user is redirected to dashboard"
-2. "Password must be hashed using bcrypt with 10 salt rounds"
-3. "Invalid credentials display error message within 200ms"
-4. "Login button is disabled during authentication"
-5. "Failed login attempts are logged to security audit table"
-
-**Phase 1: Behavior-First Filtering**:
-- AC1: ✅ Pass (observable, system-level, in scope)
-- AC2: ❌ Skip [IMPLEMENTATION_DETAIL] - hashing algorithm not user-observable
-- AC3: ❌ Skip [OUT_OF_SCOPE] - performance metric (200ms) non-deterministic in CI
-- AC4: ❌ Skip [UNIT_LEVEL] - UI component behavior, no system integration
-- AC5: ✅ Pass (observable via logs, system-level, data integrity)
-
-**Phase 2: Candidate Enumeration**:
-- AC1 → 2 candidates: (1) happy path, (2) error case
-- AC5 → 1 candidate: audit log verification
-
-**Phase 3: ROI Calculation**:
-- AC1 happy path: ROI = (9×10 + 0 + 8) / 11 = 8.9
-- AC1 error case: ROI = (7×8 + 0 + 9) / 11 = 5.9
-- AC5 audit log: ROI = (5×3 + 10 + 7) / 11 = 3.8 (legal requirement +10)
-
-**Phase 4: Budget Enforcement**:
-- Budget: 3 integration tests
-- Selected: All 3 (within budget)
-- E2E: None (no complete user journey defined in this feature set)
-
-**Output**: 3 integration tests, 2 ACs skipped with rationale

.claude/agents-en/document-reviewer.md

@@ -158,7 +158,8 @@ Template storage locations follow @docs/rules/documentation-criteria.md.
    - Verify validity with multiple information sources
 
 3. **Proactive Latest Information Collection**:
-   - `[technology] best practices 2024/2025`
+   Check current year before searching: `date +%Y`
+   - `[technology] best practices {current_year}`
    - `[technology] deprecation`, `[technology] security vulnerability`
    - Check release notes of official repositories
 

.claude/agents-en/technical-designer.md

@@ -309,34 +309,10 @@ Implementation sample creation checklist:
 **Principle**: Set specific, verifiable conditions. Avoid ambiguous expressions, document in format convertible to test cases.
 **Example**: "Login works" → "After authentication with correct credentials, navigates to dashboard screen"
 **Comprehensiveness**: Cover happy path, unhappy path, and edge cases. Define non-functional requirements in separate section.
-   - Expected behavior (happy path)
-   - Error handling (unhappy path)
-   - Edge cases
 
-4. **Priority**: Place important acceptance criteria at the top
+### Writing Measurable ACs
 
-### AC Scoping for Autonomous Implementation
-
-**Core Principle**: AC = User-observable behavior verifiable in isolated CI environment
-
-**Behavior-First Principle** (Test Generation Upstream Control):
-
-Before writing any AC, apply the observability test:
-
-1. **User-Observable Check**:
-   - Question: "Can a user (or system operator) observe this behavior?"
-   - If NO → This is an **implementation detail**, exclude from AC
-   - If YES → Continue to check 2
-
-2. **Verification Context Check**:
-   - Question: "Can this be verified without full system integration?"
-   - If YES → This is **unit/component level**, exclude from integration/E2E AC
-   - If NO → This is a valid AC for integration/E2E tests
-
-3. **CI Environment Check**:
-   - Question: "Is this verifiable deterministically in CI?"
-   - If NO → Exclude (e.g., performance metrics, real external services)
-   - If YES → Valid AC
+**Core Principle**: AC = User-observable behavior verifiable in isolated environment
 
 **Include** (High automation ROI):
 - Business logic correctness (calculations, state transitions, data transformations)
@@ -347,68 +323,34 @@ Before writing any AC, apply the observability test:
 **Exclude** (Low ROI in LLM/CI/CD environment):
 - External service real connections → Use contract/interface verification instead
 - Performance metrics → Non-deterministic in CI, defer to load testing
-- Implementation details (hashing algorithms, internal function calls) → Focus on observable behavior
-- UI layout specifics (exact pixel positions, styling) → Focus on information availability, not presentation
-
-**Examples of Proper AC Formulation**:
-
-**❌ Bad (Implementation Detail)**:
-- "Password must be hashed using bcrypt with 10 salt rounds"
-- "Use Redis for session storage"
-- "API response time must be < 200ms"
-
-**✅ Good (User-Observable Behavior)**:
-- "After successful login, user can access protected resources without re-authenticating for 24 hours"
-- "Failed login attempts are logged and visible in admin security audit"
-- "System processes checkout requests without blocking user interaction"
-
-**Rationale**:
-- Implementation details (bcrypt, Redis) are verified via code review and unit tests
-- User-observable outcomes (session persistence, audit logs, non-blocking UX) are verified via integration/E2E tests
-- Performance targets belong in "Non-functional Requirements" section for specialized testing
+- Implementation details (technology choice, algorithms, internal structure) → Focus on observable behavior
+- UI presentation method (layout, styling) → Focus on information availability
 
-**Downstream Impact**:
+**Example**:
+- ❌ Implementation detail: "Data is stored using specific technology X"
+- ✅ Observable behavior: "Saved data can be retrieved after system restart"
 
-This scoping is **mandatory for acceptance-test-generator**. Tests are generated only from ACs that pass all 3 checks above, preventing over-generation of low-ROI tests.
-
-*Note: Non-functional requirements (performance, reliability, scalability) are defined in the "Non-functional Requirements" section and automatically verified by tools like quality-fixer*
+*Note: Non-functional requirements (performance, reliability, scalability) are defined in "Non-functional Requirements" section*
 
 ## Latest Information Research Guidelines
 
-### Research Timing
-1. **Mandatory Research**:
-   - When considering new technology/library introduction
-   - When designing performance optimization
-   - When designing security-related implementation
-   - When major version upgrades of existing technology
-
-2. **Recommended Research**:
-   - Before implementing complex algorithms
-   - When considering improvements to existing patterns
-
-### Research Method
-
 **Required Research Timing**: New technology introduction, performance optimization, security design, major version upgrades
+**Recommended Research**: Before implementing complex algorithms, when considering improvements to existing patterns
 
-**Specific Search Pattern Examples**:
-- `React Server Components best practices 2024` (new feature research)
-- `PostgreSQL vs MongoDB performance comparison 2024` (technology selection)
-- `microservices authentication patterns` (design patterns)
-- `Node.js v20 breaking changes migration guide` (version upgrade)
-- `[framework name] official documentation` (official information)
-
-**Citation**: Add "## References" section at end of ADR/Design Doc with URLs and descriptions
-
-### Citation Format
-
-Add at the end of ADR/Design Doc in the following format:
+**Search Pattern Examples**:
+To get latest information, always check current year before searching:
+```bash
+date +%Y  # e.g., 2025
+```
+Include this year in search queries:
+- `React Server Components best practices {current_year}` (new feature research)
+- `PostgreSQL vs MongoDB performance comparison {current_year}` (technology selection)
+- `[framework name] official documentation` (official docs don't need year)
 
+**Citation**: Add "## References" section at end of ADR/Design Doc
 ```markdown
 ## References
-
 - [Title](URL) - Brief description of referenced content
-- [Framework Official Documentation](URL) - Related design principles and features
-- [Technical Blog Article](URL) - Implementation patterns and best practices
 ```
 
 ## Update Mode Operation