Pilot automatic Squad casting, onboarding, and research #2009

Goal

Prototype a gradual agentic Squad experience in which installing the gh-aw workflows leads to useful repository analysis without requiring the current slash-command choreography.

Development and testing must remain isolated from dev. Use the bradygaster-agentic-squad-pilot branch, based on dev. Existing workflows on dev must remain unchanged and usable.

Product rules

• This is experimental software; backwards compatibility is not required.
• Be brave, never careless.
• No goose chases: do not add work outside the goals in this issue without first surfacing it and receiving explicit approval.
• Labels describe machine-visible state.
• Slash commands express human intent and intervention.
• Native GitHub PR review and merge actions govern code acceptance.
• Every Squad-authored issue, comment, and PR must explain:
  • what happens next automatically;
  • what the user should do now;
  • what the user can optionally do;
  • how to stop or redirect the work;
  • the current blocking state.
• Use multiple cohesive workflows rather than extending the existing monolithic dispatcher.

Staged delivery

Stage 1 — Automatic Cast

When the Squad workflow-installation PR reaches the target repository's default branch:

1. Detect the installation using an explicit, stable bootstrap marker.
2. Confirm no committed final Squad exists.
3. Confirm no Cast PR is already open.
4. Analyze repository code, manifests, architecture, tests, deployment configuration, open issues, and open PRs.
5. Consult relevant current technical information where network policy permits.
6. Generate an efficient, descriptively named, repository-specific Squad.
7. Run the existing deterministic Cast validator.
8. Open or update exactly one Cast PR.
9. Stop for native human PR review and merge.

Cast acceptance criteria:

• Descriptive names only.
• Every role is justified by concrete repository evidence.
• Current-stack and relevant modern-stack expertise are represented.
• Open customer issues and PRs influence the roster.
• No redundant or generic filler roles.
• Repeated triggers are idempotent.
• The validator cannot be bypassed.

Stage 2 — Onboarding issue

When the Cast PR merges:

1. Create or update exactly one issue titled [Squad] Your repository team is ready.
2. Link the merged Cast PR and summarize the active roster.
3. Explain which automatic stages are currently enabled.
4. Explain that [Research], [Triage], [Planning], and [Implementation Plan] issues may appear as those stages are enabled.
5. Explain that executable Work Items are not created until a human explicitly authorizes an Implementation Plan.
6. Explain available intervention commands.
7. Include the universal state-aware next-steps footer.

Re-casting must not create duplicate onboarding issues.

Stage 3 — Bounded automatic Research

Only begin after Stages 1–2 pass their evaluation gates.

1. Support one repository-intake Research run after Cast merge.
2. Support focused Research from a free-form Mission issue or /squad research <topic>.
3. Initially leave daily scheduled Research disabled.
4. Cap active Research at three open issues per repository.
5. Count active Research using an automation-owned state label rather than title parsing.
6. Deduplicate using a stable body marker, origin reference, and normalized topic identity.
7. Allow zero new Research issues as a successful run.
8. At the cap, scheduled discovery creates nothing; a human-requested Mission receives a visible waiting state.
9. Do not maintain a hidden queue.
10. Each Research issue executes automatically and ends with one outcome:
    • proceed to Triage;
    • more evidence required;
    • dead end.
11. For the first pilot, completed Research stops instead of automatically opening Triage.

Stage 4 — Optional automatic Triage

Enable only after automatic Research is consistently relevant, evidence-backed, bounded, and idempotent.

Triage may proceed, request more Research, merge with existing work, defer, reject, or close as already resolved. It must be able to terminate weak ideas without creating Planning work.

Human intervention commands

• /squad activate [phase N] — approve an Implementation Plan and create Work Items.
• /squad revise [phase] <feedback> — revise or redirect the current artifact.
• /squad stop <reason> — terminate the current chain.
• /squad status — report current phase, progress, and blockers.
• /squad research <focus> — request focused or supplemental Research.
• /squad implement — retry or resume a blocked Work Item.

Automatic Research, Triage, Planning, and Implementation Plan progression should require no commands unless Squad needs human information, access, evidence, authority, or a business decision.

Workflow boundaries

Prefer separate cohesive workflows for:

• Cast
• Onboarding
• Research discovery
• Research execution
• Triage

Do not add Planning, Implementation Plan activation, or implementation automation to the initial pilot.

Each workflow must have a narrow trigger, least-privilege permissions, bounded safe outputs, an idempotency contract, a visible failure state, and one documented handoff.

Pilot validation

Test from a commit-pinned feature-branch ref in a fresh disposable target repository. Do not use or modify @dev workflows.

Validate:

1. The installation merge triggers exactly one Cast PR.
2. Cast is repository-specific and passes deterministic validation.
3. Re-triggering does not create duplicate Cast PRs.
4. Cast merge creates exactly one onboarding issue.
5. Re-casting does not duplicate onboarding.
6. Research creates no more than three active issues.
7. Research topics are concrete, evidence-backed, and non-duplicative.
8. Research runs automatically.
9. Dead ends terminate cleanly.
10. /squad revise, /squad status, and /squad stop work as interventions.
11. No event invokes or changes the existing dev workflow behavior.

Deferred

• Daily scheduled Research.
• Automatic Triage until Research is proven.
• Automatic Planning and Implementation Plan creation.
• Implementation Plan activation.
• Cross-repository work-item dispatch.
• Automatic implementation or merging.

These require separate approval after the preceding stages are validated.