Fix/teammate team context

[40verse]

Summary

• What changed: Teammates now receive a structured [TEAM CONTEXT] block prepended to their initial prompt at spawn time. A new buildTeamContextBlock() utility in teamHelpers.ts produces the block containing: team name, agent role/type, team lead identity, other teammates (names + types), team config file path, and shared goal. This block is injected at the three spawn paths in spawnMultiAgent.ts — split-pane (tmux), separate-window (iTerm2), and in-process — using the existing mailbox system for pane-based agents and direct prompt injection for in-process agents.

• Why it changed: Spawned teammates had zero knowledge of their team structure. They didn't know who the lead was, who else was on the team, or where to find the team config. This forced the lead agent to manually brief every teammate, wasting tokens and creating coordination failures when teammates couldn't discover peers or roles on their own.

Impact

• User-facing impact: Multi-agent teams are immediately more effective — every teammate knows its role, lead, peers, and shared goal from turn one without the lead having to explain it. Teammates can also self-serve by reading the team config path to discover members who join later.
• Developer/maintainer impact: buildTeamContextBlock() is a single shared function with full test coverage. Adding new fields to the team context block requires changing only one function. No new dependencies introduced.

Testing

• bun run build — passes
• bun run smoke — passes
• focused tests: bun test src/utils/swarm/teamHelpers.test.ts — 8/8 pass, 21 assertions

Notes

• Provider/model path tested: N/A — change is model-agnostic (prompt content, not API calls)
• Screenshots attached: N/A — no UI changes
• Follow-up work or known limitations: The context block is a static snapshot at spawn time. If teammates join after spawn, existing agents only discover them by reading the team config file (which the addendum now tells them how to do). A future enhancement could push roster-update messages to existing teammates when new members join.

Pushing now in relation to #405

[40verse]

This is another from my list of the initial source analysis. All my PRs are related to that research. Im trying to hold off until after the rename on further PRs but I saw the issue spring up.

[gnanam1990]

Thanks for the PR. The team-context addition is a useful improvement, and I like the direction of centralizing the formatting in buildTeamContextBlock().

I did find one blocking issue before this can be merged:

1. src/tools/shared/spawnMultiAgent.ts:956-960, 985, 1069-1076
   In handleSpawnInProcess(), promptWithContext is used in both config.prompt and startInProcessTeammate({ prompt: ... }) before teamContext / promptWithContext are declared later in the function. Since const bindings are in the temporal dead zone until initialization, this will fail at runtime with ReferenceError: Cannot access 'promptWithContext' before initialization whenever the in-process spawn path is used.

Other than that, I didn’t find any additional high-confidence regressions in the PR head I reviewed.

Happy to take another look once that’s fixed.

[kevincodex1]

please rebase to latest main

[kevincodex1]

please rebase to main branch to fix the broken tests

[kevincodex1]

saw it. let me recheck again

[kevincodex1]

looks great to me

[Vasanthdev2004]

Rechecked the latest head a37c3c3b9bdac230f3297dac52391a04375ddc1e against current origin/main 72e6a945fe1311a0b9eea1033703a74dc6cdbc18.

The earlier TDZ issue is fixed on this revision, but I still can't approve because moving the team-file registration earlier introduced a new in-process regression.

Current blocker:

1. src/tools/shared/spawnMultiAgent.ts:956-971 now appends the teammate to teamFile.members and writes the file before spawnInProcessTeammate() is attempted at :989. If that spawn then fails, the function throws at :991-992 but leaves the new member persisted in the team file even though no teammate actually exists.

   Direct repro on this head:

   • mock spawnInProcessTeammate() to return { success: false, error: 'spawn failed' }
   • call spawnTeammate() through the real handleSpawnInProcess() path
   • function throws spawn failed
   • captured writeTeamFileAsync() payload already contains the new worker@team member

   Baseline on current origin/main for the same repro:

   • function throws spawn failed
   • writeTeamFileAsync() is never called (null in the repro)

   This is a real behavioral regression: a failed in-process spawn now leaves a ghost teammate in the team roster, which can affect later roster discovery / unique-name generation and make the persisted team config disagree with reality.

What I verified on this head:

• direct failure-path repro above on latest head
• same failure-path repro on current origin/main for baseline
• bun test src/utils/swarm/teamHelpers.test.ts -> 8 pass
• bun run build -> success
• bun run smoke -> success

I didn't find another high-confidence blocker beyond that failure-path regression, but I wouldn't merge this until the team file write is made atomic with successful in-process spawn (or rolled back on failure).

[40verse]

I will rebase and resubmit following the feedback, thanks!

[40verse]

Ive updated with recommended fixes, tests, and a pre-commit.sh hook I can reference from any environment to get consistent CI. If I need to split it into its own PR, I can.

[Vasanthdev2004]

Rechecked the current head ad9c5bdd8f6aebe74167d432f33356cfbd0d8885 against current origin/main.

The earlier in-process spawn regressions are fixed on this head, and the new focused tests/build/smoke all pass. I still can't approve because the new pre-commit safety net has a real logic bug that makes its PR scan effectively a no-op.

1. scripts/pre-commit.sh:98 plus scripts/pr-intent-scan.ts:467-489 and scripts/pr-intent-scan.ts:523-526
   The hook says it scans the staged diff:

   • git diff --cached --unified=0 | bun run scripts/pr-intent-scan.ts --base HEAD

   But scripts/pr-intent-scan.ts never reads stdin. It always recomputes its own diff with getGitDiff(baseRef), and with --base HEAD that becomes git diff HEAD...HEAD, i.e. an empty diff.

   Direct repro I verified locally on this head:

   • pipe a fake diff containing +await writeTeamFileAsync() into bun run scripts/pr-intent-scan.ts --base HEAD
   • output is still PR intent scan: no suspicious additions found.

   So the new pre-commit hook currently always reports the scan as clean, even when the staged changes should be flagged. That blocks approval because this PR explicitly adds the hook/scan as protection against the exact regression class discussed in the PR.

Non-blocking notes:

• .github/workflows/pr-checks.yml:38-43 typecheck is surfacing a large pre-existing TS baseline on both this branch and current origin/main; I did not treat that as a PR-specific blocker.
• The two provider tests that failed in the GitHub merge run did not reproduce locally on the branch, and the focused tests for this PR passed.

What I verified on this head:

• bun test src/tools/shared/spawnMultiAgent.inProcess.test.ts src/utils/swarm/teamHelpers.test.ts scripts/pr-intent-scan.test.ts -> 35 pass
• bun test src/commands/provider/provider.test.tsx -> 10 pass
• bun run build -> success
• bun run smoke -> success
• bun test --max-concurrency=1 -> only unrelated src/utils/geminiCredentials.test.ts failures locally
• direct stdin repro of the pre-commit scan issue above