@zeyue0329/xiaoma-cli 1.12.0 → 1.15.0

package/src/core/tasks/xiaoma-create-prd/steps-c/step-05-domain.md

@@ -1,194 +0,0 @@
-# Step 5: Domain-Specific Requirements (Optional)
-
-**Progress: Step 5 of 13** - Next: Innovation Focus
-
-## STEP GOAL:
-
-For complex domains only that have a mapping in ../data/domain-complexity.csv, explore domain-specific constraints, compliance requirements, and technical considerations that shape the product.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product-focused PM facilitator collaborating with an expert peer
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise
-
-### Step-Specific Rules:
-
-- 🎯 This step is OPTIONAL - only needed for complex domains
-- 🚫 SKIP if domain complexity is "low" from step-02
-- 💬 APPROACH: Natural conversation to discover domain-specific needs
-- 🎯 Focus on constraints, compliance, and domain patterns
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Check domain complexity from step-02 classification first
-- ⚠️ If complexity is "low", offer to skip this step
-- ⚠️ Present A/P/C menu after domain requirements defined (or skipped)
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Domain classification from step-02 is available
-- If complexity is low, this step may be skipped
-- Domain CSV data provides complexity reference
-- Focus on domain-specific constraints, not general requirements
-
-## YOUR TASK:
-
-For complex domains, explore what makes this domain special:
-- **Compliance requirements** - regulations, standards, certifications
-- **Technical constraints** - security, privacy, integration requirements
-- **Domain patterns** - common patterns, best practices, anti-patterns
-- **Risks and mitigations** - what could go wrong, how to prevent it
-
-## DOMAIN DISCOVERY SEQUENCE:
-
-### 1. Check Domain Complexity
-
-**Review classification from step-02:**
-
-- What's the domain complexity level? (low/medium/high)
-- What's the specific domain? (healthcare, fintech, education, etc.)
-
-**If complexity is LOW:**
-
-Offer to skip:
-"The domain complexity from our discovery is low. We may not need deep domain-specific requirements. Would you like to:
-- [C] Skip this step and move to Innovation
-- [D] Do domain exploration anyway"
-
-**If complexity is MEDIUM or HIGH:**
-
-Proceed with domain exploration.
-
-### 2. Load Domain Reference Data
-
-**Attempt subprocess data lookup:**
-
-"Your task: Lookup data in ../data/domain-complexity.csv
-
-**Search criteria:**
-- Find row where domain matches {{domainFromStep02}}
-
-**Return format:**
-Return ONLY the matching row as a YAML-formatted object with these fields:
-domain, complexity, typical_concerns, compliance_requirements
-
-**Do NOT return the entire CSV - only the matching row.**"
-
-**Graceful degradation (if Task tool unavailable):**
-- Load the CSV file directly
-- Find the matching row manually
-- Extract required fields
-- Understand typical concerns and compliance requirements
-
-### 3. Explore Domain-Specific Concerns
-
-**Start with what you know:**
-
-Acknowledge the domain and explore what makes it complex:
-- What regulations apply? (HIPAA, PCI-DSS, GDPR, SOX, etc.)
-- What standards matter? (ISO, NIST, domain-specific standards)
-- What certifications are needed? (security, privacy, domain-specific)
-- What integrations are required? (EMR systems, payment processors, etc.)
-
-**Explore technical constraints:**
-- Security requirements (encryption, audit logs, access control)
-- Privacy requirements (data handling, consent, retention)
-- Performance requirements (real-time, batch, latency)
-- Availability requirements (uptime, disaster recovery)
-
-### 4. Document Domain Requirements
-
-**Structure the requirements around key concerns:**
-
-```markdown
-### Compliance & Regulatory
-- [Specific requirements]
-
-### Technical Constraints
-- [Security, privacy, performance needs]
-
-### Integration Requirements
-- [Required systems and data flows]
-
-### Risk Mitigations
-- [Domain-specific risks and how to address them]
-```
-
-### 5. Validate Completeness
-
-**Check with the user:**
-
-"Are there other domain-specific concerns we should consider? For [this domain], what typically gets overlooked?"
-
-### N. Present MENU OPTIONS
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue - Save and Proceed to Innovation (Step 6 of 13)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `xiaoma-advanced-elicitation` skill, and when finished redisplay the menu
-- IF P: Invoke the `xiaoma-party-mode` skill, and when finished redisplay the menu
-- IF C: Save content to {outputFile}, update frontmatter, then read fully and follow: ./step-06-innovation.md
-- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#n-present-menu-options)
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT
-
-When user selects 'C', append to `{outputFile}`:
-
-```markdown
-## Domain-Specific Requirements
-
-{{discovered domain requirements}}
-```
-
-If step was skipped, append nothing and proceed.
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN [C continue option] is selected and [content saved or skipped], will you then read fully and follow: `./step-06-innovation.md` to explore innovation.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Domain complexity checked before proceeding
-- Offered to skip if complexity is low
-- Natural conversation exploring domain concerns
-- Compliance, technical, and integration requirements identified
-- Domain-specific risks documented with mitigations
-- User validated completeness
-- Content properly saved (or step skipped) when C selected
-
-### ❌ SYSTEM FAILURE:
-
-- Not checking domain complexity first
-- Not offering to skip for low-complexity domains
-- Missing critical compliance requirements
-- Not exploring technical constraints
-- Not asking about domain-specific risks
-- Being generic instead of domain-specific
-- Proceeding without user validation
-
-**Master Rule:** This step is OPTIONAL for simple domains. For complex domains, focus on compliance, constraints, and domain patterns. Natural conversation, not checklists.

package/src/core/tasks/xiaoma-create-prd/steps-c/step-06-innovation.md

@@ -1,211 +0,0 @@
-# Step 6: Innovation Discovery
-
-**Progress: Step 6 of 11** - Next: Project Type Analysis
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on detecting and exploring innovative aspects of the product
-- 🎯 OPTIONAL STEP: Only proceed if innovation signals are detected
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating innovation content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- Project type from step-02 is available for innovation signal matching
-- Project-type CSV data will be loaded in this step
-- Focus on detecting genuine innovation, not forced creativity
-
-## OPTIONAL STEP CHECK:
-
-Before proceeding with this step, scan for innovation signals:
-
-- Listen for language like "nothing like this exists", "rethinking how X works"
-- Check for project-type innovation signals from CSV
-- Look for novel approaches or unique combinations
-- If no innovation detected, skip this step
-
-## YOUR TASK:
-
-Detect and explore innovation patterns in the product, focusing on what makes it truly novel and how to validate the innovative aspects.
-
-## INNOVATION DISCOVERY SEQUENCE:
-
-### 1. Load Project-Type Innovation Data
-
-Load innovation signals specific to this project type:
-
-- Load `../data/project-types.csv` completely
-- Find the row where `project_type` matches detected type from step-02
-- Extract `innovation_signals` (semicolon-separated list)
-- Extract `web_search_triggers` for potential innovation research
-
-### 2. Listen for Innovation Indicators
-
-Monitor conversation for both general and project-type-specific innovation signals:
-
-#### General Innovation Language:
-
-- "Nothing like this exists"
-- "We're rethinking how [X] works"
-- "Combining [A] with [B] for the first time"
-- "Novel approach to [problem]"
-- "No one has done [concept] before"
-
-#### Project-Type-Specific Signals (from CSV):
-
-Match user descriptions against innovation_signals for their project_type:
-
-- **api_backend**: "API composition;New protocol"
-- **mobile_app**: "Gesture innovation;AR/VR features"
-- **saas_b2b**: "Workflow automation;AI agents"
-- **developer_tool**: "New paradigm;DSL creation"
-
-### 3. Initial Innovation Screening
-
-Ask targeted innovation discovery questions:
-- Guide exploration of what makes the product innovative
-- Explore if they're challenging existing assumptions
-- Ask about novel combinations of technologies/approaches
-- Identify what hasn't been done before
-- Understand which aspects feel most innovative
-
-### 4. Deep Innovation Exploration (If Detected)
-
-If innovation signals are found, explore deeply:
-
-#### Innovation Discovery Questions:
-- What makes it unique compared to existing solutions?
-- What assumption are you challenging?
-- How do we validate it works?
-- What's the fallback if it doesn't?
-- Has anyone tried this before?
-
-#### Market Context Research:
-
-If relevant innovation detected, consider web search for context:
-Use `web_search_triggers` from project-type CSV:
-`[web_search_triggers] {concept} innovations {date}`
-
-### 5. Generate Innovation Content (If Innovation Detected)
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## Innovation & Novel Patterns
-
-### Detected Innovation Areas
-
-[Innovation patterns identified based on conversation]
-
-### Market Context & Competitive Landscape
-
-[Market context and research based on conversation]
-
-### Validation Approach
-
-[Validation methodology based on conversation]
-
-### Risk Mitigation
-
-[Innovation risks and fallbacks based on conversation]
-```
-
-### 6. Present MENU OPTIONS (Only if Innovation Detected)
-
-Present the innovation content for review, then display menu:
-- Show identified innovative aspects (using structure from section 5)
-- Highlight differentiation from existing solutions
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of conversation
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Project Type Analysis (Step 7 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `xiaoma-advanced-elicitation` skill with the current innovation content, process the enhanced innovation insights that come back, ask user "Accept these improvements to the innovation analysis? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF P: Invoke the `xiaoma-party-mode` skill with the current innovation content, process the collaborative innovation exploration and ideation, ask user "Accept these changes to the innovation analysis? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-07-project-type.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## NO INNOVATION DETECTED:
-
-If no genuine innovation signals are found after exploration:
-- Acknowledge that no clear innovation signals were found
-- Note this is fine - many successful products are excellent executions of existing concepts
-- Ask if they'd like to try finding innovative angles or proceed
-
-Display: "**Select:** [A] Advanced Elicitation - Let's try to find innovative angles [C] Continue - Skip innovation section and move to Project Type Analysis (Step 7 of 11)"
-
-### Menu Handling Logic:
-- IF A: Proceed with content generation anyway, then return to menu
-- IF C: Skip this step, then read fully and follow: ./step-07-project-type.md
-
-### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 5.
-
-## SUCCESS METRICS:
-
-✅ Innovation signals properly detected from user conversation
-✅ Project-type innovation signals used to guide discovery
-✅ Genuine innovation explored (not forced creativity)
-✅ Validation approach clearly defined for innovative aspects
-✅ Risk mitigation strategies identified
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Forced innovation when none genuinely exists
-❌ Not using project-type innovation signals from CSV
-❌ Missing market context research for novel concepts
-❌ Not addressing validation approach for innovative features
-❌ Creating innovation theater without real innovative aspects
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## SKIP CONDITIONS:
-
-Skip this step and load `./step-07-project-type.md` if:
-
-- No innovation signals detected in conversation
-- Product is incremental improvement rather than breakthrough
-- User confirms innovation exploration is not needed
-- Project-type CSV has no innovation signals for this type
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document (or step is skipped), load `./step-07-project-type.md`.
-
-Remember: Do NOT proceed to step-07 until user explicitly selects 'C' from the A/P/C menu (or confirms step skip)!

package/src/core/tasks/xiaoma-create-prd/steps-c/step-07-project-type.md

@@ -1,222 +0,0 @@
-# Step 7: Project-Type Deep Dive
-
-**Progress: Step 7 of 11** - Next: Scoping
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on project-type specific requirements and technical considerations
-- 🎯 DATA-DRIVEN: Use CSV configuration to guide discovery
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating project-type content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- Project type from step-02 is available for configuration loading
-- Project-type CSV data will be loaded in this step
-- Focus on technical and functional requirements specific to this project type
-
-## YOUR TASK:
-
-Conduct project-type specific discovery using CSV-driven guidance to define technical requirements.
-
-## PROJECT-TYPE DISCOVERY SEQUENCE:
-
-### 1. Load Project-Type Configuration Data
-
-**Attempt subprocess data lookup:**
-
-"Your task: Lookup data in ../data/project-types.csv
-
-**Search criteria:**
-- Find row where project_type matches {{projectTypeFromStep02}}
-
-**Return format:**
-Return ONLY the matching row as a YAML-formatted object with these fields:
-project_type, key_questions, required_sections, skip_sections, innovation_signals
-
-**Do NOT return the entire CSV - only the matching row.**"
-
-**Graceful degradation (if Task tool unavailable):**
-- Load the CSV file directly
-- Find the matching row manually
-- Extract required fields:
-  - `key_questions` (semicolon-separated list of discovery questions)
-  - `required_sections` (semicolon-separated list of sections to document)
-  - `skip_sections` (semicolon-separated list of sections to skip)
-  - `innovation_signals` (already explored in step-6)
-
-### 2. Conduct Guided Discovery Using Key Questions
-
-Parse `key_questions` from CSV and explore each:
-
-#### Question-Based Discovery:
-
-For each question in `key_questions` from CSV:
-
-- Ask the user naturally in conversational style
-- Listen for their response and ask clarifying follow-ups
-- Connect answers to product value proposition
-
-**Example Flow:**
-If key_questions = "Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?"
-
-Ask naturally:
-
-- "What are the main endpoints your API needs to expose?"
-- "How will you handle authentication and authorization?"
-- "What data formats will you support for requests and responses?"
-
-### 3. Document Project-Type Specific Requirements
-
-Based on user answers to key_questions, synthesize comprehensive requirements:
-
-#### Requirement Categories:
-
-Cover the areas indicated by `required_sections` from CSV:
-
-- Synthesize what was discovered for each required section
-- Document specific requirements, constraints, and decisions
-- Connect to product differentiator when relevant
-
-#### Skip Irrelevant Sections:
-
-Skip areas indicated by `skip_sections` from CSV to avoid wasting time on irrelevant aspects.
-
-### 4. Generate Dynamic Content Sections
-
-Parse `required_sections` list from the matched CSV row. For each section name, generate corresponding content:
-
-#### Common CSV Section Mappings:
-
-- "endpoint_specs" or "endpoint_specification" → API endpoints documentation
-- "auth_model" or "authentication_model" → Authentication approach
-- "platform_reqs" or "platform_requirements" → Platform support needs
-- "device_permissions" or "device_features" → Device capabilities
-- "tenant_model" → Multi-tenancy approach
-- "rbac_matrix" or "permission_matrix" → Permission structure
-
-#### Template Variable Strategy:
-
-- For sections matching common template variables: generate specific content
-- For sections without template matches: include in main project_type_requirements
-- Hybrid approach balances template structure with CSV-driven flexibility
-
-### 5. Generate Project-Type Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## [Project Type] Specific Requirements
-
-### Project-Type Overview
-
-[Project type summary based on conversation]
-
-### Technical Architecture Considerations
-
-[Technical architecture requirements based on conversation]
-
-[Dynamic sections based on CSV and conversation]
-
-### Implementation Considerations
-
-[Implementation specific requirements based on conversation]
-```
-
-### 6. Present MENU OPTIONS
-
-Present the project-type content for review, then display menu:
-
-"Based on our conversation and best practices for this product type, I've documented the {project_type}-specific requirements for {{project_name}}.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from section 5]
-
-**What would you like to do?**"
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Scoping (Step 8 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `xiaoma-advanced-elicitation` skill with the current project-type content, process the enhanced technical insights that come back, ask user "Accept these improvements to the technical requirements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF P: Invoke the `xiaoma-party-mode` skill with the current project-type requirements, process the collaborative technical expertise and validation, ask user "Accept these changes to the technical requirements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-08-scoping.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from previous steps.
-
-## SUCCESS METRICS:
-
-✅ Project-type configuration loaded and used effectively
-✅ All key questions from CSV explored with user input
-✅ Required sections generated per CSV configuration
-✅ Skip sections properly avoided to save time
-✅ Technical requirements connected to product value
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Not loading or using project-type CSV configuration
-❌ Missing key questions from CSV in discovery process
-❌ Not generating required sections per CSV configuration
-❌ Documenting sections that should be skipped per CSV
-❌ Creating generic content without project-type specificity
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## PROJECT-TYPE EXAMPLES:
-
-**For api_backend:**
-
-- Focus on endpoints, authentication, data schemas, rate limiting
-- Skip visual design and user journey sections
-- Generate API specification documentation
-
-**For mobile_app:**
-
-- Focus on platform requirements, device permissions, offline mode
-- Skip API endpoint documentation unless needed
-- Generate mobile-specific technical requirements
-
-**For saas_b2b:**
-
-- Focus on multi-tenancy, permissions, integrations
-- Skip mobile-first considerations unless relevant
-- Generate enterprise-specific requirements
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-08-scoping.md` to define project scope.
-
-Remember: Do NOT proceed to step-08 (Scoping) until user explicitly selects 'C' from the A/P/C menu and content is saved!