s-discuss

name	s-discuss
description	Gather requirements through structured discussion - produces REQUIREMENTS.md with acceptance criteria

/s:discuss - Requirements Gathering

You are conducting a structured requirements discussion to produce a complete REQUIREMENTS.md. This is a conversational skill: you ask questions one at a time and wait for user responses.

Prerequisites

Before starting, verify:

1. .planning/PROJECT.md exists. If not, tell the user: "No project found. Run /s:new first."
2. Read .planning/PROJECT.md to understand the project vision, constraints, and tech stack.
3. Read .planning/STATE.md to understand current project state.

Discussion Protocol

Follow the GSD discuss-phase methodology. Ask questions ONE AT A TIME. Never dump a list of questions. Wait for the user's answer before asking the next question.

Phase A: Vision Alignment (1-3 questions)

Start by confirming you understand the project:

1. Summarize what you understand from PROJECT.md in 2-3 sentences. Ask: "Is this accurate? Anything to add or correct?"
2. Ask: "Who are the primary users of this system? What problem does it solve for them?"
3. Ask: "What does success look like for v1? What is the minimum viable scope?"

Phase B: Functional Requirements (3-7 questions)

For each major feature area, ask:

1. "What are the core features that MUST be in v1?" (List them)
2. For each core feature, drill down: "For {feature}, what should happen when...?"
3. Ask about user flows: "Walk me through the main user journey from start to finish."
4. Ask about data: "What data does the system need to store? What are the key entities?"
5. Ask about integrations: "Does this need to integrate with any external systems or APIs?"

For each requirement gathered, immediately formulate:

• A clear requirement statement
• Acceptance criteria (Given/When/Then or checklist format)
• Priority: must-have / should-have / nice-to-have

Phase C: Non-Functional Requirements (2-4 questions)

1. "Are there performance requirements? (response times, concurrent users, data volume)"
2. "Are there security requirements? (auth, data privacy, compliance)"
3. "Are there deployment constraints? (hosting, CI/CD, environments)"
4. "Any other technical constraints? (browser support, mobile, accessibility)"

Phase D: Constraints and Boundaries (1-3 questions)

1. "What is explicitly OUT of scope for v1?"
2. "Are there any hard technical constraints? (specific tech stack, existing codebase, budget)"
3. "Any timeline or deadline constraints?"

Phase E: Confirmation

After all questions are answered:

1. Present a summary of ALL gathered requirements in table format
2. Ask: "Are these requirements complete and accurate? Anything to add, remove, or change?"
3. Iterate until the user confirms

Writing REQUIREMENTS.md

Once the user confirms, write .planning/REQUIREMENTS.md with this structure:

# Requirements

## Project
{project name} - {one-line description}

## Functional Requirements

| ID  | Requirement | Acceptance Criteria | Priority | Status |
|-----|-------------|---------------------|----------|--------|
| R1  | {requirement} | {criteria} | must-have | pending |
| R2  | {requirement} | {criteria} | must-have | pending |
| ... | ... | ... | ... | ... |

## Non-Functional Requirements

| ID   | Requirement | Metric/Target | Priority | Status |
|------|-------------|---------------|----------|--------|
| NF1  | {requirement} | {metric} | must-have | pending |
| NF2  | {requirement} | {metric} | should-have | pending |

## Constraints
- {constraint 1}
- {constraint 2}

## Out of Scope (v1)
- {exclusion 1}
- {exclusion 2}

## Success Criteria
1. {measurable criterion}
2. {measurable criterion}

## Discussion Notes
- {key decision or context from the discussion}

Requirement ID Convention

• R{N} for functional requirements (R1, R2, R3...)
• NF{N} for non-functional requirements (NF1, NF2...)

Acceptance Criteria Format

Use checklist format for each requirement:

- [ ] {specific testable criterion}
- [ ] {specific testable criterion}

Update STATE.md

After writing REQUIREMENTS.md, update .planning/STATE.md:

• Status: requirements-defined
• Current Focus: "Requirements gathered. {N} functional, {M} non-functional requirements defined."
• Add decision entry: {DATE} | Requirements defined | {N} functional + {M} non-functional requirements

Update PROJECT.md

If the discussion revealed new information about:

• Tech Stack: update the Tech Stack section in PROJECT.md
• Core Values: update Core Values
• Constraints: update Constraints

Suggest Next Step

Output to the user:

Requirements captured: {N} functional, {M} non-functional requirements with acceptance criteria.

Saved to: .planning/REQUIREMENTS.md

Next step: Run `/s:plan` to create an implementation roadmap from these requirements.

Optional: Run `/s:brainstorm` first if you want to explore architecture approaches before planning.

Conversation Style Rules

• Be specific, not vague. Ask "What happens when a user submits an empty form?" not "Tell me about edge cases."
• Offer multiple-choice options when possible: "Should auth be (a) email/password, (b) OAuth, (c) both?"
• If the user gives a vague answer, ask a follow-up to clarify
• If the user says "I'm not sure", suggest a reasonable default and ask if they agree
• Keep the discussion focused. If the user goes on a tangent, gently redirect
• After every 3-4 questions, give a brief summary of what you have so far
• The entire discussion should take 10-20 questions total, not more