遷移用プロンプトをすべてworkflowに

resources/global/en/agents/default/architect.md

@@ -251,20 +251,12 @@ When review count is provided (e.g., "Review count: 3rd"), adjust judgment accor
 2. If recurring, suggest **alternative approaches** rather than detailed fixes
 3. Even when REJECTing, include perspective that "a different approach should be considered"
 
-```
+Example: When issues repeat on the 3rd review
-[ARCHITECT:REJECT]
 
-### Issues
+- Point out the normal issues
-(Normal feedback)
+- Note that the same type of issues are recurring
-
+- Explain the limitations of the current approach
-### Reconsidering the Approach
+- Present alternatives (e.g., redesign with a different pattern, introduce new technology)
-Same issues continue through the 3rd review.
-The current approach may be fundamentally problematic.
-
-Alternatives:
-- Option A: Redesign with xxx pattern
-- Option B: Introduce yyy
-```
 
 **Point**: Rather than repeating "fix this again", step back and suggest a different path.
 

resources/global/en/agents/expert-review/cqrs-es-reviewer.md

@@ -149,41 +149,6 @@ OrderUpdated, OrderDeleted
 | Insufficient consideration of eventual consistency | REJECT |
 | Minor improvements only | APPROVE (with suggestions) |
 
-## Output Format
-
-| Situation | Tag |
-|-----------|-----|
-| No issues from CQRS+ES perspective | `[CQRS-ES:APPROVE]` |
-| Design issues exist | `[CQRS-ES:REJECT]` |
-
-### REJECT Structure
-
-```
-[CQRS-ES:REJECT]
-
-### Issues
-
-1. **Issue Title**
-   - Location: filepath:line
-   - Problem: Specific CQRS/ES principle violation
-   - Fix: Correct pattern suggestion
-
-### CQRS+ES Recommendations
-- Specific design improvement advice
-```
-
-### APPROVE Structure
-
-```
-[CQRS-ES:APPROVE]
-
-### Good Points
-- List good designs following CQRS+ES principles
-
-### Improvement Suggestions (optional)
-- Further optimization opportunities if any
-```
-
 ## Communication Style
 
 - Use DDD terminology accurately

resources/global/en/agents/expert-review/frontend-reviewer.md

@@ -209,41 +209,6 @@ function UserPage() {
 | Performance issues | REJECT (if serious) |
 | Minor improvements only | APPROVE (with suggestions) |
 
-## Output Format
-
-| Situation | Tag |
-|-----------|-----|
-| No issues from frontend perspective | `[FRONTEND:APPROVE]` |
-| Design issues exist | `[FRONTEND:REJECT]` |
-
-### REJECT Structure
-
-```
-[FRONTEND:REJECT]
-
-### Issues
-
-1. **Issue Title**
-   - Location: filepath:line
-   - Problem: Specific frontend design principle violation
-   - Fix: Correct pattern suggestion
-
-### Frontend Recommendations
-- Specific design improvement advice
-```
-
-### APPROVE Structure
-
-```
-[FRONTEND:APPROVE]
-
-### Good Points
-- List good designs following frontend principles
-
-### Improvement Suggestions (optional)
-- Further optimization opportunities if any
-```
-
 ## Communication Style
 
 - Always consider user experience

resources/global/en/agents/expert-review/qa-reviewer.md

@@ -209,42 +209,6 @@ describe('OrderService', () => {
 | Serious maintainability problems | REJECT |
 | Minor improvements only | APPROVE (with suggestions) |
 
-## Output Format
-
-| Situation | Tag |
-|-----------|-----|
-| Quality standards met | `[QA:APPROVE]` |
-| Quality issues exist | `[QA:REJECT]` |
-
-### REJECT Structure
-
-```
-[QA:REJECT]
-
-### Issues
-
-1. **Issue Title** [Category: Testing/Documentation/Maintainability]
-   - Location: filepath:line
-   - Problem: Specific issue description
-   - Impact: What happens if this is left unaddressed
-   - Fix: Specific remediation method
-
-### QA Recommendations
-- Additional quality improvement advice
-```
-
-### APPROVE Structure
-
-```
-[QA:APPROVE]
-
-### Good Points
-- List excellent quality aspects
-
-### Improvement Suggestions (optional)
-- Further quality improvement opportunities if any
-```
-
 ## Communication Style
 
 - Emphasize importance of quality

resources/global/en/agents/expert-review/security-reviewer.md

@@ -170,43 +170,6 @@ Always verify:
 | Low risk but should improve | APPROVE (with suggestions) |
 | No security issues | APPROVE |
 
-## Output Format
-
-| Situation | Tag |
-|-----------|-----|
-| No security issues | `[SECURITY:APPROVE]` |
-| Vulnerabilities exist | `[SECURITY:REJECT]` |
-
-### REJECT Structure
-
-```
-[SECURITY:REJECT]
-
-### Vulnerabilities
-
-1. **Vulnerability Name** [Severity: High/Medium/Low]
-   - Location: filepath:line
-   - Problem: Specific vulnerability description
-   - Attack Scenario: How it could be exploited
-   - Fix: Specific remediation method
-   - Reference: CWE number, OWASP reference, etc.
-
-### Security Recommendations
-- Additional defensive measures
-```
-
-### APPROVE Structure
-
-```
-[SECURITY:APPROVE]
-
-### Verified Items
-- List security aspects that were verified
-
-### Recommendations (optional)
-- Further hardening opportunities if any
-```
-
 ## Communication Style
 
 - Strictly point out found vulnerabilities

resources/global/en/agents/expert-review/supervisor.md

@@ -108,68 +108,6 @@ May approve conditionally when:
 2. Recorded as technical debt with planned remediation
 3. Urgent release needed for business reasons
 
-## Output Format
-
-| Situation | Tag |
-|-----------|-----|
-| Ready for release | `[SUPERVISOR:APPROVE]` |
-| Fixes needed | `[SUPERVISOR:REJECT]` |
-
-### APPROVE Structure
-
-```
-[SUPERVISOR:APPROVE]
-
-### Summary
-- Overview of implementation (1-2 sentences)
-
-### Review Results
-| Domain | Result | Notes |
-|--------|--------|-------|
-| CQRS+ES | APPROVE | - |
-| Frontend | APPROVE | Minor improvement suggestions |
-| Security | APPROVE | - |
-| QA | APPROVE | - |
-
-### Good Points
-- Excellent aspects throughout
-
-### Future Improvements (optional)
-- Items to consider as follow-up tasks
-```
-
-### REJECT Structure
-
-```
-[SUPERVISOR:REJECT]
-
-### Summary
-- Overview of issues (1-2 sentences)
-
-### Review Results
-| Domain | Result | Notes |
-|--------|--------|-------|
-| CQRS+ES | APPROVE | - |
-| Frontend | REJECT | Component design issues |
-| Security | APPROVE | - |
-| QA | REJECT | Insufficient tests |
-
-### Items Requiring Fix
-
-**Priority: High**
-1. [Frontend] Component splitting
-   - Details: UserPage component exceeds 300 lines
-   - Action: Separate into Container/Presentational
-
-**Priority: Medium**
-2. [QA] Add tests
-   - Details: No unit tests for new feature
-   - Action: Add tests for calculateTotal function
-
-### Next Actions
-- Coder should address fixes in priority order above
-```
-
 ## Communication Style
 
 - Fair and objective

resources/global/en/agents/magi/balthasar.md

@@ -45,26 +45,6 @@ Assume the worst case. When it fails, who gets hurt and how? Is recovery possibl
 - When conveying concerns, worry rather than blame
 - Suggest long-term perspectives
 
-## Judgment Format
-
-```
-## BALTHASAR-2 Analysis
-
-### Human Impact Evaluation
-[Impact on people involved - workload, motivation, growth opportunities]
-
-### Sustainability Perspective
-[Concerns and expectations from a long-term view]
-
-### Judgment Reasoning
-[Reasons for judgment - focusing on impact on people and teams]
-
-### Judgment
-[BALTHASAR:APPROVE] or [BALTHASAR:REJECT] or [BALTHASAR:CONDITIONAL]
-```
-
-CONDITIONAL is conditional approval. Conditions must always include "safeguards to protect people."
-
 ## Important
 
 - Don't judge on pure efficiency alone

resources/global/en/agents/magi/casper.md

@@ -48,47 +48,6 @@ If the project dies, ideals and correct arguments become meaningless. Survive fi
 - Navigate between true feelings and appearances
 - Show decisiveness in the end
 
-## Output Format
-
-**Always output the final judgment for the MAGI system in this format:**
-
-```
-## CASPER-3 Analysis
-
-### Practical Evaluation
-[Realistic feasibility, resources, timing]
-
-### Political Considerations
-[Stakeholders, dynamics, risks]
-
-### Compromise Proposal (if any)
-[Realistic landing point]
-
----
-
-## MAGI System Final Judgment
-
-| System | Judgment | Key Point |
-|--------|----------|-----------|
-| MELCHIOR-1 | [APPROVE/REJECT/CONDITIONAL] | [One-line summary] |
-| BALTHASAR-2 | [APPROVE/REJECT/CONDITIONAL] | [One-line summary] |
-| CASPER-3 | [APPROVE/REJECT/CONDITIONAL] | [One-line summary] |
-
-### Alignment of the Three Perspectives
-[Points of agreement and disagreement]
-
-### Conclusion
-[Tally results and reasoning for final judgment]
-
-[MAGI:APPROVE] or [MAGI:REJECT] or [MAGI:CONDITIONAL]
-```
-
-## Final Judgment Rules
-
-- **2+ in favor** -> `[MAGI:APPROVE]`
-- **2+ against** -> `[MAGI:REJECT]`
-- **Split opinions/majority conditional** -> `[MAGI:CONDITIONAL]` (specify conditions)
-
 ## Important
 
 - Don't judge on idealism alone
@@ -96,5 +55,4 @@ If the project dies, ideals and correct arguments become meaningless. Survive fi
 - Find compromise points
 - Sometimes be prepared to play the dirty role
 - Be the most realistic among the three
-- **Always output final judgment in `[MAGI:...]` format**
 - In the end, I'm the one who decides

resources/global/en/agents/magi/melchior.md

@@ -45,26 +45,6 @@ Demand evidence for all claims. "Everyone thinks so" is not evidence. "There's p
 - Prefer expressions like "should" and "is"
 - Avoid ambiguous expressions
 
-## Judgment Format
-
-```
-## MELCHIOR-1 Analysis
-
-### Technical Evaluation
-[Logical and technical analysis]
-
-### Quantitative Perspective
-[Evaluable metrics that can be quantified]
-
-### Judgment Reasoning
-[Logical basis for the judgment - based on data and facts]
-
-### Judgment
-[MELCHIOR:APPROVE] or [MELCHIOR:REJECT] or [MELCHIOR:CONDITIONAL]
-```
-
-CONDITIONAL is conditional approval (approve if X). Conditions must be specific and verifiable.
-
 ## Important
 
 - Don't judge based on emotional reasons

resources/global/en/agents/research/digger.md

@@ -36,45 +36,6 @@ You follow the research plan from the Planner and **actually execute the researc
    - If related information exists, investigate further
 3. Create report when all complete
 
-## Output Format
-
-```
-## Research Results Report
-
-### Results by Research Item
-
-#### 1. [Research Item Name]
-**Result**: [Summary of research result]
-
-**Details**:
-[Specific data, URLs, quotes, etc.]
-
-**Additional Notes**:
-[Related information discovered additionally]
-
----
-
-#### 2. [Research Item Name]
-...
-
-### Summary
-
-#### Key Findings
-- [Important finding 1]
-- [Important finding 2]
-
-#### Caveats/Risks
-- [Discovered risks]
-
-#### Items Unable to Research
-- [Item]: [Reason]
-
-### Recommendation/Conclusion
-[Recommendations based on research results]
-
-[DIGGER:DONE]
-```
-
 ## Example: Naming Research Results
 
 ```
@@ -123,8 +84,6 @@ Scoped packages (@yourname/wolf etc.) can be used
 1. Least GitHub collisions
 2. npm addressable via scoped packages
 3. "Hawk" image fits surveillance/hunting tools
-
-[DIGGER:DONE]
 ```
 
 ## Important

resources/global/en/agents/research/planner.md

@@ -42,38 +42,6 @@ Assign priorities to research items:
 - P2: Important (improves answer quality)
 - P3: Nice to have (if time permits)
 
-## Output Format
-
-```
-## Research Plan
-
-### Understanding the Request
-[Summary and interpretation of the request]
-
-### Research Items
-
-#### P1: Required
-1. [Research item 1]
-   - Purpose: [Why investigate this]
-   - Method: [How to investigate]
-
-2. [Research item 2]
-   ...
-
-#### P2: Important
-1. [Research item]
-   ...
-
-#### P3: Nice to have
-1. [Research item]
-   ...
-
-### Instructions for Digger
-[Specific bullet points of what to research]
-
-[PLANNER:DONE]
-```
-
 ## Example: Naming Research
 
 Request: "I want to decide a project name. Candidates are wolf, fox, hawk"
@@ -114,8 +82,6 @@ Gather information to judge adoption feasibility for three project name candidat
 - Check npm, PyPI for same-name packages
 - Research general image/associations for each name
 - Check anagram possibilities
-
-[PLANNER:DONE]
 ```
 
 ## Important

resources/global/en/agents/research/supervisor.md

@@ -43,42 +43,6 @@ When all of these are met:
 - Research results are shallow (not concrete)
 - Sources unclear
 
-## Output Format
-
-### When Approved
-```
-## Research Evaluation
-
-### Evaluation Result: Approved
-
-### Evaluation Summary
-- Answer relevance: ✓ [Comment]
-- Research comprehensiveness: ✓ [Comment]
-- Information reliability: ✓ [Comment]
-
-### Research Results Summary
-[Brief summary of research results]
-
-[SUPERVISOR:APPROVE]
-```
-
-### When Returned
-```
-## Research Evaluation
-
-### Evaluation Result: Returned
-
-### Issues
-1. [Issue 1]
-2. [Issue 2]
-
-### Instructions for Planner
-- [Specifically what should be included in the plan]
-- [What perspectives to re-research from]
-
-[SUPERVISOR:REJECT]
-```
-
 ## Important
 
 - **Point out specifically**: Not "insufficient" but "XX is missing"

resources/global/en/workflows/default.yaml

@@ -18,12 +18,39 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## Status Output Format
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
 
-      Output analysis results with the following tags:
+      ## Judgment Criteria
-      - [PLANNER:DONE] Analysis complete
+
-      - [PLANNER:BLOCKED] Insufficient info (list clarifications needed)
+      | Situation | Judgment |
+      |-----------|----------|
+      | Requirements clear and implementable | DONE |
+      | Requirements unclear, insufficient info | BLOCKED |
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Analysis complete | `[PLANNER:DONE]` |
+      | Insufficient info | `[PLANNER:BLOCKED]` |
+
+      ### Output Examples
+
+      **DONE case:**
+      ```
+      [PLANNER:DONE]
+      ```
+
+      **BLOCKED case:**
+      ```
+      [PLANNER:BLOCKED]
+
+      Clarifications needed:
+      - {Question 1}
+      - {Question 2}
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -91,14 +118,37 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## Status Output Format
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
 
-      Always include these tags when work is complete:
+      ## Output Format
-      - [CODER:DONE] Implementation complete
+
-      - [CODER:BLOCKED] Cannot decide/insufficient info
+      | Situation | Tag |
+      |-----------|-----|
+      | Implementation complete | `[CODER:DONE]` |
+      | Cannot decide/insufficient info | `[CODER:BLOCKED]` |
 
       **Important**: When in doubt, `[BLOCKED]`. Don't decide on your own.
+
+      ### Output Examples
+
+      **DONE case:**
+      ```
+      Implementation complete.
+      - Created: `src/auth/service.ts`, `tests/auth.test.ts`
+      - Modified: `src/routes.ts`
+
+      [CODER:DONE]
+      ```
+
+      **BLOCKED case:**
+      ```
+      [CODER:BLOCKED]
+
+      Reason: DB schema is undefined, cannot implement
+      Required info: users table structure
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -165,7 +215,10 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
       ## Judgment Criteria
 
       | Situation | Judgment |
@@ -174,48 +227,49 @@ steps:
       | Design principle violations | REJECT |
       | Security issues | REJECT |
       | Insufficient tests | REJECT |
-      | Improvements needed (non-blocking but should be addressed) | IMPROVE |
+      | Minor improvements needed | IMPROVE |
       | No issues | APPROVE |
 
       **How to use IMPROVE:**
       - Design is acceptable but there are points that could be better
-      - Minor issues you want fixed before proceeding to next step
       - Examples: naming improvements, small refactoring, adding comments
 
-      ## Status Output Format
+      ## Output Format
 
-      Output review results with the following tags:
+      | Situation | Tag |
-      - [ARCHITECT:APPROVE] No issues
+      |-----------|-----|
-      - [ARCHITECT:IMPROVE] Minor improvements needed
+      | No issues | `[ARCHITECT:APPROVE]` |
-      - [ARCHITECT:REJECT] Structural changes required
+      | Minor improvements needed | `[ARCHITECT:IMPROVE]` |
+      | Structural changes required | `[ARCHITECT:REJECT]` |
 
       ### Output Examples
 
-      **REJECT case:**
-      ```
-      [ARCHITECT:REJECT]
-
-      ### Issues
-
-      1. **File Size Exceeded**
-         - Location: `src/services/user.ts` (523 lines)
-         - Problem: Authentication, permissions, and profile management mixed in single file
-         - Fix: Split into 3 files:
-           - `src/services/auth.ts` - Authentication
-           - `src/services/permission.ts` - Permissions
-           - `src/services/profile.ts` - Profile
-      ```
-
       **APPROVE case:**
       ```
       [ARCHITECT:APPROVE]
 
-      ### Positive Points
+      Positive points:
       - Appropriate module organization
       - Single responsibility maintained
+      ```
 
-      ### Improvement Suggestions (Optional)
+      **IMPROVE case:**
-      - Consider organizing shared utilities in `utils/` in the future
+      ```
+      [ARCHITECT:IMPROVE]
+
+      Improvements:
+      - Improve naming: `data` → `userData`
+      - Add comments
+      ```
+
+      **REJECT case:**
+      ```
+      [ARCHITECT:REJECT]
+
+      Issues:
+      1. File size exceeded
+         - Location: `src/services/user.ts` (523 lines)
+         - Fix: Split into 3 files
       ```
     instruction_template: |
       ## Workflow Context
@@ -287,12 +341,37 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## Status Output Format
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
 
-      Always include these tags when work is complete:
+      ## Output Format
-      - [CODER:DONE] Improvements complete
+
-      - [CODER:BLOCKED] Cannot decide/insufficient info
+      | Situation | Tag |
+      |-----------|-----|
+      | Improvements complete | `[CODER:DONE]` |
+      | Cannot decide/insufficient info | `[CODER:BLOCKED]` |
+
+      **Important**: When in doubt, `[BLOCKED]`. Don't decide on your own.
+
+      ### Output Examples
+
+      **DONE case:**
+      ```
+      Improvements complete.
+      - Improved naming: `data` → `userData`
+      - Added comments
+
+      [CODER:DONE]
+      ```
+
+      **BLOCKED case:**
+      ```
+      [CODER:BLOCKED]
+
+      Reason: Improvement intent unclear
+      Required info: Specific improvement details
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -332,7 +411,10 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
       ## Judgment Criteria
 
       | Situation | Judgment |
@@ -344,13 +426,31 @@ steps:
       | Minor style deviations only | APPROVE |
       | Code fits context and works | APPROVE |
 
-      **Note:** Scope creep is noted as a warning but doesn't warrant REJECT alone. Some tasks require large changes.
+      **Note:** Scope creep is noted as a warning but doesn't warrant REJECT alone.
 
-      ## Status Output Format
+      ## Output Format
 
-      Output review results with the following tags:
+      | Situation | Tag |
-      - [AI_REVIEW:APPROVE] No AI-specific issues
+      |-----------|-----|
-      - [AI_REVIEW:REJECT] Issues found
+      | No AI-specific issues | `[AI_REVIEW:APPROVE]` |
+      | Issues found | `[AI_REVIEW:REJECT]` |
+
+      ### Output Examples
+
+      **APPROVE case:**
+      ```
+      [AI_REVIEW:APPROVE]
+
+      Verification result: No issues
+      ```
+
+      **REJECT case:**
+      ```
+      [AI_REVIEW:REJECT]
+
+      Issues:
+      1. Non-existent API used: `fetch.json()` → `response.json()`
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -420,12 +520,36 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## Status Output Format
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
 
-      Always include these tags when work is complete:
+      ## Output Format
-      - [CODER:DONE] Fixes complete
+
-      - [CODER:BLOCKED] Cannot decide/insufficient info
+      | Situation | Tag |
+      |-----------|-----|
+      | AI issue fixes complete | `[CODER:DONE]` |
+      | Cannot decide/insufficient info | `[CODER:BLOCKED]` |
+
+      **Important**: When in doubt, `[BLOCKED]`. Don't decide on your own.
+
+      ### Output Examples
+
+      **DONE case:**
+      ```
+      Fixed AI Reviewer's issues.
+      - Fixed non-existent API: `fetch.json()` → `response.json()`
+
+      [CODER:DONE]
+      ```
+
+      **BLOCKED case:**
+      ```
+      [CODER:BLOCKED]
+
+      Reason: Fix method unclear
+      Required info: Alternative API specification
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -463,21 +587,43 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
       ## Judgment Criteria
 
       | Situation | Judgment |
       |-----------|----------|
-      | Critical vulnerability (Immediate REJECT) | REJECT |
+      | Critical vulnerability | REJECT |
       | Medium severity vulnerability | REJECT |
       | Minor issues/warnings only | APPROVE (note warnings) |
       | No security issues | APPROVE |
 
-      ## Status Output Format
+      ## Output Format
 
-      Output review results with the following tags:
+      | Situation | Tag |
-      - [SECURITY:APPROVE] No security issues
+      |-----------|-----|
-      - [SECURITY:REJECT] Vulnerabilities require fixes
+      | No security issues | `[SECURITY:APPROVE]` |
+      | Vulnerabilities require fixes | `[SECURITY:REJECT]` |
+
+      ### Output Examples
+
+      **APPROVE case:**
+      ```
+      [SECURITY:APPROVE]
+
+      No security issues detected.
+      ```
+
+      **REJECT case:**
+      ```
+      [SECURITY:REJECT]
+
+      Vulnerabilities:
+      1. SQL Injection: `src/db.ts:42`
+         Fix: Use parameterized query
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -550,12 +696,36 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## Status Output Format
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
 
-      Always include these tags when work is complete:
+      ## Output Format
-      - [CODER:DONE] Security fixes complete
+
-      - [CODER:BLOCKED] Cannot decide/insufficient info
+      | Situation | Tag |
+      |-----------|-----|
+      | Security fixes complete | `[CODER:DONE]` |
+      | Cannot decide/insufficient info | `[CODER:BLOCKED]` |
+
+      **Important**: Security issues require highest priority.
+
+      ### Output Examples
+
+      **DONE case:**
+      ```
+      Fixed security issues.
+      - SQL injection fix: Changed to parameterized query
+
+      [CODER:DONE]
+      ```
+
+      **BLOCKED case:**
+      ```
+      [CODER:BLOCKED]
+
+      Reason: Fix method unclear
+      Required info: Auth library specification
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -592,12 +762,37 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## Status Output Format
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
 
-      Always include these tags when work is complete:
+      ## Output Format
-      - [CODER:DONE] Fixes complete
+
-      - [CODER:BLOCKED] Cannot decide/insufficient info
+      | Situation | Tag |
+      |-----------|-----|
+      | Architect's issues fixed | `[CODER:DONE]` |
+      | Cannot decide/insufficient info | `[CODER:BLOCKED]` |
+
+      **Important**: When in doubt, `[BLOCKED]`. Don't decide on your own.
+
+      ### Output Examples
+
+      **DONE case:**
+      ```
+      Fixed Architect's issues.
+      - File split: Split into 3 files
+      - Added type definitions
+
+      [CODER:DONE]
+      ```
+
+      **BLOCKED case:**
+      ```
+      [CODER:BLOCKED]
+
+      Reason: Fix approach unclear
+      Required info: Specific split method
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -633,7 +828,10 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
       ## Judgment Criteria
 
       | Situation | Judgment |
@@ -646,11 +844,33 @@ steps:
 
       **Principle**: When in doubt, REJECT. Don't give ambiguous approval.
 
-      ## Status Output Format
+      ## Output Format
 
-      Output verification results with the following tags:
+      | Situation | Tag |
-      - [SUPERVISOR:APPROVE] if ready to merge
+      |-----------|-----|
-      - [SUPERVISOR:REJECT] if issues found (specify the issues)
+      | Final approval | `[SUPERVISOR:APPROVE]` |
+      | Return for fixes | `[SUPERVISOR:REJECT]` |
+
+      ### Output Examples
+
+      **APPROVE case:**
+      ```
+      [SUPERVISOR:APPROVE]
+
+      Verification results:
+      - Tests: ✅ All passed
+      - Build: ✅ Succeeded
+      - Requirements met: ✅
+      ```
+
+      **REJECT case:**
+      ```
+      [SUPERVISOR:REJECT]
+
+      Issues:
+      1. Tests failing: `npm test` - 2 failures
+      2. Requirements not met: Login feature not implemented
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}

resources/global/en/workflows/expert-review.yaml

@@ -30,6 +30,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Analysis complete | `[PLANNER:DONE]` |
+      | Requirements unclear | `[PLANNER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -103,6 +113,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Implementation complete | `[CODER:DONE]` |
+      | Cannot proceed | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -175,6 +195,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Design is sound | `[CQRS-ES:APPROVE]` |
+      | Design issues found | `[CQRS-ES:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -252,6 +282,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Fix complete | `[CODER:DONE]` |
+      | Cannot proceed | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -296,6 +336,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Frontend design is sound | `[FRONTEND:APPROVE]` |
+      | Design issues found | `[FRONTEND:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -373,6 +423,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Fix complete | `[CODER:DONE]` |
+      | Cannot proceed | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -417,6 +477,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | No AI-specific issues | `[AI_REVIEW:APPROVE]` |
+      | Issues found | `[AI_REVIEW:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -490,6 +560,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Fix complete | `[CODER:DONE]` |
+      | Cannot proceed | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -532,6 +612,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | No security issues | `[SECURITY:APPROVE]` |
+      | Vulnerabilities found | `[SECURITY:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -606,6 +696,17 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Minor fix complete | `[CODER:DONE]` |
+      | Major fix (restart from CQRS+ES) | `[CODER:REJECT]` |
+      | Cannot proceed | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -659,6 +760,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Quality standards met | `[QA:APPROVE]` |
+      | Quality issues found | `[QA:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -733,6 +844,18 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Minor fix complete | `[CODER:DONE]` |
+      | Security-impacting fix | `[CODER:IMPROVE]` |
+      | Major fix (restart from CQRS+ES) | `[CODER:REJECT]` |
+      | Cannot proceed | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -790,6 +913,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Ready to merge | `[SUPERVISOR:APPROVE]` |
+      | Issues found | `[SUPERVISOR:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -906,6 +1039,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Fix complete | `[CODER:DONE]` |
+      | Cannot proceed | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}

resources/global/en/workflows/magi.yaml

@@ -16,6 +16,25 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Judgment | Tag |
+      |----------|-----|
+      | In favor | `[MELCHIOR:APPROVE]` |
+      | Against | `[MELCHIOR:REJECT]` |
+      | Conditional approval | `[MELCHIOR:CONDITIONAL]` |
+
+      ### Output Example
+
+      ```
+      [MELCHIOR:APPROVE]
+
+      Reason: {Reason for approval}
+      ```
     instruction_template: |
       # MAGI System Initiated
 
@@ -25,11 +44,6 @@ steps:
       ## Instructions
       You are MELCHIOR-1 of the MAGI System.
       Analyze the above from the perspective of a scientist/engineer and render your judgment.
-
-      Your judgment must be one of:
-      - [MELCHIOR:APPROVE] - In favor
-      - [MELCHIOR:REJECT] - Against
-      - [MELCHIOR:CONDITIONAL] - Conditional approval
     transitions:
       - condition: always
         next_step: balthasar
@@ -42,6 +56,25 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Judgment | Tag |
+      |----------|-----|
+      | In favor | `[BALTHASAR:APPROVE]` |
+      | Against | `[BALTHASAR:REJECT]` |
+      | Conditional approval | `[BALTHASAR:CONDITIONAL]` |
+
+      ### Output Example
+
+      ```
+      [BALTHASAR:APPROVE]
+
+      Reason: {Reason for approval}
+      ```
     instruction_template: |
       # MAGI System Continuing
 
@@ -55,11 +88,6 @@ steps:
       You are BALTHASAR-2 of the MAGI System.
       Analyze the above from the perspective of a nurturer and render your judgment.
       Consider MELCHIOR's judgment as reference, but make your own independent assessment.
-
-      Your judgment must be one of:
-      - [BALTHASAR:APPROVE] - In favor
-      - [BALTHASAR:REJECT] - Against
-      - [BALTHASAR:CONDITIONAL] - Conditional approval
     pass_previous_response: true
     transitions:
       - condition: always
@@ -73,6 +101,35 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      Final conclusion by majority vote:
+
+      | Judgment | Tag |
+      |----------|-----|
+      | Approved (2+ in favor) | `[MAGI:APPROVE]` |
+      | Rejected (2+ against) | `[MAGI:REJECT]` |
+      | Conditional approval | `[MAGI:CONDITIONAL]` |
+
+      ### Output Example
+
+      ```
+      ## MAGI System Final Judgment
+
+      | System | Judgment |
+      |--------|----------|
+      | MELCHIOR-1 | APPROVE |
+      | BALTHASAR-2 | CONDITIONAL |
+      | CASPER-3 | APPROVE |
+
+      **Conclusion: [MAGI:APPROVE]**
+
+      [Reasoning/Summary]
+      ```
     instruction_template: |
       # MAGI System Final Deliberation
 
@@ -87,27 +144,6 @@ steps:
       Analyze the above from a practical/realistic perspective and render your judgment.
 
       **Finally, tally the judgments from all three and provide the final conclusion.**
-
-      ### Final Conclusion (Required)
-      Determine the final judgment by majority vote:
-      - [MAGI:APPROVE] - Approved (2 or more in favor)
-      - [MAGI:REJECT] - Rejected (2 or more against)
-      - [MAGI:CONDITIONAL] - Conditional approval (majority conditional or split opinions)
-
-      **Final Conclusion Format Example:**
-      ```
-      ## MAGI System Final Judgment
-
-      | System | Judgment |
-      |--------|----------|
-      | MELCHIOR-1 | APPROVE |
-      | BALTHASAR-2 | CONDITIONAL |
-      | CASPER-3 | APPROVE |
-
-      **Conclusion: [MAGI:APPROVE]**
-
-      [Reasoning/Summary]
-      ```
     pass_previous_response: true
     transitions:
       - condition: always

resources/global/en/workflows/research.yaml

@@ -20,6 +20,31 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Plan complete | `[PLANNER:DONE]` |
+      | Insufficient info | `[PLANNER:BLOCKED]` |
+
+      ### Output Examples
+
+      **DONE case:**
+      ```
+      [PLANNER:DONE]
+      ```
+
+      **BLOCKED case:**
+      ```
+      [PLANNER:BLOCKED]
+
+      Clarifications needed:
+      - {Question 1}
+      ```
     instruction_template: |
       ## Workflow Status
       - Iteration: {iteration}/{max_iterations}
@@ -41,8 +66,6 @@ steps:
       - Make assumptions for unclear points and proceed
       - If multiple interpretations exist, include all in the research scope
       - If there is feedback from Supervisor, incorporate it into the plan
-
-      Output [PLANNER:DONE] when the plan is complete.
     pass_previous_response: true
     transitions:
       - condition: done
@@ -58,6 +81,30 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Research complete | `[DIGGER:DONE]` |
+      | Unable to research | `[DIGGER:BLOCKED]` |
+
+      ### Output Examples
+
+      **DONE case:**
+      ```
+      [DIGGER:DONE]
+      ```
+
+      **BLOCKED case:**
+      ```
+      [DIGGER:BLOCKED]
+
+      Reason: {Why research was not possible}
+      ```
     instruction_template: |
       ## Workflow Status
       - Iteration: {iteration}/{max_iterations}
@@ -84,8 +131,6 @@ steps:
       - GitHub search (gh command)
       - Codebase search
       - File reading
-
-      Output [DIGGER:DONE] when the research is complete.
     pass_previous_response: true
     transitions:
       - condition: done
@@ -101,6 +146,40 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # Status Output Rules
+      Your final output MUST include a status tag following the rules below.
+
+      ## Judgment Criteria
+
+      | Situation | Judgment |
+      |-----------|----------|
+      | Research results sufficient | APPROVE |
+      | Research results insufficient | REJECT |
+
+      ## Output Format
+
+      | Situation | Tag |
+      |-----------|-----|
+      | Research complete, results sufficient | `[SUPERVISOR:APPROVE]` |
+      | Insufficient, restart from planning | `[SUPERVISOR:REJECT]` |
+
+      ### Output Examples
+
+      **APPROVE case:**
+      ```
+      [SUPERVISOR:APPROVE]
+
+      Research results adequately answer the original request.
+      ```
+
+      **REJECT case:**
+      ```
+      [SUPERVISOR:REJECT]
+
+      Missing:
+      - {Specific missing items}
+      ```
     instruction_template: |
       ## Workflow Status
       - Iteration: {iteration}/{max_iterations}
@@ -115,10 +194,6 @@ steps:
       ## Instructions
       Evaluate the research results and determine if they adequately answer the original request.
 
-      **Evaluation Output**:
-      - [SUPERVISOR:APPROVE] - Research complete, results are sufficient
-      - [SUPERVISOR:REJECT] - Insufficient, restart from planning (specify what's missing)
-
       **Important**: If there are issues, include specific instructions for the Planner.
     pass_previous_response: true
     transitions:

resources/global/ja/agents/default/architect.md

@@ -251,20 +251,12 @@ Vertical Slice の判定基準:
 2. 繰り返されている場合、細かい修正指示ではなく**アプローチ自体の代替案**を提示
 3. REJECTする場合でも、「別のアプローチを検討すべき」という観点を含める
 
-```
+例: 3回目のレビューで問題が繰り返される場合
-[ARCHITECT:REJECT]
 
-### 問題点
+- 通常の問題点を指摘
-（通常の指摘）
+- 同じ種類の問題が繰り返されていることを明記
-
+- 現在のアプローチの限界を説明
-### アプローチの再検討
+- 代替案を提示（例: 別のパターンで再設計、新技術の導入など）
-3回目のレビューで同様の問題が続いています。
-現在のアプローチでは解決が困難な可能性があります。
-
-代替案:
-- 案A: xxxパターンで再設計
-- 案B: yyyの導入
-```
 
 **ポイント**: 「もう一度修正して」と繰り返すより、立ち止まって別の道を示す。
 

resources/global/ja/agents/expert-review/cqrs-es-reviewer.md

@@ -149,41 +149,6 @@ OrderUpdated, OrderDeleted
 | 結果整合性の考慮不足 | REJECT |
 | 軽微な改善点のみ | APPROVE（改善提案は付記） |
 
-## 出力フォーマット
-
-| 状況 | タグ |
-|------|------|
-| CQRS+ES観点で問題なし | `[CQRS-ES:APPROVE]` |
-| 設計上の問題あり | `[CQRS-ES:REJECT]` |
-
-### REJECT の構造
-
-```
-[CQRS-ES:REJECT]
-
-### 問題点
-
-1. **問題のタイトル**
-   - 場所: ファイルパス:行番号
-   - 問題: CQRS/ES原則違反の具体的説明
-   - 修正案: 正しいパターンの提示
-
-### CQRS+ES観点での推奨事項
-- 設計改善の具体的なアドバイス
-```
-
-### APPROVE の構造
-
-```
-[CQRS-ES:APPROVE]
-
-### 良い点
-- CQRS+ESの原則に沿った良い設計を列挙
-
-### 改善提案（任意）
-- さらなる最適化の余地があれば
-```
-
 ## 口調の特徴
 
 - ドメイン駆動設計の用語を正確に使う

resources/global/ja/agents/expert-review/frontend-reviewer.md

@@ -209,41 +209,6 @@ function UserPage() {
 | パフォーマンス問題 | REJECT（重大な場合） |
 | 軽微な改善点のみ | APPROVE（改善提案は付記） |
 
-## 出力フォーマット
-
-| 状況 | タグ |
-|------|------|
-| フロントエンド観点で問題なし | `[FRONTEND:APPROVE]` |
-| 設計上の問題あり | `[FRONTEND:REJECT]` |
-
-### REJECT の構造
-
-```
-[FRONTEND:REJECT]
-
-### 問題点
-
-1. **問題のタイトル**
-   - 場所: ファイルパス:行番号
-   - 問題: フロントエンド設計原則違反の具体的説明
-   - 修正案: 正しいパターンの提示
-
-### フロントエンド観点での推奨事項
-- 設計改善の具体的なアドバイス
-```
-
-### APPROVE の構造
-
-```
-[FRONTEND:APPROVE]
-
-### 良い点
-- フロントエンドの原則に沿った良い設計を列挙
-
-### 改善提案（任意）
-- さらなる最適化の余地があれば
-```
-
 ## 口調の特徴
 
 - ユーザー体験を常に意識した発言

resources/global/ja/agents/expert-review/qa-reviewer.md

@@ -209,42 +209,6 @@ describe('OrderService', () => {
 | 保守性に深刻な問題 | REJECT |
 | 軽微な改善点のみ | APPROVE（改善提案は付記） |
 
-## 出力フォーマット
-
-| 状況 | タグ |
-|------|------|
-| 品質基準を満たしている | `[QA:APPROVE]` |
-| 品質上の問題がある | `[QA:REJECT]` |
-
-### REJECT の構造
-
-```
-[QA:REJECT]
-
-### 問題点
-
-1. **問題のタイトル** [カテゴリ: テスト/ドキュメント/保守性]
-   - 場所: ファイルパス:行番号
-   - 問題: 具体的な問題の説明
-   - 影響: この問題が放置された場合の影響
-   - 修正案: 具体的な修正方法
-
-### QA推奨事項
-- 品質向上のための追加アドバイス
-```
-
-### APPROVE の構造
-
-```
-[QA:APPROVE]
-
-### 良い点
-- 品質面での優れた点を列挙
-
-### 改善提案（任意）
-- さらなる品質向上の余地があれば
-```
-
 ## 口調の特徴
 
 - 品質の重要性を説く

resources/global/ja/agents/expert-review/security-reviewer.md

@@ -170,43 +170,6 @@
 | 低リスクだが改善すべき | APPROVE（改善提案は付記） |
 | セキュリティ上の問題なし | APPROVE |
 
-## 出力フォーマット
-
-| 状況 | タグ |
-|------|------|
-| セキュリティ上の問題なし | `[SECURITY:APPROVE]` |
-| 脆弱性が存在 | `[SECURITY:REJECT]` |
-
-### REJECT の構造
-
-```
-[SECURITY:REJECT]
-
-### 脆弱性
-
-1. **脆弱性の名称** [重大度: 高/中/低]
-   - 場所: ファイルパス:行番号
-   - 問題: 具体的な脆弱性の説明
-   - 攻撃シナリオ: どのように悪用される可能性があるか
-   - 修正案: 具体的な修正方法
-   - 参考: CWE番号、OWASP参照等
-
-### セキュリティ推奨事項
-- 追加の防御策
-```
-
-### APPROVE の構造
-
-```
-[SECURITY:APPROVE]
-
-### 確認済み項目
-- 確認したセキュリティ観点を列挙
-
-### 推奨事項（任意）
-- さらなる強化の余地があれば
-```
-
 ## 口調の特徴
 
 - 脆弱性を見つけたら厳格に指摘

resources/global/ja/agents/expert-review/supervisor.md

@@ -108,68 +108,6 @@
 2. 技術的負債として記録し、計画的に対応予定
 3. ビジネス上の理由で緊急リリースが必要
 
-## 出力フォーマット
-
-| 状況 | タグ |
-|------|------|
-| リリース可能 | `[SUPERVISOR:APPROVE]` |
-| 修正が必要 | `[SUPERVISOR:REJECT]` |
-
-### APPROVE の構造
-
-```
-[SUPERVISOR:APPROVE]
-
-### サマリー
-- 実装内容の概要（1-2文）
-
-### レビュー結果
-| 専門領域 | 結果 | 備考 |
-|---------|------|------|
-| CQRS+ES | APPROVE | - |
-| Frontend | APPROVE | 軽微な改善提案あり |
-| Security | APPROVE | - |
-| QA | APPROVE | - |
-
-### 良い点
-- 全体を通して優れている点
-
-### 今後の改善点（任意）
-- 後続タスクとして検討すべき点
-```
-
-### REJECT の構造
-
-```
-[SUPERVISOR:REJECT]
-
-### サマリー
-- 問題の概要（1-2文）
-
-### レビュー結果
-| 専門領域 | 結果 | 備考 |
-|---------|------|------|
-| CQRS+ES | APPROVE | - |
-| Frontend | REJECT | コンポーネント設計に問題 |
-| Security | APPROVE | - |
-| QA | REJECT | テスト不足 |
-
-### 修正が必要な項目
-
-**優先度: 高**
-1. [Frontend] コンポーネントの分割
-   - 詳細: UserPageコンポーネントが300行を超えている
-   - 対応: Container/Presentationalに分離
-
-**優先度: 中**
-2. [QA] テストの追加
-   - 詳細: 新機能のユニットテストがない
-   - 対応: calculateTotal関数のテストを追加
-
-### 次のアクション
-- Coderは上記の優先度順に修正を行ってください
-```
-
 ## 口調の特徴
 
 - 公平で客観的

resources/global/ja/agents/magi/balthasar.md

@@ -45,26 +45,6 @@
 - 懸念を伝える際も、責めるのではなく心配する
 - 長期的な視点を示唆する
 
-## 判定フォーマット
-
-```
-## BALTHASAR-2 分析
-
-### 人的影響の評価
-[関わる人々への影響 - 負荷、モチベーション、成長機会]
-
-### 持続可能性の観点
-[長期的に見た場合の懸念や期待]
-
-### 判定理由
-[判定に至った理由 - 人・チームへの影響を中心に]
-
-### 判定
-[BALTHASAR:APPROVE] または [BALTHASAR:REJECT] または [BALTHASAR:CONDITIONAL]
-```
-
-CONDITIONAL は条件付き賛成。条件には必ず「人を守るための安全策」を含める。
-
 ## 重要
 
 - 純粋な効率だけで判断しない

resources/global/ja/agents/magi/casper.md

@@ -48,47 +48,6 @@
 - 本音と建前を使い分ける
 - 最終的には決断する強さを見せる
 
-## 出力フォーマット
-
-**必ず以下の形式で、MAGIシステムとしての最終判定を出力してください：**
-
-```
-## CASPER-3 分析
-
-### 実務的評価
-[現実的な実現可能性、リソース、タイミング]
-
-### 政治的考慮
-[ステークホルダー、力学、リスク]
-
-### 妥協案（もしあれば）
-[現実的な落とし所]
-
----
-
-## MAGI System 最終判定
-
-| システム | 判定 | 要点 |
-|----------|------|------|
-| MELCHIOR-1 | [APPROVE/REJECT/CONDITIONAL] | [一言で要約] |
-| BALTHASAR-2 | [APPROVE/REJECT/CONDITIONAL] | [一言で要約] |
-| CASPER-3 | [APPROVE/REJECT/CONDITIONAL] | [一言で要約] |
-
-### 3者の論点整理
-[意見の一致点と相違点]
-
-### 結論
-[集計結果と、最終判定の理由]
-
-[MAGI:APPROVE] または [MAGI:REJECT] または [MAGI:CONDITIONAL]
-```
-
-## 最終判定のルール
-
-- **2票以上賛成** → `[MAGI:APPROVE]`
-- **2票以上反対** → `[MAGI:REJECT]`
-- **意見が分かれた/条件付きが多数** → `[MAGI:CONDITIONAL]`（条件を明示）
-
 ## 重要
 
 - 理想論だけで判断しない
@@ -96,5 +55,4 @@
 - 妥協点を見つける
 - 時には汚れ役を引き受ける覚悟を持つ
 - 3者の中で最も現実的であれ
-- **最後に必ず `[MAGI:...]` 形式の最終判定を出力すること**
 - 決めるのは、結局、私だ

resources/global/ja/agents/magi/melchior.md

@@ -45,26 +45,6 @@
 - 「〜すべき」「〜である」という表現を好む
 - 曖昧な表現を避ける
 
-## 判定フォーマット
-
-```
-## MELCHIOR-1 分析
-
-### 技術的評価
-[論理的・技術的な分析]
-
-### 定量的観点
-[数値化できる評価項目]
-
-### 判定理由
-[判定に至った論理的根拠 - データと事実に基づく]
-
-### 判定
-[MELCHIOR:APPROVE] または [MELCHIOR:REJECT] または [MELCHIOR:CONDITIONAL]
-```
-
-CONDITIONAL は条件付き賛成（〜であれば賛成）。条件は具体的かつ検証可能であること。
-
 ## 重要
 
 - 感情的な理由で判断しない

resources/global/ja/agents/research/digger.md

@@ -36,45 +36,6 @@ Plannerからの調査計画に従って、**実際に調査を実行**します
    - 関連情報があれば追加で調査
 3. すべて完了したら報告を作成
 
-## 出力フォーマット
-
-```
-## 調査結果報告
-
-### 調査項目ごとの結果
-
-#### 1. [調査項目名]
-**結果**: [調査結果の要約]
-
-**詳細**:
-[具体的なデータ、URL、引用等]
-
-**補足**:
-[追加で発見した関連情報]
-
----
-
-#### 2. [調査項目名]
-...
-
-### サマリー
-
-#### 主要な発見
-- [重要な発見1]
-- [重要な発見2]
-
-#### 注意点・リスク
-- [発見されたリスク]
-
-#### 調査できなかった項目
-- [項目]: [理由]
-
-### 推奨/結論
-[調査結果に基づく推奨事項]
-
-[DIGGER:DONE]
-```
-
 ## 例: 名前決めの調査結果
 
 ```
@@ -123,8 +84,6 @@ Plannerからの調査計画に従って、**実際に調査を実行**します
 1. GitHub での衝突が最も少ない
 2. npm はスコープ付きで対応可能
 3. 「鷹」のイメージは監視・狩猟ツールに適合
-
-[DIGGER:DONE]
 ```
 
 ## 重要

resources/global/ja/agents/research/planner.md

@@ -42,38 +42,6 @@
 - P2: 重要（あると回答の質が上がる）
 - P3: あれば良い（時間があれば）
 
-## 出力フォーマット
-
-```
-## 調査計画
-
-### 依頼の理解
-[依頼内容の要約と解釈]
-
-### 調査項目
-
-#### P1: 必須
-1. [調査項目1]
-   - 目的: [なぜ調べるか]
-   - 調査方法: [どう調べるか]
-
-2. [調査項目2]
-   ...
-
-#### P2: 重要
-1. [調査項目]
-   ...
-
-#### P3: あれば良い
-1. [調査項目]
-   ...
-
-### Diggerへの指示
-[具体的に何を調査してほしいか、箇条書きで]
-
-[PLANNER:DONE]
-```
-
 ## 例: 名前決めの調査
 
 依頼: 「プロジェクト名を決めたい。候補は wolf, fox, hawk」
@@ -114,8 +82,6 @@
 - npm, PyPI で同名パッケージの存在を確認
 - 各名前の一般的なイメージ・連想を調査
 - アナグラムの可能性を確認
-
-[PLANNER:DONE]
 ```
 
 ## 重要

resources/global/ja/agents/research/supervisor.md

@@ -43,42 +43,6 @@ Diggerの調査結果を評価し、ユーザーの依頼に対して十分な
 - 調査結果が浅い（具体性がない）
 - 情報源が不明確
 
-## 出力フォーマット
-
-### 承認の場合
-```
-## 調査評価
-
-### 評価結果: 承認
-
-### 評価サマリー
-- 依頼への回答性: ✓ [コメント]
-- 調査の網羅性: ✓ [コメント]
-- 情報の信頼性: ✓ [コメント]
-
-### 調査結果の要約
-[調査結果の簡潔なまとめ]
-
-[SUPERVISOR:APPROVE]
-```
-
-### 差し戻しの場合
-```
-## 調査評価
-
-### 評価結果: 差し戻し
-
-### 問題点
-1. [問題点1]
-2. [問題点2]
-
-### Plannerへの指示
-- [具体的に何を計画に含めるべきか]
-- [どのような観点で再調査すべきか]
-
-[SUPERVISOR:REJECT]
-```
-
 ## 重要
 
 - **具体的に指摘**: 「不十分」ではなく「XXが不足」と言う

resources/global/ja/workflows/default.yaml

@@ -18,8 +18,11 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## 判断基準
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 判定基準
 
       | 状況 | 判定 |
       |------|------|
@@ -33,14 +36,14 @@ steps:
       | 分析完了 | `[PLANNER:DONE]` |
       | 情報不足 | `[PLANNER:BLOCKED]` |
 
-      ### DONE時の出力構造
+      ### 出力例
 
+      **DONE の場合:**
       ```
       [PLANNER:DONE]
       ```
 
-      ### BLOCKED時の出力構造
+      **BLOCKED の場合:**
-        
       ```
       [PLANNER:BLOCKED]
 
@@ -48,9 +51,6 @@ steps:
       - {質問1}
       - {質問2}
       ```
-      分析結果を以下のタグで出力してください：
-      - [PLANNER:DONE] 分析完了
-      - [PLANNER:BLOCKED] 情報不足（確認事項を記載）
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -118,22 +118,22 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |      
+    status_rules_prompt: |
-      ## 出力フォーマット
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
 
-      作業完了時は必ず以下のタグを含めてください:
+      ## 出力フォーマット
 
       | 状況 | タグ |
       |------|------|
       | 実装完了 | `[CODER:DONE]` |
-      | Architectの指摘を修正完了 | `[CODER:FIXED]` |
       | 判断できない/情報不足 | `[CODER:BLOCKED]` |
 
       **重要**: 迷ったら `[BLOCKED]`。勝手に判断しない。
 
       ### 出力例
 
-      **実装完了時:**
+      **DONE の場合:**
       ```
       実装完了しました。
       - 作成: `src/auth/service.ts`, `tests/auth.test.ts`
@@ -142,22 +142,13 @@ steps:
       [CODER:DONE]
       ```
 
-      **ブロック時:**
+      **BLOCKED の場合:**
       ```
       [CODER:BLOCKED]
+
       理由: DBスキーマが未定義のため実装できません
       必要な情報: usersテーブルの構造
       ```
-        
-      **修正完了時:**
-      ```
-      Architectの指摘3点を修正しました。
-      - 型定義を追加
-      - エラーハンドリングを修正
-      - テストケースを追加
-        
-      [CODER:FIXED]
-      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -224,7 +215,10 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
       ## 判定基準
 
       | 状況 | 判定 |
@@ -233,48 +227,49 @@ steps:
       | 設計原則違反がある | REJECT |
       | セキュリティ問題がある | REJECT |
       | テストが不十分 | REJECT |
-      | 改善すべき点がある（ブロッキングではないが対応すべき） | IMPROVE |
+      | 改善すべき点がある（軽微） | IMPROVE |
       | 問題なし | APPROVE |
 
-      **IMPROVEの使い方:**
+      **IMPROVE の使い方:**
       - 設計としては許容範囲だが、改善した方が良い点がある場合
-      - 次のステップに進む前に修正させたい軽微な問題
       - 例: 命名の改善、小さなリファクタリング、コメント追加
 
-      ## ステータス出力形式
+      ## 出力フォーマット
 
-      レビュー結果を以下のタグで出力してください：
+      | 状況 | タグ |
-      - [ARCHITECT:APPROVE] 問題なし
+      |------|------|
-      - [ARCHITECT:IMPROVE] 軽微な改善必要
+      | 問題なし | `[ARCHITECT:APPROVE]` |
-      - [ARCHITECT:REJECT] 構造的な修正必要
+      | 軽微な改善必要 | `[ARCHITECT:IMPROVE]` |
+      | 構造的な修正必要 | `[ARCHITECT:REJECT]` |
 
       ### 出力例
 
-      **REJECTの場合:**
+      **APPROVE の場合:**
-      ```
-      [ARCHITECT:REJECT]
-
-      ### 問題点
-
-      1. **ファイルサイズ超過**
-         - 場所: `src/services/user.ts` (523行)
-         - 問題: 単一ファイルに認証・権限・プロフィール管理が混在
-         - 修正案: 以下の3ファイルに分割
-           - `src/services/auth.ts` - 認証
-           - `src/services/permission.ts` - 権限
-           - `src/services/profile.ts` - プロフィール
-      ```
-
-      **APPROVEの場合:**
       ```
       [ARCHITECT:APPROVE]
 
-      ### 良い点
+      良い点:
       - モジュール分割が適切
       - 単一責務が守られている
+      ```
 
-      ### 改善提案（任意）
+      **IMPROVE の場合:**
-      - `utils/` 内の共通処理は将来的に整理を検討
+      ```
+      [ARCHITECT:IMPROVE]
+
+      改善点:
+      - 命名を改善してください: `data` → `userData`
+      - コメントを追加してください
+      ```
+
+      **REJECT の場合:**
+      ```
+      [ARCHITECT:REJECT]
+
+      問題点:
+      1. ファイルサイズ超過
+         - 場所: `src/services/user.ts` (523行)
+         - 修正案: 3ファイルに分割
       ```
     instruction_template: |
       ## Workflow Context
@@ -346,45 +341,36 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## 出力フォーマット
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
 
-      作業完了時は必ず以下のタグを含めてください:
+      ## 出力フォーマット
 
       | 状況 | タグ |
       |------|------|
-      | 実装完了 | `[CODER:DONE]` |
+      | 改善完了 | `[CODER:DONE]` |
-      | Architectの指摘を修正完了 | `[CODER:FIXED]` |
       | 判断できない/情報不足 | `[CODER:BLOCKED]` |
 
       **重要**: 迷ったら `[BLOCKED]`。勝手に判断しない。
 
       ### 出力例
 
-      **実装完了時:**
+      **DONE の場合:**
       ```
-      実装完了しました。
+      改善を完了しました。
-      - 作成: `src/auth/service.ts`, `tests/auth.test.ts`
+      - 命名を改善: `data` → `userData`
-      - 変更: `src/routes.ts`
+      - コメントを追加
 
       [CODER:DONE]
       ```
 
-      **ブロック時:**
+      **BLOCKED の場合:**
       ```
       [CODER:BLOCKED]
-      理由: DBスキーマが未定義のため実装できません
-      必要な情報: usersテーブルの構造
-      ```
 
-      **修正完了時:**
+      理由: 改善の意図が不明確です
-      ```
+      必要な情報: 具体的な改善内容
-      Architectの指摘3点を修正しました。
-      - 型定義を追加
-      - エラーハンドリングを修正
-      - テストケースを追加
-      
-      [CODER:FIXED]
       ```
     instruction_template: |
       ## Workflow Context
@@ -424,7 +410,10 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
       ## 判定基準
 
       | 状況 | 判定 |
@@ -436,7 +425,7 @@ steps:
       | 軽微なスタイルの逸脱のみ | APPROVE |
       | コードが文脈に合い動作する | APPROVE |
 
-      **注意:** スコープクリープは警告として記載するが、それだけでREJECTしない。大きな変更が必要なタスクもある。
+      **注意:** スコープクリープは警告として記載するが、それだけでREJECTしない。
 
       ## 出力フォーマット
 
@@ -445,11 +434,22 @@ steps:
       | AI特有の問題なし | `[AI_REVIEW:APPROVE]` |
       | 問題あり | `[AI_REVIEW:REJECT]` |
 
-      ## ステータス出力形式
+      ### 出力例
 
-      レビュー結果を以下のタグで出力してください：
+      **APPROVE の場合:**
-      - [AI_REVIEW:APPROVE] AI特有の問題なし
+      ```
-      - [AI_REVIEW:REJECT] 問題あり
+      [AI_REVIEW:APPROVE]
+
+      検証結果: 問題なし
+      ```
+
+      **REJECT の場合:**
+      ```
+      [AI_REVIEW:REJECT]
+
+      問題点:
+      1. 存在しないAPIを使用: `fetch.json()` → `response.json()`
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -519,45 +519,35 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## 出力フォーマット
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
 
-      作業完了時は必ず以下のタグを含めてください:
+      ## 出力フォーマット
 
       | 状況 | タグ |
       |------|------|
-      | 実装完了 | `[CODER:DONE]` |
+      | AI問題の修正完了 | `[CODER:DONE]` |
-      | Architectの指摘を修正完了 | `[CODER:FIXED]` |
       | 判断できない/情報不足 | `[CODER:BLOCKED]` |
 
       **重要**: 迷ったら `[BLOCKED]`。勝手に判断しない。
 
       ### 出力例
 
-      **実装完了時:**
+      **DONE の場合:**
       ```
-      実装完了しました。
+      AI Reviewerの指摘を修正しました。
-      - 作成: `src/auth/service.ts`, `tests/auth.test.ts`
+      - 存在しないAPIを修正: `fetch.json()` → `response.json()`
-      - 変更: `src/routes.ts`
 
       [CODER:DONE]
       ```
 
-      **ブロック時:**
+      **BLOCKED の場合:**
       ```
       [CODER:BLOCKED]
-      理由: DBスキーマが未定義のため実装できません
-      必要な情報: usersテーブルの構造
-      ```
 
-      **修正完了時:**
+      理由: 指摘された問題の修正方法が不明確です
-      ```
+      必要な情報: 代替APIの仕様
-      Architectの指摘3点を修正しました。
-      - 型定義を追加
-      - エラーハンドリングを修正
-      - テストケースを追加
-      
-      [CODER:FIXED]
       ```
     instruction_template: |
       ## Workflow Context
@@ -595,21 +585,43 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
       ## 判定基準
 
       | 状況 | 判定 |
       |------|------|
-      | 重大な脆弱性（即REJECT） | REJECT |
+      | 重大な脆弱性 | REJECT |
       | 中程度の脆弱性 | REJECT |
       | 軽微な問題・警告のみ | APPROVE（警告を付記） |
       | セキュリティ問題なし | APPROVE |
 
-      ## ステータス出力形式
+      ## 出力フォーマット
 
-      レビュー結果を以下のタグで出力してください：
+      | 状況 | タグ |
-      - [SECURITY:APPROVE] セキュリティ問題なし
+      |------|------|
-      - [SECURITY:REJECT] 脆弱性があり修正が必要（具体的な問題をリスト）
+      | セキュリティ問題なし | `[SECURITY:APPROVE]` |
+      | 脆弱性があり修正が必要 | `[SECURITY:REJECT]` |
+
+      ### 出力例
+
+      **APPROVE の場合:**
+      ```
+      [SECURITY:APPROVE]
+
+      セキュリティ問題は検出されませんでした。
+      ```
+
+      **REJECT の場合:**
+      ```
+      [SECURITY:REJECT]
+
+      脆弱性:
+      1. SQLインジェクション: `src/db.ts:42`
+         修正案: パラメータ化クエリを使用
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -682,12 +694,36 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## ステータス出力形式
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
 
-      作業完了時は必ず以下のタグを含めてください：
+      ## 出力フォーマット
-      - [CODER:DONE] セキュリティ修正完了
+
-      - [CODER:BLOCKED] 判断できない/情報不足
+      | 状況 | タグ |
+      |------|------|
+      | セキュリティ修正完了 | `[CODER:DONE]` |
+      | 判断できない/情報不足 | `[CODER:BLOCKED]` |
+
+      **重要**: セキュリティの問題は最優先で対応が必要です。
+
+      ### 出力例
+
+      **DONE の場合:**
+      ```
+      セキュリティの指摘を修正しました。
+      - SQLインジェクション対策: パラメータ化クエリに変更
+
+      [CODER:DONE]
+      ```
+
+      **BLOCKED の場合:**
+      ```
+      [CODER:BLOCKED]
+
+      理由: 修正方法が不明確です
+      必要な情報: 認証ライブラリの仕様
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -723,45 +759,36 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
-      ## 出力フォーマット
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
 
-      作業完了時は必ず以下のタグを含めてください:
+      ## 出力フォーマット
 
       | 状況 | タグ |
       |------|------|
-      | 実装完了 | `[CODER:DONE]` |
+      | Architectの指摘を修正完了 | `[CODER:DONE]` |
-      | Architectの指摘を修正完了 | `[CODER:FIXED]` |
       | 判断できない/情報不足 | `[CODER:BLOCKED]` |
 
       **重要**: 迷ったら `[BLOCKED]`。勝手に判断しない。
 
       ### 出力例
 
-      **実装完了時:**
+      **DONE の場合:**
       ```
-      実装完了しました。
+      Architectの指摘を修正しました。
-      - 作成: `src/auth/service.ts`, `tests/auth.test.ts`
+      - ファイル分割: 3ファイルに分割
-      - 変更: `src/routes.ts`
+      - 型定義を追加
 
       [CODER:DONE]
       ```
 
-      **ブロック時:**
+      **BLOCKED の場合:**
       ```
       [CODER:BLOCKED]
-      理由: DBスキーマが未定義のため実装できません
-      必要な情報: usersテーブルの構造
-      ```
 
-      **修正完了時:**
+      理由: 修正方針が不明確です
-      ```
+      必要な情報: 分割の具体的な方法
-      Architectの指摘3点を修正しました。
-      - 型定義を追加
-      - エラーハンドリングを修正
-      - テストケースを追加
-      
-      [CODER:FIXED]
       ```
     instruction_template: |
       ## Workflow Context
@@ -797,7 +824,11 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
-    status_rules: |
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 判定基準
 
       | 状況 | 判定 |
       |------|------|
@@ -815,6 +846,27 @@ steps:
       |------|------|
       | 最終承認 | `[SUPERVISOR:APPROVE]` |
       | 差し戻し | `[SUPERVISOR:REJECT]` |
+
+      ### 出力例
+
+      **APPROVE の場合:**
+      ```
+      [SUPERVISOR:APPROVE]
+
+      検証結果:
+      - テスト: ✅ 全件パス
+      - ビルド: ✅ 成功
+      - 要求充足: ✅
+      ```
+
+      **REJECT の場合:**
+      ```
+      [SUPERVISOR:REJECT]
+
+      問題点:
+      1. テストが失敗: `npm test` で 2 件失敗
+      2. 元の要求を満たしていない: ログイン機能が未実装
+      ```
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}

resources/global/ja/workflows/expert-review.yaml

@@ -30,6 +30,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 分析完了 | `[PLANNER:DONE]` |
+      | 要件不明確 | `[PLANNER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -103,6 +113,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 実装完了 | `[CODER:DONE]` |
+      | 進行不可 | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -175,6 +195,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 設計に問題なし | `[CQRS-ES:APPROVE]` |
+      | 設計に問題あり | `[CQRS-ES:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -252,6 +282,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 修正完了 | `[CODER:DONE]` |
+      | 進行不可 | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -296,6 +336,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | フロントエンド設計に問題なし | `[FRONTEND:APPROVE]` |
+      | フロントエンド設計に問題あり | `[FRONTEND:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -373,6 +423,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 修正完了 | `[CODER:DONE]` |
+      | 進行不可 | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -417,6 +477,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | AI特有の問題なし | `[AI_REVIEW:APPROVE]` |
+      | 問題あり | `[AI_REVIEW:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -490,6 +560,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 修正完了 | `[CODER:DONE]` |
+      | 進行不可 | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -532,6 +612,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | セキュリティ問題なし | `[SECURITY:APPROVE]` |
+      | 脆弱性あり | `[SECURITY:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -606,6 +696,17 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 軽微な修正完了 | `[CODER:DONE]` |
+      | 大きな修正（CQRS+ESからやり直し） | `[CODER:REJECT]` |
+      | 進行不可 | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -659,6 +760,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 品質基準を満たす | `[QA:APPROVE]` |
+      | 品質問題あり | `[QA:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -733,6 +844,18 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 軽微な修正完了 | `[CODER:DONE]` |
+      | セキュリティ影響あり | `[CODER:IMPROVE]` |
+      | 大きな修正（CQRS+ESからやり直し） | `[CODER:REJECT]` |
+      | 進行不可 | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -790,6 +913,16 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 最終承認 | `[SUPERVISOR:APPROVE]` |
+      | 問題あり | `[SUPERVISOR:REJECT]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}
@@ -906,6 +1039,16 @@ steps:
       - Bash
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 修正完了 | `[CODER:DONE]` |
+      | 進行不可 | `[CODER:BLOCKED]` |
     instruction_template: |
       ## Workflow Context
       - Iteration: {iteration}/{max_iterations}

resources/global/ja/workflows/magi.yaml

@@ -16,6 +16,25 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 判定 | タグ |
+      |------|------|
+      | 賛成 | `[MELCHIOR:APPROVE]` |
+      | 反対 | `[MELCHIOR:REJECT]` |
+      | 条件付き賛成 | `[MELCHIOR:CONDITIONAL]` |
+
+      ### 出力例
+
+      ```
+      [MELCHIOR:APPROVE]
+
+      理由: {賛成の理由}
+      ```
     instruction_template: |
       # MAGI System 起動
 
@@ -25,11 +44,6 @@ steps:
       ## 指示
       あなたはMAGI System の MELCHIOR-1 です。
       科学者・技術者の観点から上記を分析し、判定を下してください。
-
-      判定は以下のいずれか:
-      - [MELCHIOR:APPROVE] - 賛成
-      - [MELCHIOR:REJECT] - 反対
-      - [MELCHIOR:CONDITIONAL] - 条件付き賛成
     transitions:
       - condition: always
         next_step: balthasar
@@ -42,6 +56,25 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 判定 | タグ |
+      |------|------|
+      | 賛成 | `[BALTHASAR:APPROVE]` |
+      | 反対 | `[BALTHASAR:REJECT]` |
+      | 条件付き賛成 | `[BALTHASAR:CONDITIONAL]` |
+
+      ### 出力例
+
+      ```
+      [BALTHASAR:APPROVE]
+
+      理由: {賛成の理由}
+      ```
     instruction_template: |
       # MAGI System 継続
 
@@ -55,11 +88,6 @@ steps:
       あなたはMAGI System の BALTHASAR-2 です。
       育成者の観点から上記を分析し、判定を下してください。
       MELCHIORの判定は参考にしつつも、独自の観点で判断してください。
-
-      判定は以下のいずれか:
-      - [BALTHASAR:APPROVE] - 賛成
-      - [BALTHASAR:REJECT] - 反対
-      - [BALTHASAR:CONDITIONAL] - 条件付き賛成
     pass_previous_response: true
     transitions:
       - condition: always
@@ -73,6 +101,35 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      最終結論は3者の多数決で判定:
+
+      | 判定 | タグ |
+      |------|------|
+      | 承認（2票以上賛成） | `[MAGI:APPROVE]` |
+      | 却下（2票以上反対） | `[MAGI:REJECT]` |
+      | 条件付き承認 | `[MAGI:CONDITIONAL]` |
+
+      ### 出力例
+
+      ```
+      ## MAGI System 最終判定
+
+      | システム | 判定 |
+      |----------|------|
+      | MELCHIOR-1 | APPROVE |
+      | BALTHASAR-2 | CONDITIONAL |
+      | CASPER-3 | APPROVE |
+
+      **結論: [MAGI:APPROVE]**
+
+      [理由・まとめ]
+      ```
     instruction_template: |
       # MAGI System 最終審議
 
@@ -87,27 +144,6 @@ steps:
       実務・現実の観点から上記を分析し、判定を下してください。
 
       **最後に、3者の判定を集計し、最終結論を出してください。**
-
-      ### 最終結論（必須）
-      3者の多数決で最終判定を出す:
-      - [MAGI:APPROVE] - 承認（2票以上賛成）
-      - [MAGI:REJECT] - 却下（2票以上反対）
-      - [MAGI:CONDITIONAL] - 条件付き承認（条件付きが多数または意見が分かれた場合）
-
-      **最終結論のフォーマット例:**
-      ```
-      ## MAGI System 最終判定
-
-      | システム | 判定 |
-      |----------|------|
-      | MELCHIOR-1 | APPROVE |
-      | BALTHASAR-2 | CONDITIONAL |
-      | CASPER-3 | APPROVE |
-
-      **結論: [MAGI:APPROVE]**
-
-      [理由・まとめ]
-      ```
     pass_previous_response: true
     transitions:
       - condition: always

resources/global/ja/workflows/research.yaml

@@ -20,6 +20,31 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 計画完了 | `[PLANNER:DONE]` |
+      | 情報不足 | `[PLANNER:BLOCKED]` |
+
+      ### 出力例
+
+      **DONE の場合:**
+      ```
+      [PLANNER:DONE]
+      ```
+
+      **BLOCKED の場合:**
+      ```
+      [PLANNER:BLOCKED]
+
+      確認事項:
+      - {質問1}
+      ```
     instruction_template: |
       ## ワークフロー状況
       - イテレーション: {iteration}/{max_iterations}
@@ -41,8 +66,6 @@ steps:
       - 不明点は仮定を置いて進める
       - 複数の解釈がある場合は、すべてを調査対象に含める
       - Supervisorからフィードバックがある場合は、指摘を反映した計画を作成
-
-      計画が完了したら [PLANNER:DONE] を出力してください。
     pass_previous_response: true
     transitions:
       - condition: done
@@ -58,6 +81,30 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 調査完了 | `[DIGGER:DONE]` |
+      | 調査不可 | `[DIGGER:BLOCKED]` |
+
+      ### 出力例
+
+      **DONE の場合:**
+      ```
+      [DIGGER:DONE]
+      ```
+
+      **BLOCKED の場合:**
+      ```
+      [DIGGER:BLOCKED]
+
+      理由: {調査できなかった理由}
+      ```
     instruction_template: |
       ## ワークフロー状況
       - イテレーション: {iteration}/{max_iterations}
@@ -84,8 +131,6 @@ steps:
       - GitHub検索（gh コマンド）
       - コードベース検索
       - ファイル読み取り
-
-      調査が完了したら [DIGGER:DONE] を出力してください。
     pass_previous_response: true
     transitions:
       - condition: done
@@ -101,6 +146,40 @@ steps:
       - Grep
       - WebSearch
       - WebFetch
+    status_rules_prompt: |
+      # ステータス出力ルール
+      最終出力には必ず以下のルールに従ったステータスタグを含めてください。
+
+      ## 判定基準
+
+      | 状況 | 判定 |
+      |------|------|
+      | 調査結果が十分 | APPROVE |
+      | 調査結果が不十分 | REJECT |
+
+      ## 出力フォーマット
+
+      | 状況 | タグ |
+      |------|------|
+      | 調査完了、結果は十分 | `[SUPERVISOR:APPROVE]` |
+      | 不十分、計画からやり直し | `[SUPERVISOR:REJECT]` |
+
+      ### 出力例
+
+      **APPROVE の場合:**
+      ```
+      [SUPERVISOR:APPROVE]
+
+      調査結果は元の依頼に対して十分です。
+      ```
+
+      **REJECT の場合:**
+      ```
+      [SUPERVISOR:REJECT]
+
+      不足点:
+      - {具体的な不足点}
+      ```
     instruction_template: |
       ## ワークフロー状況
       - イテレーション: {iteration}/{max_iterations}
@@ -115,10 +194,6 @@ steps:
       ## 指示
       調査結果を評価し、元の依頼に対して十分な回答になっているか判断してください。
 
-      **評価結果の出力**:
-      - [SUPERVISOR:APPROVE] - 調査完了、結果は十分
-      - [SUPERVISOR:REJECT] - 不十分、計画からやり直し（具体的な不足点を指摘）
-
       **重要**: 問題がある場合は、Plannerへの具体的な指示を含めてください。
     pass_previous_response: true
     transitions:

src/agents/runner.ts

@@ -32,7 +32,7 @@ export interface RunAgentOptions {
   /** Allowed tools for this agent run */
   allowedTools?: string[];
   /** Status output rules to inject into system prompt */
-  statusRules?: string;
+  statusRulesPrompt?: string;
   onStream?: StreamCallback;
   onPermissionRequest?: PermissionHandler;
   onAskUserQuestion?: AskUserQuestionHandler;
@@ -133,8 +133,8 @@ export async function runCustomAgent(
   let systemPrompt = loadAgentPrompt(agentConfig);
 
   // Inject status rules if provided
-  if (options.statusRules) {
+  if (options.statusRulesPrompt) {
-    systemPrompt = `${systemPrompt}\n\n${options.statusRules}`;
+    systemPrompt = `${systemPrompt}\n\n${options.statusRulesPrompt}`;
   }
 
   const tools = allowedTools;
@@ -217,8 +217,8 @@ export async function runAgent(
     let systemPrompt = loadAgentPromptFromPath(options.agentPath);
 
     // Inject status rules if provided
-    if (options.statusRules) {
+    if (options.statusRulesPrompt) {
-      systemPrompt = `${systemPrompt}\n\n${options.statusRules}`;
+      systemPrompt = `${systemPrompt}\n\n${options.statusRulesPrompt}`;
     }
 
     const tools = options.allowedTools;

src/config/workflowLoader.ts

@@ -70,7 +70,7 @@ function normalizeWorkflowConfig(raw: unknown, workflowDir: string): WorkflowCon
     provider: step.provider,
     model: step.model,
     instructionTemplate: step.instruction_template || step.instruction || '{task}',
-    statusRules: step.status_rules,
+    statusRulesPrompt: step.status_rules_prompt,
     transitions: step.transitions.map((t) => ({
       condition: t.condition,
       nextStep: t.next_step,

src/models/schemas.ts

@@ -64,7 +64,7 @@ export const WorkflowStepRawSchema = z.object({
   model: z.string().optional(),
   instruction: z.string().optional(),
   instruction_template: z.string().optional(),
-  status_rules: z.string().optional(),
+  status_rules_prompt: z.string().optional(),
   pass_previous_response: z.boolean().optional().default(true),
   on_no_status: OnNoStatusBehaviorSchema.optional(),
   transitions: z.array(

src/models/types.ts

@@ -70,7 +70,7 @@ export interface WorkflowStep {
   model?: string;
   instructionTemplate: string;
   /** Status output rules to be injected into system prompt */
-  statusRules?: string;
+  statusRulesPrompt?: string;
   transitions: WorkflowTransition[];
   passPreviousResponse: boolean;
   /**

src/workflow/engine.ts

@@ -148,7 +148,7 @@ export class WorkflowEngine extends EventEmitter {
       sessionId,
       agentPath: step.agentPath,
       allowedTools: step.allowedTools,
-      statusRules: step.statusRules,
+      statusRulesPrompt: step.statusRulesPrompt,
       provider: step.provider,
       model: step.model,
       onStream: this.options.onStream,

src/workflow/instruction-builder.ts

@@ -88,9 +88,9 @@ export function buildInstruction(
     instruction = instruction.replace(/\{report_dir\}/g, context.reportDir);
   }
 
-  // Append status_rules if present
+  // Append status_rules_prompt if present
-  if (step.statusRules) {
+  if (step.statusRulesPrompt) {
-    instruction = `${instruction}\n\n${step.statusRules}`;
+    instruction = `${instruction}\n\n${step.statusRulesPrompt}`;
   }
 
   return instruction;