You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Configurable init presets for the shared component #1604
A gh-aw user wants Squad for PR review automation only — they don't need the full default team (Lead, Backend, Frontend, Tester). Currently they must fork the shared component to change --preset default.
This blocks incremental adoption: a team that just wants automated triage shouldn't need to spin up five agents they'll never use.
Proposal
Support vars.SQUAD_INIT_PRESET and vars.SQUAD_INIT_EXTRA_ARGS in the shared component so consumers can configure team shape without forking.
Closing — fails the issue clarity bar: success criteria cannot be written without adoption evidence we do not have.
This feature proposes \�ars.SQUAD_INIT_PRESET\ and \�ars.SQUAD_INIT_EXTRA_ARGS\ so gh-aw users can configure team shape without forking. EECOM's verdict: speculative adoption-enablement.
More specifically: the feature requires knowing which presets adopters actually need, but we have zero production adoption data to inform that. The premise — 'a team that just wants automated triage shouldn't need to spin up five agents they'll never use' — is untested. We don't know which presets would be valuable, what the preset taxonomy should be (
eview-only, \ riage, \ull?), or whether adopters even hit this friction point. The feature also carries an implicit dependency on \squad init --preset\ being stable and well-understood, which has not been validated in real gh-aw deployments.
Per Brady's 2026-08-20 decision: every open issue must have a clear goal and observable success criteria. This one cannot meet that bar until we have E2E data showing (a) actual adopters who hit the preset friction, and (b) which team shape they wanted instead of the default.
When to refile: After the adoption path produces real feedback — either from E2E runs, the Insider Program, or direct reports from gh-aw users who tried to adopt Squad and found the default preset wrong for them. At that point the right preset taxonomy will be evident from data rather than assumption.
Activity
bradygaster commentedon Aug 20, 2026
Closing — fails the issue clarity bar: success criteria cannot be written without adoption evidence we do not have.
This feature proposes \�ars.SQUAD_INIT_PRESET\ and \�ars.SQUAD_INIT_EXTRA_ARGS\ so gh-aw users can configure team shape without forking. EECOM's verdict: speculative adoption-enablement.
More specifically: the feature requires knowing which presets adopters actually need, but we have zero production adoption data to inform that. The premise — 'a team that just wants automated triage shouldn't need to spin up five agents they'll never use' — is untested. We don't know which presets would be valuable, what the preset taxonomy should be (
eview-only, \ riage, \ull?), or whether adopters even hit this friction point. The feature also carries an implicit dependency on \squad init --preset\ being stable and well-understood, which has not been validated in real gh-aw deployments.
Per Brady's 2026-08-20 decision: every open issue must have a clear goal and observable success criteria. This one cannot meet that bar until we have E2E data showing (a) actual adopters who hit the preset friction, and (b) which team shape they wanted instead of the default.
When to refile: After the adoption path produces real feedback — either from E2E runs, the Insider Program, or direct reports from gh-aw users who tried to adopt Squad and found the default preset wrong for them. At that point the right preset taxonomy will be evident from data rather than assumption.