/spdd-story

Decompose high-level feature requirements into structured, business-focused development stories. Each story is independently deliverable, scoped to 1-5 days of work, and includes concrete acceptance criteria written in business language. Stories are split according to the INVEST principle and serve as input for the SPDD workflow (/spdd-analysis → /spdd-reasons-canvas → /spdd-generate). This command focuses on the "What" and "For whom" — technical analysis and implementation details are left to downstream SPDD phases.

Input: The argument after /spdd-story is a business requirement description or file reference.

Input can be provided in two ways:

1. Text description: Direct text describing the feature or requirement
2. File/folder reference: Using @ to reference files or folders containing requirements

Examples:

# File reference
/spdd-story @requirements/team-management-feature.md

# Text description
/spdd-story Implement team management API with CRUD operations, member management, and role-based access control

# Combined
/spdd-story @requirements/team-management.md additionally needs invitation flow and audit logging

Steps

1. Validate and consolidate business input

   a. If no input provided, use the AskUserQuestion tool (open-ended, no preset options) to ask:

   "Please provide the business requirement document or description for story generation (you can use text, @file references, or both)."

   IMPORTANT: Do NOT proceed without business input.

   b. If input contains @ file/folder references:

   • Read ALL referenced files completely using the Read tool
   • For folder references, read all relevant files within the folder
   • Consolidate all file contents into a unified business context

   c. Combine all context sources:

   • Merge text descriptions with file contents
   • Preserve the complete information from all sources — do NOT summarize or truncate

   d. Context Integrity Check:

   • Verify all @ references were successfully read
   • If any file cannot be read, report the error and ask user to provide alternative
   • Confirm the consolidated context contains sufficient information to proceed

2. Scan existing stories for context

   Do NOT explore the codebase — that is /spdd-analysis's responsibility. Only gather enough context to avoid duplication and determine numbering.

   a. List existing stories:

   • List files in requirements/ directory (if exists)
   • Read existing stories to understand numbering conventions and scope boundaries

   b. Identify coverage gaps:

   • Note which features and operations are already covered by existing stories
   • Ensure new stories do not duplicate or conflict with existing ones

   c. Determine next available story number:

   • Extract the highest [User-story-N] number from existing filenames
   • New stories start from N+1

3. Abstract task analysis and INVEST evaluation

   Before creating any stories, analyze the feature at an abstract level.

   a. Identify the abstract task:

   ### Abstract Task: "[Feature Name]"
   
   **Analysis Dimensions**:
   - **Core Responsibility**: [What is the primary purpose of this feature]
   - **Primary Operations**: [List the main operations: create, query, update, delete, list, etc.]
   - **Key Constraints**: [Data uniqueness, permissions, associations, business rules]
   - **Technical Complexity**: [Low/Medium/High — standard CRUD, complex business logic, etc.]
   - **Business Complexity**: [Low/Medium/High — multiple query scenarios, cascading effects, etc.]
   

   b. INVEST compliance check:

   ### INVEST Evaluation:
   - ✅/❌ **Independent**: [Can this be developed, tested, and deployed independently?]
   - ✅/❌ **Negotiable**: [Can design details be discussed with the team?]
   - ✅/❌ **Valuable**: [Does this provide clear business value?]
   - ✅/❌ **Estimable**: [Can the team accurately estimate the effort?]
   - ✅/❌ **Small**: [Can it be completed in 1-2 sprints?]
   - ✅/❌ **Testable**: [Are there clear acceptance criteria?]
   
   **Conclusion**: [Needs splitting / Ready as-is]