fraim-framework 2.0.65 → 2.0.67

package/dist/registry/ai-manager-rules/customer-development-phases/phase4-inventory-compilation.md

@@ -0,0 +1,206 @@
+# Phase 4: Inventory Compilation
+
+## Objective
+Create the final structured prospect database in CSV format with all qualified prospects, contact information, and outreach recommendations.
+
+## CSV Structure
+
+### Required Columns
+1. **Name**: Full name of prospect
+2. **Platform Found**: Where they were discovered
+3. **Profile URL**: Link to their profile/post
+4. **Contact Information**: Email, LinkedIn, phone (if available)
+5. **Pain Points Identified**: Specific problems they expressed
+6. **Relevance Score**: 1-10 qualification score
+7. **Discovery Context**: Quote or context of their pain point
+8. **Follow-up Priority**: High/Medium/Low
+9. **Notes**: Additional relevant information
+10. **Date Found**: When they were discovered
+11. **Industry**: Their industry/sector
+12. **Job Title**: Their professional role
+13. **Company**: Their organization
+14. **Location**: Geographic location
+15. **Engagement Level**: High/Medium/Low activity level
+
+### Optional Enhancement Columns
+16. **Company Size**: Startup/SMB/Enterprise
+17. **Contact Method**: Preferred outreach channel
+18. **Mutual Connections**: LinkedIn connections in common
+19. **Recent Activity**: Last relevant post/activity
+20. **Outreach Status**: Not contacted/Contacted/Responded/etc.
+
+## Compilation Process
+
+### Step 1: Data Consolidation
+1. **Gather All Qualified Prospects** from Phase 3 (score 6+)
+2. **Remove Duplicates** found across multiple platforms
+3. **Verify Data Completeness** for each prospect
+4. **Standardize Formats** for consistency
+
+### Step 2: Priority Assignment
+
+#### High Priority (Top 20 prospects)
+- Score 8-10
+- Recent activity (within 30 days)
+- Clear contact information
+- Strong pain point match
+- Decision-making authority
+
+#### Medium Priority (Next 30-50 prospects)
+- Score 6-7
+- Moderate activity levels
+- Some contact information
+- Good pain point match
+- Some influence or authority
+
+#### Low Priority (Remaining qualified prospects)
+- Score 6+
+- Lower activity or older posts
+- Limited contact information
+- Partial pain point match
+- Future potential
+
+### Step 3: Contact Information Enhancement
+For high and medium priority prospects:
+1. **Email Discovery**:
+   - Check company websites for email patterns
+   - Use professional email formats (first.last@company.com)
+   - Verify with email validation tools if available
+
+2. **LinkedIn Optimization**:
+   - Ensure LinkedIn URLs are complete
+   - Check for premium messaging availability
+   - Note mutual connections
+
+3. **Alternative Contacts**:
+   - Twitter handles for social outreach
+   - Company phone numbers
+   - Professional websites or blogs
+
+### Step 4: Outreach Strategy Documentation
+
+#### For Each High Priority Prospect:
+- **Recommended Approach**: Email, LinkedIn, Twitter DM, etc.
+- **Message Angle**: Which pain point to address first
+- **Timing**: Best time/day to reach out
+- **Follow-up Plan**: Sequence if no initial response
+
+#### Message Personalization Notes:
+- Specific pain point they mentioned
+- Platform where you found them
+- Relevant context from their posts
+- Value proposition alignment
+
+## Quality Assurance
+
+### Data Validation Checklist
+- [ ] All required columns populated
+- [ ] No duplicate entries
+- [ ] Consistent formatting across all fields
+- [ ] Valid URLs for profiles and contacts
+- [ ] Relevance scores properly calculated
+- [ ] Priority assignments logical
+
+### Content Review
+- [ ] Pain points accurately captured
+- [ ] Discovery context provides clear value
+- [ ] Contact information verified where possible
+- [ ] Notes provide actionable insights
+- [ ] Outreach recommendations are specific
+
+## Summary Report Generation
+
+### Executive Summary
+- **Total Prospects Discovered**: [Number]
+- **Qualified Prospects**: [Number scoring 6+]
+- **High Priority Prospects**: [Top 20]
+- **Contact Information Success Rate**: [Percentage with contact info]
+- **Platform Breakdown**: [Numbers by platform]
+
+### Platform Performance
+- **LinkedIn**: [Number] prospects, [Average score]
+- **Reddit**: [Number] prospects, [Average score]
+- **X (Twitter)**: [Number] prospects, [Average score]
+- **Facebook**: [Number] prospects, [Average score]
+- **Forums**: [Number] prospects, [Average score]
+- **Web Search**: [Number] prospects, [Average score]
+
+### Outreach Recommendations
+1. **Immediate Action** (Next 7 days): Top 10 prospects
+2. **Short-term Follow-up** (Next 30 days): Next 20 prospects
+3. **Long-term Pipeline** (Next 90 days): Remaining qualified prospects
+
+## File Management
+
+### File Naming Convention
+`users-to-target-{YYYY-MM-DD-HHMM}.csv`
+
+Example: `users-to-target-2026-02-03-1430.csv`
+
+### File Location
+`docs/customer-development/users-to-target-{timestamp}.csv`
+
+### Backup and Version Control
+- Save working versions during compilation
+- Create backup before final export
+- Include timestamp in filename for version tracking
+
+## Coaching Guidance
+
+### For Founders Overwhelmed by Data:
+"Focus on the top 20 prospects first. Quality outreach to fewer people is better than mass outreach to everyone."
+
+### For Founders Wanting More Prospects:
+"This is a great start. You can always run the workflow again to find more prospects as your understanding of the market evolves."
+
+### For Founders Questioning Quality:
+"Remember, these are people who have already expressed the problem you solve. That's much better than cold outreach to random prospects."
+
+## Success Validation
+
+### Minimum Success Criteria:
+- [ ] 50+ qualified prospects in final CSV
+- [ ] 70%+ relevance score average
+- [ ] Contact information for 60%+ of prospects
+- [ ] Top 20 prospects clearly identified
+- [ ] Outreach strategy documented
+
+### Optimal Success Criteria:
+- [ ] 100+ qualified prospects in final CSV
+- [ ] 80%+ relevance score average
+- [ ] Contact information for 75%+ of prospects
+- [ ] Clear next steps for top 50 prospects
+- [ ] Platform-specific insights documented
+
+## Common Issues and Solutions
+
+### Low Contact Information Success Rate:
+- Spend more time on LinkedIn profile research
+- Use company websites to find email patterns
+- Consider social media outreach as alternative
+
+### Too Many Low-Scoring Prospects:
+- Revisit qualification criteria
+- Be more selective in Phase 3
+- Focus on recent activity and clear pain points
+
+### Duplicate Prospects Across Platforms:
+- Use name and company matching to identify duplicates
+- Keep the entry with the best contact information
+- Note multiple platforms in discovery context
+
+## Time Estimate
+1-2 hours to compile and format final prospect inventory.
+
+## Deliverables
+1. **Final CSV File**: Complete prospect inventory
+2. **Summary Report**: Statistics and recommendations
+3. **Top 20 Priority List**: Immediate action items
+4. **Outreach Templates**: Suggested message frameworks
+
+## Workflow Completion
+Once Phase 4 is complete, the founder has:
+- Systematic prospect discovery process
+- Qualified lead database
+- Clear outreach priorities
+- Actionable next steps for customer development

package/dist/registry/ai-manager-rules/design-phases/design-completeness-review.md

@@ -0,0 +1,73 @@
+# Phase: Design-Completeness-Review
+
+## INTENT
+To verify that the technical design addresses all aspects of the functional specification, including the validation plan and testing strategy.
+
+## OUTCOME
+Confirmation that:
+- Design addresses all functional spec requirements
+- Validation plan from spec is reflected in design
+- Testing strategy covers all specified scenarios
+- Technical approach enables spec validation
+- Design is ready for implementation
+
+## WORKFLOW
+
+### Step 1: Load Functional Specification
+- Read the functional specification document from `docs/feature specs/{issue_number}-*.md`
+- Extract all requirements, user workflows, and validation criteria
+- Note any UI mockups and interaction patterns
+
+### Step 2: Verify Spec Requirements Coverage
+- Check that design addresses each functional requirement
+- Confirm technical approach supports all user workflows from spec
+- Verify API design enables the specified user experience
+- Ensure data models support all spec requirements
+
+### Step 3: Validation Plan Alignment
+**Critical**: The spec's validation plan must be implementable with this design
+- Review validation scenarios from functional spec
+- Confirm design provides necessary APIs/interfaces for validation
+- Check that testing strategy covers all validation scenarios
+- Verify design enables browser testing (if UI changes)
+- Ensure backend validation points are accessible
+
+### Step 4: Technical Feasibility Check
+- Confirm design is technically sound and implementable
+- Check that all spec requirements can be built with this approach
+- Verify integration points are well-defined
+- Assess if design enables the spec's success criteria
+
+## VALIDATION
+
+### Phase Complete When:
+- ✅ All functional spec requirements addressed in design
+- ✅ Validation plan from spec is implementable with this design
+- ✅ Testing strategy covers all spec scenarios
+- ✅ Technical approach is sound and feasible
+- ✅ Design enables spec success criteria
+- ✅ Ready for implementation phase
+
+### Phase Incomplete If:
+- ❌ Functional spec requirements not addressed
+- ❌ Validation plan not implementable with current design
+- ❌ Testing strategy insufficient for spec scenarios
+- ❌ Technical approach infeasible or unclear
+- ❌ Design doesn't enable spec success criteria
+
+### Report Back:
+```javascript
+seekMentoring({
+  workflowType: "design",
+  issueNumber: "{issue_number}",
+  currentPhase: "design-completeness-review", 
+  status: "complete",
+  evidence: {
+    specRequirementsCovered: true,
+    validationPlanImplementable: true,
+    testingStrategySufficient: true,
+    technicallyFeasible: true,
+    functionalSpecPath: "docs/feature specs/{issue_number}-*.md"
+  }
+})
+```

package/dist/registry/ai-manager-rules/design-phases/design-design.md

@@ -0,0 +1,145 @@
+# Phase: Design-Design
+
+## INTENT
+To create a comprehensive technical design that translates the feature specification into implementable architecture, APIs, and technical solutions.
+
+## OUTCOME
+A complete technical design document that:
+- Translates spec requirements into technical architecture
+- Defines APIs, data models, and system interactions
+- Identifies technical risks and mitigation strategies
+- Provides clear implementation guidance
+- Includes technical validation criteria
+
+## PRINCIPLES
+- **Spec-Driven**: Design directly addresses specification requirements
+- **Implementation-Ready**: Provides clear technical guidance
+- **Risk-Aware**: Identifies and mitigates technical risks
+- **Validation-Focused**: Includes technical validation criteria
+- **Template-Compliant**: Follows RFC template structure
+
+## WORKFLOW
+
+### Step 1: Get Repository Context and Issue Details
+
+**GitHub Repository Context**: Before using GitHub MCP tools, read the local `.fraim/config.json` file to get the repository context:
+- Use `git.repoOwner` for the GitHub repository owner
+- Use `git.repoName` for the GitHub repository name
+- These values are required for GitHub MCP API calls (owner/repo parameters)
+
+**Read Issue Details**: Use GitHub MCP tools to get the complete issue information:
+- Read the full issue description, title, and labels
+- Check for linked documents (specs, RFCs, design docs)
+- Review any comments or discussion threads
+- Note acceptance criteria and requirements
+- Identify if there's an existing specification document
+
+### Step 2: Load Template and Specification
+- Call `get_fraim_file({ path: "templates/specs/TECHSPEC-TEMPLATE.md" })` (for features)
+- Call `get_fraim_file({ path: "templates/specs/BUGSPEC-TEMPLATE.md" })` (for bugs)
+- Read the completed specification document from previous phase
+- Call `get_fraim_file({ path: "rules/spike-first-development.md" })`
+
+### Step 3: Check for PR Feedback
+
+**CRITICAL**: Before creating design, check for feedback:
+- **PR Review Feedback**: `docs/evidence/{issue_number}-design-feedback.md`
+
+**If PR feedback exists:**
+- **MUST address all UNADDRESSED items** before proceeding
+- Update feedback file after addressing each item
+- Change status from UNADDRESSED to ADDRESSED with resolution details
+- Cannot skip or defer feedback items
+- Phase cannot complete until all feedback is addressed
+
+**PR Feedback File Format** (if exists):
+```markdown
+### Comment X - ADDRESSED
+- **Author**: reviewer_name
+- **Comment**: Original feedback
+- **Status**: ADDRESSED
+- **Resolution**: How you addressed this feedback
+```
+
+### Step 4: Analyze Specification Requirements
+- Extract all technical requirements from specification
+- Identify system components that need modification
+- Determine API changes or additions needed
+- Note any performance or scalability considerations
+- List integration points with existing systems
+
+### Step 5: Create Technical Design Document
+- Create RFC file at `docs/rfcs/{issue_number}-{kebab-case-title}.md`
+- Follow appropriate template structure (TECHSPEC or BUGSPEC)
+- Include all required sections:
+  - Problem statement (from spec)
+  - Technical requirements
+  - Proposed solution architecture
+  - API design and data models
+  - Implementation plan
+  - Testing strategy
+  - Risk assessment and mitigation
+  - Alternative approaches considered
+
+### Step 6: Design System Architecture
+- Define component interactions and data flow
+- Specify API endpoints and request/response formats
+- Design database schema changes (if needed)
+- Plan integration with existing systems
+- Consider scalability and performance implications
+
+### Step 7: Identify Technical Risks
+- List unfamiliar technologies or patterns
+- Note complex integrations or dependencies
+- Identify performance bottlenecks
+- Consider security implications
+- Plan risk mitigation strategies
+
+### Step 8: Apply Labels
+- Label the GitHub issue with `phase:design`
+- This will trigger automatic PR creation/update
+
+## VALIDATION
+
+### Phase Complete When:
+- ✅ Technical design document created using appropriate template
+- ✅ All specification requirements addressed technically
+- ✅ System architecture clearly defined
+- ✅ API design and data models specified
+- ✅ Technical risks identified and mitigation planned
+- ✅ Implementation plan provides clear guidance
+- ✅ Testing strategy defined
+- ✅ **PR feedback addressed** (if `docs/evidence/{issue_number}-design-feedback.md` exists)
+- ✅ Issue labeled with `phase:design`
+
+### Phase Incomplete If:
+- ❌ Design document missing or incomplete
+- ❌ Template structure not followed
+- ❌ Specification requirements not addressed
+- ❌ Architecture unclear or missing
+- ❌ Technical risks not identified
+- ❌ Implementation guidance insufficient
+- ❌ **PR feedback not addressed** (UNADDRESSED items remain in feedback file)
+
+### Report Back:
+When you complete this phase, call:
+
+```javascript
+seekMentoring({
+  workflowType: "design",
+  issueNumber: "{issue_number}",
+  currentPhase: "design-design", 
+  status: "complete",
+  evidence: {
+    designDocument: "docs/rfcs/{issue_number}-{title}.md",
+    templateUsed: "TECHSPEC-TEMPLATE.md",
+    architectureComponents: ["API layer", "Database schema", "UI components"],
+    technicalRisks: ["Integration with legacy system", "Performance at scale"],
+    issueLabeled: "phase:design"
+  },
+  findings: {
+    keyDecisions: ["Use REST API", "PostgreSQL for data storage", "React components"],
+    riskMitigation: ["Spike legacy integration", "Load testing plan"]
+  }
+})
+```

package/dist/registry/ai-manager-rules/design-phases/design.md

@@ -0,0 +1,108 @@
+# Phase: Design
+
+## INTENT
+To create a comprehensive technical design that translates the feature specification into implementable architecture, APIs, and technical solutions.
+
+## OUTCOME
+A complete technical design document that:
+- Translates spec requirements into technical architecture
+- Defines APIs, data models, and system interactions
+- Identifies technical risks and mitigation strategies
+- Provides clear implementation guidance
+- Includes technical validation criteria
+
+## PRINCIPLES
+- **Spec-Driven**: Design directly addresses specification requirements
+- **Implementation-Ready**: Provides clear technical guidance
+- **Risk-Aware**: Identifies and mitigates technical risks
+- **Validation-Focused**: Includes technical validation criteria
+- **Template-Compliant**: Follows RFC template structure
+
+## WORKFLOW
+
+### Step 1: Load Template and Specification
+- Call `get_fraim_file({ path: "templates/specs/TECHSPEC-TEMPLATE.md" })` (for features)
+- Call `get_fraim_file({ path: "templates/specs/BUGSPEC-TEMPLATE.md" })` (for bugs)
+- Read the completed specification document from previous phase
+- Call `get_fraim_file({ path: "rules/spike-first-development.md" })`
+
+### Step 2: Analyze Specification Requirements
+- Extract all technical requirements from specification
+- Identify system components that need modification
+- Determine API changes or additions needed
+- Note any performance or scalability considerations
+- List integration points with existing systems
+
+### Step 3: Create Technical Design Document
+- Create RFC file at `docs/rfcs/{issue_number}-{kebab-case-title}.md`
+- Follow appropriate template structure (TECHSPEC or BUGSPEC)
+- Include all required sections:
+  - Problem statement (from spec)
+  - Technical requirements
+  - Proposed solution architecture
+  - API design and data models
+  - Implementation plan
+  - Testing strategy
+  - Risk assessment and mitigation
+  - Alternative approaches considered
+
+### Step 4: Design System Architecture
+- Define component interactions and data flow
+- Specify API endpoints and request/response formats
+- Design database schema changes (if needed)
+- Plan integration with existing systems
+- Consider scalability and performance implications
+
+### Step 5: Identify Technical Risks
+- List unfamiliar technologies or patterns
+- Note complex integrations or dependencies
+- Identify performance bottlenecks
+- Consider security implications
+- Plan risk mitigation strategies
+
+### Step 6: Apply Labels
+- Label the GitHub issue with `phase:design`
+- This will trigger automatic PR creation/update
+
+## VALIDATION
+
+### Phase Complete When:
+- ✅ Technical design document created using appropriate template
+- ✅ All specification requirements addressed technically
+- ✅ System architecture clearly defined
+- ✅ API design and data models specified
+- ✅ Technical risks identified and mitigation planned
+- ✅ Implementation plan provides clear guidance
+- ✅ Testing strategy defined
+- ✅ Issue labeled with `phase:design`
+
+### Phase Incomplete If:
+- ❌ Design document missing or incomplete
+- ❌ Template structure not followed
+- ❌ Specification requirements not addressed
+- ❌ Architecture unclear or missing
+- ❌ Technical risks not identified
+- ❌ Implementation guidance insufficient
+
+### Report Back:
+When you complete this phase, call:
+
+```javascript
+seekCoachingOnNextStep({
+  workflowType: "design",
+  issueNumber: "{issue_number}",
+  currentPhase: "design", 
+  status: "complete",
+  evidence: {
+    designDocument: "docs/rfcs/{issue_number}-{title}.md",
+    templateUsed: "TECHSPEC-TEMPLATE.md",
+    architectureComponents: ["API layer", "Database schema", "UI components"],
+    technicalRisks: ["Integration with legacy system", "Performance at scale"],
+    issueLabeled: "phase:design"
+  },
+  findings: {
+    keyDecisions: ["Use REST API", "PostgreSQL for data storage", "React components"],
+    riskMitigation: ["Spike legacy integration", "Load testing plan"]
+  }
+})
+```

package/dist/registry/ai-manager-rules/design-phases/finalize.md

@@ -0,0 +1,60 @@
+# Phase: Finalize
+
+## INTENT
+To prepare completed work for human review by setting proper labels, creating/updating PR, and documenting evidence.
+
+## OUTCOME
+Work is ready for human review with:
+- Proper issue labels applied
+- PR created/updated with work
+- Evidence documented
+- Clean handoff to next phase or review
+
+## WORKFLOW
+
+### Step 1: Apply Issue Labels
+- Remove current phase label (e.g., `phase:spec`, `phase:design`, `phase:impl`)
+- Add `status:needs-review` label
+- Keep any other relevant labels
+
+### Step 2: Create/Update Pull Request
+- Ensure PR exists for the feature branch
+- Update PR title to reflect completed work
+- Update PR description with summary of work completed
+- Link to relevant documents (specs, designs, evidence)
+
+### Step 3: Document Evidence
+- Create evidence file at `docs/evidence/{issue_number}-{workflow}-evidence.md`
+- Document key decisions made
+- List deliverables created
+- Note any recommendations for next phase
+
+### Step 4: Prepare Handoff
+- Ensure all work is committed to git
+- Verify documentation is complete
+- Confirm work is ready for human review
+
+## VALIDATION
+
+### Phase Complete When:
+- ✅ Issue labels updated (`status:needs-review`)
+- ✅ PR created/updated with work summary
+- ✅ Evidence documented
+- ✅ All work committed to git
+- ✅ Ready for human review
+
+### Report Back:
+```javascript
+seekCoachingOnNextStep({
+  workflowType: "{workflow_type}",
+  issueNumber: "{issue_number}",
+  currentPhase: "finalize", 
+  status: "complete",
+  evidence: {
+    labelsApplied: ["status:needs-review"],
+    prUpdated: true,
+    evidenceDocumented: "docs/evidence/{issue_number}-{workflow}-evidence.md",
+    workCommitted: true
+  }
+})
+```