Repository navigation
Description
Problem
When users work with Squad for extended sessions (full-day work), there's no native mechanism to track what they've asked for. Users lose track of their requests, and the only existing tools (SQL todos table, plan.md) are opt-in — requiring the user to explicitly say "track this" or use the [[PLAN]] prefix.
The gap: Squad tracks what agents do (orchestration logs, history, decisions) but not what users ask.
What Squad Tracks Today (and the Gap)
| Layer | What it captures | The gap |
|---|---|---|
| Orchestration log | Agent spawns, routing, outcomes | Tracks agent work, not user intent |
| decisions.md | Accumulated team policies | Decisions ≠ requests |
| history.md | Per-agent learned knowledge | What agents learned, not what was asked |
| Scribe logs | Post-session narrative | After-the-fact summary, not live list |
| Session store | Raw conversation turns | Unstructured — no semantic extraction |
| SQL todos | Task tracking | Opt-in — requires "track this" |
| plan.md | Planning artifact | Opt-in — requires [[PLAN]] prefix |
Proposed Phased Approach
Phase 1: Catalog as Directive
Catalog common enhancements to Squad via directives. Treat auto-tracking as a directive — a coordinator behavior that can be captured in .squad/decisions.md and applied via squad.agent.md prompt engineering. This lets teams opt-in by adding a directive like:
"Always extract and track user asks from every message. Maintain a structured ask list throughout the session."
This requires zero product changes — it's a prompt pattern that any Squad team can adopt today.
Phase 2: CLI Switch (Opt-In)
Add a CLI flag to explicitly enable ask tracking:
squad shell --track-asks
squad --track-asks
When enabled:
- Coordinator automatically extracts asks from each user message
- Classifies: new ask vs. follow-up vs. status check vs. directive
- Maintains a structured ask list in
.squad/sessions/{id}/asks.json - Natural language access: "What have I asked for?" / "What's pending?"
- Survives context compaction (file-based, not in-memory)
Phase 3: Config File Option
Add a squad.config.ts option for project-level configuration:
export default defineSquad({
session: {
autoTrackAsks: true,
askSummary: 'end-of-session', // or 'continuous'
}
});This makes tracking a project-level setting — set once, forget.
NOT proposed: Default-on
Auto-tracking should not be turned on by default. It should remain opt-in via CLI switch or config to avoid:
- Unwanted overhead for quick sessions
- Coordinator context bloat
- Unexpected behavior changes
What Auto-Tracking Unlocks
- Day-long sessions: Work all day, never lose track of what you asked for
- Handoff clarity: "Here's what was asked, here's where we are"
- Session summaries: Automatic done / in-progress / not-started report
- Cross-session continuity: Next session reads yesterday's ask registry
- Accountability: Clear mapping from ask to agent to outcome
Ask Registry Shape (Phase 2+)
[
{ "id": "ask-1", "text": "Set up Express server", "agent": "Dallas", "status": "done", "turn": 3 },
{ "id": "ask-2", "text": "Add search feature", "status": "in-progress", "turn": 7 },
{ "id": "ask-3", "text": "Always use Zod for validation", "type": "directive", "status": "captured", "turn": 12 }
]Questions for Discussion
- Phase 1 scope: Should we ship a pre-built directive template that teams can copy, or document it as a pattern in the Squad docs?
- Phase 2 UX: What should the ask list look like when the user says "What have I asked for?" — table, bullet list, grouped by status?
- Phase 3 config surface: Should this live in
squad.config.tsonly, or also in.squad/config.jsonfor non-SDK users? - Classification: How sophisticated should the ask classifier be? Simple (every user message = ask) vs. smart (distinguish asks from follow-ups, feedback, status checks)?
/cc @bradygaster @tamirdresher for opinions on phasing and approach.
Reported by: Dina Berry
Source: Session conversation analyzing Squad product UX gap
Activity
diberry commentedon Mar 13, 2026
Assigning @bradygaster and @tamirdresher for opinions on phasing and approach. (Could not auto-assign due to repo permissions — please self-assign if interested.)
tamirdresher commentedon Mar 13, 2026
@diberry
https://github.com/bradygaster/squad/issues/365#issuecomment-4053287066
github-actions commentedon Mar 13, 2026
🏗️ Squad Triage — Flight (Lead)
Issue: #366 — Product Enhancement: Native Session Ask-Tracking
Assigned to: FIDO (Quality Owner)
Reason: Issue relates to testing/quality work
@copilot evaluation: 🔴 Not suitable — issue involves work outside the coding agent's capability profile.
Team roster:
squad:flightsquad:proceduressquad:eecomsquad:fidosquad:paosquad:capcomsquad:controlsquad:surgeonsquad:boostersquad:gncsquad:networksquad:retrosquad:incosquad:guidosquad:telemetrysquad:voxsquad:dskysquad:simssquad:handbooksquad:ralphsquad:copilotgithub-actions commentedon Mar 13, 2026
📋 Assigned to Flight (Lead)
Issue: #366 — Product Enhancement: Native Session Ask-Tracking
Flight will pick this up in the next Copilot session.
github-actions commentedon Mar 13, 2026
📋 Assigned to EECOM (Core Dev)
Issue: #366 — Product Enhancement: Native Session Ask-Tracking
EECOM will pick this up in the next Copilot session.
test: hostile input, SDK failure, and stress tests (github#380)
fix: P0 quality fixes from quality review (github#381)
diberry commentedon Mar 23, 2026
Closing — not a Squad product addition
Native session ask-tracking isn't an addition to Squad the product. If a user needs ask-tracking or session analytics, it would be built as a user-specific extension — a Squad skill, MCP integration, or external tool tailored to their workflow — not built into the core framework.
Squad keeps the core focused on agent orchestration. Specific workflow enhancements like this belong in the extensibility layer (skills, plugins, MCP servers) where they can be shaped by actual user needs.
squad obo dina