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

This commit is contained in:
nrslib 2026-01-27 00:26:43 +09:00
parent d8133bbc8c
commit 7beb604f1e
38 changed files with 1128 additions and 1160 deletions

View File

@ -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"
```
[ARCHITECT:REJECT]
Example: When issues repeat on the 3rd review
### Issues
(Normal feedback)
### Reconsidering the Approach
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 out the normal issues
- Note that the same type of issues are recurring
- Explain the limitations of the current approach
- Present alternatives (e.g., redesign with a different pattern, introduce new technology)
**Point**: Rather than repeating "fix this again", step back and suggest a different path.

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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"

View File

@ -18,12 +18,39 @@ steps:
- Bash
- WebSearch
- WebFetch
status_rules: |
## Status Output Format
status_rules_prompt: |
# Status Output Rules
Your final output MUST include a status tag following the rules below.
Output analysis results with the following tags:
- [PLANNER:DONE] Analysis complete
- [PLANNER:BLOCKED] Insufficient info (list clarifications needed)
## Judgment Criteria
| 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 Output Format
status_rules_prompt: |
# Status Output Rules
Your final output MUST include a status tag following the rules below.
Always include these tags when work is complete:
- [CODER:DONE] Implementation complete
- [CODER:BLOCKED] Cannot decide/insufficient info
## Output Format
| 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:
- [ARCHITECT:APPROVE] No issues
- [ARCHITECT:IMPROVE] Minor improvements needed
- [ARCHITECT:REJECT] Structural changes required
| Situation | Tag |
|-----------|-----|
| No issues | `[ARCHITECT:APPROVE]` |
| 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)
- Consider organizing shared utilities in `utils/` in the future
**IMPROVE case:**
```
[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 Output Format
status_rules_prompt: |
# Status Output Rules
Your final output MUST include a status tag following the rules below.
Always include these tags when work is complete:
- [CODER:DONE] Improvements complete
- [CODER:BLOCKED] Cannot decide/insufficient info
## Output Format
| 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:
- [AI_REVIEW:APPROVE] No AI-specific issues
- [AI_REVIEW:REJECT] Issues found
| Situation | Tag |
|-----------|-----|
| 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 Output Format
status_rules_prompt: |
# Status Output Rules
Your final output MUST include a status tag following the rules below.
Always include these tags when work is complete:
- [CODER:DONE] Fixes complete
- [CODER:BLOCKED] Cannot decide/insufficient info
## Output Format
| 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:
- [SECURITY:APPROVE] No security issues
- [SECURITY:REJECT] Vulnerabilities require fixes
| Situation | Tag |
|-----------|-----|
| 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 Output Format
status_rules_prompt: |
# Status Output Rules
Your final output MUST include a status tag following the rules below.
Always include these tags when work is complete:
- [CODER:DONE] Security fixes complete
- [CODER:BLOCKED] Cannot decide/insufficient info
## Output Format
| 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 Output Format
status_rules_prompt: |
# Status Output Rules
Your final output MUST include a status tag following the rules below.
Always include these tags when work is complete:
- [CODER:DONE] Fixes complete
- [CODER:BLOCKED] Cannot decide/insufficient info
## Output Format
| 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:
- [SUPERVISOR:APPROVE] if ready to merge
- [SUPERVISOR:REJECT] if issues found (specify the issues)
| Situation | Tag |
|-----------|-----|
| 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}

View File

@ -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}

View File

@ -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

View File

@ -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:

View File

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

View File

@ -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の原則に沿った良い設計を列挙
### 改善提案(任意)
- さらなる最適化の余地があれば
```
## 口調の特徴
- ドメイン駆動設計の用語を正確に使う

View File

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

View File

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

View File

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

View File

@ -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は上記の優先度順に修正を行ってください
```
## 口調の特徴
- 公平で客観的

View File

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

View File

@ -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:...]` 形式の最終判定を出力すること**
- 決めるのは、結局、私だ

View File

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

View File

@ -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]
```
## 重要

View File

@ -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]
```
## 重要

View File

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

View File

@ -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:REJECT] 構造的な修正必要
| 状況 | タグ |
|------|------|
| 問題なし | `[ARCHITECT:APPROVE]` |
| 軽微な改善必要 | `[ARCHITECT:IMPROVE]` |
| 構造的な修正必要 | `[ARCHITECT:REJECT]` |
### 出力例
**REJECTの場合:**
```
[ARCHITECT:REJECT]
### 問題点
1. **ファイルサイズ超過**
- 場所: `src/services/user.ts` (523行)
- 問題: 単一ファイルに認証・権限・プロフィール管理が混在
- 修正案: 以下の3ファイルに分割
- `src/services/auth.ts` - 認証
- `src/services/permission.ts` - 権限
- `src/services/profile.ts` - プロフィール
```
**APPROVEの場合:**
**APPROVE の場合:**
```
[ARCHITECT:APPROVE]
### 良い点
良い点:
- モジュール分割が適切
- 単一責務が守られている
```
### 改善提案(任意)
- `utils/` 内の共通処理は将来的に整理を検討
**IMPROVE の場合:**
```
[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]` |
| Architectの指摘を修正完了 | `[CODER:FIXED]` |
| 改善完了 | `[CODER:DONE]` |
| 判断できない/情報不足 | `[CODER:BLOCKED]` |
**重要**: 迷ったら `[BLOCKED]`。勝手に判断しない。
### 出力例
**実装完了時:**
**DONE の場合:**
```
実装完了しました。
- 作成: `src/auth/service.ts`, `tests/auth.test.ts`
- 変更: `src/routes.ts`
改善を完了しました。
- 命名を改善: `data` → `userData`
- コメントを追加
[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]` |
## ステータス出力形式
### 出力例
レビュー結果を以下のタグで出力してください:
- [AI_REVIEW:APPROVE] AI特有の問題なし
- [AI_REVIEW:REJECT] 問題あり
**APPROVE の場合:**
```
[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]` |
| Architectの指摘を修正完了 | `[CODER:FIXED]` |
| AI問題の修正完了 | `[CODER:DONE]` |
| 判断できない/情報不足 | `[CODER:BLOCKED]` |
**重要**: 迷ったら `[BLOCKED]`。勝手に判断しない。
### 出力例
**実装完了時:**
**DONE の場合:**
```
実装完了しました。
- 作成: `src/auth/service.ts`, `tests/auth.test.ts`
- 変更: `src/routes.ts`
AI Reviewerの指摘を修正しました。
- 存在しないAPIを修正: `fetch.json()` → `response.json()`
[CODER:DONE]
```
**ブロック時:**
**BLOCKED の場合:**
```
[CODER:BLOCKED]
理由: DBスキーマが未定義のため実装できません
必要な情報: usersテーブルの構造
```
**修正完了時:**
```
Architectの指摘3点を修正しました。
- 型定義を追加
- エラーハンドリングを修正
- テストケースを追加
[CODER:FIXED]
理由: 指摘された問題の修正方法が不明確です
必要な情報: 代替APIの仕様
```
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:FIXED]` |
| Architectの指摘を修正完了 | `[CODER:DONE]` |
| 判断できない/情報不足 | `[CODER:BLOCKED]` |
**重要**: 迷ったら `[BLOCKED]`。勝手に判断しない。
### 出力例
**実装完了時:**
**DONE の場合:**
```
実装完了しました。
- 作成: `src/auth/service.ts`, `tests/auth.test.ts`
- 変更: `src/routes.ts`
Architectの指摘を修正しました。
- ファイル分割: 3ファイルに分割
- 型定義を追加
[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}

View File

@ -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}

View File

@ -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

View File

@ -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:

View File

@ -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) {
systemPrompt = `${systemPrompt}\n\n${options.statusRules}`;
if (options.statusRulesPrompt) {
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) {
systemPrompt = `${systemPrompt}\n\n${options.statusRules}`;
if (options.statusRulesPrompt) {
systemPrompt = `${systemPrompt}\n\n${options.statusRulesPrompt}`;
}
const tools = options.allowedTools;

View File

@ -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,

View File

@ -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(

View File

@ -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;
/**

View File

@ -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,

View File

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