Document rolling captain teams
This commit is contained in:
@@ -15,6 +15,8 @@ a task is complex. The default is still one agent executing one task from
|
||||
- Use stronger models only where they change the outcome.
|
||||
- Keep each implementation slice measurable, validated, committed, and pushed.
|
||||
- Avoid merge conflicts by giving every agent a disjoint task and file scope.
|
||||
- Keep teams rolling: when one team finishes, integrate or park its result and
|
||||
start the next disjoint team without waiting for every other team to finish.
|
||||
|
||||
## Roles
|
||||
|
||||
@@ -55,13 +57,16 @@ example:
|
||||
- dependency cleanup
|
||||
- test/hardening work
|
||||
|
||||
The captain owns implementation for its assigned task group. The captain turns
|
||||
one task-group objective into smaller disjoint subtasks, spawns or requests
|
||||
workers when useful, reviews their changes, runs focused validation when cheap,
|
||||
and returns an integration-ready result. If nested subagents are available, the
|
||||
captain may spawn workers. If nested subagents are not available in the current
|
||||
surface, the captain returns a worker plan and the director performs the
|
||||
second-level spawns without taking over implementation.
|
||||
The captain owns implementation for its assigned task group. A team should be a
|
||||
captain plus multiple workers when the work can be split into disjoint files.
|
||||
The captain turns one task-group objective, or a small coherent run of adjacent
|
||||
task rows, into smaller disjoint subtasks, spawns or requests workers when
|
||||
useful, reviews their changes, runs focused validation when cheap, and returns
|
||||
an integration-ready result. If nested subagents are available, the captain may
|
||||
spawn workers and continue through the next compatible subtask after each worker
|
||||
returns. If nested subagents are not available in the current surface, the
|
||||
captain returns a worker plan and the director performs the second-level spawns
|
||||
without taking over implementation.
|
||||
|
||||
The captain must not edit broad shared files unless assigned. The captain must
|
||||
not rewrite the task tracker or roadmap except for a requested status note.
|
||||
@@ -111,38 +116,47 @@ has requested `gpt-5.4` captains, so use that override for captains.
|
||||
- Prefer the smallest number of teams that keeps disjoint work moving. Multiple
|
||||
captains are appropriate when task rows have non-overlapping write scopes and
|
||||
can validate independently. Avoid many agents in one file family.
|
||||
- Do not synchronize all teams at a barrier unless validation or merge risk
|
||||
requires it. Use rolling integration: wait for whichever team finishes first,
|
||||
process that result, then immediately start another disjoint team if ready
|
||||
work remains.
|
||||
|
||||
## Delegation Flow
|
||||
|
||||
1. Director picks one or more `Ready` tasks from
|
||||
1. Director picks two or more `Ready` tasks from
|
||||
`docs/modernization/tasks.md` with disjoint write scopes.
|
||||
2. Director assigns each independent task group to a `gpt-5.4` captain.
|
||||
3. Captains implement directly or coordinate workers/explorers for disjoint
|
||||
subtasks.
|
||||
subtasks, and may continue through a coherent sequence of adjacent tasks
|
||||
within the assigned scope.
|
||||
4. Captains run focused validation when cheap and return changed files,
|
||||
validation, blockers, and integration notes.
|
||||
5. Director reviews for scope conflicts and integrates returned changes.
|
||||
6. Director runs the listed validation command or the quiet checkpoint wrapper.
|
||||
5. Director waits for whichever team finishes first, reviews for scope
|
||||
conflicts, integrates returned changes, and starts the next disjoint team
|
||||
while other teams keep running.
|
||||
6. Director runs the listed validation command or the quiet checkpoint wrapper
|
||||
for each integrated slice.
|
||||
7. Director updates `tasks.md`, `debt.md`, and `roadmap.md` if tasks moved.
|
||||
8. Director commits and pushes the verified slice.
|
||||
8. Director commits and pushes verified slices incrementally.
|
||||
|
||||
## Director Prompt Template For A Captain
|
||||
|
||||
```text
|
||||
You are the gpt-5.4 team captain for the <group> task group in PanoPainter.
|
||||
|
||||
Task source: docs/modernization/tasks.md task <TASK-ID>.
|
||||
Task source: docs/modernization/tasks.md task(s) <TASK-ID-LIST>.
|
||||
Debt ids: <DEBT-LIST>.
|
||||
Assigned scope: <FILES/DIRS>.
|
||||
Validation: <COMMANDS>.
|
||||
|
||||
Goal: <ONE PARAGRAPH>.
|
||||
|
||||
Own this task group through implementation. Split into disjoint worker tasks
|
||||
only when that is faster or safer than doing the bounded edits yourself. Use
|
||||
gpt-5.4 only for risky C++ behavior changes. Keep tasks small enough to
|
||||
validate. Do not edit outside the assigned scope. Other agents may be working
|
||||
in parallel; do not revert unrelated changes.
|
||||
Own this task group through implementation. Build a small team of workers for
|
||||
disjoint subtasks when possible, review their outputs, and keep looping through
|
||||
the assigned coherent task sequence until the scope is done, blocked, or no
|
||||
longer safe to continue. Use gpt-5.4 only for risky C++ behavior changes. Keep
|
||||
tasks small enough to validate. Do not edit outside the assigned scope. Other
|
||||
agents may be working in parallel; do not revert unrelated changes.
|
||||
|
||||
Return:
|
||||
- recommended worker tasks with model choice and file scope
|
||||
|
||||
Reference in New Issue
Block a user