903111dd74
- knowledge/task-decomposition.md: 分解の可否判断基準、ファイル排他原則、 失敗パターン（パート重複・共有契約不整合）をドメイン知識として追加 - team-leader-implement instruction: 分解前に可否を判断するステップを追加。 横断的関心事・少ファイル・リファクタ系は1パートで実装するよう指示 - takt-default-team-leader.yaml: implement movement に task-decomposition ナレッジを追加
30 lines
1.5 KiB
Markdown
30 lines
1.5 KiB
Markdown
Analyze the implementation task and, if decomposition is appropriate, split into multiple parts for parallel execution.
|
|
|
|
**Important:** Reference the plan report: {report:plan.md}
|
|
|
|
**Steps:**
|
|
|
|
1. Assess whether decomposition is appropriate
|
|
- Identify files to change and check inter-file dependencies
|
|
- If cross-cutting concerns exist (shared types, IDs, events), implement in a single part
|
|
- If few files are involved, or the task is a rename/refactoring, implement in a single part
|
|
|
|
2. If decomposing: group files by layer/module
|
|
- Create groups based on high cohesion (e.g., Domain layer / Infrastructure layer / API layer)
|
|
- If there are type or interface dependencies, keep both sides in the same group
|
|
- Never assign the same file to multiple parts
|
|
- Keep test files and implementation files in the same part
|
|
|
|
3. Assign file ownership exclusively to each part
|
|
- Each part's instruction must clearly state:
|
|
- **Responsible files** (list of files to create/modify)
|
|
- **Reference-only files** (read-only, modification prohibited)
|
|
- **Implementation task** (what and how to implement)
|
|
- **Completion criteria** (implementation of responsible files is complete)
|
|
- If tests are already written, instruct parts to implement so existing tests pass
|
|
- Do not include build checks (all parts complete first, then build is verified together)
|
|
|
|
**Constraints:**
|
|
- Parts do not run tests (handled by subsequent movements)
|
|
- Do not modify files outside your responsibility (causes conflicts)
|