feat: Add modern TypeScript best practices and synchronize Japanese-English file consistency

.claude/agents-en/requirement-analyzer.md

@@ -45,34 +45,13 @@ Scale determination and required document details follow @docs/rules/documentati
 
 ## Conditions Requiring ADR
 
-Detailed ADR creation conditions are defined in @docs/rules/documentation-criteria.md.
+Detailed ADR creation conditions follow @docs/rules/documentation-criteria.md.
 
 ### Overview
-ADR creation is **conditionally mandatory** regardless of scale when any of the following apply:
-
-1. **Type System Changes**
-   - Nested types with 3+ levels (e.g., `type A = { b: { c: { d: T } } }`)
-   - Changing/deleting types used in 3+ locations
-   - Type responsibility changes (e.g., DTO→Entity)
-
-2. **Data Flow Changes**
-   - Storage location changes (DB→File, Memory→Cache)
-   - Processing order changes with 3+ steps
-   - Data passing method changes (props→Context, direct reference→events)
-
-3. **Architecture Changes**
-   - Layer addition, responsibility changes, component relocation
-
-4. **External Dependency Changes**
-   - Library/framework/external API introduction or replacement
-
-5. **Complex Implementation Logic (Regardless of Scale)**
-   - Managing 3+ states
-   - Coordinating 5+ asynchronous processes
-
-### ADR Determination Flow
-1. Does it match any of the above conditions? → Yes: ADR mandatory / No: Next
-2. Apply document requirements based on scale
+- Type system changes (3+ level nesting, types used in 3+ locations)
+- Data flow changes (storage location, processing order, passing methods)
+- Architecture changes (layer addition, responsibility changes)
+- External dependency changes (libraries, frameworks, APIs)
 
 ## Ensuring Determination Consistency
 

.claude/commands-en/build.md

@@ -2,8 +2,6 @@
 description: Execute decomposed tasks in autonomous execution mode
 ---
 
-**Command Context**: This command is dedicated to the implementation phase with autonomous execution.
-
 Strictly follow @docs/guides/sub-agents.md and act as an orchestrator.
 
 Work plan: $ARGUMENTS
@@ -22,8 +20,6 @@ Before starting any task, always:
 
 Verify approval status before proceeding. Once confirmed, initiate autonomous execution mode.
 
-**Scope**: From task decomposition through implementation completion. Immediate halt upon detecting requirement changes.
-
 ## Output Example
 Implementation phase completed.
 - Task decomposition: Generated under docs/plans/tasks/

docs/design/template-en.md

@@ -14,11 +14,11 @@
 ### Agreement Checklist
 
 #### Scope
-- [ ] [Functions/components to change]
-- [ ] [Functions to add]
+- [ ] [Features/components to change]
+- [ ] [Features to add]
 
 #### Non-Scope (Explicitly not changing)
-- [ ] [Functions/components not to change]
+- [ ] [Features/components not to change]
 - [ ] [Existing logic to preserve]
 
 #### Constraints
@@ -28,11 +28,11 @@
 
 ### Problem to Solve
 
-[Specific problems or challenges this feature aims to solve]
+[Specific problems or challenges this feature aims to address]
 
 ### Current Challenges
 
-[Problems or limitations in the current system]
+[Current system issues or limitations]
 
 ### Requirements
 
@@ -42,58 +42,87 @@
 
 #### Non-Functional Requirements
 
-- **Performance**: [Requirements for response time, throughput, etc.]
+- **Performance**: [Response time, throughput requirements]
 - **Scalability**: [Requirements for handling increased load]
-- **Reliability**: [Requirements for error rate, availability, etc.]
-- **Maintainability**: [Code understandability, ease of modification]
+- **Reliability**: [Error rate, availability requirements]
+- **Maintainability**: [Code readability and changeability]
 
 ## Acceptance Criteria
 
-Define specific and verifiable conditions for determining successful implementation of each functional requirement.
-These conditions serve as the basis for test cases and are used to objectively judge implementation completion.
-(Note: Checkboxes remain empty at design time since implementation is not yet complete)
+Define specific and verifiable conditions that determine successful implementation for each functional requirement.
+These conditions serve as the basis for test cases and are used to objectively determine implementation completion.
+(Note: Checkboxes remain empty at design time as implementation is not yet complete)
 
 - [ ] [Specific acceptance criteria for functional requirement 1]
   - Example: "When user clicks login button, authentication succeeds with correct credentials"
-  - Example: "When invalid credentials are entered, appropriate error message displays"
+  - Example: "When credentials are invalid, appropriate error message is displayed"
 - [ ] [Specific acceptance criteria for functional requirement 2]
-  - Example: "In data list screen, pagination displays 10 items per page"
-  - Example: "When typing in search field, real-time filtering occurs"
+  - Example: "Data list screen displays with pagination of 10 items per page"
+  - Example: "When input is entered in search field, real-time filtering is applied"
 
 ## Existing Codebase Analysis
 
 ### Implementation Path Mapping
 | Type | Path | Description |
 |------|------|-------------|
-| Existing | src/[actual path] | [Current implementation] |
-| New | src/[planned path] | [Planned new creation] |
+| Existing | src/[actual-path] | [Current implementation] |
+| New | src/[planned-path] | [Planned new creation] |
 
-### Integration Points
-| Integration Point | Location | Old Implementation | New Implementation | Switch Method |
-|------------------|----------|-------------------|-------------------|---------------|
-| Point 1 | [Class/Function] | [Existing process] | [New process] | [DI/Factory etc.] |
-| Point 2 | [Another location] | [Existing] | [New] | [Method] |
+### Integration Points (Include even for new implementations)
+- **Integration Target**: [What to connect with]
+- **Invocation Method**: [How it will be invoked]
 
-### Main Components
+## Design
 
-#### Component 1
+### Change Impact Map
+
+```yaml
+Change Target: [Component/feature to change]
+Direct Impact:
+  - [Files/functions requiring direct changes]
+  - [Interface change points]
+Indirect Impact:
+  - [Data format changes]
+  - [Processing time changes]
+No Ripple Effect:
+  - [Explicitly specify unaffected features]
+```
+
+### Architecture Overview
+
+[How this feature is positioned within the overall system]
+
+### Data Flow
+
+```
+[Express data flow using diagrams or pseudo-code]
+```
 
-**Responsibility**: [What this component is responsible for]
+### Integration Points List
 
-**Input/Output**:
-- Input: [What it receives]
-- Output: [What it returns]
+| Integration Point | Location | Old Implementation | New Implementation | Switching Method |
+|-------------------|----------|-------------------|-------------------|------------------|
+| Integration Point 1 | [Class/Function] | [Existing Process] | [New Process] | [DI/Factory etc.] |
+| Integration Point 2 | [Another Location] | [Existing] | [New] | [Method] |
 
-**Dependencies**: [What other components it depends on]
+### Main Components
+
+#### Component 1
+
+- **Responsibility**: [Scope of responsibility for this component]
+- **Interface**: [APIs and type definitions provided]
+- **Dependencies**: [Relationships with other components]
 
 #### Component 2
 
-[Same format]
+- **Responsibility**: [Scope of responsibility for this component]
+- **Interface**: [APIs and type definitions provided]
+- **Dependencies**: [Relationships with other components]
 
-## Type Definitions
+### Type Definitions
 
 ```typescript
-// Include main type definitions here
+// Record major type definitions here
 ```
 
 ### Data Contract
@@ -108,17 +137,17 @@ Input:
 
 Output:
   Type: [TypeScript type definition]
-  Guarantees: [Conditions always satisfied]
+  Guarantees: [Conditions that must always be met]
   On Error: [Exception/null/default value]
 
 Invariants:
-  - [Conditions that remain unchanged before/after processing]
+  - [Conditions that remain unchanged before and after processing]
 ```
 
 ### State Transitions and Invariants (When Applicable)
 
 ```yaml
-State Definitions:
+State Definition:
   - Initial State: [Initial values and conditions]
   - Possible States: [List of states]
 
@@ -131,105 +160,111 @@ System Invariants:
 
 ### Error Handling
 
-[Types of errors and handling methods]
+[Types of errors and how to handle them]
 
-### Security Considerations
+### Logging and Monitoring
 
-[Security measures, authentication, authorization, data protection]
+[What to record in logs and how to monitor]
 
 ## Implementation Plan
 
 ### Phase Division
 
 #### Phase 1: [Phase Name]
-**Purpose**: [What this phase aims to achieve]
+**Purpose**: [What to achieve in this phase]
 
-**Implementation Content**:
+**Implementation Items**:
 - [Implementation item 1]
 - [Implementation item 2]
 
-(Duration goes to work plan)
+(Timeline goes to work plan document)
 
-**Phase Completion Criteria**:
-- [ ] [Functional completion criteria]
-- [ ] [Quality completion criteria]
+**Phase Completion Conditions**:
+- [ ] [Functional completion conditions]
+- [ ] [Quality completion conditions]
 
 **E2E Verification Procedures**:
 1. [Operation verification steps]
 2. [Expected result verification]
 3. [Performance verification (when applicable)]
 
 #### Phase 2: [Phase Name]
-**Purpose**: [What this phase aims to achieve]
+**Purpose**: [What to achieve in this phase]
 
-**Implementation Content**:
+**Implementation Items**:
 - [Implementation item 1]
 - [Implementation item 2]
 
-**Phase Completion Criteria**:
-- [ ] [Functional completion criteria]
-- [ ] [Quality completion criteria]
+**Phase Completion Conditions**:
+- [ ] [Functional completion conditions]
+- [ ] [Quality completion conditions]
 
 **E2E Verification Procedures**:
 1. [Operation verification steps]
 2. [Expected result verification]
 
 ### Migration Strategy
 
-[Technical migration approach, backward compatibility assurance methods]
+[Technical migration approach, ensuring backward compatibility]
 
 ## Test Strategy
 
-### Test Categories
+### Basic Test Design Policy
+
+Automatically derive test cases from acceptance criteria:
+- Create at least one test case for each acceptance criterion
+- Implement measurable standards from acceptance criteria as assertions
 
-#### Unit Tests
-- [Testing scope and methods]
-- Target coverage: [percentage]
+### Unit Tests
 
-#### Integration Tests
-- [What integration points to test]
+[Unit testing policy and coverage goals]
+- Verify individual elements of functional acceptance criteria
 
-#### E2E Tests
-- [Main scenarios to test]
+### Integration Tests
 
-### Test Data
+[Integration testing policy and important test cases]
+- Verify combined operations of functional acceptance criteria
 
-[Test data requirements and preparation methods]
+### E2E Tests
 
-## Performance and Monitoring
+[E2E testing policy]
+- Verify entire scenarios of acceptance criteria
+- Confirm functional operation from user perspective
 
-### Performance Targets
+### Performance Tests
 
-- Response time: [target value]
-- Throughput: [target value]
-- Resource usage: [memory, CPU, etc.]
+[Performance testing methods and standards]
+- Verify performance standards of non-functional acceptance criteria
 
-### Monitoring
+## Security Considerations
 
-[Metrics to monitor, logging strategy]
+[Security concerns and countermeasures]
 
-## Deployment and Operations
+## Future Extensibility
 
-### Deployment Strategy
+[Considerations for future feature additions or changes]
 
-[Deployment method, rollback plan]
+## Alternative Solutions
 
-### Feature Flags
+### Alternative 1
 
-[If feature flags are used, describe control method]
+- **Overview**: [Description of alternative solution]
+- **Advantages**: [Advantages]
+- **Disadvantages**: [Disadvantages]
+- **Reason for Rejection**: [Why it wasn't adopted]
 
 ## Risks and Mitigation
 
 | Risk | Impact | Probability | Mitigation |
 |------|--------|-------------|------------|
-| [Risk 1] | [High/Medium/Low] | [High/Medium/Low] | [Countermeasure] |
-| [Risk 2] | [High/Medium/Low] | [High/Medium/Low] | [Countermeasure] |
+| [Risk 1] | High/Medium/Low | High/Medium/Low | [Countermeasure] |
 
-## Open Questions
+## References
 
-- [ ] [Question 1]
-- [ ] [Question 2]
+- [Related documentation and links]
 
-## References
+## Update History
 
-- [Related documentation, technical articles, etc.]
+| Date | Version | Changes | Author |
+|------|---------|---------|--------|
+| YYYY-MM-DD | 1.0 | Initial version | [Name] |