Add codebase-first assumption-driven alternative to the interview-style discuss-phase. New `workflow.discuss_mode: "assumptions"` config routes to a separate workflow that spawns a gsd-assumptions-analyzer agent to read 5-15 codebase files, surface assumptions with evidence, and ask only for corrections (~2-4 interactions vs ~15-20). - New gsd-assumptions-analyzer agent for deep codebase analysis - New discuss-phase-assumptions.md workflow (15 steps) - Command-level routing via dual @reference + process gate - Identical CONTEXT.md output — downstream agents unaffected - Existing discuss-phase.md workflow untouched (zero diff) - Mode-aware plan-phase gate and progress display - User documentation and integration tests - Update agent count and list in copilot-install tests (17 → 18) Closes #637 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
4.2 KiB
name, description, argument-hint, allowed-tools
| name | description | argument-hint | allowed-tools | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| gsd:discuss-phase | Gather phase context through adaptive questioning before planning. Use --auto to skip interactive questions (Claude picks recommended defaults). | <phase> [--auto] [--batch] [--analyze] [--text] |
|
How it works:
- Load prior context (PROJECT.md, REQUIREMENTS.md, STATE.md, prior CONTEXT.md files)
- Scout codebase for reusable assets and patterns
- Analyze phase — skip gray areas already decided in prior phases
- Present remaining gray areas — user selects which to discuss
- Deep-dive each selected area until satisfied
- Create CONTEXT.md with decisions that guide research and planning
Output: {phase_num}-CONTEXT.md — decisions clear enough that downstream agents can act without asking the user again
<execution_context>
@/.claude/get-shit-done/workflows/discuss-phase.md
@/.claude/get-shit-done/workflows/discuss-phase-assumptions.md
@~/.claude/get-shit-done/templates/context.md
</execution_context>
Context files are resolved in-workflow using init phase-op and roadmap/state tool calls.
If DISCUSS_MODE is "assumptions": Follow the discuss-phase-assumptions.md workflow instead of the steps below. Skip all remaining steps in this process section.
If DISCUSS_MODE is "discuss" (or unset, or any other value): Continue with the steps below (current behavior).
- Validate phase number (error if missing or not in roadmap)
- Check if CONTEXT.md exists (offer update/view/skip if yes)
- Load prior context — Read PROJECT.md, REQUIREMENTS.md, STATE.md, and all prior CONTEXT.md files
- Scout codebase — Find reusable assets, patterns, and integration points
- Analyze phase — Check prior decisions, skip already-decided areas, generate remaining gray areas
- Present gray areas — Multi-select: which to discuss? Annotate with prior decisions + code context
- Deep-dive each area — 4 questions per area, code-informed options, Context7 for library choices
- Write CONTEXT.md — Sections match areas discussed + code_context section
- Offer next steps (research or plan)
CRITICAL: Scope guardrail
- Phase boundary from ROADMAP.md is FIXED
- Discussion clarifies HOW to implement, not WHETHER to add more
- If user suggests new capabilities: "That's its own phase. I'll note it for later."
- Capture deferred ideas — don't lose them, don't act on them
Domain-aware gray areas: Gray areas depend on what's being built. Analyze the phase goal:
- Something users SEE → layout, density, interactions, states
- Something users CALL → responses, errors, auth, versioning
- Something users RUN → output format, flags, modes, error handling
- Something users READ → structure, tone, depth, flow
- Something being ORGANIZED → criteria, grouping, naming, exceptions
Generate 3-4 phase-specific gray areas, not generic categories.
Probing depth:
- Ask 4 questions per area before checking
- "More questions about [area], or move to next? (Remaining: [list unvisited areas])"
- Show remaining unvisited areas so user knows what's still ahead
- If more → ask 4 more, check again
- After all areas → "Ready to create context?"
Do NOT ask about (Claude handles these):
- Technical implementation
- Architecture choices
- Performance concerns
- Scope expansion
<success_criteria>
- Prior context loaded and applied (no re-asking decided questions)
- Gray areas identified through intelligent analysis
- User chose which areas to discuss
- Each selected area explored until satisfied
- Scope creep redirected to deferred ideas
- CONTEXT.md captures decisions, not vague vision
- User knows next steps </success_criteria>