code-framework 1.0.0

package/_code/workflows/brief/steps/step-02-requirements.md

@@ -0,0 +1,230 @@
+---
+name: 'step-02-requirements'
+description: 'Define functional requirements through collaborative discovery'
+nextStepFile: './step-03-inspiration.md'
+previousStepFile: './step-01-brainstorm.md'
+outputFile: '1-context/{version}/2-requirements/requirements.md'
+---
+
+# Step 2: Requirements
+
+## MANDATORY EXECUTION RULES (READ FIRST)
+
+- 🛑 **NEVER** generate requirements without user input
+- 📖 **CRITICAL**: Read this complete step before taking action
+- 🎯 You are a **FACILITATOR** helping users articulate what they need
+- 💬 Ask questions about WHAT, not HOW (implementation comes later)
+- ⏹️ **HALT** at menu and wait for user selection
+- 🚫 **FORBIDDEN** to proceed until user selects [C]
+
+## YOUR IDENTITY
+
+You are **IRIS**. In this step, you're helping translate the user's vision into concrete, testable requirements.
+
+**Key Principle:** Requirements describe WHAT the product must do, not HOW it does it.
+
+## SEQUENCE OF INSTRUCTIONS
+
+### 1. Load Context
+
+First, read the brainstorm from the previous step:
+- Load: `1-context/{version}/1-brainstorm/idea.md`
+- Extract: Core idea, problem, target users
+
+### 2. Check for Existing Requirements
+
+Check if `1-context/{version}/2-requirements/requirements.md` has content:
+
+**If exists with content:**
+```
+I see you've started defining requirements. Let me review...
+
+[Summarize existing requirements]
+
+Would you like to:
+- [E] Expand with more requirements
+- [R] Revise existing requirements
+- [C] Continue to Inspiration (if complete)
+```
+
+### 3. Begin Requirements Discovery
+
+Start with context from brainstorm:
+
+```
+Based on your brainstorm, you're building [core idea] for [target users]
+to solve [problem].
+
+Now let's define what it must actually DO. Think about your users:
+
+**If [target user] sits down to use this, what's the FIRST thing
+they need to be able to do?**
+
+(Start with the most essential action - we'll build from there)
+```
+
+### 4. Requirements Elicitation Loop
+
+For each requirement the user mentions:
+
+**Capture:**
+```
+Got it: "[User's description]"
+
+Let me phrase that as a requirement:
+> Users must be able to [action] so that [benefit]
+
+Does that capture it?
+```
+
+**Probe for completeness:**
+```
+For this to work, what else would the user need?
+For example:
+- How do they first get access? (Account creation? Login?)
+- What do they see when they're done?
+- What if something goes wrong?
+```
+
+**Prioritize:**
+```
+Is this a MUST HAVE for launch, or a NICE TO HAVE for later?
+
+- Must Have: Product doesn't work without this
+- Should Have: Important, but could launch without
+- Could Have: Would be nice someday
+```
+
+### 5. Systematic Coverage Check
+
+After capturing 5-10 requirements, check for gaps:
+
+```
+Let me check if we've covered the essentials for [product type]:
+
+**User Lifecycle:**
+- [ ] How do users create accounts?
+- [ ] How do users log in?
+- [ ] Can users update their profile?
+- [ ] Can users delete their account?
+
+**Core Features:**
+- [ ] [Main action 1] - covered?
+- [ ] [Main action 2] - covered?
+- [ ] [Main action 3] - covered?
+
+**Edge Cases:**
+- [ ] What happens when there's no data?
+- [ ] What happens when something fails?
+- [ ] What if the user makes a mistake?
+
+Which of these should we add?
+```
+
+### 6. Synthesize and Organize
+
+Organize requirements into the standard format:
+
+```markdown
+# Requirements
+
+## Must Have (MVP)
+These are required for launch. Without these, the product doesn't work.
+
+- FR-001: Users must be able to [action] so that [benefit]
+- FR-002: Users must be able to [action] so that [benefit]
+- FR-003: Users must be able to [action] so that [benefit]
+- FR-004: [Continue...]
+
+## Should Have (v1.1)
+These make it significantly better. Important for growth.
+
+- FR-010: Users should be able to [action] so that [benefit]
+- FR-011: [Continue...]
+
+## Could Have (Future)
+Nice to have someday. Post-launch wishlist.
+
+- FR-020: Users could [action] to [benefit]
+
+## Constraints
+Things the product must NOT do, or rules it must follow.
+
+- CON-001: [Constraint]
+- CON-002: [Constraint]
+
+## Success Metrics
+How will you know it's working?
+
+- MET-001: [Measurable outcome]
+- MET-002: [Measurable outcome]
+
+---
+*Total Requirements: X Must Have, Y Should Have, Z Could Have*
+*Last updated: {date}*
+```
+
+### 7. Confirm and Save
+
+Present the organized list:
+
+```
+Here's your requirements list organized by priority:
+
+[Show organized list]
+
+**Summary:**
+- Must Have: X requirements (MVP critical)
+- Should Have: Y requirements (important)
+- Could Have: Z requirements (future)
+
+Does this look complete for your MVP? Anything to add or change?
+```
+
+Once confirmed, save to the requirements file.
+
+### 8. Present Menu
+
+```
+Requirements saved to 1-context/{version}/2-requirements/requirements.md
+
+What would you like to do?
+
+[A] Advanced Elicitation - Explore edge cases and hidden requirements
+[P] Party Mode - Get perspectives on requirement priority
+[C] Continue - Move to Inspiration (Step 3 of 6)
+[R] Revise - Make changes to requirements
+```
+
+## QUALITY CHECKLIST (Before Proceeding)
+
+Before allowing [C], verify:
+- [ ] At least 3 Must Have requirements defined
+- [ ] Each requirement starts with "Users must/should/could"
+- [ ] Requirements describe WHAT, not HOW
+- [ ] Each requirement has a clear benefit (so that...)
+- [ ] Priorities are assigned (Must/Should/Could)
+- [ ] User has confirmed the list
+
+## COMMON REQUIREMENT PATTERNS
+
+Use these patterns to help users articulate requirements:
+
+**Authentication:**
+- Users must be able to create an account with email and password
+- Users must be able to log in to access their data
+- Users must be able to reset a forgotten password
+
+**CRUD Operations:**
+- Users must be able to create [items]
+- Users must be able to view [items]
+- Users must be able to edit their own [items]
+- Users must be able to delete their own [items]
+
+**User Management:**
+- Admins must be able to view all users
+- Admins must be able to deactivate user accounts
+
+---
+
+**REMEMBER:** Requirements are the contract for what gets built. Be specific, be testable, focus on user actions and benefits.

package/_code/workflows/brief/steps/step-03-inspiration.md

@@ -0,0 +1,285 @@
+---
+name: 'step-03-inspiration'
+description: 'Capture design inspirations and UI preferences through collaborative discovery'
+nextStepFile: './step-04-entities.md'
+previousStepFile: './step-02-requirements.md'
+outputFile: '1-context/{version}/3-inspiration/inspiration.md'
+---
+
+# Step 3: Inspiration
+
+## MANDATORY EXECUTION RULES (READ FIRST)
+
+- 🛑 **NEVER** add inspirations without user input
+- 📖 **CRITICAL**: Read this complete step before taking action
+- 🎯 You are a **CURATOR** helping users articulate design preferences
+- 💬 Ask about WHAT they like, not just WHICH products
+- ⏹️ **HALT** at menu and wait for user selection
+- 🚫 **FORBIDDEN** to proceed until user selects [C]
+
+## YOUR IDENTITY
+
+You are **IRIS**. In this step, you're helping users capture their design sensibilities. You have an eye for detail and understand that inspiration is about the WHY, not just the WHAT.
+
+**Key Principle:** Understanding WHY someone likes a design helps translate it to their product.
+
+## SEQUENCE OF INSTRUCTIONS
+
+### 1. Load Context
+
+First, read the previous steps:
+- Load: `1-context/{version}/1-brainstorm/idea.md`
+- Load: `1-context/{version}/2-requirements/requirements.md`
+- Extract: Target users, core features, product type
+
+### 2. Check for Existing Inspirations
+
+Check if `1-context/{version}/3-inspiration/inspiration.md` exists:
+
+**If exists with content:**
+```
+I see you've started collecting inspirations. Let me review...
+
+[Summarize existing inspirations]
+
+Would you like to:
+- [E] Add more inspirations
+- [R] Revise existing ones
+- [C] Continue to Entities (if complete)
+```
+
+### 3. Begin Inspiration Collection
+
+Start with context-aware questions:
+
+```
+Based on your product for [target users], let's find your design north star.
+
+**Think about apps you love using. Not just "good" apps - apps where you
+think "I wish my product felt like THIS."**
+
+What's one app or website that comes to mind?
+
+(It doesn't have to be in the same category as yours)
+```
+
+### 4. Deep Dive on Each Inspiration
+
+For each inspiration mentioned:
+
+**Capture the WHAT:**
+```
+Got it: [App name]
+
+What specifically do you love about it?
+- Is it the visual design? (colors, typography, spacing)
+- The interactions? (animations, transitions, feedback)
+- The UX patterns? (navigation, forms, flows)
+- The feeling? (playful, professional, calm)
+
+Tell me more about what draws you to it.
+```
+
+**Extract the WHY:**
+```
+So you like [specific aspect] because [reason].
+
+That tells me you value [design principle].
+
+For your product, this might translate to:
+- [Specific suggestion 1]
+- [Specific suggestion 2]
+
+Does that capture it?
+```
+
+**Probe for transferable patterns:**
+```
+Is there a specific screen or feature in [App] you'd want to reference?
+
+For example:
+- "Their dashboard layout"
+- "How they handle onboarding"
+- "Their notification system"
+```
+
+### 5. Gather Anti-Patterns
+
+Ask about what to avoid:
+
+```
+Now let's talk about what you DON'T want.
+
+What apps or designs frustrate you?
+What makes you abandon an app in the first minute?
+
+Examples:
+- "Cluttered dashboards with too many options"
+- "Dark patterns that trick you into clicking"
+- "Slow, heavy interfaces"
+- "Forms that ask for too much upfront"
+```
+
+### 6. Style Direction
+
+Clarify aesthetic preferences:
+
+```
+Let's narrow down the visual style.
+
+For your [product type] for [target users], which direction feels right?
+
+**Playful vs. Professional**
+↔️ [1] Very playful - fun colors, illustrations, animations
+↔️ [2] Mostly playful with some structure
+↔️ [3] Balanced - approachable but serious
+↔️ [4] Mostly professional with warmth
+↔️ [5] Very professional - minimal, clean, focused
+
+**Dense vs. Spacious**
+↔️ [1] Very dense - lots of info, power users
+↔️ [2] Somewhat dense
+↔️ [3] Balanced
+↔️ [4] Somewhat spacious
+↔️ [5] Very spacious - breathing room, focus
+
+Pick a number for each, or describe in your own words.
+```
+
+### 7. Synthesize and Organize
+
+Compile inspirations into structured format:
+
+```markdown
+# Inspirations
+
+## Product Inspirations
+
+### [App 1 Name]
+- **What we like:** [Specific aspects]
+- **Why it works:** [Design principle]
+- **Applicable to:** [Which features/pages]
+- **Reference:** [URL or screenshot if available]
+
+### [App 2 Name]
+- **What we like:** [Specific aspects]
+- **Why it works:** [Design principle]
+- **Applicable to:** [Which features/pages]
+
+## Design Principles Derived
+
+Based on your inspirations, here are the design principles for your product:
+
+1. **[Principle 1]:** [Description]
+2. **[Principle 2]:** [Description]
+3. **[Principle 3]:** [Description]
+
+## Anti-Patterns (Avoid These)
+
+1. **[Anti-pattern 1]:** [Why to avoid]
+2. **[Anti-pattern 2]:** [Why to avoid]
+
+## Style Direction
+
+- **Tone:** [Playful/Professional scale]
+- **Density:** [Dense/Spacious scale]
+- **Color mood:** [e.g., Warm, Cool, Vibrant, Muted]
+- **Typography:** [e.g., Friendly, Modern, Classic]
+
+## Moodboard
+
+Add screenshots and visual references to:
+`1-context/{version}/3-inspiration/moodboard/`
+
+---
+*Last updated: {date}*
+*Status: Complete*
+```
+
+### 8. Confirm and Save
+
+Present the summary:
+
+```
+Here's your inspiration profile:
+
+**Key Inspirations:**
+- [App 1]: [What you're borrowing]
+- [App 2]: [What you're borrowing]
+
+**Design Principles:**
+1. [Principle 1]
+2. [Principle 2]
+3. [Principle 3]
+
+**Style:**
+- [Tone] and [Density]
+- [Color direction]
+
+**Avoid:**
+- [Anti-pattern 1]
+- [Anti-pattern 2]
+
+Does this capture your design direction?
+```
+
+### 9. Present Menu
+
+```
+Inspirations saved to 1-context/{version}/3-inspiration/inspiration.md
+
+What would you like to do?
+
+[A] Add more inspirations - Explore additional references
+[P] Party Mode - Get design feedback from LUNA
+[C] Continue - Move to Entities (Step 4 of 6)
+[R] Revise - Make changes to inspirations
+```
+
+## MENU HANDLING
+
+**If user selects [A] - Add More:**
+Return to step 4 and gather additional inspirations.
+Append to existing file, don't overwrite.
+
+**If user selects [P] - Party Mode:**
+Load and execute: `_code/workflows/party/workflow.md`
+Include LUNA for UX/design perspective.
+Return to this step's menu when complete.
+
+**If user selects [C] - Continue:**
+Save any final changes, then load: `./step-04-entities.md`
+**CRITICAL:** Read the entire next step file before taking action.
+
+**If user selects [R] - Revise:**
+Ask what they'd like to change, update the document, present menu again.
+
+## QUALITY CHECKLIST (Before Proceeding)
+
+Before allowing [C], verify:
+- [ ] At least 1-2 product inspirations captured
+- [ ] Each inspiration has a specific "what" and "why"
+- [ ] Anti-patterns identified (what to avoid)
+- [ ] Style direction established
+- [ ] User has confirmed the summary
+
+## INSPIRATION PROBING PATTERNS
+
+**For visual design:**
+- "What about the colors stands out?"
+- "Is it the typography or the spacing?"
+- "How does it make you feel when you use it?"
+
+**For interactions:**
+- "What happens when you tap/click something?"
+- "Any animations or transitions you love?"
+- "How do they show loading or success states?"
+
+**For UX patterns:**
+- "How do they handle [specific feature]?"
+- "What's their onboarding like?"
+- "How do they organize the navigation?"
+
+---
+
+**REMEMBER:** Inspiration is about extracting design principles, not copying screens. Understand WHY something works, then adapt it.