Product Enhancement: Native Session Ask-Tracking #364

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)

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 → agent → 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

1. 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?
2. 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?
3. Phase 3 config surface: Should this live in squad.config.ts only, or also in .squad/config.json for non-SDK users?
4. 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 @tamir for opinions on phasing and approach.

Reported by: Dina Berry
Source: Session conversation analyzing Squad product UX gap