Skill を Agent Team ベースに刷新し、hybrid-codex ピースを追加

- SKILL.md: 疑似コードから命令形の手順1-8に書き換え、レポート抽出・Loop Monitor手順を追加
- engine.md: エージェント→チームメイト用語統一、yolo 権限キーワード対応
- takt-command.md: /takt {piece} [yolo] {task} 形式の引数パースを追加
- deploySkill.ts: cleanDir() で再デプロイ時の古いファイル残存を防止
- hybrid-codex ピース13点を en/ja に追加
This commit is contained in:
nrslib 2026-02-06 10:05:27 +09:00
parent ec983089f9
commit 8fab3f0064
17 changed files with 6426 additions and 132 deletions

View File

@ -0,0 +1,631 @@
# Default TAKT Piece
# Plan -> Architect -> Implement -> AI Review -> Reviewers (parallel: Architect + QA) -> Supervisor Approval
#
# Boilerplate sections (Piece Context, User Request, Previous Response,
# Additional User Inputs, Instructions heading) are auto-injected by buildInstruction().
# Only movement-specific content belongs in instruction_template.
#
# Template Variables (available in instruction_template):
# {iteration} - Piece-wide turn count (total movements executed across all agents)
# {max_iterations} - Maximum iterations allowed for the piece
# {movement_iteration} - Per-movement iteration count (how many times THIS movement has been executed)
# {previous_response} - Output from the previous movement (only when pass_previous_response: true)
# {report_dir} - Report directory name (e.g., "20250126-143052-task-summary")
#
# Movement-level Fields:
# report: - Report file(s) for the movement (auto-injected as Report File/Files in Piece Context)
# Single: report: 00-plan.md
# Multiple: report:
# - Scope: 01-coder-scope.md
# - Decisions: 02-coder-decisions.md
name: default-hybrid-codex
description: Standard development piece with planning and specialized reviews (hybrid: coder=codex)
max_iterations: 30
initial_movement: plan
loop_monitors:
- cycle: [ai_review, ai_fix]
threshold: 3
judge:
agent: ../agents/default/supervisor.md
instruction_template: |
The ai_review ↔ ai_fix loop has repeated {cycle_count} times.
Review the reports from each cycle and determine whether this loop
is healthy (making progress) or unproductive (repeating the same issues).
**Reports to reference:**
- AI Review results: {report:04-ai-review.md}
**Judgment criteria:**
- Are new issues being found/fixed in each cycle?
- Are the same findings being repeated?
- Are fixes actually being applied?
rules:
- condition: Healthy (making progress)
next: ai_review
- condition: Unproductive (no improvement)
next: reviewers
movements:
- name: plan
edit: false
agent: ../agents/default/planner.md
report:
name: 00-plan.md
format: |
```markdown
# Task Plan
## Original Request
{User's request as-is}
## Analysis Results
### Objective
{What needs to be achieved}
### Scope
{Impact scope}
### Implementation Approach
{How to proceed}
## Clarifications Needed (if any)
- {Unclear points or items requiring confirmation}
```
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
rules:
- condition: Requirements are clear and implementable
next: architect
- condition: User is asking a question (not an implementation task)
next: COMPLETE
- condition: Requirements unclear, insufficient info
next: ABORT
appendix: |
Clarifications needed:
- {Question 1}
- {Question 2}
instruction_template: |
Analyze the task and create an implementation plan.
**Note:** If returned from implement movement (Previous Response exists),
review and revise the plan based on that feedback (replan).
**Tasks (for implementation tasks):**
1. Understand the requirements
2. Identify impact scope
3. Decide implementation approach
- name: architect
edit: false
agent: ../agents/default/architect.md
report:
name: 01-architecture.md
format: |
```markdown
# Architecture Design
## Task Size
Small / Medium / Large
## Design Decisions
### File Structure
| File | Role |
|------|------|
| `src/example.ts` | Summary |
### Technology Selection
- {Selected technologies/libraries and reasoning}
### Design Patterns
- {Patterns to adopt and where to apply}
## Implementation Guidelines
- {Guidelines for Coder to follow during implementation}
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: Small task (no design needed)
next: implement
- condition: Design complete
next: implement
- condition: Insufficient info, cannot proceed
next: ABORT
instruction_template: |
Read the plan report ({report:00-plan.md}) and perform architecture design.
**Small task criteria:**
- Only 1-2 files to modify
- Can follow existing patterns
- No technology selection needed
For small tasks, skip the design report and use the "Small task (no design needed)" rule.
**Tasks requiring design:**
- 3+ files to modify
- Adding new modules/features
- Technology selection needed
- Architecture pattern decisions needed
**Tasks:**
1. Evaluate task size
2. Decide file structure
3. Select technology (if needed)
4. Choose design patterns
5. Create implementation guidelines for Coder
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
report:
- Scope: 02-coder-scope.md
- Decisions: 03-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Implementation complete
next: ai_review
- condition: No implementation (report only)
next: ai_review
- condition: Cannot proceed, insufficient info
next: ai_review
- condition: User input required
next: implement
requires_user_input: true
interactive_only: true
instruction_template: |
Follow the plan from the plan movement and the design from the architect movement.
**Reports to reference:**
- Plan: {report:00-plan.md}
- Design: {report:01-architecture.md} (if exists)
Use only the Report Directory files shown in Piece Context. Do not search or open reports outside that directory.
**Important:** Do not make design decisions; follow the design determined in the architect movement.
Report if you encounter unclear points or need design changes.
**Scope report format (create at implementation start):**
```markdown
# Change Scope Declaration
## Task
{One-line task summary}
## Planned Changes
| Type | File |
|------|------|
| Create | `src/example.ts` |
| Modify | `src/routes.ts` |
## Estimated Size
Small / Medium / Large
## Impact Scope
- {Affected modules or features}
```
**Decisions report format (on completion, only if decisions were made):**
```markdown
# Decision Log
## 1. {Decision Content}
- **Background**: {Why the decision was needed}
- **Options Considered**: {List of options}
- **Reason**: {Why this option was chosen}
```
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
**No-implementation handling (required)**
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 04-ai-review.md
format: |
```markdown
# AI-Generated Code Review
## Result: APPROVE / REJECT
## Summary
{One sentence summarizing result}
## Verified Items
| Aspect | Result | Notes |
|--------|--------|-------|
| Assumption validity | ✅ | - |
| API/Library existence | ✅ | - |
| Context fit | ✅ | - |
| Scope | ✅ | - |
## Issues (if REJECT)
| # | Category | Location | Issue |
|---|----------|----------|-------|
| 1 | Hallucinated API | `src/file.ts:23` | Non-existent method |
```
**Cognitive load reduction rules:**
- No issues -> Summary 1 line + check table only (10 lines or less)
- Issues found -> + Issues in table format (25 lines or less)
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: No AI-specific issues
next: reviewers
- condition: AI-specific issues found
next: ai_fix
instruction_template: |
**This is AI Review iteration {movement_iteration}.**
For the 1st iteration, review thoroughly and report all issues at once.
For iteration 2+, prioritize verifying that previously REJECTed items have been fixed.
Review the code for AI-specific issues:
- Assumption validation
- Plausible but wrong patterns
- Context fit with existing codebase
- Scope creep detection
- name: ai_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI issues fixed
next: ai_review
- condition: No fix needed (verified target files/spec)
next: ai_no_fix
- condition: Cannot proceed, insufficient info
next: ai_no_fix
instruction_template: |
**This is AI Review iteration {movement_iteration}.**
If this is iteration 2 or later, it means your previous fixes were not actually applied.
**Your belief that you "already fixed it" is wrong.**
**First, acknowledge:**
- Files you thought were "fixed" are actually not fixed
- Your understanding of previous work is incorrect
- You need to start from zero
**Required actions:**
1. Open all flagged files with Read tool (drop assumptions, verify facts)
2. Search for problem code with grep to confirm it exists
3. Fix confirmed problems with Edit tool
4. Run tests to verify (`./gradlew :backend:test` etc.)
5. Report specifically "what you checked and what you fixed"
**Report format:**
- ❌ "Already fixed"
- ✅ "Checked file X at L123, found problem Y, fixed to Z"
**Absolutely prohibited:**
- Reporting "fixed" without opening files
**Handling "no fix needed" (required)**
- Do not claim "no fix needed" unless you can show the checked target file(s) for each AI Review issue
- If an issue involves generated code or spec sync, and you cannot verify the source spec, output the tag for "Unable to proceed with fixes"
- When "no fix needed", output the tag for "Unable to proceed with fixes" and include the reason + checked scope
**Required output (include headings)**
## Files checked
- {path:line}
## Searches run
- {command and summary}
## Fixes applied
- {what changed}
## Test results
- {command and outcome}
- Judging based on assumptions
- Leaving problems that AI Reviewer REJECTED
- name: ai_no_fix
edit: false
agent: ../agents/default/architecture-reviewer.md
allowed_tools:
- Read
- Glob
- Grep
rules:
- condition: ai_review's findings are valid (fix required)
next: ai_fix
- condition: ai_fix's judgment is valid (no fix needed)
next: reviewers
instruction_template: |
ai_review (reviewer) and ai_fix (coder) disagree.
- ai_review found issues and REJECTed
- ai_fix verified and determined "no fix needed"
Review both outputs and arbitrate which judgment is correct.
**Reports to reference:**
- AI Review results: {report:04-ai-review.md}
**Judgment criteria:**
- Are ai_review's findings specific and pointing to real issues in the code?
- Does ai_fix's rebuttal have evidence (file verification, test results)?
- Are the findings non-blocking (record-only) or do they require actual fixes?
- name: reviewers
parallel:
- name: arch-review
edit: false
agent: ../agents/default/architecture-reviewer.md
report:
name: 05-architect-review.md
format: |
```markdown
# Architecture Review
## Result: APPROVE / REJECT
## Summary
{1-2 sentences summarizing result}
## Reviewed Perspectives
- [x] Structure & Design
- [x] Code Quality
- [x] Change Scope
## Issues (if REJECT)
| # | Scope | Location | Issue | Fix |
|---|-------|----------|-------|-----|
| 1 | In-scope | `src/file.ts:42` | Issue description | Fix method |
Scope: "In-scope" (fixable now) / "Out-of-scope" (existing issue, non-blocking)
## Existing Issues (informational, non-blocking)
- {Record of existing issues unrelated to current change}
```
**Cognitive load reduction rules:**
- APPROVE -> Summary only (5 lines or less)
- REJECT -> Issues in table format (30 lines or less)
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
**Verify that the implementation follows the design from the architect movement.**
Do NOT review AI-specific issues (that's the ai_review movement).
**Reports to reference:**
- Design: {report:01-architecture.md} (if exists)
- Implementation scope: {report:02-coder-scope.md}
**Review perspectives:**
- Design consistency (does it follow the file structure and patterns defined by architect?)
- Code quality
- Change scope appropriateness
- Test coverage
- Dead code
- Call chain verification
**Note:** For small tasks that skipped the architect movement, review design validity as usual.
- name: qa-review
edit: false
agent: ../agents/default/qa-reviewer.md
report:
name: 06-qa-review.md
format: |
```markdown
# QA Review
## Result: APPROVE / REJECT
## Summary
{1-2 sentences summarizing result}
## Reviewed Perspectives
| Perspective | Result | Notes |
|-------------|--------|-------|
| Test Coverage | ✅ | - |
| Test Quality | ✅ | - |
| Error Handling | ✅ | - |
| Documentation | ✅ | - |
| Maintainability | ✅ | - |
## Issues (if REJECT)
| # | Category | Issue | Fix |
|---|----------|-------|-----|
| 1 | Testing | Issue description | Fix method |
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
Review the changes from the quality assurance perspective.
**Review Criteria:**
- Test coverage and quality
- Test strategy (unit/integration/E2E)
- Error handling
- Logging and monitoring
- Maintainability
rules:
- condition: all("approved")
next: supervise
- condition: any("needs_fix")
next: fix
- name: fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Fix complete
next: reviewers
- condition: Cannot proceed, insufficient info
next: plan
instruction_template: |
Address the feedback from the reviewers.
The "Original User Request" is reference information, not the latest instruction.
Review the session conversation history and fix the issues raised by the reviewers.
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
## Evidence
- {key files/grep/diff/log evidence you verified}
- name: supervise
edit: false
agent: ../agents/default/supervisor.md
report:
- Validation: 07-supervisor-validation.md
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
rules:
- condition: All checks passed
next: COMPLETE
- condition: Requirements unmet, tests failing, build errors
next: plan
instruction_template: |
Run tests, verify the build, and perform final approval.
**Piece Overall Review:**
1. Does the implementation match the plan ({report:00-plan.md}) and design ({report:01-architecture.md}, if exists)?
2. Were all review movement issues addressed?
3. Was the original task objective achieved?
**Review Reports:** Read all reports in Report Directory and
check for any unaddressed improvement suggestions.
**Validation report format:**
```markdown
# Final Validation Results
## Result: APPROVE / REJECT
## Validation Summary
| Item | Status | Verification Method |
|------|--------|---------------------|
| Requirements met | ✅ | Matched against requirements list |
| Tests | ✅ | `npm test` (N passed) |
| Build | ✅ | `npm run build` succeeded |
| Functional check | ✅ | Main flows verified |
## Deliverables
- Created: {Created files}
- Modified: {Modified files}
## Incomplete Items (if REJECT)
| # | Item | Reason |
|---|------|--------|
| 1 | {Item} | {Reason} |
```
**Summary report format (only if APPROVE):**
```markdown
# Task Completion Summary
## Task
{Original request in 1-2 sentences}
## Result
✅ Complete
## Changes
| Type | File | Summary |
|------|------|---------|
| Create | `src/file.ts` | Summary description |
## Review Results
| Review | Result |
|--------|--------|
| Architecture Design | ✅ Complete |
| AI Review | ✅ APPROVE |
| Architect Review | ✅ APPROVE |
| QA | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## Verification Commands
```bash
npm test
npm run build
```
```

View File

@ -0,0 +1,687 @@
# Expert CQRS Review Piece
# Review piece with CQRS+ES, Frontend, Security, and QA experts
#
# Flow:
# plan -> implement -> ai_review -> reviewers (parallel) -> supervise -> COMPLETE
# ↓ ├─ cqrs-es-review ↓
# ai_fix ├─ frontend-review fix_supervisor
# ├─ security-review
# └─ qa-review
# any("needs_fix") → fix → reviewers
#
# Template Variables:
# {iteration} - Piece-wide turn count (total movements executed across all agents)
# {max_iterations} - Maximum iterations allowed for the piece
# {movement_iteration} - Per-movement iteration count (how many times THIS movement has been executed)
# {task} - Original user request
# {previous_response} - Output from the previous movement
# {user_inputs} - Accumulated user inputs during piece
# {report_dir} - Report directory name (e.g., "20250126-143052-task-summary")
name: expert-cqrs-hybrid-codex
description: CQRS+ES, Frontend, Security, QA Expert Review (hybrid: coder=codex)
max_iterations: 30
initial_movement: plan
movements:
# ===========================================
# Movement 0: Planning
# ===========================================
- name: plan
edit: false
agent: ../agents/default/planner.md
report:
name: 00-plan.md
format: |
```markdown
# Task Plan
## Original Request
{User's request as-is}
## Analysis Results
### Objective
{What needs to be achieved}
### Scope
{Impact scope}
### Implementation Approach
{How to proceed}
## Clarifications Needed (if any)
- {Unclear points or items requiring confirmation}
```
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
Analyze the task and create an implementation plan.
**Note:** If returned from implement movement (Previous Response exists),
review and revise the plan based on that feedback (replan).
**Tasks:**
1. Understand the requirements
2. Identify impact scope
3. Decide implementation approach
rules:
- condition: Task analysis and planning is complete
next: implement
- condition: Requirements are unclear and planning cannot proceed
next: ABORT
# ===========================================
# Movement 1: Implementation
# ===========================================
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
report:
- Scope: 01-coder-scope.md
- Decisions: 02-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
Follow the plan from the plan movement and implement.
Refer to the plan report ({report:00-plan.md}) and proceed with implementation.
Use only the Report Directory files shown in Piece Context. Do not search or open reports outside that directory.
**Scope report format (create at implementation start):**
```markdown
# Change Scope Declaration
## Task
{One-line task summary}
## Planned Changes
| Type | File |
|------|------|
| Create | `src/example.ts` |
| Modify | `src/routes.ts` |
## Estimated Size
Small / Medium / Large
## Impact Scope
- {Affected modules or features}
```
**Decisions report format (on completion, only if decisions were made):**
```markdown
# Decision Log
## 1. {Decision Content}
- **Background**: {Why the decision was needed}
- **Options Considered**: {List of options}
- **Reason**: {Why this option was chosen}
```
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
rules:
- condition: Implementation is complete
next: ai_review
- condition: No implementation (report only)
next: ai_review
- condition: Cannot proceed with implementation
next: ai_review
- condition: User input required
next: implement
requires_user_input: true
interactive_only: true
# ===========================================
# Movement 2: AI Review
# ===========================================
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 03-ai-review.md
format: |
```markdown
# AI-Generated Code Review
## Result: APPROVE / REJECT
## Summary
{One sentence summarizing result}
## Verified Items
| Aspect | Result | Notes |
|--------|--------|-------|
| Assumption validity | ✅ | - |
| API/Library existence | ✅ | - |
| Context fit | ✅ | - |
| Scope | ✅ | - |
## Issues (if REJECT)
| # | Category | Location | Issue |
|---|----------|----------|-------|
| 1 | Hallucinated API | `src/file.ts:23` | Non-existent method |
```
**Cognitive load reduction rules:**
- No issues → Summary 1 line + check table only (10 lines or less)
- Issues found → + Issues in table format (25 lines or less)
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
**This is AI Review iteration {movement_iteration}.**
For the 1st iteration, review thoroughly and report all issues at once.
For iteration 2+, prioritize verifying that previously REJECTed items have been fixed.
Review the code for AI-specific issues:
- Assumption validation
- Plausible but wrong patterns
- Context fit with existing codebase
- Scope creep detection
rules:
- condition: No AI-specific issues found
next: reviewers
- condition: AI-specific issues detected
next: ai_fix
- name: ai_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
**This is AI Review iteration {movement_iteration}.**
If this is iteration 2 or later, it means your previous fixes were not actually applied.
**Your belief that you "already fixed it" is wrong.**
**First, acknowledge:**
- Files you thought were "fixed" are actually not fixed
- Your understanding of previous work is incorrect
- You need to start from zero
**Required actions:**
1. Open all flagged files with Read tool (drop assumptions, verify facts)
2. Search for problem code with grep to confirm it exists
3. Fix confirmed problems with Edit tool
4. Run tests to verify (`./gradlew :backend:test` etc.)
5. Report specifically "what you checked and what you fixed"
**Report format:**
- ❌ "Already fixed"
- ✅ "Checked file X at L123, found problem Y, fixed to Z"
**Absolutely prohibited:**
- Reporting "fixed" without opening files
- Judging based on assumptions
- Leaving problems that AI Reviewer REJECTED
**Handling "no fix needed" (required)**
- Do not claim "no fix needed" unless you can show the checked target file(s) for each AI Review issue
- If an issue involves generated code or spec sync, and you cannot verify the source spec, output the tag for "Unable to proceed with fixes"
- When "no fix needed", output the tag for "Unable to proceed with fixes" and include the reason + checked scope
**Required output (include headings)**
## Files checked
- {path:line}
## Searches run
- {command and summary}
## Fixes applied
- {what changed}
## Test results
- {command and outcome}
**No-implementation handling (required)**
rules:
- condition: AI Reviewer's issues have been fixed
next: ai_review
- condition: No fix needed (verified target files/spec)
next: ai_no_fix
- condition: Unable to proceed with fixes
next: ai_no_fix
- name: ai_no_fix
edit: false
agent: ../agents/default/architecture-reviewer.md
allowed_tools:
- Read
- Glob
- Grep
rules:
- condition: ai_review's findings are valid (fix required)
next: ai_fix
- condition: ai_fix's judgment is valid (no fix needed)
next: reviewers
instruction_template: |
ai_review (reviewer) and ai_fix (coder) disagree.
- ai_review found issues and REJECTed
- ai_fix verified and determined "no fix needed"
Review both outputs and arbitrate which judgment is correct.
**Reports to reference:**
- AI Review results: {report:03-ai-review.md}
**Judgment criteria:**
- Are ai_review's findings specific and pointing to real issues in the code?
- Does ai_fix's rebuttal have evidence (file verification, test results)?
- Are the findings non-blocking (record-only) or do they require actual fixes?
# ===========================================
# Movement 3: Expert Reviews (Parallel)
# ===========================================
- name: reviewers
parallel:
- name: cqrs-es-review
edit: false
agent: ../agents/expert-cqrs/cqrs-es-reviewer.md
report:
name: 04-cqrs-es-review.md
format: |
```markdown
# CQRS+ES Review
## Result: APPROVE / REJECT
## Summary
{1-2 sentences summarizing result}
## Reviewed Perspectives
| Perspective | Result | Notes |
|-------------|--------|-------|
| Aggregate Design | ✅ | - |
| Event Design | ✅ | - |
| Command/Query Separation | ✅ | - |
| Projections | ✅ | - |
| Eventual Consistency | ✅ | - |
## Issues (if REJECT)
| # | Scope | Location | Issue | Fix |
|---|-------|----------|-------|-----|
| 1 | In-scope | `src/file.ts:42` | Issue description | Fix method |
Scope: "In-scope" (fixable now) / "Out-of-scope" (existing issue, non-blocking)
## Existing Issues (informational, non-blocking)
- {Record of existing issues unrelated to current change}
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
Review the changes from the CQRS (Command Query Responsibility Segregation)
and Event Sourcing perspective. Do NOT review AI-specific issues (that's the ai_review movement).
**Review Criteria:**
- Aggregate design validity
- Event design (granularity, naming, schema)
- Command/Query separation
- Projection design
- Eventual consistency considerations
**Note**: If this project does not use CQRS+ES patterns,
review from a general domain design perspective.
- name: frontend-review
edit: false
agent: ../agents/expert/frontend-reviewer.md
report:
name: 05-frontend-review.md
format: |
```markdown
# Frontend Review
## Result: APPROVE / REJECT
## Summary
{1-2 sentences summarizing result}
## Reviewed Perspectives
| Perspective | Result | Notes |
|-------------|--------|-------|
| Component Design | ✅ | - |
| State Management | ✅ | - |
| Performance | ✅ | - |
| Accessibility | ✅ | - |
| Type Safety | ✅ | - |
## Issues (if REJECT)
| # | Location | Issue | Fix |
|---|----------|-------|-----|
| 1 | `src/file.tsx:42` | Issue description | Fix method |
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
Review the changes from the frontend development perspective.
**Review Criteria:**
- Component design (separation of concerns, granularity)
- State management (local/global decisions)
- Performance (re-rendering, memoization)
- Accessibility (keyboard support, ARIA)
- Data fetching patterns
- TypeScript type safety
**Note**: If this project does not include frontend code,
approve and proceed to the next movement.
- name: security-review
edit: false
agent: ../agents/expert/security-reviewer.md
report:
name: 06-security-review.md
format: |
```markdown
# Security Review
## Result: APPROVE / REJECT
## Severity: None / Low / Medium / High / Critical
## Check Results
| Category | Result | Notes |
|----------|--------|-------|
| Injection | ✅ | - |
| Auth/Authz | ✅ | - |
| Data Protection | ✅ | - |
| Dependencies | ✅ | - |
## Vulnerabilities (if REJECT)
| # | Severity | Type | Location | Fix |
|---|----------|------|----------|-----|
| 1 | High | SQLi | `src/db.ts:42` | Use parameterized query |
## Warnings (non-blocking)
- {Security recommendations}
```
**Cognitive load reduction rules:**
- No issues -> Check table only (10 lines or less)
- Warnings -> + Warnings 1-2 lines (15 lines or less)
- Vulnerabilities -> + Table format (30 lines or less)
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
Perform security review on the changes. Check for vulnerabilities including:
- Injection attacks (SQL, Command, XSS)
- Authentication/Authorization issues
- Data exposure risks
- Cryptographic weaknesses
- name: qa-review
edit: false
agent: ../agents/expert/qa-reviewer.md
report:
name: 07-qa-review.md
format: |
```markdown
# QA Review
## Result: APPROVE / REJECT
## Summary
{1-2 sentences summarizing result}
## Reviewed Perspectives
| Perspective | Result | Notes |
|-------------|--------|-------|
| Test Coverage | ✅ | - |
| Test Quality | ✅ | - |
| Error Handling | ✅ | - |
| Documentation | ✅ | - |
| Maintainability | ✅ | - |
## Issues (if REJECT)
| # | Category | Issue | Fix |
|---|----------|-------|-----|
| 1 | Testing | Issue description | Fix method |
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
Review the changes from the quality assurance perspective.
**Review Criteria:**
- Test coverage and quality
- Test strategy (unit/integration/E2E)
- Documentation (in-code and external)
- Error handling
- Logging and monitoring
- Maintainability
rules:
- condition: all("approved")
next: supervise
- condition: any("needs_fix")
next: fix
- name: fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Fix complete
next: reviewers
- condition: Cannot proceed, insufficient info
next: plan
instruction_template: |
Address the feedback from the reviewers.
The "Original User Request" is reference information, not the latest instruction.
Review the session conversation history and fix the issues raised by the reviewers.
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
## Evidence
- {key files/grep/diff/log evidence you verified}
# ===========================================
# Movement 4: Supervision
# ===========================================
- name: supervise
edit: false
agent: ../agents/expert/supervisor.md
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
## Previous Reviews Summary
Reaching this movement means all the following reviews have been APPROVED:
- AI Review: APPROVED
- CQRS+ES Review: APPROVED
- Frontend Review: APPROVED
- Security Review: APPROVED
- QA Review: APPROVED
Run tests, verify the build, and perform final approval.
**Piece Overall Review:**
1. Does the implementation match the plan ({report:00-plan.md})?
2. Were all review movement issues addressed?
3. Was the original task objective achieved?
**Review Reports:** Read all reports in Report Directory and
check for any unaddressed improvement suggestions.
**Validation report format:**
```markdown
# Final Validation Results
## Result: APPROVE / REJECT
## Validation Summary
| Item | Status | Verification Method |
|------|--------|---------------------|
| Requirements met | ✅ | Matched against requirements list |
| Tests | ✅ | `npm test` (N passed) |
| Build | ✅ | `npm run build` succeeded |
| Functional check | ✅ | Main flows verified |
## Deliverables
- Created: {Created files}
- Modified: {Modified files}
## Incomplete Items (if REJECT)
| # | Item | Reason |
|---|------|--------|
| 1 | {Item} | {Reason} |
```
**Summary report format (only if APPROVE):**
```markdown
# Task Completion Summary
## Task
{Original request in 1-2 sentences}
## Result
✅ Complete
## Changes
| Type | File | Summary |
|------|------|---------|
| Create | `src/file.ts` | Summary description |
## Review Results
| Review | Result |
|--------|--------|
| AI Review | ✅ APPROVE |
| CQRS+ES | ✅ APPROVE |
| Frontend | ✅ APPROVE |
| Security | ✅ APPROVE |
| QA | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## Verification Commands
```bash
npm test
npm run build
```
```
rules:
- condition: All validations pass and ready to merge
next: COMPLETE
- condition: Issues detected during final review
next: fix_supervisor
- name: fix_supervisor
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
Fix the issues pointed out by the supervisor.
The supervisor has identified issues from a big-picture perspective.
Address items in priority order.
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
## Evidence
- {key files/grep/diff/log evidence you verified}
rules:
- condition: Supervisor's issues have been fixed
next: supervise
- condition: Unable to proceed with fixes
next: plan

View File

@ -0,0 +1,700 @@
# Expert Review Piece
# Review piece with Architecture, Frontend, Security, and QA experts
#
# Flow:
# plan -> implement -> ai_review -> reviewers (parallel) -> supervise -> COMPLETE
# ↓ ├─ arch-review ↓
# ai_fix ├─ frontend-review fix_supervisor
# ├─ security-review
# └─ qa-review
# any("needs_fix") → fix → reviewers
#
# AI review runs immediately after implementation to catch AI-specific issues early,
# before expert reviews begin.
#
# Boilerplate sections (Piece Context, User Request, Previous Response,
# Additional User Inputs, Instructions heading) are auto-injected by buildInstruction().
# Only movement-specific content belongs in instruction_template.
#
# Template Variables (available in instruction_template):
# {iteration} - Piece-wide turn count (total movements executed across all agents)
# {max_iterations} - Maximum iterations allowed for the piece
# {movement_iteration} - Per-movement iteration count (how many times THIS movement has been executed)
# {previous_response} - Output from the previous movement (only when pass_previous_response: true)
# {report_dir} - Report directory name (e.g., "20250126-143052-task-summary")
#
# Movement-level Fields:
# report: - Report file(s) for the movement (auto-injected as Report File/Files in Piece Context)
# Single: report: 00-plan.md
# Multiple: report:
# - Scope: 01-coder-scope.md
# - Decisions: 02-coder-decisions.md
name: expert-hybrid-codex
description: Architecture, Frontend, Security, QA Expert Review (hybrid: coder=codex)
max_iterations: 30
initial_movement: plan
movements:
# ===========================================
# Movement 0: Planning
# ===========================================
- name: plan
edit: false
agent: ../agents/default/planner.md
report:
name: 00-plan.md
format: |
```markdown
# Task Plan
## Original Request
{User's request as-is}
## Analysis Results
### Objective
{What needs to be achieved}
### Scope
{Impact scope}
### Implementation Approach
{How to proceed}
## Clarifications Needed (if any)
- {Unclear points or items requiring confirmation}
```
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
Analyze the task and create an implementation plan.
**Note:** If returned from implement movement (Previous Response exists),
review and revise the plan based on that feedback (replan).
**Tasks:**
1. Understand the requirements
2. Identify impact scope
3. Decide implementation approach
rules:
- condition: Task analysis and planning is complete
next: implement
- condition: Requirements are unclear and planning cannot proceed
next: ABORT
# ===========================================
# Movement 1: Implementation
# ===========================================
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
report:
- Scope: 01-coder-scope.md
- Decisions: 02-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
Follow the plan from the plan movement and implement.
Refer to the plan report ({report:00-plan.md}) and proceed with implementation.
Use only the Report Directory files shown in Piece Context. Do not search or open reports outside that directory.
**Scope report format (create at implementation start):**
```markdown
# Change Scope Declaration
## Task
{One-line task summary}
## Planned Changes
| Type | File |
|------|------|
| Create | `src/example.ts` |
| Modify | `src/routes.ts` |
## Estimated Size
Small / Medium / Large
## Impact Scope
- {Affected modules or features}
```
**Decisions report format (on completion, only if decisions were made):**
```markdown
# Decision Log
## 1. {Decision Content}
- **Background**: {Why the decision was needed}
- **Options Considered**: {List of options}
- **Reason**: {Why this option was chosen}
```
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
rules:
- condition: Implementation is complete
next: ai_review
- condition: No implementation (report only)
next: ai_review
- condition: Cannot proceed with implementation
next: ai_review
- condition: User input required
next: implement
requires_user_input: true
interactive_only: true
# ===========================================
# Movement 2: AI Review
# ===========================================
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 03-ai-review.md
format: |
```markdown
# AI-Generated Code Review
## Result: APPROVE / REJECT
## Summary
{One sentence summarizing result}
## Verified Items
| Aspect | Result | Notes |
|--------|--------|-------|
| Assumption validity | ✅ | - |
| API/Library existence | ✅ | - |
| Context fit | ✅ | - |
| Scope | ✅ | - |
## Issues (if REJECT)
| # | Category | Location | Issue |
|---|----------|----------|-------|
| 1 | Hallucinated API | `src/file.ts:23` | Non-existent method |
```
**Cognitive load reduction rules:**
- No issues -> Summary 1 line + check table only (10 lines or less)
- Issues found -> + Issues in table format (25 lines or less)
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
**This is AI Review iteration {movement_iteration}.**
For the 1st iteration, review thoroughly and report all issues at once.
For iteration 2+, prioritize verifying that previously REJECTed items have been fixed.
Review the code for AI-specific issues:
- Assumption validation
- Plausible but wrong patterns
- Context fit with existing codebase
- Scope creep detection
rules:
- condition: No AI-specific issues found
next: reviewers
- condition: AI-specific issues detected
next: ai_fix
- name: ai_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
**This is AI Review iteration {movement_iteration}.**
If this is iteration 2 or later, it means your previous fixes were not actually applied.
**Your belief that you "already fixed it" is wrong.**
**First, acknowledge:**
- Files you thought were "fixed" are actually not fixed
- Your understanding of previous work is incorrect
- You need to start from zero
**Required actions:**
1. Open all flagged files with Read tool (drop assumptions, verify facts)
2. Search for problem code with grep to confirm it exists
3. Fix confirmed problems with Edit tool
4. Run tests to verify (`./gradlew :backend:test` etc.)
5. Report specifically "what you checked and what you fixed"
**Report format:**
- ❌ "Already fixed"
- ✅ "Checked file X at L123, found problem Y, fixed to Z"
**Absolutely prohibited:**
- Reporting "fixed" without opening files
- Judging based on assumptions
- Leaving problems that AI Reviewer REJECTED
- Removing scope creep
**Handling "no fix needed" (required)**
- Do not claim "no fix needed" unless you can show the checked target file(s) for each AI Review issue
- If an issue involves generated code or spec sync, and you cannot verify the source spec, output the tag for "Unable to proceed with fixes"
- When "no fix needed", output the tag for "Unable to proceed with fixes" and include the reason + checked scope
**Required output (include headings)**
## Files checked
- {path:line}
## Searches run
- {command and summary}
## Fixes applied
- {what changed}
## Test results
- {command and outcome}
**No-implementation handling (required)**
rules:
- condition: AI Reviewer's issues have been fixed
next: ai_review
- condition: No fix needed (verified target files/spec)
next: ai_no_fix
- condition: Unable to proceed with fixes
next: ai_no_fix
- name: ai_no_fix
edit: false
agent: ../agents/default/architecture-reviewer.md
allowed_tools:
- Read
- Glob
- Grep
rules:
- condition: ai_review's findings are valid (fix required)
next: ai_fix
- condition: ai_fix's judgment is valid (no fix needed)
next: reviewers
instruction_template: |
ai_review (reviewer) and ai_fix (coder) disagree.
- ai_review found issues and REJECTed
- ai_fix verified and determined "no fix needed"
Review both outputs and arbitrate which judgment is correct.
**Reports to reference:**
- AI Review results: {report:03-ai-review.md}
**Judgment criteria:**
- Are ai_review's findings specific and pointing to real issues in the code?
- Does ai_fix's rebuttal have evidence (file verification, test results)?
- Are the findings non-blocking (record-only) or do they require actual fixes?
# ===========================================
# Movement 3: Expert Reviews (Parallel)
# ===========================================
- name: reviewers
parallel:
- name: arch-review
edit: false
agent: ../agents/default/architecture-reviewer.md
report:
name: 04-architect-review.md
format: |
```markdown
# Architecture Review
## Result: APPROVE / REJECT
## Summary
{1-2 sentences summarizing result}
## Reviewed Aspects
- [x] Structure/Design
- [x] Code Quality
- [x] Change Scope
- [x] Test Coverage
- [x] Dead Code
- [x] Call Chain Verification
## Issues (if REJECT)
| # | Scope | Location | Issue | Fix |
|---|-------|----------|-------|-----|
| 1 | In-scope | `src/file.ts:42` | Issue description | Fix method |
Scope: "In-scope" (fixable now) / "Out-of-scope" (existing issue, non-blocking)
## Existing Issues (informational, non-blocking)
- {Record of existing issues unrelated to current change}
```
**Cognitive load reduction rules:**
- APPROVE -> Summary only (5 lines or less)
- REJECT -> Issues in table format (30 lines or less)
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
Focus on **architecture and design** review. Do NOT review AI-specific issues (that's the ai_review movement).
**Review Criteria:**
- Structure/design validity
- Code quality
- Change scope appropriateness
- Test coverage
- Dead code
- Call chain verification
- name: frontend-review
edit: false
agent: ../agents/expert/frontend-reviewer.md
report:
name: 05-frontend-review.md
format: |
```markdown
# Frontend Review
## Result: APPROVE / REJECT
## Summary
{1-2 sentences summarizing result}
## Reviewed Perspectives
| Perspective | Result | Notes |
|-------------|--------|-------|
| Component Design | ✅ | - |
| State Management | ✅ | - |
| Performance | ✅ | - |
| Accessibility | ✅ | - |
| Type Safety | ✅ | - |
## Issues (if REJECT)
| # | Location | Issue | Fix |
|---|----------|-------|-----|
| 1 | `src/file.tsx:42` | Issue description | Fix method |
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
Review the changes from the frontend development perspective.
**Review Criteria:**
- Component design (separation of concerns, granularity)
- State management (local/global decisions)
- Performance (re-rendering, memoization)
- Accessibility (keyboard support, ARIA)
- Data fetching patterns
- TypeScript type safety
**Note**: If this project does not include frontend code,
approve and proceed to the next movement.
- name: security-review
edit: false
agent: ../agents/expert/security-reviewer.md
report:
name: 06-security-review.md
format: |
```markdown
# Security Review
## Result: APPROVE / REJECT
## Severity: None / Low / Medium / High / Critical
## Check Results
| Category | Result | Notes |
|----------|--------|-------|
| Injection | ✅ | - |
| Auth/Authz | ✅ | - |
| Data Protection | ✅ | - |
| Dependencies | ✅ | - |
## Vulnerabilities (if REJECT)
| # | Severity | Type | Location | Fix |
|---|----------|------|----------|-----|
| 1 | High | SQLi | `src/db.ts:42` | Use parameterized query |
## Warnings (non-blocking)
- {Security recommendations}
```
**Cognitive load reduction rules:**
- No issues -> Check table only (10 lines or less)
- Warnings -> + Warnings 1-2 lines (15 lines or less)
- Vulnerabilities -> + Table format (30 lines or less)
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
Perform security review on the changes. Check for vulnerabilities including:
- Injection attacks (SQL, Command, XSS)
- Authentication/Authorization issues
- Data exposure risks
- Cryptographic weaknesses
- name: qa-review
edit: false
agent: ../agents/expert/qa-reviewer.md
report:
name: 07-qa-review.md
format: |
```markdown
# QA Review
## Result: APPROVE / REJECT
## Summary
{1-2 sentences summarizing result}
## Reviewed Perspectives
| Perspective | Result | Notes |
|-------------|--------|-------|
| Test Coverage | ✅ | - |
| Test Quality | ✅ | - |
| Error Handling | ✅ | - |
| Documentation | ✅ | - |
| Maintainability | ✅ | - |
## Issues (if REJECT)
| # | Category | Issue | Fix |
|---|----------|-------|-----|
| 1 | Testing | Issue description | Fix method |
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
Review the changes from the quality assurance perspective.
**Review Criteria:**
- Test coverage and quality
- Test strategy (unit/integration/E2E)
- Documentation (in-code and external)
- Error handling
- Logging and monitoring
- Maintainability
rules:
- condition: all("approved")
next: supervise
- condition: any("needs_fix")
next: fix
- name: fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Fix complete
next: reviewers
- condition: Cannot proceed, insufficient info
next: plan
instruction_template: |
Address the feedback from the reviewers.
The "Original User Request" is reference information, not the latest instruction.
Review the session conversation history and fix the issues raised by the reviewers.
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
## Evidence
- {key files/grep/diff/log evidence you verified}
# ===========================================
# Movement 4: Supervision
# ===========================================
- name: supervise
edit: false
agent: ../agents/expert/supervisor.md
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
## Previous Reviews Summary
Reaching this movement means all the following reviews have been APPROVED:
- Architecture Review: APPROVED
- Frontend Review: APPROVED
- AI Review: APPROVED
- Security Review: APPROVED
- QA Review: APPROVED
Run tests, verify the build, and perform final approval.
**Piece Overall Review:**
1. Does the implementation match the plan ({report:00-plan.md})?
2. Were all review movement issues addressed?
3. Was the original task objective achieved?
**Review Reports:** Read all reports in Report Directory and
check for any unaddressed improvement suggestions.
**Validation report format:**
```markdown
# Final Validation Results
## Result: APPROVE / REJECT
## Validation Summary
| Item | Status | Verification Method |
|------|--------|---------------------|
| Requirements met | ✅ | Matched against requirements list |
| Tests | ✅ | `npm test` (N passed) |
| Build | ✅ | `npm run build` succeeded |
| Functional check | ✅ | Main flows verified |
## Deliverables
- Created: {Created files}
- Modified: {Modified files}
## Incomplete Items (if REJECT)
| # | Item | Reason |
|---|------|--------|
| 1 | {Item} | {Reason} |
```
**Summary report format (only if APPROVE):**
```markdown
# Task Completion Summary
## Task
{Original request in 1-2 sentences}
## Result
✅ Complete
## Changes
| Type | File | Summary |
|------|------|---------|
| Create | `src/file.ts` | Summary description |
## Review Results
| Review | Result |
|--------|--------|
| Architecture | ✅ APPROVE |
| Frontend | ✅ APPROVE |
| AI Review | ✅ APPROVE |
| Security | ✅ APPROVE |
| QA | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## Verification Commands
```bash
npm test
npm run build
```
```
rules:
- condition: All validations pass and ready to merge
next: COMPLETE
- condition: Issues detected during final review
next: fix_supervisor
- name: fix_supervisor
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
Fix the issues pointed out by the supervisor.
The supervisor has identified issues from a big-picture perspective.
Address items in priority order.
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
## Evidence
- {key files/grep/diff/log evidence you verified}
rules:
- condition: Supervisor's issues have been fixed
next: supervise
- condition: Unable to proceed with fixes
next: plan

View File

@ -0,0 +1,428 @@
# Minimal TAKT Piece
# Implement -> Parallel Review (AI + Supervisor) -> Fix if needed -> Complete
# (Simplest configuration - no plan, no architect review)
#
# Template Variables (auto-injected):
# {iteration} - Piece-wide turn count (total movements executed across all agents)
# {max_iterations} - Maximum iterations allowed for the piece
# {movement_iteration} - Per-movement iteration count (how many times THIS movement has been executed)
# {task} - Original user request (auto-injected)
# {previous_response} - Output from the previous movement (auto-injected)
# {user_inputs} - Accumulated user inputs during piece (auto-injected)
# {report_dir} - Report directory name (e.g., "20250126-143052-task-summary")
name: minimal-hybrid-codex
description: Minimal development piece (implement -> parallel review -> fix if needed -> complete) (hybrid: coder=codex)
max_iterations: 20
initial_movement: implement
movements:
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
report:
- Scope: 01-coder-scope.md
- Decisions: 02-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
instruction_template: |
Implement the task.
Use only the Report Directory files shown in Piece Context. Do not search or open reports outside that directory.
**Scope report format (create at implementation start):**
```markdown
# Change Scope Declaration
## Task
{One-line task summary}
## Planned Changes
| Type | File |
|------|------|
| Create | `src/example.ts` |
| Modify | `src/routes.ts` |
## Estimated Size
Small / Medium / Large
## Impact Scope
- {Affected modules or features}
```
**Decisions report format (on completion, only if decisions were made):**
```markdown
# Decision Log
## 1. {Decision Content}
- **Background**: {Why the decision was needed}
- **Options Considered**: {List of options}
- **Reason**: {Why this option was chosen}
```
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
rules:
- condition: Implementation complete
next: reviewers
- condition: Cannot proceed, insufficient info
next: ABORT
- condition: User input required because there are items to confirm with the user
next: implement
requires_user_input: true
interactive_only: true
- name: reviewers
parallel:
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 03-ai-review.md
format: |
```markdown
# AI-Generated Code Review
## Result: APPROVE / REJECT
## Summary
{One sentence summarizing result}
## Verified Items
| Aspect | Result | Notes |
|--------|--------|-------|
| Assumption validity | ✅ | - |
| API/Library existence | ✅ | - |
| Context fit | ✅ | - |
| Scope | ✅ | - |
## Issues (if REJECT)
| # | Category | Location | Issue |
|---|----------|----------|-------|
| 1 | Hallucinated API | `src/file.ts:23` | Non-existent method |
```
**Cognitive load reduction rules:**
- No issues -> Summary 1 line + check table only (10 lines or less)
- Issues found -> + Issues in table format (25 lines or less)
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
Review the code for AI-specific issues:
- Assumption validation
- Plausible but wrong patterns
- Context fit with existing codebase
- Scope creep detection
rules:
- condition: No AI-specific issues
- condition: AI-specific issues found
- name: supervise
edit: false
agent: ../agents/default/supervisor.md
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
Run tests, verify the build, and perform final approval.
**Piece Overall Review:**
1. Does the implementation meet the original request?
2. Were AI Review issues addressed?
3. Was the original task objective achieved?
**Review Reports:** Read all reports in Report Directory and
check for any unaddressed improvement suggestions.
**Validation report format:**
```markdown
# Final Validation Results
## Result: APPROVE / REJECT
## Validation Summary
| Item | Status | Verification Method |
|------|--------|---------------------|
| Requirements met | ✅ | Matched against requirements list |
| Tests | ✅ | `npm test` (N passed) |
| Build | ✅ | `npm run build` succeeded |
| Functional check | ✅ | Main flows verified |
## Deliverables
- Created: {Created files}
- Modified: {Modified files}
## Incomplete Items (if REJECT)
| # | Item | Reason |
|---|------|--------|
| 1 | {Item} | {Reason} |
```
**Summary report format (only if APPROVE):**
```markdown
# Task Completion Summary
## Task
{Original request in 1-2 sentences}
## Result
✅ Complete
## Changes
| Type | File | Summary |
|------|------|---------|
| Create | `src/file.ts` | Summary description |
## Review Results
| Review | Result |
|--------|--------|
| AI Review | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## Verification Commands
```bash
npm test
npm run build
```
```
rules:
- condition: All checks passed
- condition: Requirements unmet, tests failing
rules:
- condition: all("No AI-specific issues", "All checks passed")
next: COMPLETE
- condition: all("AI-specific issues found", "Requirements unmet, tests failing")
next: fix_both
- condition: any("AI-specific issues found")
next: ai_fix
- condition: any("Requirements unmet, tests failing")
next: supervise_fix
- name: fix_both
parallel:
- name: ai_fix_parallel
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI Reviewer's issues fixed
- condition: No fix needed (verified target files/spec)
- condition: Cannot proceed, insufficient info
instruction_template: |
**This is AI Review iteration {movement_iteration}.**
If this is iteration 2 or later, it means your previous fixes were not actually applied.
**Your belief that you "already fixed it" is wrong.**
**First, acknowledge:**
- Files you thought were "fixed" are actually not fixed
- Your understanding of previous work is incorrect
- You need to start from zero
**Required actions:**
1. Open all flagged files with Read tool (drop assumptions, verify facts)
2. Search for problem code with grep to confirm it exists
3. Fix confirmed problems with Edit tool
4. Run tests to verify (e.g., `npm test`, `./gradlew test`)
5. Report specifically "what you checked and what you fixed"
**Report format:**
- ❌ "Already fixed"
- ✅ "Checked file X at L123, found problem Y, fixed to Z"
**Absolutely prohibited:**
- Reporting "fixed" without opening files
- Judging based on assumptions
- Leaving problems that AI Reviewer REJECTED
**Handling "no fix needed" (required)**
- Do not claim "no fix needed" unless you can show the checked target file(s) for each AI Review issue
- If an issue involves generated code or spec sync, and you cannot verify the source spec, output the tag for "Cannot proceed, insufficient info"
- When "no fix needed", output the tag for "Cannot proceed, insufficient info" and include the reason + checked scope
**Required output (include headings)**
## Files checked
- {path:line}
## Searches run
- {command and summary}
## Fixes applied
- {what changed}
## Test results
- {command and outcome}
- name: supervise_fix_parallel
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Supervisor's issues fixed
- condition: Cannot proceed, insufficient info
instruction_template: |
Fix the issues pointed out by the supervisor.
The supervisor has identified issues from a big-picture perspective.
Address items in priority order.
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
## Evidence
- {key files/grep/diff/log evidence you verified}
rules:
- condition: all("AI Reviewer's issues fixed", "Supervisor's issues fixed")
next: reviewers
- condition: any("No fix needed (verified target files/spec)", "Cannot proceed, insufficient info")
next: implement
- name: ai_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI Reviewer's issues fixed
next: reviewers
- condition: No fix needed (verified target files/spec)
next: implement
- condition: Cannot proceed, insufficient info
next: implement
instruction_template: |
**This is AI Review iteration {movement_iteration}.**
If this is iteration 2 or later, it means your previous fixes were not actually applied.
**Your belief that you "already fixed it" is wrong.**
**First, acknowledge:**
- Files you thought were "fixed" are actually not fixed
- Your understanding of previous work is incorrect
- You need to start from zero
**Required actions:**
1. Open all flagged files with Read tool (drop assumptions, verify facts)
2. Search for problem code with grep to confirm it exists
3. Fix confirmed problems with Edit tool
4. Run tests to verify (e.g., `npm test`, `./gradlew test`)
5. Report specifically "what you checked and what you fixed"
**Report format:**
- ❌ "Already fixed"
- ✅ "Checked file X at L123, found problem Y, fixed to Z"
**Absolutely prohibited:**
- Reporting "fixed" without opening files
- Judging based on assumptions
- Leaving problems that AI Reviewer REJECTED
**Handling "no fix needed" (required)**
- Do not claim "no fix needed" unless you can show the checked target file(s) for each AI Review issue
- If an issue involves generated code or spec sync, and you cannot verify the source spec, output the tag for "Cannot proceed, insufficient info"
- When "no fix needed", output the tag for "Cannot proceed, insufficient info" and include the reason + checked scope
**Required output (include headings)**
## Files checked
- {path:line}
## Searches run
- {command and summary}
## Fixes applied
- {what changed}
## Test results
- {command and outcome}
- name: supervise_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Supervisor's issues fixed
next: reviewers
- condition: Cannot proceed, insufficient info
next: implement
instruction_template: |
Fix the issues pointed out by the supervisor.
The supervisor has identified issues from a big-picture perspective.
Address items in priority order.
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
## Evidence
- {key files/grep/diff/log evidence you verified}

View File

@ -0,0 +1,43 @@
# Passthrough TAKT Piece
# Thinnest wrapper. Pass task directly to coder as-is.
#
# Flow:
# execute (do the task)
# ↓
# COMPLETE
name: passthrough-hybrid-codex
description: Single-agent thin wrapper. Pass task directly to coder as-is. (hybrid: coder=codex)
max_iterations: 10
initial_movement: execute
movements:
- name: execute
edit: true
agent: ../agents/default/coder.md
provider: codex
report:
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Task complete
next: COMPLETE
- condition: Cannot proceed
next: ABORT
- condition: User input required
next: execute
requires_user_input: true
interactive_only: true
instruction_template: |
Do the task.

View File

@ -0,0 +1,428 @@
# Review-Fix Minimal TAKT Piece
# Review -> Fix (if needed) -> Re-review -> Complete
# (Starts with review, no implementation movement)
#
# Template Variables (auto-injected):
# {iteration} - Piece-wide turn count (total movements executed across all agents)
# {max_iterations} - Maximum iterations allowed for the piece
# {movement_iteration} - Per-movement iteration count (how many times THIS movement has been executed)
# {task} - Original user request (auto-injected)
# {previous_response} - Output from the previous movement (auto-injected)
# {user_inputs} - Accumulated user inputs during piece (auto-injected)
# {report_dir} - Report directory name (e.g., "20250126-143052-task-summary")
name: review-fix-minimal-hybrid-codex
description: Review and fix piece for existing code (starts with review, no implementation) (hybrid: coder=codex)
max_iterations: 20
initial_movement: reviewers
movements:
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
report:
- Scope: 01-coder-scope.md
- Decisions: 02-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
instruction_template: |
Implement the task.
Use only the Report Directory files shown in Piece Context. Do not search or open reports outside that directory.
**Scope report format (create at implementation start):**
```markdown
# Change Scope Declaration
## Task
{One-line task summary}
## Planned Changes
| Type | File |
|------|------|
| Create | `src/example.ts` |
| Modify | `src/routes.ts` |
## Estimated Size
Small / Medium / Large
## Impact Scope
- {Affected modules or features}
```
**Decisions report format (on completion, only if decisions were made):**
```markdown
# Decision Log
## 1. {Decision Content}
- **Background**: {Why the decision was needed}
- **Options Considered**: {List of options}
- **Reason**: {Why this option was chosen}
```
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
rules:
- condition: Implementation complete
next: reviewers
- condition: Cannot proceed, insufficient info
next: ABORT
- condition: User input required because there are items to confirm with the user
next: implement
requires_user_input: true
interactive_only: true
- name: reviewers
parallel:
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 03-ai-review.md
format: |
```markdown
# AI-Generated Code Review
## Result: APPROVE / REJECT
## Summary
{One sentence summarizing result}
## Verified Items
| Aspect | Result | Notes |
|--------|--------|-------|
| Assumption validity | ✅ | - |
| API/Library existence | ✅ | - |
| Context fit | ✅ | - |
| Scope | ✅ | - |
## Issues (if REJECT)
| # | Category | Location | Issue |
|---|----------|----------|-------|
| 1 | Hallucinated API | `src/file.ts:23` | Non-existent method |
```
**Cognitive load reduction rules:**
- No issues -> Summary 1 line + check table only (10 lines or less)
- Issues found -> + Issues in table format (25 lines or less)
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
Review the code for AI-specific issues:
- Assumption validation
- Plausible but wrong patterns
- Context fit with existing codebase
- Scope creep detection
rules:
- condition: No AI-specific issues
- condition: AI-specific issues found
- name: supervise
edit: false
agent: ../agents/default/supervisor.md
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
Run tests, verify the build, and perform final approval.
**Piece Overall Review:**
1. Does the implementation meet the original request?
2. Were AI Review issues addressed?
3. Was the original task objective achieved?
**Review Reports:** Read all reports in Report Directory and
check for any unaddressed improvement suggestions.
**Validation report format:**
```markdown
# Final Validation Results
## Result: APPROVE / REJECT
## Validation Summary
| Item | Status | Verification Method |
|------|--------|---------------------|
| Requirements met | ✅ | Matched against requirements list |
| Tests | ✅ | `npm test` (N passed) |
| Build | ✅ | `npm run build` succeeded |
| Functional check | ✅ | Main flows verified |
## Deliverables
- Created: {Created files}
- Modified: {Modified files}
## Incomplete Items (if REJECT)
| # | Item | Reason |
|---|------|--------|
| 1 | {Item} | {Reason} |
```
**Summary report format (only if APPROVE):**
```markdown
# Task Completion Summary
## Task
{Original request in 1-2 sentences}
## Result
✅ Complete
## Changes
| Type | File | Summary |
|------|------|---------|
| Create | `src/file.ts` | Summary description |
## Review Results
| Review | Result |
|--------|--------|
| AI Review | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## Verification Commands
```bash
npm test
npm run build
```
```
rules:
- condition: All checks passed
- condition: Requirements unmet, tests failing
rules:
- condition: all("No AI-specific issues", "All checks passed")
next: COMPLETE
- condition: all("AI-specific issues found", "Requirements unmet, tests failing")
next: fix_both
- condition: any("AI-specific issues found")
next: ai_fix
- condition: any("Requirements unmet, tests failing")
next: supervise_fix
- name: fix_both
parallel:
- name: ai_fix_parallel
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI Reviewer's issues fixed
- condition: No fix needed (verified target files/spec)
- condition: Cannot proceed, insufficient info
instruction_template: |
**This is AI Review iteration {movement_iteration}.**
If this is iteration 2 or later, it means your previous fixes were not actually applied.
**Your belief that you "already fixed it" is wrong.**
**First, acknowledge:**
- Files you thought were "fixed" are actually not fixed
- Your understanding of previous work is incorrect
- You need to start from zero
**Required actions:**
1. Open all flagged files with Read tool (drop assumptions, verify facts)
2. Search for problem code with grep to confirm it exists
3. Fix confirmed problems with Edit tool
4. Run tests to verify (e.g., `npm test`, `./gradlew test`)
5. Report specifically "what you checked and what you fixed"
**Report format:**
- ❌ "Already fixed"
- ✅ "Checked file X at L123, found problem Y, fixed to Z"
**Absolutely prohibited:**
- Reporting "fixed" without opening files
- Judging based on assumptions
- Leaving problems that AI Reviewer REJECTED
**Handling "no fix needed" (required)**
- Do not claim "no fix needed" unless you can show the checked target file(s) for each AI Review issue
- If an issue involves generated code or spec sync, and you cannot verify the source spec, output the tag for "Cannot proceed, insufficient info"
- When "no fix needed", output the tag for "Cannot proceed, insufficient info" and include the reason + checked scope
**Required output (include headings)**
## Files checked
- {path:line}
## Searches run
- {command and summary}
## Fixes applied
- {what changed}
## Test results
- {command and outcome}
- name: supervise_fix_parallel
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Supervisor's issues fixed
- condition: Cannot proceed, insufficient info
instruction_template: |
Fix the issues pointed out by the supervisor.
The supervisor has identified issues from a big-picture perspective.
Address items in priority order.
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
## Evidence
- {key files/grep/diff/log evidence you verified}
rules:
- condition: all("AI Reviewer's issues fixed", "Supervisor's issues fixed")
next: reviewers
- condition: any("No fix needed (verified target files/spec)", "Cannot proceed, insufficient info")
next: implement
- name: ai_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI Reviewer's issues fixed
next: reviewers
- condition: No fix needed (verified target files/spec)
next: implement
- condition: Cannot proceed, insufficient info
next: implement
instruction_template: |
**This is AI Review iteration {movement_iteration}.**
If this is iteration 2 or later, it means your previous fixes were not actually applied.
**Your belief that you "already fixed it" is wrong.**
**First, acknowledge:**
- Files you thought were "fixed" are actually not fixed
- Your understanding of previous work is incorrect
- You need to start from zero
**Required actions:**
1. Open all flagged files with Read tool (drop assumptions, verify facts)
2. Search for problem code with grep to confirm it exists
3. Fix confirmed problems with Edit tool
4. Run tests to verify (e.g., `npm test`, `./gradlew test`)
5. Report specifically "what you checked and what you fixed"
**Report format:**
- ❌ "Already fixed"
- ✅ "Checked file X at L123, found problem Y, fixed to Z"
**Absolutely prohibited:**
- Reporting "fixed" without opening files
- Judging based on assumptions
- Leaving problems that AI Reviewer REJECTED
**Handling "no fix needed" (required)**
- Do not claim "no fix needed" unless you can show the checked target file(s) for each AI Review issue
- If an issue involves generated code or spec sync, and you cannot verify the source spec, output the tag for "Cannot proceed, insufficient info"
- When "no fix needed", output the tag for "Cannot proceed, insufficient info" and include the reason + checked scope
**Required output (include headings)**
## Files checked
- {path:line}
## Searches run
- {command and summary}
## Fixes applied
- {what changed}
## Test results
- {command and outcome}
- name: supervise_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Supervisor's issues fixed
next: reviewers
- condition: Cannot proceed, insufficient info
next: implement
instruction_template: |
Fix the issues pointed out by the supervisor.
The supervisor has identified issues from a big-picture perspective.
Address items in priority order.
**Required output (include headings)**
## Work done
- {summary of work performed}
## Changes made
- {summary of code changes}
## Test results
- {command and outcome}
## Evidence
- {key files/grep/diff/log evidence you verified}

View File

@ -0,0 +1,359 @@
# Coding TAKT Piece
# Architect -> Implement -> Parallel Review (AI + Architecture) -> Fix if needed
#
# 設計を重視しながらも、planとsuperviseを省略した軽量な開発ピース。
# 並列レビュー後、問題がなければ直接完了し、高速なフィードバックループを実現。
#
# フロー:
# architect (設計)
# ↓
# implement (実装)
# ↓
# reviewers (並列レビュー)
# ├─ ai_review (AI特有問題検出)
# └─ arch-review (設計準拠性確認)
# ↓
# [判定]
# ├─ all(approved) → COMPLETE
# └─ any(needs_fix) → fix → reviewers (再レビュー)
#
# Template Variables (auto-injected by buildInstruction):
# {iteration} - Piece-wide turn count (total movements executed across all agents)
# {max_iterations} - Maximum iterations allowed for the piece
# {movement_iteration} - Per-movement iteration count (how many times THIS movement has been executed)
# {task} - Original user request
# {previous_response} - Output from the previous movement
# {user_inputs} - Accumulated user inputs during piece
# {report_dir} - Report directory name (e.g., "20250126-143052-task-summary")
name: coding-hybrid-codex
description: Architecture-focused development piece with parallel reviews (architect -> implement -> parallel review -> complete) (hybrid: coder=codex)
max_iterations: 20
initial_movement: architect-plan
movements:
- name: architect-plan
edit: false
agent: ../agents/default/architecture-reviewer.md
report:
name: architecture-reviewer
format: |
```markdown
# アーキテクチャ設計
## タスク規模
Small / Medium / Large
## 設計判断
### ファイル構成
| ファイル | 役割 |
|---------|------|
| `src/example.ts` | 概要 |
### 技術選定
- {選定した技術・ライブラリとその理由}
### 設計パターン
- {採用するパターンと適用箇所}
## 実装ガイドライン
- {Coderが実装時に従うべき指針}
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: 小規模タスク(設計不要)
next: implement
- condition: 設計完了
next: implement
- condition: 情報不足、判断できない
next: ABORT
instruction_template: |
タスクのアーキテクチャ設計を行ってください。
**タスク**: {task}
**進行状況**: {iteration}/{max_iterations} ターン
**小規模タスクの判断基準:**
- 1-2ファイルの変更のみ
- 既存パターンの踏襲で済む
- 技術選定が不要
小規模タスクの場合は設計レポートを作成せず、「小規模タスク(設計不要)」のルールに対応してください。
**設計が必要なタスク:**
- 3ファイル以上の変更
- 新しいモジュール・機能の追加
- 技術選定が必要
- アーキテクチャパターンの決定が必要
**やること:**
1. タスクの規模を評価Small/Medium/Large
2. 影響を受けるファイル構成を特定
3. 必要に応じて技術選定を行う
4. 設計パターンの選択
5. Coderへの実装ガイドライン作成
**やらないこと:**
- コードの実装Coderの仕事
- コードレビュー
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
report:
- Scope: 02-coder-scope.md
- Decisions: 03-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 実装完了
next: reviewers
- condition: 実装未着手(レポートのみ)
next: reviewers
- condition: 判断できない、情報不足
next: reviewers
- condition: ユーザー入力が必要
next: implement
requires_user_input: true
interactive_only: true
instruction_template: |
architect-planムーブメントで決定した設計に従って実装してください。
**参照するレポート:**
- 設計: {report:01-architecture.md}(存在する場合)
Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
**重要:** 設計判断はせず、architect-planムーブメントで決定された設計に従ってください。
不明点や設計の変更が必要な場合は報告してください。
**重要**: 実装と同時に単体テストを追加してください。
- 新規作成したクラス・関数には単体テストを追加
- 既存コードを変更した場合は該当するテストを更新
- テストファイルの配置: プロジェクトの規約に従う(例: `__tests__/`, `*.test.ts`
- **テスト実行は必須です。** 実装完了後、必ずテストを実行して結果を確認してください。
**Scopeレポートフォーマット実装開始時に作成:**
```markdown
# 変更スコープ宣言
## タスク
{タスクの1行要約}
## 変更予定
| 種別 | ファイル |
|------|---------|
| 作成 | `src/example.ts` |
| 変更 | `src/routes.ts` |
## 推定規模
Small / Medium / Large
## 影響範囲
- {影響するモジュールや機能}
```
**Decisionsレポートフォーマット実装完了時、決定がある場合のみ:**
```markdown
# 決定ログ
## 1. {決定内容}
- **背景**: {なぜ決定が必要だったか}
- **検討した選択肢**: {選択肢リスト}
- **理由**: {選んだ理由}
```
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
- name: reviewers
parallel:
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 04-ai-review.md
format: |
```markdown
# AI生成コードレビュー
## 結果: APPROVE / REJECT
## サマリー
{1文で結果を要約}
## 検証した項目
| 観点 | 結果 | 備考 |
|------|------|------|
| 仮定の妥当性 | ✅ | - |
| API/ライブラリの実在 | ✅ | - |
| コンテキスト適合 | ✅ | - |
| スコープ | ✅ | - |
## 問題点REJECTの場合
| # | カテゴリ | 場所 | 問題 |
|---|---------|------|------|
| 1 | 幻覚API | `src/file.ts:23` | 存在しないメソッド |
```
**認知負荷軽減ルール:**
- 問題なし → サマリー1文 + チェック表のみ10行以内
- 問題あり → + 問題を表形式で25行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: AI特有の問題なし
- condition: AI特有の問題あり
instruction_template: |
AI特有の問題についてコードをレビューしてください:
- 仮定の検証
- もっともらしいが間違っているパターン
- 既存コードベースとの適合性
- スコープクリープの検出
**参照するレポート:**
- 実装スコープ: {report:02-coder-scope.md}
- 決定ログ: {report:03-coder-decisions.md}(存在する場合)
- name: arch-review
edit: false
agent: ../agents/default/architecture-reviewer.md
report:
name: 05-architect-review.md
format: |
```markdown
# アーキテクチャレビュー
## 結果: APPROVE / REJECT
## サマリー
{1-2文で結果を要約}
## 確認した観点
- [x] 構造・設計
- [x] コード品質
- [x] 変更スコープ
- [x] テストカバレッジ
- [x] デッドコード
- [x] 呼び出しチェーン検証
## 問題点REJECTの場合
| # | スコープ | 場所 | 問題 | 修正案 |
|---|---------|------|------|--------|
| 1 | スコープ内 | `src/file.ts:42` | 問題の説明 | 修正方法 |
スコープ: 「スコープ内」(今回修正可能)/ 「スコープ外」(既存問題・非ブロッキング)
## 既存問題(参考・非ブロッキング)
- {既存問題の記録。今回の変更と無関係な問題}
```
**認知負荷軽減ルール:**
- APPROVE → サマリーのみ5行以内
- REJECT → 問題点を表形式で30行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
**実装がarchitectムーブメントの設計に従っているか**を確認してください。
AI特有の問題はレビューしないでくださいai_reviewムーブメントで行います
**参照するレポート:**
- 設計: {report:01-architecture.md}(存在する場合)
- 実装スコープ: {report:02-coder-scope.md}
**レビュー観点:**
- 設計との整合性architectが定めたファイル構成・パターンに従っているか
- コード品質DRY、YAGNI、Fail Fast、イディオマティック
- 変更スコープの適切性
- テストカバレッジ
- デッドコード
- 呼び出しチェーン検証
**注意:** architectムーブメントをスキップした小規模タスクの場合は、従来通り設計の妥当性も確認してください。
rules:
- condition: all("AI特有の問題なし", "approved")
next: COMPLETE
- condition: any("AI特有の問題あり", "needs_fix")
next: fix
- name: fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 修正完了
next: reviewers
- condition: 判断できない、情報不足
next: ABORT
instruction_template: |
レビュアーのフィードバックに対応してください。
**両方のレビュー結果を確認してください:**
- AI Review: {report:04-ai-review.md}
- Architecture Review: {report:05-architect-review.md}
**重要:** 両方のレビューで指摘された問題を全て修正してください。
- AI Reviewの指摘: 幻覚API、仮定の妥当性、スコープクリープ等
- Architecture Reviewの指摘: 設計との整合性、コード品質、テストカバレッジ等
**必須アクション:**
1. 指摘された全ファイルを Read tool で開く
2. 問題箇所を確認する
3. Edit tool で修正する
4. **テストを実行して検証する(必須)**
5. 修正内容を具体的に報告する
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
## 証拠
- {確認したファイル/検索/差分/ログの要点を列挙}

View File

@ -0,0 +1,628 @@
# Default TAKT Piece
# Plan -> Architect -> Implement -> AI Review -> Reviewers (parallel: Architect + QA) -> Supervisor Approval
#
# Template Variables (auto-injected by buildInstruction):
# {iteration} - Piece-wide turn count (total movements executed across all agents)
# {max_iterations} - Maximum iterations allowed for the piece
# {movement_iteration} - Per-movement iteration count (how many times THIS movement has been executed)
# {task} - Original user request
# {previous_response} - Output from the previous movement
# {user_inputs} - Accumulated user inputs during piece
# {report_dir} - Report directory name (e.g., "20250126-143052-task-summary")
name: default-hybrid-codex
description: Standard development piece with planning and specialized reviews (hybrid: coder=codex)
max_iterations: 30
initial_movement: plan
loop_monitors:
- cycle: [ai_review, ai_fix]
threshold: 3
judge:
agent: ../agents/default/supervisor.md
instruction_template: |
ai_review と ai_fix のループが {cycle_count} 回繰り返されました。
各サイクルのレポートを確認し、このループが健全(進捗がある)か、
非生産的(同じ問題を繰り返している)かを判断してください。
**参照するレポート:**
- AIレビュー結果: {report:04-ai-review.md}
**判断基準:**
- 各サイクルで新しい問題が発見・修正されているか
- 同じ指摘が繰り返されていないか
- 修正が実際に反映されているか
rules:
- condition: 健全(進捗あり)
next: ai_review
- condition: 非生産的(改善なし)
next: reviewers
movements:
- name: plan
edit: false
agent: ../agents/default/planner.md
report:
name: 00-plan.md
format: |
```markdown
# タスク計画
## 元の要求
{ユーザーの要求をそのまま記載}
## 分析結果
### 目的
{達成すべきこと}
### スコープ
{影響範囲}
### 実装アプローチ
{どう進めるか}
## 確認事項(あれば)
- {不明点や確認が必要な点}
```
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
rules:
- condition: 要件が明確で実装可能
next: architect
- condition: ユーザーが質問をしている(実装タスクではない)
next: COMPLETE
- condition: 要件が不明確、情報不足
next: ABORT
appendix: |
確認事項:
- {質問1}
- {質問2}
instruction_template: |
タスクを分析し、実装方針を立ててください。
**注意:** Previous Responseがある場合は差し戻しのため、
その内容を踏まえて計画を見直してくださいreplan
**やること(実装タスクの場合):**
1. タスクの要件を理解する
2. 影響範囲を特定する
3. 実装アプローチを決める
- name: architect
edit: false
agent: ../agents/default/architect.md
report:
name: 01-architecture.md
format: |
```markdown
# アーキテクチャ設計
## タスク規模
Small / Medium / Large
## 設計判断
### ファイル構成
| ファイル | 役割 |
|---------|------|
| `src/example.ts` | 概要 |
### 技術選定
- {選定した技術・ライブラリとその理由}
### 設計パターン
- {採用するパターンと適用箇所}
## 実装ガイドライン
- {Coderが実装時に従うべき指針}
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: 小規模タスク(設計不要)
next: implement
- condition: 設計完了
next: implement
- condition: 情報不足、判断できない
next: ABORT
instruction_template: |
計画レポート({report:00-plan.md})を読み、アーキテクチャ設計を行ってください。
**小規模タスクの判断基準:**
- 1-2ファイルの変更のみ
- 既存パターンの踏襲で済む
- 技術選定が不要
小規模タスクの場合は設計レポートを作成せず、「小規模タスク(設計不要)」のルールに対応してください。
**設計が必要なタスク:**
- 3ファイル以上の変更
- 新しいモジュール・機能の追加
- 技術選定が必要
- アーキテクチャパターンの決定が必要
**やること:**
1. タスクの規模を評価
2. ファイル構成を決定
3. 技術選定(必要な場合)
4. 設計パターンの選択
5. Coderへの実装ガイドライン作成
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
report:
- Scope: 02-coder-scope.md
- Decisions: 03-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 実装完了
next: ai_review
- condition: 実装未着手(レポートのみ)
next: ai_review
- condition: 判断できない、情報不足
next: ai_review
- condition: ユーザー入力が必要
next: implement
requires_user_input: true
interactive_only: true
instruction_template: |
planムーブメントで立てた計画と、architectムーブメントで決定した設計に従って実装してください。
**参照するレポート:**
- 計画: {report:00-plan.md}
- 設計: {report:01-architecture.md}(存在する場合)
Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
**重要:** 設計判断はせず、architectムーブメントで決定された設計に従ってください。
不明点や設計の変更が必要な場合は報告してください。
**重要**: 実装と同時に単体テストを追加してください。
- 新規作成したクラス・関数には単体テストを追加
- 既存コードを変更した場合は該当するテストを更新
- テストファイルの配置: プロジェクトの規約に従う(例: `__tests__/`, `*.test.ts`
**Scopeレポートフォーマット実装開始時に作成:**
```markdown
# 変更スコープ宣言
## タスク
{タスクの1行要約}
## 変更予定
| 種別 | ファイル |
|------|---------|
| 作成 | `src/example.ts` |
| 変更 | `src/routes.ts` |
## 推定規模
Small / Medium / Large
## 影響範囲
- {影響するモジュールや機能}
```
**Decisionsレポートフォーマット実装完了時、決定がある場合のみ:**
```markdown
# 決定ログ
## 1. {決定内容}
- **背景**: {なぜ決定が必要だったか}
- **検討した選択肢**: {選択肢リスト}
- **理由**: {選んだ理由}
```
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 04-ai-review.md
format: |
```markdown
# AI生成コードレビュー
## 結果: APPROVE / REJECT
## サマリー
{1文で結果を要約}
## 検証した項目
| 観点 | 結果 | 備考 |
|------|------|------|
| 仮定の妥当性 | ✅ | - |
| API/ライブラリの実在 | ✅ | - |
| コンテキスト適合 | ✅ | - |
| スコープ | ✅ | - |
## 問題点REJECTの場合
| # | カテゴリ | 場所 | 問題 |
|---|---------|------|------|
| 1 | 幻覚API | `src/file.ts:23` | 存在しないメソッド |
```
**認知負荷軽減ルール:**
- 問題なし → サマリー1文 + チェック表のみ10行以内
- 問題あり → + 問題を表形式で25行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: AI特有の問題なし
next: reviewers
- condition: AI特有の問題あり
next: ai_fix
instruction_template: |
**これは {movement_iteration} 回目のAI Reviewです。**
初回は網羅的にレビューし、指摘すべき問題をすべて出し切ってください。
2回目以降は、前回REJECTした項目が修正されたかの確認を優先してください。
AI特有の問題についてコードをレビューしてください:
- 仮定の検証
- もっともらしいが間違っているパターン
- 既存コードベースとの適合性
- スコープクリープの検出
- name: ai_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI問題の修正完了
next: ai_review
- condition: 修正不要(指摘対象ファイル/仕様の確認済み)
next: ai_no_fix
- condition: 判断できない、情報不足
next: ai_no_fix
instruction_template: |
**これは {movement_iteration} 回目の AI Review です。**
2回目以降は、前回の修正が実際には行われていなかったということです。
**あなたの「修正済み」という認識が間違っています。**
**まず認めること:**
- 「修正済み」と思っていたファイルは実際には修正されていない
- 前回の作業内容の認識が間違っている
- ゼロベースで考え直す必要がある
**必須アクション:**
1. 指摘された全ファイルを Read tool で開く(思い込みを捨てて事実確認)
2. 問題箇所を grep で検索して実在を確認する
3. 確認した問題を Edit tool で修正する
4. テストを実行して検証する(`./gradlew :backend:test` 等)
5. 「何を確認して、何を修正したか」を具体的に報告する
**報告フォーマット:**
- ❌ 「既に修正されています」
- ✅ 「ファイルXのL123を確認した結果、問題Yが存在したため、Zに修正しました」
**絶対に禁止:**
- ファイルを開かずに「修正済み」と報告
**修正不要の扱い(必須)**
- AI Reviewの指摘ごとに「対象ファイルの確認結果」を示せない場合は修正不要と判断しない
- 指摘が「生成物」「仕様同期」に関係する場合は、生成元/仕様の確認ができなければ「判断できない、情報不足」に対応するタグを出力する
- 修正不要の場合は「判断できない、情報不足」に対応するタグを出力し、理由と確認範囲を明記する
**必須出力(見出しを含める)**
## 確認したファイル
- {ファイルパス:行番号}
## 実行した検索
- {コマンドと要約}
## 修正内容
- {変更内容}
## テスト結果
- {実行コマンドと結果}
- 思い込みで判断
- AI Reviewer が REJECT した問題の放置
- name: ai_no_fix
edit: false
agent: ../agents/default/architecture-reviewer.md
allowed_tools:
- Read
- Glob
- Grep
rules:
- condition: ai_reviewの指摘が妥当修正すべき
next: ai_fix
- condition: ai_fixの判断が妥当修正不要
next: reviewers
instruction_template: |
ai_reviewレビュアーと ai_fixコーダーの意見が食い違っています。
- ai_review は問題を指摘し REJECT しました
- ai_fix は確認の上「修正不要」と判断しました
両者の出力を確認し、どちらの判断が妥当か裁定してください。
**参照するレポート:**
- AIレビュー結果: {report:04-ai-review.md}
**判断基準:**
- ai_review の指摘が具体的で、コード上の実在する問題を指しているか
- ai_fix の反論に根拠(ファイル確認結果、テスト結果)があるか
- 指摘が非ブロッキング(記録のみ)レベルか、実際に修正が必要か
- name: reviewers
parallel:
- name: arch-review
edit: false
agent: ../agents/default/architecture-reviewer.md
report:
name: 05-architect-review.md
format: |
```markdown
# アーキテクチャレビュー
## 結果: APPROVE / REJECT
## サマリー
{1-2文で結果を要約}
## 確認した観点
- [x] 構造・設計
- [x] コード品質
- [x] 変更スコープ
- [x] テストカバレッジ
- [x] デッドコード
- [x] 呼び出しチェーン検証
## 問題点REJECTの場合
| # | スコープ | 場所 | 問題 | 修正案 |
|---|---------|------|------|--------|
| 1 | スコープ内 | `src/file.ts:42` | 問題の説明 | 修正方法 |
スコープ: 「スコープ内」(今回修正可能)/ 「スコープ外」(既存問題・非ブロッキング)
## 既存問題(参考・非ブロッキング)
- {既存問題の記録。今回の変更と無関係な問題}
```
**認知負荷軽減ルール:**
- APPROVE → サマリーのみ5行以内
- REJECT → 問題点を表形式で30行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
**実装がarchitectムーブメントの設計に従っているか**を確認してください。
AI特有の問題はレビューしないでくださいai_reviewムーブメントで行います
**参照するレポート:**
- 設計: {report:01-architecture.md}(存在する場合)
- 実装スコープ: {report:02-coder-scope.md}
**レビュー観点:**
- 設計との整合性architectが定めたファイル構成・パターンに従っているか
- コード品質
- 変更スコープの適切性
- テストカバレッジ
- デッドコード
- 呼び出しチェーン検証
**注意:** architectムーブメントをスキップした小規模タスクの場合は、従来通り設計の妥当性も確認してください。
- name: qa-review
edit: false
agent: ../agents/default/qa-reviewer.md
report:
name: 06-qa-review.md
format: |
```markdown
# QAレビュー
## 結果: APPROVE / REJECT
## サマリー
{1-2文で結果を要約}
## レビュー観点
| 観点 | 結果 | 備考 |
|------|------|------|
| テストカバレッジ | ✅ | - |
| テスト品質 | ✅ | - |
| エラーハンドリング | ✅ | - |
| ドキュメント | ✅ | - |
| 保守性 | ✅ | - |
## 問題点REJECTの場合
| # | カテゴリ | 問題 | 修正案 |
|---|---------|------|--------|
| 1 | テスト | 問題の説明 | 修正方法 |
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
品質保証の観点から変更をレビューしてください。
**レビュー観点:**
- テストカバレッジと品質
- テスト戦略unit/integration/E2E
- エラーハンドリング
- ログとモニタリング
- 保守性
rules:
- condition: all("approved")
next: supervise
- condition: any("needs_fix")
next: fix
- name: fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 修正完了
next: reviewers
- condition: 判断できない、情報不足
next: plan
instruction_template: |
レビュアーのフィードバックに対応してください。
セッションの会話履歴を確認し、レビュアーの指摘事項を修正してください。
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
## 証拠
- {確認したファイル/検索/差分/ログの要点を列挙}
- name: supervise
edit: false
agent: ../agents/default/supervisor.md
report:
- Validation: 07-supervisor-validation.md
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
rules:
- condition: すべて問題なし
next: COMPLETE
- condition: 要求未達成、テスト失敗、ビルドエラー
next: plan
instruction_template: |
テスト実行、ビルド確認、最終承認を行ってください。
**ピース全体の確認:**
1. 計画({report:00-plan.md})と設計({report:01-architecture.md}、存在する場合)に従った実装か
2. 各レビュームーブメントの指摘が対応されているか
3. 元のタスク目的が達成されているか
**レポートの確認:** Report Directory内の全レポートを読み、
未対応の改善提案がないか確認してください。
**Validationレポートフォーマット:**
```markdown
# 最終検証結果
## 結果: APPROVE / REJECT
## 検証サマリー
| 項目 | 状態 | 確認方法 |
|------|------|---------|
| 要求充足 | ✅ | 要求リストと照合 |
| テスト | ✅ | `npm test` (N passed) |
| ビルド | ✅ | `npm run build` 成功 |
| 動作確認 | ✅ | 主要フロー確認 |
## 成果物
- 作成: {作成したファイル}
- 変更: {変更したファイル}
## 未完了項目REJECTの場合
| # | 項目 | 理由 |
|---|------|------|
| 1 | {項目} | {理由} |
```
**SummaryレポートフォーマットAPPROVEの場合のみ:**
```markdown
# タスク完了サマリー
## タスク
{元の要求を1-2文で}
## 結果
✅ 完了
## 変更内容
| 種別 | ファイル | 概要 |
|------|---------|------|
| 作成 | `src/file.ts` | 概要説明 |
## レビュー結果
| レビュー | 結果 |
|---------|------|
| Architecture Design | ✅ 完了 |
| AI Review | ✅ APPROVE |
| Architect Review | ✅ APPROVE |
| QA | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## 確認コマンド
```bash
npm test
npm run build
```
```

View File

@ -0,0 +1,694 @@
# Expert Review Piece
# CQRS+ES、フロントエンド、セキュリティ、QAの専門家によるレビューピース
#
# フロー:
# plan -> implement -> ai_review -> reviewers (parallel) -> supervise -> COMPLETE
# ↓ ├─ cqrs-es-review ↓
# ai_fix ├─ frontend-review fix_supervisor
# ├─ security-review
# └─ qa-review
# any("needs_fix") → fix → reviewers
#
# ボイラープレートセクションPiece Context, User Request, Previous Response,
# Additional User Inputs, Instructions headingはbuildInstruction()が自動挿入。
# instruction_templateにはムーブメント固有の内容のみ記述。
#
# テンプレート変数instruction_template内で使用可能:
# {iteration} - ピース全体のターン数(全エージェントで実行されたムーブメントの合計)
# {max_iterations} - ピースの最大イテレーション数
# {movement_iteration} - ムーブメントごとのイテレーション数(このムーブメントが何回実行されたか)
# {previous_response} - 前のムーブメントの出力pass_previous_response: true の場合のみ)
# {report_dir} - レポートディレクトリ名(例: "20250126-143052-task-summary"
#
# ムーブメントレベルフィールド:
# report: - ムーブメントのレポートファイルPiece ContextにReport File/Filesとして自動挿入
# 単一: report: 00-plan.md
# 複数: report:
# - Scope: 01-coder-scope.md
# - Decisions: 02-coder-decisions.md
name: expert-cqrs-hybrid-codex
description: CQRS+ES・フロントエンド・セキュリティ・QA専門家レビュー (hybrid: coder=codex)
max_iterations: 30
initial_movement: plan
movements:
# ===========================================
# Movement 0: Planning
# ===========================================
- name: plan
edit: false
agent: ../agents/default/planner.md
report:
name: 00-plan.md
format: |
```markdown
# タスク計画
## 元の要求
{ユーザーの要求をそのまま記載}
## 分析結果
### 目的
{達成すべきこと}
### スコープ
{影響範囲}
### 実装アプローチ
{どう進めるか}
## 確認事項(あれば)
- {不明点や確認が必要な点}
```
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
タスクを分析し、実装方針を立ててください。
**注意:** Previous Responseがある場合は差し戻しのため、
その内容を踏まえて計画を見直してくださいreplan
**やること:**
1. タスクの要件を理解する
2. 影響範囲を特定する
3. 実装アプローチを決める
rules:
- condition: タスク分析と計画が完了した
next: implement
- condition: 要件が不明確で計画を立てられない
next: ABORT
# ===========================================
# Movement 1: Implementation
# ===========================================
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
report:
- Scope: 01-coder-scope.md
- Decisions: 02-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
planムーブメントで立てた計画に従って実装してください。
計画レポート({report:00-plan.md})を参照し、実装を進めてください。
Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
**Scopeレポートフォーマット実装開始時に作成:**
```markdown
# 変更スコープ宣言
## タスク
{タスクの1行要約}
## 変更予定
| 種別 | ファイル |
|------|---------|
| 作成 | `src/example.ts` |
| 変更 | `src/routes.ts` |
## 推定規模
Small / Medium / Large
## 影響範囲
- {影響するモジュールや機能}
```
**Decisionsレポートフォーマット実装完了時、決定がある場合のみ:**
```markdown
# 決定ログ
## 1. {決定内容}
- **背景**: {なぜ決定が必要だったか}
- **検討した選択肢**: {選択肢リスト}
- **理由**: {選んだ理由}
```
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
rules:
- condition: 実装が完了した
next: ai_review
- condition: 実装未着手(レポートのみ)
next: ai_review
- condition: 実装を進行できない
next: ai_review
- condition: ユーザー入力が必要
next: implement
requires_user_input: true
interactive_only: true
# ===========================================
# Movement 2: AI Review
# ===========================================
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 03-ai-review.md
format: |
```markdown
# AI生成コードレビュー
## 結果: APPROVE / REJECT
## サマリー
{1文で結果を要約}
## 検証した項目
| 観点 | 結果 | 備考 |
|------|------|------|
| 仮定の妥当性 | ✅ | - |
| API/ライブラリの実在 | ✅ | - |
| コンテキスト適合 | ✅ | - |
| スコープ | ✅ | - |
## 問題点REJECTの場合
| # | カテゴリ | 場所 | 問題 |
|---|---------|------|------|
| 1 | 幻覚API | `src/file.ts:23` | 存在しないメソッド |
```
**認知負荷軽減ルール:**
- 問題なし → サマリー1文 + チェック表のみ10行以内
- 問題あり → + 問題を表形式で25行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
**これは {movement_iteration} 回目のAI Reviewです。**
初回は網羅的にレビューし、指摘すべき問題をすべて出し切ってください。
2回目以降は、前回REJECTした項目が修正されたかの確認を優先してください。
AI特有の問題についてコードをレビューしてください:
- 仮定の検証
- もっともらしいが間違っているパターン
- 既存コードベースとの適合性
- スコープクリープの検出
rules:
- condition: AI特有の問題が見つからない
next: reviewers
- condition: AI特有の問題が検出された
next: ai_fix
- name: ai_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
**これは {movement_iteration} 回目の AI Review です。**
2回目以降は、前回の修正が実際には行われていなかったということです。
**あなたの「修正済み」という認識が間違っています。**
**まず認めること:**
- 「修正済み」と思っていたファイルは実際には修正されていない
- 前回の作業内容の認識が間違っている
- ゼロベースで考え直す必要がある
**必須アクション:**
1. 指摘された全ファイルを Read tool で開く(思い込みを捨てて事実確認)
2. 問題箇所を grep で検索して実在を確認する
3. 確認した問題を Edit tool で修正する
4. テストを実行して検証する(`./gradlew :backend:test` 等)
5. 「何を確認して、何を修正したか」を具体的に報告する
**報告フォーマット:**
- ❌ 「既に修正されています」
- ✅ 「ファイルXのL123を確認した結果、問題Yが存在したため、Zに修正しました」
**絶対に禁止:**
- ファイルを開かずに「修正済み」と報告
- 思い込みで判断
- AI Reviewer が REJECT した問題の放置
**修正不要の扱い(必須)**
- AI Reviewの指摘ごとに「対象ファイルの確認結果」を示せない場合は修正不要と判断しない
- 指摘が「生成物」「仕様同期」に関係する場合は、生成元/仕様の確認ができなければ「修正を進行できない」に対応するタグを出力する
- 修正不要の場合は「修正を進行できない」に対応するタグを出力し、理由と確認範囲を明記する
**必須出力(見出しを含める)**
## 確認したファイル
- {ファイルパス:行番号}
## 実行した検索
- {コマンドと要約}
## 修正内容
- {変更内容}
## テスト結果
- {実行コマンドと結果}
rules:
- condition: AI Reviewerの指摘に対する修正が完了した
next: ai_review
- condition: 修正不要(指摘対象ファイル/仕様の確認済み)
next: ai_no_fix
- condition: 修正を進行できない
next: ai_no_fix
- name: ai_no_fix
edit: false
agent: ../agents/default/architecture-reviewer.md
allowed_tools:
- Read
- Glob
- Grep
rules:
- condition: ai_reviewの指摘が妥当修正すべき
next: ai_fix
- condition: ai_fixの判断が妥当修正不要
next: reviewers
instruction_template: |
ai_reviewレビュアーと ai_fixコーダーの意見が食い違っています。
- ai_review は問題を指摘し REJECT しました
- ai_fix は確認の上「修正不要」と判断しました
両者の出力を確認し、どちらの判断が妥当か裁定してください。
**参照するレポート:**
- AIレビュー結果: {report:03-ai-review.md}
**判断基準:**
- ai_review の指摘が具体的で、コード上の実在する問題を指しているか
- ai_fix の反論に根拠(ファイル確認結果、テスト結果)があるか
- 指摘が非ブロッキング(記録のみ)レベルか、実際に修正が必要か
# ===========================================
# Movement 3: Expert Reviews (Parallel)
# ===========================================
- name: reviewers
parallel:
- name: cqrs-es-review
edit: false
agent: ../agents/expert-cqrs/cqrs-es-reviewer.md
report:
name: 04-cqrs-es-review.md
format: |
```markdown
# CQRS+ESレビュー
## 結果: APPROVE / REJECT
## サマリー
{1-2文で結果を要約}
## 確認した観点
| 観点 | 結果 | 備考 |
|------|------|------|
| Aggregate設計 | ✅ | - |
| イベント設計 | ✅ | - |
| Command/Query分離 | ✅ | - |
| プロジェクション | ✅ | - |
| 結果整合性 | ✅ | - |
## 問題点REJECTの場合
| # | スコープ | 場所 | 問題 | 修正案 |
|---|---------|------|------|--------|
| 1 | スコープ内 | `src/file.ts:42` | 問題の説明 | 修正方法 |
スコープ: 「スコープ内」(今回修正可能)/ 「スコープ外」(既存問題・非ブロッキング)
## 既存問題(参考・非ブロッキング)
- {既存問題の記録。今回の変更と無関係な問題}
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
CQRSコマンドクエリ責務分離とEvent Sourcingイベントソーシングの観点から
変更をレビューしてください。AI特有の問題のレビューは不要ですai_reviewムーブメントで実施済み
**レビュー観点:**
- Aggregate設計の妥当性
- イベント設計(粒度、命名、スキーマ)
- Command/Queryの分離
- プロジェクション設計
- 結果整合性の考慮
**注意**: このプロジェクトがCQRS+ESパターンを使用していない場合は、
一般的なドメイン設計の観点からレビューしてください。
- name: frontend-review
edit: false
agent: ../agents/expert/frontend-reviewer.md
report:
name: 05-frontend-review.md
format: |
```markdown
# フロントエンドレビュー
## 結果: APPROVE / REJECT
## サマリー
{1-2文で結果を要約}
## 確認した観点
| 観点 | 結果 | 備考 |
|------|------|------|
| コンポーネント設計 | ✅ | - |
| 状態管理 | ✅ | - |
| パフォーマンス | ✅ | - |
| アクセシビリティ | ✅ | - |
| 型安全性 | ✅ | - |
## 問題点REJECTの場合
| # | 場所 | 問題 | 修正案 |
|---|------|------|--------|
| 1 | `src/file.tsx:42` | 問題の説明 | 修正方法 |
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
フロントエンド開発の観点から変更をレビューしてください。
**レビュー観点:**
- コンポーネント設計(責務分離、粒度)
- 状態管理(ローカル/グローバルの判断)
- パフォーマンス(再レンダリング、メモ化)
- アクセシビリティキーボード操作、ARIA
- データフェッチパターン
- TypeScript型安全性
**注意**: このプロジェクトがフロントエンドを含まない場合は、
問題なしとして次に進んでください。
- name: security-review
edit: false
agent: ../agents/expert/security-reviewer.md
report:
name: 06-security-review.md
format: |
```markdown
# セキュリティレビュー
## 結果: APPROVE / REJECT
## 重大度: None / Low / Medium / High / Critical
## チェック結果
| カテゴリ | 結果 | 備考 |
|---------|------|------|
| インジェクション | ✅ | - |
| 認証・認可 | ✅ | - |
| データ保護 | ✅ | - |
| 依存関係 | ✅ | - |
## 脆弱性REJECTの場合
| # | 重大度 | 種類 | 場所 | 修正案 |
|---|--------|------|------|--------|
| 1 | High | SQLi | `src/db.ts:42` | パラメータ化クエリを使用 |
## 警告(ブロッキングではない)
- {セキュリティに関する推奨事項}
```
**認知負荷軽減ルール:**
- 問題なし → チェック表のみ10行以内
- 警告 → + 警告1-2行15行以内
- 脆弱性 → + 表形式30行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
セキュリティの観点から変更をレビューしてください。以下の脆弱性をチェック:
- インジェクション攻撃SQL, コマンド, XSS
- 認証・認可の不備
- データ露出リスク
- 暗号化の弱点
- name: qa-review
edit: false
agent: ../agents/expert/qa-reviewer.md
report:
name: 07-qa-review.md
format: |
```markdown
# QAレビュー
## 結果: APPROVE / REJECT
## サマリー
{1-2文で結果を要約}
## 確認した観点
| 観点 | 結果 | 備考 |
|------|------|------|
| テストカバレッジ | ✅ | - |
| テスト品質 | ✅ | - |
| エラーハンドリング | ✅ | - |
| ドキュメント | ✅ | - |
| 保守性 | ✅ | - |
## 問題点REJECTの場合
| # | カテゴリ | 問題 | 修正案 |
|---|---------|------|--------|
| 1 | テスト | 問題の説明 | 修正方法 |
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
品質保証の観点から変更をレビューしてください。
**レビュー観点:**
- テストカバレッジと品質
- テスト戦略(単体/統合/E2E
- ドキュメント(コード内・外部)
- エラーハンドリング
- ログとモニタリング
- 保守性
rules:
- condition: all("approved")
next: supervise
- condition: any("needs_fix")
next: fix
- name: fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 修正が完了した
next: reviewers
- condition: 修正を進行できない
next: plan
instruction_template: |
レビュアーからのフィードバックに対応してください。
「Original User Request」は参考情報であり、最新の指示ではありません。
セッションの会話履歴を確認し、レビュアーの指摘事項を修正してください。
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
## 証拠
- {確認したファイル/検索/差分/ログの要点を列挙}
# ===========================================
# Movement 4: Supervision
# ===========================================
- name: supervise
edit: false
agent: ../agents/expert/supervisor.md
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
## Previous Reviews Summary
このムーブメントに到達したということは、以下のレビューがすべてAPPROVEされています
- AI Review: APPROVED
- CQRS+ES Review: APPROVED
- Frontend Review: APPROVED
- Security Review: APPROVED
- QA Review: APPROVED
テスト実行、ビルド確認、最終承認を行ってください。
**ピース全体の確認:**
1. 計画({report:00-plan.md})と実装結果が一致しているか
2. 各レビュームーブメントの指摘が対応されているか
3. 元のタスク目的が達成されているか
**レポートの確認:** Report Directory内の全レポートを読み、
未対応の改善提案がないか確認してください。
**Validationレポートフォーマット:**
```markdown
# 最終検証結果
## 結果: APPROVE / REJECT
## 検証サマリー
| 項目 | 状態 | 確認方法 |
|------|------|---------|
| 要求充足 | ✅ | 要求リストと照合 |
| テスト | ✅ | `npm test` (N passed) |
| ビルド | ✅ | `npm run build` 成功 |
| 動作確認 | ✅ | 主要フロー確認 |
## 成果物
- 作成: {作成したファイル}
- 変更: {変更したファイル}
## 未完了項目REJECTの場合
| # | 項目 | 理由 |
|---|------|------|
| 1 | {項目} | {理由} |
```
**SummaryレポートフォーマットAPPROVEの場合のみ:**
```markdown
# タスク完了サマリー
## タスク
{元の要求を1-2文で}
## 結果
✅ 完了
## 変更内容
| 種別 | ファイル | 概要 |
|------|---------|------|
| 作成 | `src/file.ts` | 概要説明 |
## レビュー結果
| レビュー | 結果 |
|---------|------|
| AI Review | ✅ APPROVE |
| CQRS+ES | ✅ APPROVE |
| Frontend | ✅ APPROVE |
| Security | ✅ APPROVE |
| QA | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## 確認コマンド
```bash
npm test
npm run build
```
```
rules:
- condition: すべての検証が完了し、マージ可能な状態である
next: COMPLETE
- condition: 問題が検出された
next: fix_supervisor
- name: fix_supervisor
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
監督者からの指摘を修正してください。
監督者は全体を俯瞰した視点から問題を指摘しています。
優先度の高い項目から順に対応してください。
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
## 証拠
- {確認したファイル/検索/差分/ログの要点を列挙}
rules:
- condition: 監督者の指摘に対する修正が完了した
next: supervise
- condition: 修正を進行できない
next: plan

View File

@ -0,0 +1,685 @@
# Expert Review Piece
# アーキテクチャ、フロントエンド、セキュリティ、QAの専門家によるレビューピース
#
# フロー:
# plan -> implement -> ai_review -> reviewers (parallel) -> supervise -> COMPLETE
# ↓ ├─ arch-review ↓
# ai_fix ├─ frontend-review fix_supervisor
# ├─ security-review
# └─ qa-review
# any("needs_fix") → fix → reviewers
#
# テンプレート変数:
# {iteration} - ピース全体のターン数(全エージェントで実行されたムーブメントの合計)
# {max_iterations} - ピースの最大イテレーション数
# {movement_iteration} - ムーブメントごとのイテレーション数(このムーブメントが何回実行されたか)
# {task} - 元のユーザー要求
# {previous_response} - 前のムーブメントの出力
# {user_inputs} - ピース中に蓄積されたユーザー入力
# {report_dir} - レポートディレクトリ名(例: "20250126-143052-task-summary"
name: expert-hybrid-codex
description: アーキテクチャ・フロントエンド・セキュリティ・QA専門家レビュー (hybrid: coder=codex)
max_iterations: 30
initial_movement: plan
movements:
# ===========================================
# Movement 0: Planning
# ===========================================
- name: plan
edit: false
agent: ../agents/default/planner.md
report:
name: 00-plan.md
format: |
```markdown
# タスク計画
## 元の要求
{ユーザーの要求をそのまま記載}
## 分析結果
### 目的
{達成すべきこと}
### スコープ
{影響範囲}
### 実装アプローチ
{どう進めるか}
## 確認事項(あれば)
- {不明点や確認が必要な点}
```
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
タスクを分析し、実装方針を立ててください。
**注意:** Previous Responseがある場合は差し戻しのため、
その内容を踏まえて計画を見直してくださいreplan
**やること:**
1. タスクの要件を理解する
2. 影響範囲を特定する
3. 実装アプローチを決める
rules:
- condition: タスク分析と計画が完了した
next: implement
- condition: 要件が不明確で計画を立てられない
next: ABORT
# ===========================================
# Movement 1: Implementation
# ===========================================
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
report:
- Scope: 01-coder-scope.md
- Decisions: 02-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
planムーブメントで立てた計画に従って実装してください。
計画レポート({report:00-plan.md})を参照し、実装を進めてください。
Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
**Scopeレポートフォーマット実装開始時に作成:**
```markdown
# 変更スコープ宣言
## タスク
{タスクの1行要約}
## 変更予定
| 種別 | ファイル |
|------|---------|
| 作成 | `src/example.ts` |
| 変更 | `src/routes.ts` |
## 推定規模
Small / Medium / Large
## 影響範囲
- {影響するモジュールや機能}
```
**Decisionsレポートフォーマット実装完了時、決定がある場合のみ:**
```markdown
# 決定ログ
## 1. {決定内容}
- **背景**: {なぜ決定が必要だったか}
- **検討した選択肢**: {選択肢リスト}
- **理由**: {選んだ理由}
```
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
rules:
- condition: 実装が完了した
next: ai_review
- condition: 実装未着手(レポートのみ)
next: ai_review
- condition: 実装を進行できない
next: ai_review
- condition: ユーザー入力が必要
next: implement
requires_user_input: true
interactive_only: true
# ===========================================
# Movement 2: AI Review
# ===========================================
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 03-ai-review.md
format: |
```markdown
# AI生成コードレビュー
## 結果: APPROVE / REJECT
## サマリー
{1文で結果を要約}
## 検証した項目
| 観点 | 結果 | 備考 |
|------|------|------|
| 仮定の妥当性 | ✅ | - |
| API/ライブラリの実在 | ✅ | - |
| コンテキスト適合 | ✅ | - |
| スコープ | ✅ | - |
## 問題点REJECTの場合
| # | カテゴリ | 場所 | 問題 |
|---|---------|------|------|
| 1 | 幻覚API | `src/file.ts:23` | 存在しないメソッド |
```
**認知負荷軽減ルール:**
- 問題なし → サマリー1文 + チェック表のみ10行以内
- 問題あり → + 問題を表形式で25行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
**これは {movement_iteration} 回目のAI Reviewです。**
初回は網羅的にレビューし、指摘すべき問題をすべて出し切ってください。
2回目以降は、前回REJECTした項目が修正されたかの確認を優先してください。
AI特有の問題についてコードをレビューしてください:
- 仮定の検証
- もっともらしいが間違っているパターン
- 既存コードベースとの適合性
- スコープクリープの検出
rules:
- condition: AI特有の問題が見つからない
next: reviewers
- condition: AI特有の問題が検出された
next: ai_fix
- name: ai_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
session: refresh
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
**これは {movement_iteration} 回目の AI Review です。**
2回目以降は、前回の修正が実際には行われていなかったということです。
**あなたの「修正済み」という認識が間違っています。**
**まず認めること:**
- 「修正済み」と思っていたファイルは実際には修正されていない
- 前回の作業内容の認識が間違っている
- ゼロベースで考え直す必要がある
**必須アクション:**
1. 指摘された全ファイルを Read tool で開く(思い込みを捨てて事実確認)
2. 問題箇所を grep で検索して実在を確認する
3. 確認した問題を Edit tool で修正する
4. テストを実行して検証する(`./gradlew :backend:test` 等)
5. 「何を確認して、何を修正したか」を具体的に報告する
**報告フォーマット:**
- ❌ 「既に修正されています」
- ✅ 「ファイルXのL123を確認した結果、問題Yが存在したため、Zに修正しました」
**絶対に禁止:**
- ファイルを開かずに「修正済み」と報告
- 思い込みで判断
- AI Reviewer が REJECT した問題の放置
**修正不要の扱い(必須)**
- AI Reviewの指摘ごとに「対象ファイルの確認結果」を示せない場合は修正不要と判断しない
- 指摘が「生成物」「仕様同期」に関係する場合は、生成元/仕様の確認ができなければ「修正を進行できない」に対応するタグを出力する
- 修正不要の場合は「修正を進行できない」に対応するタグを出力し、理由と確認範囲を明記する
**必須出力(見出しを含める)**
## 確認したファイル
- {ファイルパス:行番号}
## 実行した検索
- {コマンドと要約}
## 修正内容
- {変更内容}
## テスト結果
- {実行コマンドと結果}
rules:
- condition: AI Reviewerの指摘に対する修正が完了した
next: ai_review
- condition: 修正不要(指摘対象ファイル/仕様の確認済み)
next: ai_no_fix
- condition: 修正を進行できない
next: ai_no_fix
- name: ai_no_fix
edit: false
agent: ../agents/default/architecture-reviewer.md
allowed_tools:
- Read
- Glob
- Grep
rules:
- condition: ai_reviewの指摘が妥当修正すべき
next: ai_fix
- condition: ai_fixの判断が妥当修正不要
next: reviewers
instruction_template: |
ai_reviewレビュアーと ai_fixコーダーの意見が食い違っています。
- ai_review は問題を指摘し REJECT しました
- ai_fix は確認の上「修正不要」と判断しました
両者の出力を確認し、どちらの判断が妥当か裁定してください。
**参照するレポート:**
- AIレビュー結果: {report:03-ai-review.md}
**判断基準:**
- ai_review の指摘が具体的で、コード上の実在する問題を指しているか
- ai_fix の反論に根拠(ファイル確認結果、テスト結果)があるか
- 指摘が非ブロッキング(記録のみ)レベルか、実際に修正が必要か
# ===========================================
# Movement 3: Expert Reviews (Parallel)
# ===========================================
- name: reviewers
parallel:
- name: arch-review
edit: false
agent: ../agents/default/architecture-reviewer.md
report:
name: 04-architect-review.md
format: |
```markdown
# アーキテクチャレビュー
## 結果: APPROVE / REJECT
## サマリー
{1-2文で結果を要約}
## 確認した観点
- [x] 構造・設計
- [x] コード品質
- [x] 変更スコープ
- [x] テストカバレッジ
- [x] デッドコード
- [x] 呼び出しチェーン検証
## 問題点REJECTの場合
| # | スコープ | 場所 | 問題 | 修正案 |
|---|---------|------|------|--------|
| 1 | スコープ内 | `src/file.ts:42` | 問題の説明 | 修正方法 |
スコープ: 「スコープ内」(今回修正可能)/ 「スコープ外」(既存問題・非ブロッキング)
## 既存問題(参考・非ブロッキング)
- {既存問題の記録。今回の変更と無関係な問題}
```
**認知負荷軽減ルール:**
- APPROVE → サマリーのみ5行以内
- REJECT → 問題点を表形式で30行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
**アーキテクチャと設計**のレビューに集中してください。AI特有の問題のレビューは不要ですai_reviewムーブメントで実施済み
**レビュー観点:**
- 構造・設計の妥当性
- コード品質
- 変更スコープの適切性
- テストカバレッジ
- デッドコード
- 呼び出しチェーン検証
- name: frontend-review
edit: false
agent: ../agents/expert/frontend-reviewer.md
report:
name: 05-frontend-review.md
format: |
```markdown
# フロントエンドレビュー
## 結果: APPROVE / REJECT
## サマリー
{1-2文で結果を要約}
## 確認した観点
| 観点 | 結果 | 備考 |
|------|------|------|
| コンポーネント設計 | ✅ | - |
| 状態管理 | ✅ | - |
| パフォーマンス | ✅ | - |
| アクセシビリティ | ✅ | - |
| 型安全性 | ✅ | - |
## 問題点REJECTの場合
| # | 場所 | 問題 | 修正案 |
|---|------|------|--------|
| 1 | `src/file.tsx:42` | 問題の説明 | 修正方法 |
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
フロントエンド開発の観点から変更をレビューしてください。
**レビュー観点:**
- コンポーネント設計(責務分離、粒度)
- 状態管理(ローカル/グローバルの判断)
- パフォーマンス(再レンダリング、メモ化)
- アクセシビリティキーボード操作、ARIA
- データフェッチパターン
- TypeScript型安全性
**注意**: このプロジェクトがフロントエンドを含まない場合は、
問題なしとして次に進んでください。
- name: security-review
edit: false
agent: ../agents/expert/security-reviewer.md
report:
name: 06-security-review.md
format: |
```markdown
# セキュリティレビュー
## 結果: APPROVE / REJECT
## 重大度: None / Low / Medium / High / Critical
## チェック結果
| カテゴリ | 結果 | 備考 |
|---------|------|------|
| インジェクション | ✅ | - |
| 認証・認可 | ✅ | - |
| データ保護 | ✅ | - |
| 依存関係 | ✅ | - |
## 脆弱性REJECTの場合
| # | 重大度 | 種類 | 場所 | 修正案 |
|---|--------|------|------|--------|
| 1 | High | SQLi | `src/db.ts:42` | パラメータ化クエリを使用 |
## 警告(ブロッキングではない)
- {セキュリティに関する推奨事項}
```
**認知負荷軽減ルール:**
- 問題なし → チェック表のみ10行以内
- 警告 → + 警告1-2行15行以内
- 脆弱性 → + 表形式30行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
セキュリティの観点から変更をレビューしてください。以下の脆弱性をチェック:
- インジェクション攻撃SQL, コマンド, XSS
- 認証・認可の不備
- データ露出リスク
- 暗号化の弱点
- name: qa-review
edit: false
agent: ../agents/expert/qa-reviewer.md
report:
name: 07-qa-review.md
format: |
```markdown
# QAレビュー
## 結果: APPROVE / REJECT
## サマリー
{1-2文で結果を要約}
## 確認した観点
| 観点 | 結果 | 備考 |
|------|------|------|
| テストカバレッジ | ✅ | - |
| テスト品質 | ✅ | - |
| エラーハンドリング | ✅ | - |
| ドキュメント | ✅ | - |
| 保守性 | ✅ | - |
## 問題点REJECTの場合
| # | カテゴリ | 問題 | 修正案 |
|---|---------|------|--------|
| 1 | テスト | 問題の説明 | 修正方法 |
```
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction_template: |
品質保証の観点から変更をレビューしてください。
**レビュー観点:**
- テストカバレッジと品質
- テスト戦略(単体/統合/E2E
- ドキュメント(コード内・外部)
- エラーハンドリング
- ログとモニタリング
- 保守性
rules:
- condition: all("approved")
next: supervise
- condition: any("needs_fix")
next: fix
- name: fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 修正が完了した
next: reviewers
- condition: 修正を進行できない
next: plan
instruction_template: |
レビュアーからのフィードバックに対応してください。
「Original User Request」は参考情報であり、最新の指示ではありません。
セッションの会話履歴を確認し、レビュアーの指摘事項を修正してください。
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
## 証拠
- {確認したファイル/検索/差分/ログの要点を列挙}
# ===========================================
# Movement 4: Supervision
# ===========================================
- name: supervise
edit: false
agent: ../agents/expert/supervisor.md
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
## Previous Reviews Summary
このムーブメントに到達したということは、以下のレビューがすべてAPPROVEされています
- AI Review: APPROVED
- Architecture Review: APPROVED
- Frontend Review: APPROVED
- Security Review: APPROVED
- QA Review: APPROVED
テスト実行、ビルド確認、最終承認を行ってください。
**ピース全体の確認:**
1. 計画({report:00-plan.md})と実装結果が一致しているか
2. 各レビュームーブメントの指摘が対応されているか
3. 元のタスク目的が達成されているか
**レポートの確認:** Report Directory内の全レポートを読み、
未対応の改善提案がないか確認してください。
**Validationレポートフォーマット:**
```markdown
# 最終検証結果
## 結果: APPROVE / REJECT
## 検証サマリー
| 項目 | 状態 | 確認方法 |
|------|------|---------|
| 要求充足 | ✅ | 要求リストと照合 |
| テスト | ✅ | `npm test` (N passed) |
| ビルド | ✅ | `npm run build` 成功 |
| 動作確認 | ✅ | 主要フロー確認 |
## 成果物
- 作成: {作成したファイル}
- 変更: {変更したファイル}
## 未完了項目REJECTの場合
| # | 項目 | 理由 |
|---|------|------|
| 1 | {項目} | {理由} |
```
**SummaryレポートフォーマットAPPROVEの場合のみ:**
```markdown
# タスク完了サマリー
## タスク
{元の要求を1-2文で}
## 結果
✅ 完了
## 変更内容
| 種別 | ファイル | 概要 |
|------|---------|------|
| 作成 | `src/file.ts` | 概要説明 |
## レビュー結果
| レビュー | 結果 |
|---------|------|
| AI Review | ✅ APPROVE |
| Architecture | ✅ APPROVE |
| Frontend | ✅ APPROVE |
| Security | ✅ APPROVE |
| QA | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## 確認コマンド
```bash
npm test
npm run build
```
```
rules:
- condition: すべての検証が完了し、マージ可能な状態である
next: COMPLETE
- condition: 問題が検出された
next: fix_supervisor
- name: fix_supervisor
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
instruction_template: |
監督者からの指摘を修正してください。
監督者は全体を俯瞰した視点から問題を指摘しています。
優先度の高い項目から順に対応してください。
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
## 証拠
- {確認したファイル/検索/差分/ログの要点を列挙}
rules:
- condition: 監督者の指摘に対する修正が完了した
next: supervise
- condition: 修正を進行できない
next: plan

View File

@ -0,0 +1,428 @@
# Simple TAKT Piece
# Implement -> AI Review -> Supervisor Approval
# (最もシンプルな構成 - plan, architect review, fix ムーブメントなし)
#
# Template Variables (auto-injected):
# {iteration} - Piece-wide turn count (total movements executed across all agents)
# {max_iterations} - Maximum iterations allowed for the piece
# {movement_iteration} - Per-movement iteration count (how many times THIS movement has been executed)
# {task} - Original user request (auto-injected)
# {previous_response} - Output from the previous movement (auto-injected)
# {user_inputs} - Accumulated user inputs during piece (auto-injected)
# {report_dir} - Report directory name (e.g., "20250126-143052-task-summary")
name: minimal-hybrid-codex
description: Minimal development piece (implement -> parallel review -> fix if needed -> complete) (hybrid: coder=codex)
max_iterations: 20
initial_movement: implement
movements:
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
report:
- Scope: 01-coder-scope.md
- Decisions: 02-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
instruction_template: |
タスクを実装してください。
Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
**Scopeレポートフォーマット実装開始時に作成:**
```markdown
# 変更スコープ宣言
## タスク
{タスクの1行要約}
## 変更予定
| 種別 | ファイル |
|------|---------|
| 作成 | `src/example.ts` |
| 変更 | `src/routes.ts` |
## 推定規模
Small / Medium / Large
## 影響範囲
- {影響するモジュールや機能}
```
**Decisionsレポートフォーマット実装完了時、決定がある場合のみ:**
```markdown
# 決定ログ
## 1. {決定内容}
- **背景**: {なぜ決定が必要だったか}
- **検討した選択肢**: {選択肢リスト}
- **理由**: {選んだ理由}
```
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
rules:
- condition: 実装が完了した
next: reviewers
- condition: 実装を進行できない
next: ABORT
- condition: ユーザーへの確認事項があるためユーザー入力が必要
next: implement
requires_user_input: true
interactive_only: true
- name: reviewers
parallel:
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 03-ai-review.md
format: |
```markdown
# AI生成コードレビュー
## 結果: APPROVE / REJECT
## サマリー
{1文で結果を要約}
## 検証した項目
| 観点 | 結果 | 備考 |
|------|------|------|
| 仮定の妥当性 | ✅ | - |
| API/ライブラリの実在 | ✅ | - |
| コンテキスト適合 | ✅ | - |
| スコープ | ✅ | - |
## 問題点REJECTの場合
| # | カテゴリ | 場所 | 問題 |
|---|---------|------|------|
| 1 | 幻覚API | `src/file.ts:23` | 存在しないメソッド |
```
**認知負荷軽減ルール:**
- 問題なし → サマリー1文 + チェック表のみ10行以内
- 問題あり → + 問題を表形式で25行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
AI特有の問題についてコードをレビューしてください:
- 仮定の検証
- もっともらしいが間違っているパターン
- 既存コードベースとの適合性
- スコープクリープの検出
rules:
- condition: "AI特有の問題なし"
- condition: "AI特有の問題あり"
- name: supervise
edit: false
agent: ../agents/default/supervisor.md
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
テスト実行、ビルド確認、最終承認を行ってください。
**ピース全体の確認:**
1. 実装結果が元の要求を満たしているか
2. AI Reviewの指摘が対応されているか
3. 元のタスク目的が達成されているか
**レポートの確認:** Report Directory内の全レポートを読み、
未対応の改善提案がないか確認してください。
**Validationレポートフォーマット:**
```markdown
# 最終検証結果
## 結果: APPROVE / REJECT
## 検証サマリー
| 項目 | 状態 | 確認方法 |
|------|------|---------|
| 要求充足 | ✅ | 要求リストと照合 |
| テスト | ✅ | `npm test` (N passed) |
| ビルド | ✅ | `npm run build` 成功 |
| 動作確認 | ✅ | 主要フロー確認 |
## 成果物
- 作成: {作成したファイル}
- 変更: {変更したファイル}
## 未完了項目REJECTの場合
| # | 項目 | 理由 |
|---|------|------|
| 1 | {項目} | {理由} |
```
**SummaryレポートフォーマットAPPROVEの場合のみ:**
```markdown
# タスク完了サマリー
## タスク
{元の要求を1-2文で}
## 結果
✅ 完了
## 変更内容
| 種別 | ファイル | 概要 |
|------|---------|------|
| 作成 | `src/file.ts` | 概要説明 |
## レビュー結果
| レビュー | 結果 |
|---------|------|
| AI Review | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## 確認コマンド
```bash
npm test
npm run build
```
```
rules:
- condition: "すべて問題なし"
- condition: "要求未達成、テスト失敗、ビルドエラー"
rules:
- condition: all("AI特有の問題なし", "すべて問題なし")
next: COMPLETE
- condition: all("AI特有の問題あり", "要求未達成、テスト失敗、ビルドエラー")
next: fix_both
- condition: any("AI特有の問題あり")
next: ai_fix
- condition: any("要求未達成、テスト失敗、ビルドエラー")
next: supervise_fix
- name: fix_both
parallel:
- name: ai_fix_parallel
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI問題の修正完了
- condition: 修正不要(指摘対象ファイル/仕様の確認済み)
- condition: 判断できない、情報不足
instruction_template: |
**これは {movement_iteration} 回目の AI Review です。**
2回目以降は、前回の修正が実際には行われていなかったということです。
**あなたの「修正済み」という認識が間違っています。**
**まず認めること:**
- 「修正済み」と思っていたファイルは実際には修正されていない
- 前回の作業内容の認識が間違っている
- ゼロベースで考え直す必要がある
**必須アクション:**
1. 指摘された全ファイルを Read tool で開く(思い込みを捨てて事実確認)
2. 問題箇所を grep で検索して実在を確認する
3. 確認した問題を Edit tool で修正する
4. テストを実行して検証する(例: `npm test`, `./gradlew test`
5. 「何を確認して、何を修正したか」を具体的に報告する
**報告フォーマット:**
- ❌ 「既に修正されています」
- ✅ 「ファイルXのL123を確認した結果、問題Yが存在したため、Zに修正しました」
**絶対に禁止:**
- ファイルを開かずに「修正済み」と報告
- 思い込みで判断
- AI Reviewer が REJECT した問題の放置
**修正不要の扱い(必須)**
- AI Reviewの指摘ごとに「対象ファイルの確認結果」を示せない場合は修正不要と判断しない
- 指摘が「生成物」「仕様同期」に関係する場合は、生成元/仕様の確認ができなければ「判断できない、情報不足」に対応するタグを出力する
- 修正不要の場合は「判断できない、情報不足」に対応するタグを出力し、理由と確認範囲を明記する
**必須出力(見出しを含める)**
## 確認したファイル
- {ファイルパス:行番号}
## 実行した検索
- {コマンドと要約}
## 修正内容
- {変更内容}
## テスト結果
- {実行コマンドと結果}
- name: supervise_fix_parallel
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 監督者の指摘に対する修正が完了した
- condition: 修正を進行できない
instruction_template: |
監督者からの指摘を修正してください。
監督者は全体を俯瞰した視点から問題を指摘しています。
優先度の高い項目から順に対応してください。
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
## 証拠
- {確認したファイル/検索/差分/ログの要点を列挙}
rules:
- condition: all("AI問題の修正完了", "監督者の指摘に対する修正が完了した")
next: reviewers
- condition: any("修正不要(指摘対象ファイル/仕様の確認済み)", "判断できない、情報不足", "修正を進行できない")
next: implement
- name: ai_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI問題の修正完了
next: reviewers
- condition: 修正不要(指摘対象ファイル/仕様の確認済み)
next: implement
- condition: 判断できない、情報不足
next: implement
instruction_template: |
**これは {movement_iteration} 回目の AI Review です。**
2回目以降は、前回の修正が実際には行われていなかったということです。
**あなたの「修正済み」という認識が間違っています。**
**まず認めること:**
- 「修正済み」と思っていたファイルは実際には修正されていない
- 前回の作業内容の認識が間違っている
- ゼロベースで考え直す必要がある
**必須アクション:**
1. 指摘された全ファイルを Read tool で開く(思い込みを捨てて事実確認)
2. 問題箇所を grep で検索して実在を確認する
3. 確認した問題を Edit tool で修正する
4. テストを実行して検証する(例: `npm test`, `./gradlew test`
5. 「何を確認して、何を修正したか」を具体的に報告する
**報告フォーマット:**
- ❌ 「既に修正されています」
- ✅ 「ファイルXのL123を確認した結果、問題Yが存在したため、Zに修正しました」
**絶対に禁止:**
- ファイルを開かずに「修正済み」と報告
- 思い込みで判断
- AI Reviewer が REJECT した問題の放置
**修正不要の扱い(必須)**
- AI Reviewの指摘ごとに「対象ファイルの確認結果」を示せない場合は修正不要と判断しない
- 指摘が「生成物」「仕様同期」に関係する場合は、生成元/仕様の確認ができなければ「判断できない、情報不足」に対応するタグを出力する
- 修正不要の場合は「判断できない、情報不足」に対応するタグを出力し、理由と確認範囲を明記する
**必須出力(見出しを含める)**
## 確認したファイル
- {ファイルパス:行番号}
## 実行した検索
- {コマンドと要約}
## 修正内容
- {変更内容}
## テスト結果
- {実行コマンドと結果}
- name: supervise_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 監督者の指摘に対する修正が完了した
next: reviewers
- condition: 修正を進行できない
next: implement
instruction_template: |
監督者からの指摘を修正してください。
監督者は全体を俯瞰した視点から問題を指摘しています。
優先度の高い項目から順に対応してください。
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
## 証拠
- {確認したファイル/検索/差分/ログの要点を列挙}

View File

@ -0,0 +1,43 @@
# Passthrough TAKT Piece
# タスクをそのままエージェントに渡す最薄ラッパー。
#
# フロー:
# execute (タスク実行)
# ↓
# COMPLETE
name: passthrough-hybrid-codex
description: Single-agent thin wrapper. Pass task directly to coder as-is. (hybrid: coder=codex)
max_iterations: 10
initial_movement: execute
movements:
- name: execute
edit: true
agent: ../agents/default/coder.md
provider: codex
report:
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: タスク完了
next: COMPLETE
- condition: 進行できない
next: ABORT
- condition: ユーザー入力が必要
next: execute
requires_user_input: true
interactive_only: true
instruction_template: |
タスクをこなしてください。

View File

@ -0,0 +1,428 @@
# Review-Fix Minimal TAKT Piece
# Review -> Fix (if needed) -> Re-review -> Complete
# (レビューから開始、実装ムーブメントなし)
#
# Template Variables (auto-injected):
# {iteration} - Piece-wide turn count (total movements executed across all agents)
# {max_iterations} - Maximum iterations allowed for the piece
# {movement_iteration} - Per-movement iteration count (how many times THIS movement has been executed)
# {task} - Original user request (auto-injected)
# {previous_response} - Output from the previous movement (auto-injected)
# {user_inputs} - Accumulated user inputs during piece (auto-injected)
# {report_dir} - Report directory name (e.g., "20250126-143052-task-summary")
name: review-fix-minimal-hybrid-codex
description: 既存コードのレビューと修正ピース(レビュー開始、実装なし) (hybrid: coder=codex)
max_iterations: 20
initial_movement: reviewers
movements:
- name: implement
edit: true
agent: ../agents/default/coder.md
provider: codex
report:
- Scope: 01-coder-scope.md
- Decisions: 02-coder-decisions.md
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
instruction_template: |
タスクを実装してください。
Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
**Scopeレポートフォーマット実装開始時に作成:**
```markdown
# 変更スコープ宣言
## タスク
{タスクの1行要約}
## 変更予定
| 種別 | ファイル |
|------|---------|
| 作成 | `src/example.ts` |
| 変更 | `src/routes.ts` |
## 推定規模
Small / Medium / Large
## 影響範囲
- {影響するモジュールや機能}
```
**Decisionsレポートフォーマット実装完了時、決定がある場合のみ:**
```markdown
# 決定ログ
## 1. {決定内容}
- **背景**: {なぜ決定が必要だったか}
- **検討した選択肢**: {選択肢リスト}
- **理由**: {選んだ理由}
```
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
rules:
- condition: 実装が完了した
next: reviewers
- condition: 実装を進行できない
next: ABORT
- condition: ユーザーへの確認事項があるためユーザー入力が必要
next: implement
requires_user_input: true
interactive_only: true
- name: reviewers
parallel:
- name: ai_review
edit: false
agent: ../agents/default/ai-antipattern-reviewer.md
report:
name: 03-ai-review.md
format: |
```markdown
# AI生成コードレビュー
## 結果: APPROVE / REJECT
## サマリー
{1文で結果を要約}
## 検証した項目
| 観点 | 結果 | 備考 |
|------|------|------|
| 仮定の妥当性 | ✅ | - |
| API/ライブラリの実在 | ✅ | - |
| コンテキスト適合 | ✅ | - |
| スコープ | ✅ | - |
## 問題点REJECTの場合
| # | カテゴリ | 場所 | 問題 |
|---|---------|------|------|
| 1 | 幻覚API | `src/file.ts:23` | 存在しないメソッド |
```
**認知負荷軽減ルール:**
- 問題なし → サマリー1文 + チェック表のみ10行以内
- 問題あり → + 問題を表形式で25行以内
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
AI特有の問題についてコードをレビューしてください:
- 仮定の検証
- もっともらしいが間違っているパターン
- 既存コードベースとの適合性
- スコープクリープの検出
rules:
- condition: "AI特有の問題なし"
- condition: "AI特有の問題あり"
- name: supervise
edit: false
agent: ../agents/default/supervisor.md
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
テスト実行、ビルド確認、最終承認を行ってください。
**ピース全体の確認:**
1. 実装結果が元の要求を満たしているか
2. AI Reviewの指摘が対応されているか
3. 元のタスク目的が達成されているか
**レポートの確認:** Report Directory内の全レポートを読み、
未対応の改善提案がないか確認してください。
**Validationレポートフォーマット:**
```markdown
# 最終検証結果
## 結果: APPROVE / REJECT
## 検証サマリー
| 項目 | 状態 | 確認方法 |
|------|------|---------|
| 要求充足 | ✅ | 要求リストと照合 |
| テスト | ✅ | `npm test` (N passed) |
| ビルド | ✅ | `npm run build` 成功 |
| 動作確認 | ✅ | 主要フロー確認 |
## 成果物
- 作成: {作成したファイル}
- 変更: {変更したファイル}
## 未完了項目REJECTの場合
| # | 項目 | 理由 |
|---|------|------|
| 1 | {項目} | {理由} |
```
**SummaryレポートフォーマットAPPROVEの場合のみ:**
```markdown
# タスク完了サマリー
## タスク
{元の要求を1-2文で}
## 結果
✅ 完了
## 変更内容
| 種別 | ファイル | 概要 |
|------|---------|------|
| 作成 | `src/file.ts` | 概要説明 |
## レビュー結果
| レビュー | 結果 |
|---------|------|
| AI Review | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## 確認コマンド
```bash
npm test
npm run build
```
```
rules:
- condition: "すべて問題なし"
- condition: "要求未達成、テスト失敗、ビルドエラー"
rules:
- condition: all("AI特有の問題なし", "すべて問題なし")
next: COMPLETE
- condition: all("AI特有の問題あり", "要求未達成、テスト失敗、ビルドエラー")
next: fix_both
- condition: any("AI特有の問題あり")
next: ai_fix
- condition: any("要求未達成、テスト失敗、ビルドエラー")
next: supervise_fix
- name: fix_both
parallel:
- name: ai_fix_parallel
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI問題の修正完了
- condition: 修正不要(指摘対象ファイル/仕様の確認済み)
- condition: 判断できない、情報不足
instruction_template: |
**これは {movement_iteration} 回目の AI Review です。**
2回目以降は、前回の修正が実際には行われていなかったということです。
**あなたの「修正済み」という認識が間違っています。**
**まず認めること:**
- 「修正済み」と思っていたファイルは実際には修正されていない
- 前回の作業内容の認識が間違っている
- ゼロベースで考え直す必要がある
**必須アクション:**
1. 指摘された全ファイルを Read tool で開く(思い込みを捨てて事実確認)
2. 問題箇所を grep で検索して実在を確認する
3. 確認した問題を Edit tool で修正する
4. テストを実行して検証する(例: `npm test`, `./gradlew test`
5. 「何を確認して、何を修正したか」を具体的に報告する
**報告フォーマット:**
- ❌ 「既に修正されています」
- ✅ 「ファイルXのL123を確認した結果、問題Yが存在したため、Zに修正しました」
**絶対に禁止:**
- ファイルを開かずに「修正済み」と報告
- 思い込みで判断
- AI Reviewer が REJECT した問題の放置
**修正不要の扱い(必須)**
- AI Reviewの指摘ごとに「対象ファイルの確認結果」を示せない場合は修正不要と判断しない
- 指摘が「生成物」「仕様同期」に関係する場合は、生成元/仕様の確認ができなければ「判断できない、情報不足」に対応するタグを出力する
- 修正不要の場合は「判断できない、情報不足」に対応するタグを出力し、理由と確認範囲を明記する
**必須出力(見出しを含める)**
## 確認したファイル
- {ファイルパス:行番号}
## 実行した検索
- {コマンドと要約}
## 修正内容
- {変更内容}
## テスト結果
- {実行コマンドと結果}
- name: supervise_fix_parallel
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 監督者の指摘に対する修正が完了した
- condition: 修正を進行できない
instruction_template: |
監督者からの指摘を修正してください。
監督者は全体を俯瞰した視点から問題を指摘しています。
優先度の高い項目から順に対応してください。
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
## 証拠
- {確認したファイル/検索/差分/ログの要点を列挙}
rules:
- condition: all("AI問題の修正完了", "監督者の指摘に対する修正が完了した")
next: reviewers
- condition: any("修正不要(指摘対象ファイル/仕様の確認済み)", "判断できない、情報不足", "修正を進行できない")
next: implement
- name: ai_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI問題の修正完了
next: reviewers
- condition: 修正不要(指摘対象ファイル/仕様の確認済み)
next: implement
- condition: 判断できない、情報不足
next: implement
instruction_template: |
**これは {movement_iteration} 回目の AI Review です。**
2回目以降は、前回の修正が実際には行われていなかったということです。
**あなたの「修正済み」という認識が間違っています。**
**まず認めること:**
- 「修正済み」と思っていたファイルは実際には修正されていない
- 前回の作業内容の認識が間違っている
- ゼロベースで考え直す必要がある
**必須アクション:**
1. 指摘された全ファイルを Read tool で開く(思い込みを捨てて事実確認)
2. 問題箇所を grep で検索して実在を確認する
3. 確認した問題を Edit tool で修正する
4. テストを実行して検証する(例: `npm test`, `./gradlew test`
5. 「何を確認して、何を修正したか」を具体的に報告する
**報告フォーマット:**
- ❌ 「既に修正されています」
- ✅ 「ファイルXのL123を確認した結果、問題Yが存在したため、Zに修正しました」
**絶対に禁止:**
- ファイルを開かずに「修正済み」と報告
- 思い込みで判断
- AI Reviewer が REJECT した問題の放置
**修正不要の扱い(必須)**
- AI Reviewの指摘ごとに「対象ファイルの確認結果」を示せない場合は修正不要と判断しない
- 指摘が「生成物」「仕様同期」に関係する場合は、生成元/仕様の確認ができなければ「判断できない、情報不足」に対応するタグを出力する
- 修正不要の場合は「判断できない、情報不足」に対応するタグを出力し、理由と確認範囲を明記する
**必須出力(見出しを含める)**
## 確認したファイル
- {ファイルパス:行番号}
## 実行した検索
- {コマンドと要約}
## 修正内容
- {変更内容}
## テスト結果
- {実行コマンドと結果}
- name: supervise_fix
edit: true
agent: ../agents/default/coder.md
provider: codex
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 監督者の指摘に対する修正が完了した
next: reviewers
- condition: 修正を進行できない
next: implement
instruction_template: |
監督者からの指摘を修正してください。
監督者は全体を俯瞰した視点から問題を指摘しています。
優先度の高い項目から順に対応してください。
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}
## 証拠
- {確認したファイル/検索/差分/ログの要点を列挙}

View File

@ -1,105 +1,199 @@
---
name: takt-engine
description: TAKT ピースエンジンのリファレンス。/takt コマンドから使用される。ピースYAML定義に従ったマルチエージェントオーケストレーション。
description: TAKT ピースエンジン。Agent Team を使ったマルチエージェントオーケストレーション。/takt コマンドから使用される。
---
# TAKT Piece Engine
ピースYAMLファイルを読み込み、定義されたワークフロー状態遷移マシンに従って複数のAIエージェントをオーケストレーションするエンジン。
## あなたの役割: Team Lead
## 設計原則
あなたは **Team Leadオーケストレーター** である。
ピースYAMLに定義されたワークフロー状態遷移マシンに従って Agent Team を率いる。
- **Skill = 純粋なエンジンロジックのみ**
- ピースYAML、エージェント .md は全て **ファイル参照** で実行時に Read する
- Skill 内にピース定義・エージェント定義を一切埋め込まない
- このスキルが持つのは「YAMLの読み方」「状態遷移の回し方」「ルール評価の仕方」だけ
### 禁止事項
## ピース解決
- **自分で作業するな** — コーディング、レビュー、設計、テスト等は全てチームメイトに委任する
- **タスクを自分で分析して1つの Task にまとめるな** — movement を1つずつ順番に実行せよ
- **movement をスキップするな** — 必ず initial_movement から開始し、Rule 評価で決まった次の movement に進む
### ピースYAMLの検索
### あなたの仕事は4つだけ
引数の第1トークンからピースYAMLファイルを特定する。
1. ピースYAML を読んでワークフローを理解する
2. 各 movement のプロンプトを構築するreferences/engine.md 参照)
3. **Task tool** でチームメイトを起動して作業を委任する
4. チームメイトの出力から Rule 評価を行い、次の movement を決定する
1. ファイルパス判定: `.yaml` / `.yml` で終わる、または `/` を含む → Read で直接読む
2. ピース名検索(以下の順で Glob/Read を試行):
### ツールの使い分け(重要)
| やること | 使うツール | 説明 |
|---------|-----------|------|
| チーム作成 | **Teammate** tool (operation: "spawnTeam") | 最初に1回だけ呼ぶ |
| チーム解散 | **Teammate** tool (operation: "cleanup") | 最後に1回だけ呼ぶ |
| チームメイト起動 | **Task** tool (team_name 付き) | movement ごとに呼ぶ。**結果は同期的に返る** |
**Teammate tool でチームメイトを個別に起動することはできない。** チームメイトの起動は必ず Task tool を使う。
**Task tool は同期的に結果を返す。** TaskOutput やポーリングは不要。呼べば結果が返ってくる。
## 手順(この順序で厳密に実行せよ)
### 手順 1: ピース解決と読み込み
引数の第1トークンからピースYAMLファイルを特定して Read で読む。
**第1トークンがない場合ピース名未指定:**
→ ユーザーに「ピース名を指定してください。例: `/takt coding タスク内容`」と伝えて終了する。
**ピースYAMLの検索順序:**
1. `.yaml` / `.yml` で終わる、または `/` を含む → ファイルパスとして直接 Read
2. ピース名として検索:
- `~/.takt/pieces/{name}.yaml` (ユーザーカスタム、優先)
- `~/.claude/skills/takt/pieces/{name}.yaml` Skill同梱ビルトイン
3. 見つからない場合: 上記2ディレクトリを Glob (`*.yaml`) で列挙し、AskUserQuestion で選択させる
3. 見つからない場合: 上記2ディレクトリを Glob で列挙し、AskUserQuestion で選択させる
### エージェント .md の解決
YAMLから以下を抽出する→ references/yaml-schema.md 参照):
- `name`, `max_iterations`, `initial_movement`, `movements` 配列
ピースYAML内の `agent:` フィールドは、**ピースYAMLファイルのディレクトリからの相対パス**。
### 手順 2: エージェント .md の事前読み込み
例: ピースが `~/.claude/skills/takt/pieces/default.yaml` にあり、`agent: ../agents/default/coder.md` の場合
全 movementparallel のサブステップ含む)から `agent:` パスを収集する。
パスは **ピースYAMLファイルのディレクトリからの相対パス** で解決する。
例: ピースが `~/.claude/skills/takt/pieces/coding.yaml` にあり、`agent: ../agents/default/coder.md` の場合
→ 絶対パスは `~/.claude/skills/takt/agents/default/coder.md`
解決手順:
1. ピースYAMLのディレクトリパスを取得
2. 各 movement の `agent:` の相対パスを絶対パスに変換
3. Read tool で .md ファイルの内容を読み込む
4. 読み込んだ内容をエージェントのシステムプロンプトとして使用する
重複を除いて Read で全て読み込む。読み込んだ内容はチームメイトへのプロンプトに使う。
**全てのエージェント .md を事前に読み込む**(状態遷移ループ開始前に)。
### 手順 3: Agent Team 作成
## 実行フロー
### ステップ 1: ピースYAMLの読み込みと解析
1. ピース解決でYAMLファイルパスを特定し、Read で読み込む
2. YAML内容を解析して以下を抽出する→ references/yaml-schema.md 参照):
- `name`: ピース名
- `max_iterations`: 最大イテレーション数
- `initial_movement`: 開始 movement 名
- `movements`: 全 movement 定義の配列
### ステップ 2: エージェントの事前読み込み
全 movementparallel のサブステップ含む)から `agent:` パスを収集し、重複を除いて Read で読み込む。
### ステップ 3: 状態遷移ループ
**詳細は references/engine.md を参照。**
**今すぐ** Teammate tool を呼べ:
```
iteration = 0
current_movement = initial_movement
previous_response = ""
LOOP:
iteration++
if iteration > max_iterations → 強制終了ABORT
movement = movements[current_movement] を取得
if movement が parallel:
→ 並列実行engine.md の「Parallel Movement の実行」参照)
else:
→ 通常実行engine.md の「通常 Movement の実行」参照)
agent_output を取得
rule 評価engine.md の「Rule 評価」参照)
→ matched_rule を決定
next = matched_rule.next
if next == "COMPLETE" → 成功終了、ユーザーに結果を報告
if next == "ABORT" → 失敗終了、ユーザーにエラーを報告
previous_response = agent_output
current_movement = next
→ LOOP に戻る
Teammate tool を呼ぶ:
operation: "spawnTeam"
team_name: "takt"
description: "TAKT {piece_name} ワークフロー"
```
### ステップ 4: 完了報告
### 手順 4: 初期化
- COMPLETE: 最後の agent 出力のサマリーをユーザーに表示
- ABORT: 失敗理由をユーザーに表示
- max_iterations 到達: 強制終了を通知
`initial_movement` の名前を確認し、`movements` 配列から該当する movement を取得する。
**以下の変数を初期化する:**
- `iteration = 1`
- `current_movement = initial_movement の movement 定義`
- `previous_response = ""`
- `permission_mode = コマンドで解析された権限モード("bypassPermissions" または "default"`
- `movement_history = []`遷移履歴。Loop Monitor 用)
**レポートディレクトリ**: いずれかの movement に `report` フィールドがある場合、`.takt/reports/{YYYYMMDD-HHmmss}-{slug}/` を作成し、パスを `report_dir` 変数に保持する。
次に **手順 5** に進む。
### 手順 5: チームメイト起動
**iteration が max_iterations を超えていたら → 手順 8ABORT: イテレーション上限)に進む。**
current_movement のプロンプトを構築する(→ references/engine.md のプロンプト構築を参照)。
**通常 movement の場合parallel フィールドなし):**
Task tool を1つ呼ぶ。**Task tool は同期的に結果を返す。待機やポーリングは不要。**
```
Task tool を呼ぶ:
prompt: <構築したプロンプト全文>
description: "{movement名} - {piece_name}"
subagent_type: "general-purpose"
team_name: "takt"
name: "{movement の name}"
mode: permission_mode
```
Task tool の戻り値がチームメイトの出力。**手順 5a** に進む。
**parallel movement の場合:**
**1つのメッセージで**、parallel 配列の各サブステップに対して Task tool を並列に呼ぶ。
全ての Task tool が結果を返したら **手順 5a** に進む。
```
// サブステップの数だけ Task tool を同時に呼ぶ(例: 2つの場合
Task tool を呼ぶ1つ目:
prompt: <サブステップ1用プロンプト>
description: "{サブステップ1名} - {piece_name}"
subagent_type: "general-purpose"
team_name: "takt"
name: "{サブステップ1の name}"
mode: permission_mode
Task tool を呼ぶ2つ目:
prompt: <サブステップ2用プロンプト>
description: "{サブステップ2名} - {piece_name}"
subagent_type: "general-purpose"
team_name: "takt"
name: "{サブステップ2の name}"
mode: permission_mode
```
### 手順 5a: レポート抽出と Loop Monitor
**レポート抽出**current_movement に `report` フィールドがある場合のみ):
チームメイト出力から ```markdown ブロックを抽出し、Write tool で `{report_dir}/{ファイル名}` に保存する。
詳細は references/engine.md の「レポートの抽出と保存」を参照。
**Loop Monitor チェック**(ピースに `loop_monitors` がある場合のみ):
`movement_history` に current_movement の名前を追加する。
遷移履歴が loop_monitor の `cycle` パターンに `threshold` 回以上マッチした場合、judge チームメイトを起動して遷移先をオーバーライドする。
詳細は references/engine.md の「Loop Monitors」を参照。
### 手順 6: Rule 評価
Task tool から返ってきたチームメイトの出力から matched_rule を決定する。
**通常 movement:**
1. 出力に `[STEP:N]` タグがあるか探す(複数ある場合は最後のタグを採用)
2. タグがあれば → rules[N] を選択0始まりインデックス
3. タグがなければ → 出力全体を読み、全 condition と比較して最も近いものを選択
**parallel movement:**
1. 各サブステップの Task tool 出力に対して、サブステップの rules で条件マッチを判定
2. マッチした condition 文字列を記録
3. 親 movement の rules で aggregate 評価:
- `all("X")`: 全サブステップが "X" にマッチしたら true
- `any("X")`: いずれかのサブステップが "X" にマッチしたら true
- `all("X", "Y")`: サブステップ1が "X"、サブステップ2が "Y" にマッチしたら true
4. 親 rules を上から順に評価し、最初に true になった rule を選択
matched_rule が決まったら **手順 7** に進む。
どの rule にもマッチしなかったら → **手順 8ABORT: ルール不一致)** に進む。
### 手順 7: 次の movement を決定
matched_rule の `next` を確認する:
- **`next` が "COMPLETE"** → **手順 8COMPLETE** に進む
- **`next` が "ABORT"** → **手順 8ABORT** に進む
- **`next` が movement 名** → 以下を実行して **手順 5 に戻る**:
1. `previous_response` = 直前のチームメイト出力
2. `current_movement` = `next` で指定された movement を movements 配列から取得
3. `iteration` を +1 する
4. **手順 5 に戻る**
### 手順 8: 終了
1. Teammate tool を呼ぶ:
```
Teammate tool を呼ぶ:
operation: "cleanup"
```
2. ユーザーに結果を報告する:
- **COMPLETE**: 最後のチームメイト出力のサマリーを表示
- **ABORT**: 失敗理由を表示
- **イテレーション上限**: 強制終了を通知
## 詳細リファレンス
| ファイル | 内容 |
|---------|------|
| `references/engine.md` | Movement 実行、プロンプト構築、Rule 評価の詳細ロジック |
| `references/engine.md` | プロンプト構築、レポート管理、ループ検出の詳細 |
| `references/yaml-schema.md` | ピースYAMLの構造定義とフィールド説明 |

View File

@ -1,42 +1,46 @@
# TAKT 実行エンジン詳細
## 通常 Movement の実行
## チームメイトの起動方法
通常の movement`parallel` フィールドを持たない movementは、Task tool で1つのエージェントを起動する。
全ての movement は Task tool でチームメイトを起動して実行する。
**あなたTeam Leadが直接作業することは禁止。**
### Task tool の呼び出し
```
Task tool:
subagent_type: "general-purpose"
description: "{movement名} - {ピース名}" 3-5語
prompt: <後述のプロンプト構築で組み立てた内容>
mode: <permission_mode から決定>
team_name: "takt"
name: "{movement_name}"
description: "{movement_name} - {piece_name}"
prompt: <プロンプト構築で組み立てた内容>
mode: permission_mode
```
### permission_mode の決定
### permission_mode
movement の `edit` フィールドと `permission_mode` フィールドから決定する:
コマンド引数で解析された `permission_mode` をそのまま Task tool の `mode` に渡す。
- `/takt coding yolo タスク``permission_mode = "bypassPermissions"`(確認なし)
- `/takt coding タスク``permission_mode = "default"`(権限確認あり)
| edit | permission_mode | Task tool の mode |
|------|----------------|-------------------|
| true | 未指定 | "bypassPermissions" |
| true | "edit" | "bypassPermissions" |
| true | "full" | "bypassPermissions" |
| false | 未指定 | "default" |
| false | "readonly" | "default" |
## 通常 Movement の実行
`edit: false` の movement は読み取り専用。`edit: true` の movement はファイル編集が可能。
通常の movement`parallel` フィールドを持たないは、Task tool で1つのチームメイトを起動する。
1. プロンプトを構築する(後述の「プロンプト構築」参照)
2. Task tool でチームメイトを起動する
3. チームメイトの出力を受け取る
4. Rule 評価で次の movement を決定する
## Parallel Movement の実行
`parallel` フィールドを持つ movement は、複数のサブステップを並列実行する。
`parallel` フィールドを持つ movement は、複数のチームメイトを並列起動する。
### 実行手順
1. parallel 配列の各サブステップに対して Task tool を起動する
1. parallel 配列の各サブステップに対して Task tool を準備する
2. **全ての Task tool を1つのメッセージで並列に呼び出す**(依存関係がないため)
3. 全エージェントの完了を待つ
3. 全チームメイトの完了を待つ
4. 各サブステップの出力を収集する
5. 各サブステップの出力に対して、そのサブステップの `rules` で条件マッチを判定する
6. 親 movement の `rules` で aggregate 評価all()/any())を行う
@ -53,7 +57,7 @@ movement の `edit` フィールドと `permission_mode` フィールドから
## プロンプト構築
movement のエージェント起動時、以下を結合してプロンプトを組み立てる。
チームメイト起動時、以下を結合してプロンプトを組み立てる。
### 構成要素(上から順に結合)
@ -86,7 +90,7 @@ movement の `edit` フィールドと `permission_mode` フィールドから
| 変数 | 値 |
|-----|-----|
| `{task}` | ユーザーが入力したタスク内容 |
| `{previous_response}` | 前の movement のエージェント出力 |
| `{previous_response}` | 前の movement のチームメイト出力 |
| `{iteration}` | ピース全体のイテレーション数1始まり |
| `{max_iterations}` | ピースの max_iterations 値 |
| `{movement_iteration}` | この movement が実行された回数1始まり |
@ -106,7 +110,7 @@ movement の `edit` フィールドと `permission_mode` フィールドから
## レポート出力指示の自動注入
movement に `report` フィールドがある場合、プロンプト末尾にレポート出力指示を自動追加する。これにより、takt 本体の Phase 2レポート出力フェーズを1回の呼び出しに統合する。
movement に `report` フィールドがある場合、プロンプト末尾にレポート出力指示を自動追加する。
### 形式1: name + format
@ -156,9 +160,10 @@ report:
### レポートの抽出と保存
エージェントの出力からレポート内容を抽出し、Write tool でレポートディレクトリに保存する。
チームメイトの出力からレポート内容を抽出し、Write tool でレポートディレクトリに保存する。
**この作業は Team Leadあなたが行う。** チームメイトの出力を受け取った後に実施する。
**レポートディレクトリ**: `.takt/reports/{timestamp}-{slug}/` に作成するtakt 本体と同じ構造)
**レポートディレクトリ**: `.takt/reports/{timestamp}-{slug}/` に作成する。
- `{timestamp}`: `YYYYMMDD-HHmmss` 形式
- `{slug}`: タスク内容の先頭30文字をスラグ化
@ -169,7 +174,7 @@ report:
## ステータスタグ出力指示の自動注入
movement に `rules` がある場合、プロンプト末尾にステータスタグ出力指示を自動追加する。これにより、takt 本体の Phase 3ステータス判定フェーズを1回の呼び出しに統合する。
movement に `rules` がある場合、プロンプト末尾にステータスタグ出力指示を自動追加する。
### 注入する指示
@ -194,7 +199,7 @@ condition が `ai("条件テキスト")` 形式の場合でも、同じくタグ
[STEP:1] = 別の条件テキスト
```
これにより、エージェントが自ら判断して適切なタグを出力する。ai() の括弧は除去して condition テキストのみを表示する。
ai() の括弧は除去して condition テキストのみを表示する。
### サブステップの場合
@ -202,7 +207,7 @@ parallel のサブステップにも同様にタグ出力指示を注入する
## Rule 評価
movement 実行後、エージェントの出力テキストからどの rule にマッチするかを判定する。
チームメイトの出力からどの rule にマッチするかを判定する。
### 通常 Movement の Rule 評価
@ -210,7 +215,7 @@ movement 実行後、エージェントの出力テキストからどの rule
#### 1. タグベース検出(優先)
エージェント出力に `[STEP:N]` タグN は 0始まりのインデックスが含まれる場合、そのインデックスに対応する rule を選択する。複数のタグがある場合は **最後のタグ** を採用する。
チームメイト出力に `[STEP:N]` タグN は 0始まりのインデックスが含まれる場合、そのインデックスに対応する rule を選択する。複数のタグがある場合は **最後のタグ** を採用する。
例: rules が `["タスク完了", "進行できない"]` で出力に `[STEP:0]` → "タスク完了" を選択
@ -218,11 +223,6 @@ movement 実行後、エージェントの出力テキストからどの rule
タグが出力に含まれない場合、出力テキスト全体を読み、全ての condition と比較して最もマッチするものを選択する。
**出力テキストの判定例**:
- rules: `["実装完了", "判断できない"]`
- 出力: 「全てのファイルを修正し、テストもパスしました。」
- → "実装完了" にマッチ
### Parallel Movement の Rule 評価Aggregate
親 movement の rules に `all()` / `any()` の aggregate 条件を使用する。
@ -252,13 +252,6 @@ movement 実行後、エージェントの出力テキストからどの rule
いずれかのサブステップのマッチ条件が "needs_fix" であれば true。
```yaml
- condition: any("AI特有の問題あり")
next: ai_fix
```
**引数が1つ**: いずれかのサブステップが "AI特有の問題あり" にマッチすれば true。
#### Aggregate 評価の順序
親 rules を上から順に評価し、最初にマッチした rule を採用する。
@ -308,11 +301,11 @@ loop_monitors:
### 検出ロジック
1. movement 遷移履歴を記録する(例: `[plan, implement, ai_review, ai_fix, ai_review, ai_fix, ...]`
2. 各 loop_monitor の `cycle` パターン(例: `[ai_review, ai_fix]`が履歴の末尾に `threshold` 回以上連続で出現するかチェックする
2. 各 loop_monitor の `cycle` パターンが履歴の末尾に `threshold` 回以上連続で出現するかチェックする
3. 閾値に達した場合:
a. judge の `agent` を Read で読み込む
b. `instruction_template``{cycle_count}` を実際のサイクル回数に置換する
c. Task tool で judge エージェントを起動する
c. Task tool でチームメイトjudgeを起動する
d. judge の出力を judge の `rules` で評価する
e. マッチした rule の `next` に遷移する(通常のルール評価をオーバーライドする)
@ -330,7 +323,7 @@ loop_monitors:
### レポートの保存
エージェント出力からレポート内容を抽出し、Write tool でレポートディレクトリに保存する。
チームメイト出力からレポート内容を抽出し、Write tool でレポートディレクトリに保存する。
抽出手順:
1. 出力内の ```markdown ブロックを検索する
@ -339,36 +332,42 @@ loop_monitors:
### レポートの参照
後続の movement の `instruction_template` 内で `{report:ファイル名}` として参照すると、engine がそのレポートファイルを Read して内容をプレースホルダーに展開する。
後続の movement の `instruction_template` 内で `{report:ファイル名}` として参照すると、そのレポートファイルを Read して内容をプレースホルダーに展開する。
## 状態遷移の全体像
```
[開始]
ピースYAML読み込み + エージェント .md 読み込み
Teammate(spawnTeam) でチーム作成
レポートディレクトリ作成
initial_movement を取得
┌─→ movement を実行
│ ├── 通常: Task tool (1エージェント)
┌─→ Task tool でチームメイト起動
│ ├── 通常: 1つの Task tool 呼び出し
│ │ prompt = agent.md + context + instruction + task
│ │ + previous_response + レポート指示 + タグ指示
│ └── parallel: Task tool (複数エージェント並列)
│ 各サブステップも同様のプロンプト構築
│ └── parallel: 複数の Task tool を1メッセージで並列呼び出し
│ 各サブステップを別々のチームメイトとして起動
│ ↓
出力からレポート抽出 → Write で保存
チームメイトの出力を受け取る
│ ↓
Loop Monitor チェック(該当サイクルがあれば judge 介入
出力からレポート抽出 → Write で保存Team Lead が実施
│ ↓
│ Rule 評価
│ Loop Monitor チェック(該当サイクルがあれば judge チームメイト介入)
│ ↓
│ Rule 評価Team Lead が実施)
│ ├── タグ検出 [STEP:N] → rule 選択
│ └── タグなし → AI フォールバック判定
│ ├── parallel: サブステップ条件 → aggregate(all/any)
│ ↓
│ next を決定
│ ├── COMPLETE → [成功終了] ユーザーに結果報告
│ ├── ABORT → [失敗終了] ユーザーにエラー報告
│ ├── COMPLETE → Teammate(cleanup) → ユーザーに結果報告
│ ├── ABORT → Teammate(cleanup) → ユーザーにエラー報告
│ └── movement名 → ループ検出チェック → 次の movement
│ ↓
└──────────────────────────────────────────────┘

View File

@ -9,13 +9,22 @@ TAKT ピースランナーを実行する。
$ARGUMENTS を以下のように解析する:
- 第1トークン: ピース名またはYAMLファイルパス必須
- 残りのトークン: タスク内容(省略時は AskUserQuestion でユーザーに入力を求める)
```
/takt {piece} [permission] {task...}
```
- **第1トークン**: ピース名またはYAMLファイルパス必須
- **第2トークン**: 権限モード(任意)。以下のキーワードの場合は権限モードとして解釈する:
- `yolo` — 全権限付与mode: "bypassPermissions"
- 上記以外 → タスク内容の一部として扱う
- **残りのトークン**: タスク内容(省略時は AskUserQuestion でユーザーに入力を求める)
- **権限モード省略時のデフォルト**: `"default"`(権限確認あり)
例:
- `/takt passthrough タスクを実行`
- `/takt default src/foo.ts のバグを修正`
- `/takt /path/to/custom.yaml 実装して`
- `/takt coding FizzBuzzを作って` → coding ピース、default 権限
- `/takt coding yolo FizzBuzzを作って` → coding ピース、bypassPermissions
- `/takt passthrough yolo 全テストを実行` → passthrough ピース、bypassPermissions
- `/takt /path/to/custom.yaml 実装して` → カスタムYAML、default 権限
## 実行手順
@ -25,4 +34,4 @@ $ARGUMENTS を以下のように解析する:
2. `~/.claude/skills/takt/references/engine.md` - 実行エンジンの詳細ロジック
3. `~/.claude/skills/takt/references/yaml-schema.md` - ピースYAML構造リファレンス
**重要**: これら3ファイルを最初に全て読み込んでから、SKILL.md の「実行フロー」に従って処理を開始する。
**重要**: これら3ファイルを最初に全て読み込んでから、SKILL.md の「手順」に従って処理を開始する。

View File

@ -12,7 +12,7 @@
* the directory structure is mirrored.
*/
import { existsSync, readdirSync, readFileSync, writeFileSync, mkdirSync, statSync } from 'node:fs';
import { existsSync, readdirSync, readFileSync, writeFileSync, mkdirSync, rmSync, statSync } from 'node:fs';
import { homedir } from 'node:os';
import { join, dirname, relative } from 'node:path';
@ -83,14 +83,17 @@ export async function deploySkill(): Promise<void> {
// 3. Deploy references/ (engine.md, yaml-schema.md)
const refsSrcDir = join(skillResourcesDir, 'references');
const refsDestDir = join(skillDir, 'references');
cleanDir(refsDestDir);
copyDirRecursive(refsSrcDir, refsDestDir, copiedFiles);
// 4. Deploy builtin piece YAMLs → skills/takt/pieces/
const piecesDestDir = join(skillDir, 'pieces');
cleanDir(piecesDestDir);
copyDirRecursive(builtinPiecesDir, piecesDestDir, copiedFiles);
// 5. Deploy builtin agent .md files → skills/takt/agents/
const agentsDestDir = join(skillDir, 'agents');
cleanDir(agentsDestDir);
copyDirRecursive(builtinAgentsDir, agentsDestDir, copiedFiles);
// Report results
@ -135,6 +138,13 @@ export async function deploySkill(): Promise<void> {
}
}
/** Remove a directory and all its contents so stale files don't persist across deploys. */
function cleanDir(dir: string): void {
if (existsSync(dir)) {
rmSync(dir, { recursive: true });
}
}
/** Copy a single file, creating parent directories as needed. */
function copyFile(src: string, dest: string, copiedFiles: string[]): void {
if (!existsSync(src)) return;