Closed
Labels
go:noNot pursuingNot pursuingsquadSquad triage inbox — Lead will assign to a memberSquad triage inbox — Lead will assign to a membertype:spikeResearch/investigation — produces a plan, not codeResearch/investigation — produces a plan, not code
Description
Problem: Squad can't currently observe its own behavior patterns — rendering issues, UX quirks, output quality, timing — in a structured way. We rely on anecdotal user reports to identify problems.
Vision: A self-testing or self-observation framework where Squad can:
- Capture behavioral snapshots — what does the output actually look like to users? Are there rendering issues, malformed tables, broken markdown, noisy tool output leaking through?
- Pattern detection — across sessions, identify recurring UX problems (e.g., 'agents go silent for too long', 'tables render wrong in terminal X', 'output hygiene violations')
- Self-improvement proposals — when patterns are detected, auto-file issues or suggest prompt/template changes
- Regression testing — after changes to squad.agent.md or spawn templates, verify that known-good behaviors still work
Research questions:
- How would Squad capture its own output for analysis? (session logs? dedicated test harness?)
- Can we run 'smoke test' sessions that exercise common workflows and validate output format?
- What metrics matter? (response time, output length, tool call count, rendering correctness, personality consistency)
- Could a dedicated agent role ('QA Observer') watch sessions and flag issues?
- How do we test across different terminal renderers / Copilot hosts?
Concrete first step: Design a test session format where Squad runs itself through scripted scenarios and a reviewer agent grades the output quality.
Metadata
Metadata
Assignees
Labels
go:noNot pursuingNot pursuingsquadSquad triage inbox — Lead will assign to a memberSquad triage inbox — Lead will assign to a membertype:spikeResearch/investigation — produces a plan, not codeResearch/investigation — produces a plan, not code
Activity
bradygaster commentedon Feb 12, 2026
Sprint Plan Scope (from Brady)
Goal: Design and implement self-improvement tests that run in GitHub Actions — NOT locally. The CLI environment stays free for the user to keep working.
Key Constraints
bradygaster/squad. Never file issues in other repos. (We tried that once. Never again.)Deliverables
bradygaster/squadwhen regressions or improvement opportunities are detectedsquad.agent.mdand spawn template changesWhat "Good" Looks Like
squad.agent.md→ Actions runs smoke tests → if output quality degrades → issue filed automatically in this repocc @copilot
bradygaster commentedon Feb 13, 2026
Closing as go:no — this is a cool idea but it's out of scope for v0.4.0. The current sprint priority is VS Code client parity (#32-#34). Self-testing framework can be revisited post-v0.4.0 when the core multi-surface story is solid.
Key concern: this is significant infrastructure work (CI-based smoke tests, auto-filing issues, regression detection) that doesn't contribute to the immediate goal of shipping Squad on VS Code.
Reopening candidate for v0.5.0 or later.
docs: add feature showcase prompts to sample-prompts.md
blog: add workstreams horizontal scaling post (github#23)
docs: add blog post github#23 — Squad Goes Enterprise (ADO support)
fix: add ADO platform awareness to governance file (squad.agent.md)
docs: add blog post github#23 — Squad Goes Enterprise (ADO support)
fix: add ADO platform awareness to governance file (squad.agent.md)
feat: Azure DevOps platform adapter — Squad for enterprise (#191)
feat: CommunicationAdapter — platform-agnostic agent-human communicat…
docs: add release notes blog github#26 + remove duplicate ADO blog gi…
docs: add release notes blog #26 + remove duplicate ADO blog #23 (#278)
docs(e2e): record E4 agent-binding verification result
docs(e2e): record E4 agent-binding verification result (PASS, n=1) (#…