npm - @pennyfarthing/core - Versions diffs - 7.4.1 → 7.5.0 - Mend

@pennyfarthing/core 7.4.1 → 7.5.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (890) hide show

package/pennyfarthing-dist/workflows/prd/steps-c/step-03-success.md DELETED Viewed

@@ -1,226 +0,0 @@
----
-name: 'step-03-success'
-description: 'Define comprehensive success criteria covering user, business, and technical success'
-# File References
-nextStepFile: './step-04-journeys.md'
-outputFile: '{planning_artifacts}/prd.md'
-# Task References
-advancedElicitationTask: '{project_root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-partyModeWorkflow: '{project_root}/_bmad/core/workflows/party-mode/workflow.md'
----
-# Step 3: Success Criteria Definition
-**Progress: Step 3 of 11** - Next: User Journey Mapping
-## 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 defining what winning looks like for this product
-- 🎯 COLLABORATIVE discovery, not assumption-based goal setting
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-## EXECUTION PROTOCOLS:
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating success criteria 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
-- Executive Summary and Project Classification already exist in document
-- Input documents from step-01 are available (product briefs, research, brainstorming)
-- No additional data files needed for this step
-- Focus on measurable, specific success criteria
-- LEVERAGE existing input documents to inform success criteria
-## YOUR TASK:
-Define comprehensive success criteria that cover user success, business success, and technical success, using input documents as a foundation while allowing user refinement.
-## SUCCESS DISCOVERY SEQUENCE:
-### 1. Begin Success Definition Conversation
-**Check Input Documents for Success Indicators:**
-Analyze product brief, research, and brainstorming documents for success criteria already mentioned.
-**If Input Documents Contain Success Criteria:**
-Guide user to refine existing success criteria:
-- Acknowledge what's already documented in their materials
-- Extract key success themes from brief, research, and brainstorming
-- Help user identify gaps and areas for expansion
-- Probe for specific, measurable outcomes: When do users feel delighted/relieved/empowered?
-- Ask about emotional success moments and completion scenarios
-- Explore what "worth it" means beyond what's already captured
-**If No Success Criteria in Input Documents:**
-Start with user-centered success exploration:
-- Guide conversation toward defining what "worth it" means for users
-- Ask about the moment users realize their problem is solved
-- Explore specific user outcomes and emotional states
-- Identify success "aha!" moments and completion scenarios
-- Focus on user experience of success first
-### 2. Explore User Success Metrics
-Listen for specific user outcomes and help make them measurable:
-- Guide from vague to specific: NOT "users are happy" → "users complete [key action] within [timeframe]"
-- Ask about emotional success: "When do they feel delighted/relieved/empowered?"
-- Identify success moments: "What's the 'aha!' moment?"
-- Define completion scenarios: "What does 'done' look like for the user?"
-### 3. Define Business Success
-Transition to business metrics:
-- Guide conversation to business perspective on success
-- Explore timelines: What does 3-month success look like? 12-month success?
-- Identify key business metrics: revenue, user growth, engagement, or other measures?
-- Ask what specific metric would indicate "this is working"
-- Understand business success from their perspective
-### 4. Challenge Vague Metrics
-Push for specificity on business metrics:
-- "10,000 users" → "What kind of users? Doing what?"
-- "99.9% uptime" → "What's the real concern - data loss? Failed payments?"
-- "Fast" → "How fast, and what specifically needs to be fast?"
-- "Good adoption" → "What percentage adoption by when?"
-### 5. Connect to Product Differentiator
-Tie success metrics back to what makes the product special:
-- Connect success criteria to the product's unique differentiator
-- Ensure metrics reflect the specific value proposition
-- Adapt success criteria to domain context:
-  - Consumer: User love, engagement, retention
-  - B2B: ROI, efficiency, adoption
-  - Developer tools: Developer experience, community
-  - Regulated: Compliance, safety, validation
-  - GovTech: Government compliance, accessibility, procurement
-### 6. Smart Scope Negotiation
-Guide scope definition through success lens:
-- Help user distinguish MVP (must work to be useful) from growth (competitive) and vision (dream)
-- Guide conversation through three scope levels:
-  1. MVP: What's essential for proving the concept?
-  2. Growth: What makes it competitive?
-  3. Vision: What's the dream version?
-- Challenge scope creep conversationally: Could this wait until after launch? Is this essential for MVP?
-- For complex domains: Ensure compliance minimums are included in MVP
-### 7. Generate Success Criteria Content
-Prepare the content to append to the document:
-#### Content Structure:
-When saving to document, append these Level 2 and Level 3 sections:
-```markdown
-## Success Criteria
-### User Success
-[Content about user success criteria based on conversation]
-### Business Success
-[Content about business success metrics based on conversation]
-### Technical Success
-[Content about technical success requirements based on conversation]
-### Measurable Outcomes
-[Content about specific measurable outcomes based on conversation]
-## Product Scope
-### MVP - Minimum Viable Product
-[Content about MVP scope based on conversation]
-### Growth Features (Post-MVP)
-[Content about growth features based on conversation]
-### Vision (Future)
-[Content about future vision based on conversation]
-```
-### 8. Present MENU OPTIONS
-Present the success criteria content for user review, then display menu:
-- Show the drafted success criteria and scope definition (using structure from section 7)
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of the conversation
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to User Journey Mapping (Step 4 of 11)"
-#### Menu Handling Logic:
-- IF A: Execute {advancedElicitationTask} with the current success criteria content, process the enhanced success metrics that come back, ask user "Accept these improvements to the success criteria? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF P: Execute {partyModeWorkflow} with the current success criteria, process the collaborative improvements to metrics and scope, ask user "Accept these changes to the success criteria? (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 load, read entire file, then execute {nextStepFile}
-- 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 step 7.
-## SUCCESS METRICS:
-✅ User success criteria clearly identified and made measurable
-✅ Business success metrics defined with specific targets
-✅ Success criteria connected to product differentiator
-✅ Scope properly negotiated (MVP, Growth, Vision)
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-## FAILURE MODES:
-❌ Accepting vague success metrics without pushing for specificity
-❌ Not connecting success criteria back to product differentiator
-❌ Missing scope negotiation and leaving it undefined
-❌ Generating content without real user input on what success looks like
-❌ 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
-## DOMAIN CONSIDERATIONS:
-If working in regulated domains (healthcare, fintech, govtech):
-- Include compliance milestones in success criteria
-- Add regulatory approval timelines to MVP scope
-- Consider audit requirements as technical success metrics
-## NEXT STEP:
-After user selects 'C' and content is saved to document, load `./step-04-journeys.md` to map user journeys.
-Remember: Do NOT proceed to step-04 until user explicitly selects 'C' from the A/P/C menu and content is saved!

package/pennyfarthing-dist/workflows/prd/steps-c/step-04-journeys.md DELETED Viewed

@@ -1,213 +0,0 @@
----
-name: 'step-04-journeys'
-description: 'Map ALL user types that interact with the system with narrative story-based journeys'
-# File References
-nextStepFile: './step-05-domain.md'
-outputFile: '{planning_artifacts}/prd.md'
-# Task References
-advancedElicitationTask: '{project_root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-partyModeWorkflow: '{project_root}/_bmad/core/workflows/party-mode/workflow.md'
----
-# Step 4: User Journey Mapping
-**Progress: Step 4 of 11** - Next: Domain Requirements
-## 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 mapping ALL user types that interact with the system
-- 🎯 CRITICAL: No journey = no functional requirements = product doesn't exist
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-## EXECUTION PROTOCOLS:
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating journey 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
-- Success criteria and scope already defined
-- Input documents from step-01 are available (product briefs with user personas)
-- Every human interaction with the system needs a journey
-## YOUR TASK:
-Create compelling narrative user journeys that leverage existing personas from product briefs and identify additional user types needed for comprehensive coverage.
-## JOURNEY MAPPING SEQUENCE:
-### 1. Leverage Existing Users & Identify Additional Types
-**Check Input Documents for Existing Personas:**
-Analyze product brief, research, and brainstorming documents for user personas already defined.
-**If User Personas Exist in Input Documents:**
-Guide user to build on existing personas:
-- Acknowledge personas found in their product brief
-- Extract key persona details and backstories
-- Leverage existing insights about their needs
-- Prompt to identify additional user types beyond those documented
-- Suggest additional user types based on product context (admins, moderators, support, API consumers, internal ops)
-- Ask what additional user types should be considered
-**If No Personas in Input Documents:**
-Start with comprehensive user type discovery:
-- Guide exploration of ALL people who interact with the system
-- Consider beyond primary users: admins, moderators, support staff, API consumers, internal ops
-- Ask what user types should be mapped for this specific product
-- Ensure comprehensive coverage of all system interactions
-### 2. Create Narrative Story-Based Journeys
-For each user type, create compelling narrative journeys that tell their story:
-#### Narrative Journey Creation Process:
-**If Using Existing Persona from Input Documents:**
-Guide narrative journey creation:
-- Use persona's existing backstory from brief
-- Explore how the product changes their life/situation
-- Craft journey narrative: where do we meet them, how does product help them write their next chapter?
-**If Creating New Persona:**
-Guide persona creation with story framework:
-- Name: realistic name and personality
-- Situation: What's happening in their life/work that creates need?
-- Goal: What do they desperately want to achieve?
-- Obstacle: What's standing in their way?
-- Solution: How does the product solve their story?
-**Story-Based Journey Mapping:**
-Guide narrative journey creation using story structure:
-- **Opening Scene**: Where/how do we meet them? What's their current pain?
-- **Rising Action**: What steps do they take? What do they discover?
-- **Climax**: Critical moment where product delivers real value
-- **Resolution**: How does their situation improve? What's their new reality?
-Encourage narrative format with specific user details, emotional journey, and clear before/after contrast
-### 3. Guide Journey Exploration
-For each journey, facilitate detailed exploration:
-- What happens at each step specifically?
-- What could go wrong? What's the recovery path?
-- What information do they need to see/hear?
-- What's their emotional state at each point?
-- Where does this journey succeed or fail?
-### 4. Connect Journeys to Requirements
-After each journey, explicitly state:
-- This journey reveals requirements for specific capability areas
-- Help user see how different journeys create different feature sets
-- Connect journey needs to concrete capabilities (onboarding, dashboards, notifications, etc.)
-### 5. Aim for Comprehensive Coverage
-Guide toward complete journey set:
-- **Primary user** - happy path (core experience)
-- **Primary user** - edge case (different goal, error recovery)
-- **Secondary user** (admin, moderator, support, etc.)
-- **API consumer** (if applicable)
-Ask if additional journeys are needed to cover uncovered user types
-### 6. Generate User Journey Content
-Prepare the content to append to the document:
-#### Content Structure:
-When saving to document, append these Level 2 and Level 3 sections:
-```markdown
-## User Journeys
-[All journey narratives based on conversation]
-### Journey Requirements Summary
-[Summary of capabilities revealed by journeys based on conversation]
-```
-### 7. Present MENU OPTIONS
-Present the user journey content for review, then display menu:
-- Show the mapped user journeys (using structure from section 6)
-- Highlight how each journey reveals different capabilities
-- 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 Domain Requirements (Step 5 of 11)"
-#### Menu Handling Logic:
-- IF A: Execute {advancedElicitationTask} with the current journey content, process the enhanced journey insights that come back, ask user "Accept these improvements to the user journeys? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF P: Execute {partyModeWorkflow} with the current journeys, process the collaborative journey improvements and additions, ask user "Accept these changes to the user journeys? (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 load, read entire file, then execute {nextStepFile}
-- 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 step 6.
-## SUCCESS METRICS:
-✅ Existing personas from product briefs leveraged when available
-✅ All user types identified (not just primary users)
-✅ Rich narrative storytelling for each persona and journey
-✅ Complete story-based journey mapping with emotional arc
-✅ Journey requirements clearly connected to capabilities needed
-✅ Minimum 3-4 compelling narrative journeys covering different user types
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-## FAILURE MODES:
-❌ Ignoring existing personas from product briefs
-❌ Only mapping primary user journeys and missing secondary users
-❌ Creating generic journeys without rich persona details and narrative
-❌ Missing emotional storytelling elements that make journeys compelling
-❌ Missing critical decision points and failure scenarios
-❌ Not connecting journeys to required capabilities
-❌ Not having enough journey diversity (admin, support, API, etc.)
-❌ 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
-## JOURNEY TYPES TO ENSURE:
-**Minimum Coverage:**
-1. **Primary User - Success Path**: Core experience journey
-2. **Primary User - Edge Case**: Error recovery, alternative goals
-3. **Admin/Operations User**: Management, configuration, monitoring
-4. **Support/Troubleshooting**: Help, investigation, issue resolution
-5. **API/Integration** (if applicable): Developer/technical user journey
-## NEXT STEP:
-After user selects 'C' and content is saved to document, load `./step-05-domain.md`.
-Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!

package/pennyfarthing-dist/workflows/prd/steps-c/step-05-domain.md DELETED Viewed

@@ -1,207 +0,0 @@
----
-name: 'step-05-domain'
-description: 'Explore domain-specific requirements for complex domains (optional step)'
-# File References
-nextStepFile: './step-06-innovation.md'
-outputFile: '{planning_artifacts}/prd.md'
-domainComplexityCSV: '../data/domain-complexity.csv'
-# Task References
-advancedElicitationTask: '{project_root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-partyModeWorkflow: '{project_root}/_bmad/core/workflows/party-mode/workflow.md'
----
-# 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 {domainComplexityCSV}, 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}`
-### 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 {domainComplexityCSV}
-**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: Execute {advancedElicitationTask}, and when finished redisplay the menu
-- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
-- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
-- 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 load and read fully `{nextStepFile}` 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.