fraim-framework 2.0.67 → 2.0.68

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

@@ -1,206 +0,0 @@
-# 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

@@ -1,73 +0,0 @@
-# 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

@@ -1,145 +0,0 @@
-# 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

@@ -1,108 +0,0 @@
-# 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

@@ -1,60 +0,0 @@
-# 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
-  }
-})
-```