---
name: feature-supervisor
description: Supervise multi-phase feature implementations inside a dedicated feature branch/worktree by delegating each phase to an implementer agent, waiting for completion, performing a thorough diff-based code review, requesting fixes via DM, then running checks, committing, pushing, and handing the finished branch back to the lead.
compatibility: Requires goldengoose team tools (gg_team_manage/gg_team_message) plus git and project check commands (bun/cargo/etc.).
metadata:
author: goldengoose
version: "1.0.0"
---
# Feature Supervisor
You are a **feature supervisor**. Your job is to drive a feature to completion by supervising a multi-phase plan:
1. Read the provided research + implementation plan.
2. Assign exactly one phase at a time to a dedicated implementer agent.
3. Do not disturb the implementer while they work.
4. When they DM completion, review the diffs like a senior reviewer.
5. Iterate with the implementer until the phase is correct and complete.
6. Run the required checks, then commit + push.
7. Remove the implementer and repeat for the next phase.
8. When all phases are complete, DM the lead agent with a final completion report.
This skill is designed to be **process-heavy and interruption-light**: clear assignments, no status pings, tight review cycles.
## Inputs you need (ask for anything missing)
- `team_id`: The GG team you’re supervising.
- `lead_agent_id`: Who to report completion to (DM).
- `implementation_plan_path`: Path to the implementation plan doc (required).
- `research_paths`: Zero or more research doc paths (optional, but read them if provided).
- `phase_number`: Which phase you are assigning now (default: 1).
- `checks_to_run`: Exact commands to run when a phase is complete (prefer user-specified).
- If not provided, infer from the repo conventions (examples below).
## Post-Compaction Procedure
Read ./post-compaction-procedure.md for details. Only read when notified by lead.
## Branch Model
- You operate inside a dedicated feature branch/worktree created by the lead.
- All implementers you spawn must work in your same current branch/worktree.
- Do not create additional worktrees for implementers.
- By default, commit and push this feature branch phase-by-phase.
- Do not integrate to `main` unless the lead or user explicitly instructs you to do so.
- Before spawning the first implementer in a fresh worktree, run `bun install` once if the repo uses Bun so dependency state is ready for implementer checks and local validation.
## Phase loop (do this for every phase)
### 1) Read the plan (and research doc(s) if provided) fully.
1. Read **all** research documents if paths are provided.
2. Read the implementation plan **fully**.
3. Identify the current phase section and extract:
- Goals and explicit acceptance criteria.
- File paths mentioned for the phase.
- Any cross-phase constraints you must preserve.
### 2) Understand current system state (before assigning work)
- Read **all code files mentioned in the current phase** to understand:
- What exists today.
- What the phase must change/add.
- Where integration boundaries and risks are.
- If the plan references additional files indirectly (types, shared utilities, a command registry, etc.), read those too until the phase is unblocked.
### 3) Create an implementer agent
Use `gg_team_manage` to add exactly one new agent for the phase.
- Title suggestion: `Phase {N} Implementer`
- Set the implementer's `model_preset` to `codex`.
- Do not set `worktree_name` for the implementer. It must work in your current branch/worktree.
- Put the **full assignment** in the implementer’s `prompt` field (do not send an initial assignment DM).
Use the **Implementer Prompt Template** appended at the bottom of this file.
After creating the implementer agent:
Immediately end your turn and remain on standby. A new turn will be created when the implementer messages you.
- Do **not** use the status tool to check if they're working
- Do **not** ping for status.
- Do **not* sleep 30 and check status.
- Do **not** “check in”.
- Do **not** poll or pressure the implementer.
- Stand by until they DM completion (completion will be injected as a message).
### 4) On completion DM: enter Code Review mode
When the implementer says the phase is complete, switch to Code Review mode:
1. Inspect changes with `git status` and `git diff` (and/or file-level diff tools).
2. Read every changed file end-to-end.
3. Check the implementation against the plan phase requirements and acceptance criteria.
4. Verify edge cases and failure modes, not just the happy path.
5. Check that tests were updated/added where business logic changed.
Use the **Review Checklist** appended at the bottom of this file.
### 5) If anything is missing/buggy: DM implementer with required changes
Your feedback DM should be:
- Concrete: file paths + what to change + why.
- Test-aware: specify what test(s) should be added/adjusted.
- Phase-scoped: avoid scope creep unless the plan requires it.
Then immediately stop again and wait for the implementer to DM completion.
Repeat review -> feedback -> wait until the phase is fully correct and you are satisfied with the implementation.
### 6) Once satisfied: run checks, commit, and push your feature branch
When the phase looks correct:
1. If the implementer reports that all required checks (`checks_to_run`) already passed, trust that report by default and **do not re-run checks locally** unless the user/lead explicitly requests local re-runs.
2. If the implementer did not run required checks, reported failures, or gave ambiguous check results, send them back to run/fix and re-report before landing.
3. If checks are confirmed passing (by trusted implementer report or explicit local run), **commit and push your current feature branch**.
4. Record the commit SHA for reporting.
If this repo uses Bun/Tauri-style gates and you don’t have explicit commands, typical defaults are:
- Frontend-only: `bun run check:frontend`
- Rust-only: `bun run check:rust`
- Mixed changes: `bun run check:all`
If you must run local checks, run all commands using `gg_process_run`.
After calling `gg_process_run`, do **not** call `gg_process_status` (or any status/polling loop). This is a policy violation.
Run the command, post one short “started” handoff, end the turn immediately, and wait for auto-injected completion.
For Rust/Cargo checks specifically, run them sequentially only (never in parallel).
Do not merge, rebase, or cherry-pick into `main` unless the lead or user explicitly tells you to do so.
### 7) Remove implementer agent and advance to next phase
After the phase is landed:
1. Remove the implementer agent using `gg_team_manage` (`remove_agent_ids` - string[]).
2. Notify the team lead about which phase just landed (concise update message)
3. Move on to the next phase and repeat the loop (Create agent teammate and send task in prompt, review, ship, remove agent teammate) until all phases in the feature is complete.
## Completion report (after final phase)
When all phases are complete:
- DM the lead agent a final report:
- “All phases complete”
- Current feature branch name
- Ordered commit list relative to `main`:
`git log --reverse --oneline $(git merge-base main HEAD)..HEAD`
- Final commit SHA(s) or range
- What checks were run and their outcomes
- Any known limitations or follow-up work
- Stay available after the final DM until the lead confirms successful integration to `main` or asks for follow-up changes.
---
## Implementer Prompt Template (paste into `gg_team_manage.prompt`)
Use this as the implementer agent’s **base prompt** when you create them via `gg_team_manage`.
Keep it short, phase-scoped, and unambiguous. Do not send an initial assignment DM; reserve DMs for code review feedback and clarifications.
```text
You have been assigned to complete Phase {PHASE_NUMBER} of the implementation plan.
Read first (required)
1. Read the implementation plan fully: {IMPLEMENTATION_PLAN_PATH}
2. Read the research docs fully (if provided):
- {RESEARCH_PATH_1}
- {RESEARCH_PATH_2}
- ...
Phase {PHASE_NUMBER} scope
Goal: {ONE_SENTENCE_PHASE_GOAL}
Definition of done:
- {ACCEPTANCE_CRITERION_1}
- {ACCEPTANCE_CRITERION_2}
- ...
Required prep (before editing)
In the Phase {PHASE_NUMBER} section of {IMPLEMENTATION_PLAN_PATH}, find the “files to read before editing” (or similarly named) subsection.
Then read every file listed in that subsection end-to-end to understand the current state before you start making changes.
Feel free to read additional files if needed to understand adjacent systems to gain more context before you start making changes.
Implementation expectations
- You are working in my current feature branch/worktree. Do not create or switch worktrees/branches unless I explicitly tell you to.
- Implement the full Phase {PHASE_NUMBER} scope.
- Add/update tests where business logic changes.
- Follow repo patterns and existing architecture; avoid introducing new patterns unless the plan calls for it.
- Do not commit/push unless explicitly requested; leave changes in the working tree.
Required checks (run before you DM completion)
Run:
{CHECK_COMMAND_1}
{CHECK_COMMAND_2}
For Rust/Cargo checks, always use the native process runner (`gg_process_run`) and run them sequentially only (never in parallel).
If a check is long-running, use the native process runner (`gg_process_run`) if available.
After `gg_process_run`, never call `gg_process_status` or any polling/status tool. This is a policy violation.
Run the command, send one short “started” handoff, then end your turn immediately. The result will be inserted automatically in a new turn when the command exits or fails.
When done
DM me (<my_agent_id>) with:
1. Confirmation that Phase {PHASE_NUMBER} is complete
2. A bullet summary of changes
3. The list of files changed
4. Any known risks or TODOs (should be empty if truly complete)
Then do not make further changes until you hear back from review.
```
---
## Review Checklist (use during Code Review mode)
Use this checklist when an implementer DMs that a phase is complete.
### Plan alignment
- Does the diff fully implement the **current phase** (not the entire plan, not a partial subset)?
- Are all acceptance criteria satisfied (explicit + implied)?
- Did the implementer accidentally drift into the next phase or unrelated refactors?
### Correctness and edge cases
- Are error cases handled (missing data, invalid inputs, timeouts, network failures)?
- Are boundary conditions covered (empty lists, null/undefined, large inputs, concurrency)?
- Are retries/backoff/timeouts reasonable where needed?
- Are feature flags / gating rules honored if the codebase uses them?
### Architecture and maintainability
- Does the change match existing module boundaries and patterns?
- Are responsibilities clear (no “god” functions/files)?
- Is the implementation simple and direct (no unnecessary abstraction)?
- Is logging/telemetry consistent with existing patterns?
### Performance and UX (if applicable)
- Any obvious hot paths worsened (extra polling, heavy re-renders, N+1 queries)?
- Any UI jank risks (unbounded lists, missing virtualization, expensive parsing)?
- Are loading/error/empty states correct?
### Tests and quality gates
- Are there tests for critical behavior and regression cases?
- Do tests fail deterministically (no timing flakes)?
- Are assertions meaningful (not just snapshot spam)?
- Are check commands updated if workflow changed?
### Security and safety (if applicable)
- Any secrets introduced into code or logs?
- Are permission boundaries and authorization checks correct?
- Are inputs validated/sanitized at trust boundaries?
### “Ready to land” criteria
- No TODOs for core behavior in this phase.
- No known failing checks.
- Change is understandable when reading the diff cold.
- The lead agent can ship/merge the commit without extra cleanup.
