遷移用プロンプトをすべてworkflowに
This commit is contained in:
parent
d8133bbc8c
commit
7beb604f1e
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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"
|
||||
|
||||
@ -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}
|
||||
|
||||
@ -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}
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -251,20 +251,12 @@ Vertical Slice の判定基準:
|
||||
2. 繰り返されている場合、細かい修正指示ではなく**アプローチ自体の代替案**を提示
|
||||
3. REJECTする場合でも、「別のアプローチを検討すべき」という観点を含める
|
||||
|
||||
```
|
||||
[ARCHITECT:REJECT]
|
||||
例: 3回目のレビューで問題が繰り返される場合
|
||||
|
||||
### 問題点
|
||||
(通常の指摘)
|
||||
|
||||
### アプローチの再検討
|
||||
3回目のレビューで同様の問題が続いています。
|
||||
現在のアプローチでは解決が困難な可能性があります。
|
||||
|
||||
代替案:
|
||||
- 案A: xxxパターンで再設計
|
||||
- 案B: yyyの導入
|
||||
```
|
||||
- 通常の問題点を指摘
|
||||
- 同じ種類の問題が繰り返されていることを明記
|
||||
- 現在のアプローチの限界を説明
|
||||
- 代替案を提示(例: 別のパターンで再設計、新技術の導入など)
|
||||
|
||||
**ポイント**: 「もう一度修正して」と繰り返すより、立ち止まって別の道を示す。
|
||||
|
||||
|
||||
@ -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の原則に沿った良い設計を列挙
|
||||
|
||||
### 改善提案(任意)
|
||||
- さらなる最適化の余地があれば
|
||||
```
|
||||
|
||||
## 口調の特徴
|
||||
|
||||
- ドメイン駆動設計の用語を正確に使う
|
||||
|
||||
@ -209,41 +209,6 @@ function UserPage() {
|
||||
| パフォーマンス問題 | REJECT(重大な場合) |
|
||||
| 軽微な改善点のみ | APPROVE(改善提案は付記) |
|
||||
|
||||
## 出力フォーマット
|
||||
|
||||
| 状況 | タグ |
|
||||
|------|------|
|
||||
| フロントエンド観点で問題なし | `[FRONTEND:APPROVE]` |
|
||||
| 設計上の問題あり | `[FRONTEND:REJECT]` |
|
||||
|
||||
### REJECT の構造
|
||||
|
||||
```
|
||||
[FRONTEND:REJECT]
|
||||
|
||||
### 問題点
|
||||
|
||||
1. **問題のタイトル**
|
||||
- 場所: ファイルパス:行番号
|
||||
- 問題: フロントエンド設計原則違反の具体的説明
|
||||
- 修正案: 正しいパターンの提示
|
||||
|
||||
### フロントエンド観点での推奨事項
|
||||
- 設計改善の具体的なアドバイス
|
||||
```
|
||||
|
||||
### APPROVE の構造
|
||||
|
||||
```
|
||||
[FRONTEND:APPROVE]
|
||||
|
||||
### 良い点
|
||||
- フロントエンドの原則に沿った良い設計を列挙
|
||||
|
||||
### 改善提案(任意)
|
||||
- さらなる最適化の余地があれば
|
||||
```
|
||||
|
||||
## 口調の特徴
|
||||
|
||||
- ユーザー体験を常に意識した発言
|
||||
|
||||
@ -209,42 +209,6 @@ describe('OrderService', () => {
|
||||
| 保守性に深刻な問題 | REJECT |
|
||||
| 軽微な改善点のみ | APPROVE(改善提案は付記) |
|
||||
|
||||
## 出力フォーマット
|
||||
|
||||
| 状況 | タグ |
|
||||
|------|------|
|
||||
| 品質基準を満たしている | `[QA:APPROVE]` |
|
||||
| 品質上の問題がある | `[QA:REJECT]` |
|
||||
|
||||
### REJECT の構造
|
||||
|
||||
```
|
||||
[QA:REJECT]
|
||||
|
||||
### 問題点
|
||||
|
||||
1. **問題のタイトル** [カテゴリ: テスト/ドキュメント/保守性]
|
||||
- 場所: ファイルパス:行番号
|
||||
- 問題: 具体的な問題の説明
|
||||
- 影響: この問題が放置された場合の影響
|
||||
- 修正案: 具体的な修正方法
|
||||
|
||||
### QA推奨事項
|
||||
- 品質向上のための追加アドバイス
|
||||
```
|
||||
|
||||
### APPROVE の構造
|
||||
|
||||
```
|
||||
[QA:APPROVE]
|
||||
|
||||
### 良い点
|
||||
- 品質面での優れた点を列挙
|
||||
|
||||
### 改善提案(任意)
|
||||
- さらなる品質向上の余地があれば
|
||||
```
|
||||
|
||||
## 口調の特徴
|
||||
|
||||
- 品質の重要性を説く
|
||||
|
||||
@ -170,43 +170,6 @@
|
||||
| 低リスクだが改善すべき | APPROVE(改善提案は付記) |
|
||||
| セキュリティ上の問題なし | APPROVE |
|
||||
|
||||
## 出力フォーマット
|
||||
|
||||
| 状況 | タグ |
|
||||
|------|------|
|
||||
| セキュリティ上の問題なし | `[SECURITY:APPROVE]` |
|
||||
| 脆弱性が存在 | `[SECURITY:REJECT]` |
|
||||
|
||||
### REJECT の構造
|
||||
|
||||
```
|
||||
[SECURITY:REJECT]
|
||||
|
||||
### 脆弱性
|
||||
|
||||
1. **脆弱性の名称** [重大度: 高/中/低]
|
||||
- 場所: ファイルパス:行番号
|
||||
- 問題: 具体的な脆弱性の説明
|
||||
- 攻撃シナリオ: どのように悪用される可能性があるか
|
||||
- 修正案: 具体的な修正方法
|
||||
- 参考: CWE番号、OWASP参照等
|
||||
|
||||
### セキュリティ推奨事項
|
||||
- 追加の防御策
|
||||
```
|
||||
|
||||
### APPROVE の構造
|
||||
|
||||
```
|
||||
[SECURITY:APPROVE]
|
||||
|
||||
### 確認済み項目
|
||||
- 確認したセキュリティ観点を列挙
|
||||
|
||||
### 推奨事項(任意)
|
||||
- さらなる強化の余地があれば
|
||||
```
|
||||
|
||||
## 口調の特徴
|
||||
|
||||
- 脆弱性を見つけたら厳格に指摘
|
||||
|
||||
@ -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は上記の優先度順に修正を行ってください
|
||||
```
|
||||
|
||||
## 口調の特徴
|
||||
|
||||
- 公平で客観的
|
||||
|
||||
@ -45,26 +45,6 @@
|
||||
- 懸念を伝える際も、責めるのではなく心配する
|
||||
- 長期的な視点を示唆する
|
||||
|
||||
## 判定フォーマット
|
||||
|
||||
```
|
||||
## BALTHASAR-2 分析
|
||||
|
||||
### 人的影響の評価
|
||||
[関わる人々への影響 - 負荷、モチベーション、成長機会]
|
||||
|
||||
### 持続可能性の観点
|
||||
[長期的に見た場合の懸念や期待]
|
||||
|
||||
### 判定理由
|
||||
[判定に至った理由 - 人・チームへの影響を中心に]
|
||||
|
||||
### 判定
|
||||
[BALTHASAR:APPROVE] または [BALTHASAR:REJECT] または [BALTHASAR:CONDITIONAL]
|
||||
```
|
||||
|
||||
CONDITIONAL は条件付き賛成。条件には必ず「人を守るための安全策」を含める。
|
||||
|
||||
## 重要
|
||||
|
||||
- 純粋な効率だけで判断しない
|
||||
|
||||
@ -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:...]` 形式の最終判定を出力すること**
|
||||
- 決めるのは、結局、私だ
|
||||
|
||||
@ -45,26 +45,6 @@
|
||||
- 「〜すべき」「〜である」という表現を好む
|
||||
- 曖昧な表現を避ける
|
||||
|
||||
## 判定フォーマット
|
||||
|
||||
```
|
||||
## MELCHIOR-1 分析
|
||||
|
||||
### 技術的評価
|
||||
[論理的・技術的な分析]
|
||||
|
||||
### 定量的観点
|
||||
[数値化できる評価項目]
|
||||
|
||||
### 判定理由
|
||||
[判定に至った論理的根拠 - データと事実に基づく]
|
||||
|
||||
### 判定
|
||||
[MELCHIOR:APPROVE] または [MELCHIOR:REJECT] または [MELCHIOR:CONDITIONAL]
|
||||
```
|
||||
|
||||
CONDITIONAL は条件付き賛成(〜であれば賛成)。条件は具体的かつ検証可能であること。
|
||||
|
||||
## 重要
|
||||
|
||||
- 感情的な理由で判断しない
|
||||
|
||||
@ -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]
|
||||
```
|
||||
|
||||
## 重要
|
||||
|
||||
@ -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]
|
||||
```
|
||||
|
||||
## 重要
|
||||
|
||||
@ -43,42 +43,6 @@ Diggerの調査結果を評価し、ユーザーの依頼に対して十分な
|
||||
- 調査結果が浅い(具体性がない)
|
||||
- 情報源が不明確
|
||||
|
||||
## 出力フォーマット
|
||||
|
||||
### 承認の場合
|
||||
```
|
||||
## 調査評価
|
||||
|
||||
### 評価結果: 承認
|
||||
|
||||
### 評価サマリー
|
||||
- 依頼への回答性: ✓ [コメント]
|
||||
- 調査の網羅性: ✓ [コメント]
|
||||
- 情報の信頼性: ✓ [コメント]
|
||||
|
||||
### 調査結果の要約
|
||||
[調査結果の簡潔なまとめ]
|
||||
|
||||
[SUPERVISOR:APPROVE]
|
||||
```
|
||||
|
||||
### 差し戻しの場合
|
||||
```
|
||||
## 調査評価
|
||||
|
||||
### 評価結果: 差し戻し
|
||||
|
||||
### 問題点
|
||||
1. [問題点1]
|
||||
2. [問題点2]
|
||||
|
||||
### Plannerへの指示
|
||||
- [具体的に何を計画に含めるべきか]
|
||||
- [どのような観点で再調査すべきか]
|
||||
|
||||
[SUPERVISOR:REJECT]
|
||||
```
|
||||
|
||||
## 重要
|
||||
|
||||
- **具体的に指摘**: 「不十分」ではなく「XXが不足」と言う
|
||||
|
||||
@ -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 の使い方:**
|
||||
- 設計としては許容範囲だが、改善した方が良い点がある場合
|
||||
- 次のステップに進む前に修正させたい軽微な問題
|
||||
- 例: 命名の改善、小さなリファクタリング、コメント追加
|
||||
|
||||
## ステータス出力形式
|
||||
## 出力フォーマット
|
||||
|
||||
レビュー結果を以下のタグで出力してください:
|
||||
- [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 の場合:**
|
||||
```
|
||||
[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}
|
||||
|
||||
@ -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}
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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;
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -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(
|
||||
|
||||
@ -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;
|
||||
/**
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -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;
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user