agileflow 3.4.3 → 4.0.0-alpha.10

package/src/core/experts/mentor/workflow.md

@@ -1,184 +0,0 @@
----
-description: Plan, build, and improve {{DOMAIN}} feature with expertise-driven workflow
-argument-hint: <feature description>
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/{{DOMAIN}}/expertise.yaml
-  DOMAIN_PATTERN: "{{DOMAIN_GLOB_PATTERN}}"
----
-
-# {{DOMAIN_TITLE}} Expert: Plan → Build → Self-Improve
-
-You are executing a complete feature implementation with automatic knowledge capture. This workflow ensures you leverage existing expertise, execute efficiently, and capture learnings for future tasks.
-
-## CRITICAL: Three-Step Workflow
-
-**You MUST follow this exact sequence. Do not skip steps.**
-
----
-
-## Step 1: PLAN (Expertise-Informed)
-
-### 1.1 Load Your Expertise
-Read your expertise file at `{{EXPERTISE_FILE}}` FIRST.
-
-Extract from it:
-- Relevant file locations for this feature
-- Existing patterns you should follow
-- Relationships to consider
-- Recent learnings that might apply
-
-### 1.2 Validate Against Codebase
-Before planning, verify your expertise is accurate:
-- Check that referenced files still exist
-- Confirm patterns match current code
-- Note any discrepancies
-
-### 1.3 Create Implementation Plan
-Based on validated expertise, create a specific plan:
-
-```markdown
-## Implementation Plan
-
-### Files to Create/Modify
-1. [exact file path] - [what changes]
-2. [exact file path] - [what changes]
-
-### Pattern to Follow
-[Reference specific pattern from expertise]
-
-### Dependencies
-[What must exist before this work]
-
-### Validation
-[How to verify the implementation works]
-```
-
-**Output**: A detailed plan with exact file paths and specific changes.
-
----
-
-## Step 2: BUILD (Execute Plan)
-
-### 2.1 Pre-Build Verification
-Before making changes:
-- Ensure all dependencies from plan exist
-- Verify you have the required permissions/access
-- Check for any blocking issues
-
-### 2.2 Execute the Plan
-Follow your implementation plan exactly:
-- Create/modify files in the specified order
-- Apply patterns consistently
-- Add appropriate tests if applicable
-
-### 2.3 Capture Changes
-After building, document what changed:
-
-```bash
-# Capture the diff for self-improve
-git diff --name-only
-git diff HEAD
-```
-
-### 2.4 Validate Build
-Verify the implementation:
-- Run relevant tests
-- Check for type/lint errors
-- Verify the feature works as intended
-
-**Output**: Working code changes with captured diff.
-
-**On Failure**: Stop and report the error. Do NOT proceed to self-improve.
-
----
-
-## Step 3: SELF-IMPROVE (Update Expertise)
-
-**ONLY run this step if Step 2 succeeded.**
-
-### 3.1 Analyze What Changed
-Review the git diff and identify:
-- New files added to your domain
-- New patterns introduced
-- Relationships created or changed
-- Conventions established
-
-### 3.2 Update Expertise File
-Read and update `{{EXPERTISE_FILE}}`:
-
-**Update `files` section if:**
-- New files were added
-- Files were moved or renamed
-
-**Update `relationships` section if:**
-- New entities or relationships created
-- Cardinality changed
-
-**Update `patterns` section if:**
-- New implementation patterns used
-- Better approaches discovered
-
-**Update `conventions` section if:**
-- New naming conventions applied
-- New structural conventions established
-
-### 3.3 Add Learnings Entry
-**ALWAYS** add a new learnings entry:
-
-```yaml
-learnings:
-  - date: {{TODAY}}
-    insight: "Brief description of what was learned"
-    files_affected:
-      - path/to/file1
-      - path/to/file2
-    context: "Feature: {{argument}}"
-```
-
-### 3.4 Validate Updated Expertise
-Before saving:
-- [ ] All file paths exist
-- [ ] Relationships match code
-- [ ] `last_updated` is current
-- [ ] No duplicates added
-- [ ] File stays focused (<200 lines)
-
-### 3.5 Save Expertise
-Write the updated expertise.yaml file.
-
----
-
-## Error Handling
-
-### If Plan Step Fails
-- Report what information is missing
-- Suggest how to resolve (update expertise, provide context)
-- Do NOT proceed to build
-
-### If Build Step Fails
-- Report the specific error
-- Capture partial progress if any
-- Do NOT proceed to self-improve
-- Consider if expertise needs correction
-
-### If Self-Improve Step Fails
-- Report what couldn't be updated
-- Save what you can
-- Build step is still valid
-
----
-
-## Context Protection Notes
-
-This workflow is designed for context efficiency:
-- **Orchestrator**: Passes minimal data between steps
-- **Sub-agents**: Each step can run in isolated context if needed
-- **Token efficiency**: Expertise file provides compressed knowledge
-
-For large features, consider running each step as a separate sub-agent invocation.
-
----
-
-## Feature Request
-
-{{argument}}

package/src/core/experts/mobile/expertise.yaml

@@ -1,136 +0,0 @@
-# Mobile Expert - Domain Knowledge
-# This file is the agent's "mental model" of the mobile domain
-# AUTO-UPDATED by self-improve.md after completing work
-
-domain: mobile
-last_updated: 2025-12-21
-version: 1.1
-
-files:
-  react_native:
-    - path: src/mobile/
-      purpose: "React Native mobile app source"
-      key_exports: []
-      conventions: "Component files use PascalCase"
-    - path: src/mobile/screens/
-      purpose: "Screen components for navigation stacks"
-      conventions: "One screen per file, named *Screen.tsx"
-    - path: src/mobile/components/
-      purpose: "Reusable mobile UI components"
-      conventions: "Platform-agnostic when possible"
-    - path: src/mobile/navigation/
-      purpose: "React Navigation configuration"
-      conventions: "Stack and tab navigators defined here"
-    - path: src/mobile/hooks/
-      purpose: "Custom hooks for mobile features"
-      conventions: "use* prefix for hooks"
-    - path: src/mobile/services/
-      purpose: "Native module wrappers and platform services"
-      conventions: "Abstraction layer over native APIs"
-
-  flutter:
-    - path: lib/
-      purpose: "Flutter app source (if using Flutter)"
-      conventions: "snake_case for file names"
-    - path: lib/screens/
-      purpose: "Screen widgets"
-    - path: lib/widgets/
-      purpose: "Reusable widget components"
-
-  native_modules:
-    - path: ios/
-      purpose: "iOS native code and Xcode project"
-      conventions: "Swift preferred over Objective-C"
-    - path: android/
-      purpose: "Android native code and Gradle project"
-      conventions: "Kotlin preferred over Java"
-
-  configuration:
-    - path: app.json
-      purpose: "Expo/React Native app configuration"
-    - path: metro.config.js
-      purpose: "Metro bundler configuration"
-    - path: babel.config.js
-      purpose: "Babel transpiler configuration"
-    - path: pubspec.yaml
-      purpose: "Flutter dependencies (if using Flutter)"
-
-relationships:
-  - parent: screens
-    child: components
-    type: uses
-    notes: "Screens compose reusable components"
-  - parent: screens
-    child: navigation
-    type: registered_in
-    notes: "Screens registered in navigation stacks"
-  - parent: services
-    child: native_modules
-    type: wraps
-    notes: "Services abstract native module APIs"
-  - parent: hooks
-    child: services
-    type: uses
-    notes: "Hooks use services for platform features"
-
-patterns:
-  - name: Platform-Agnostic Components
-    description: "Write components that work on both iOS and Android without platform checks"
-    location: src/mobile/components/
-    example: "Use Platform.select() only when necessary"
-
-  - name: Navigation Stack Pattern
-    description: "Use stack navigators for hierarchical screen flows"
-    location: src/mobile/navigation/
-    example: "createStackNavigator() for push/pop screens"
-
-  - name: Native Module Abstraction
-    description: "Wrap native modules in service layer for testability"
-    location: src/mobile/services/
-    example: "CameraService wraps react-native-camera"
-
-  - name: Responsive Mobile Design
-    description: "Handle different screen sizes and orientations"
-    location: src/mobile/components/
-    example: "Use Dimensions API or useWindowDimensions hook"
-
-  - name: Gesture Handling
-    description: "Use gesture responder system for touch interactions"
-    location: src/mobile/components/
-    example: "PanGestureHandler for swipe gestures"
-
-conventions:
-  - "Test on real iOS and Android devices, not just simulators"
-  - "Use platform-agnostic code first, platform-specific only when necessary"
-  - "Abstract native modules through service layer"
-  - "Handle safe area insets (notch, home indicator)"
-  - "Optimize bundle size (<2MB target)"
-  - "Handle offline/slow network gracefully"
-  - "Support both light and dark modes"
-  - "Minimum touch target size: 44x44 points"
-  - "Handle keyboard appearance and avoidance"
-
-performance_targets:
-  bundle_size: "<2MB compressed"
-  startup_time: "<2s cold start"
-  frame_rate: "60fps for animations"
-  memory: "<200MB typical usage"
-  battery: "Minimal background activity"
-
-# Learnings are AUTO-UPDATED by self-improve.md
-# Do not edit manually - let the agent learn from experience
-learnings:
-  - id: agileflow-context
-    date: 2025-12-21
-    learning: "AgileFlow is a Node.js CLI tool, not a mobile application. This mobile expert assists with mobile development projects that use AgileFlow, but the AgileFlow codebase itself has no mobile-specific patterns."
-    context: "Initial seeding"
-
-  - id: project-agnostic-expertise
-    date: 2025-12-21
-    learning: "Mobile expertise in this file provides generic React Native, Flutter, and native mobile patterns. Project-specific mobile learnings will be accumulated through self-improve.md as the agent works on actual mobile projects."
-    context: "Understanding AgileFlow's role"
-
-  - id: cli-vs-mobile
-    date: 2025-12-21
-    learning: "When working on AgileFlow itself, mobile expertise is not applicable. When helping users build mobile apps, these patterns guide architecture, component structure, and platform conventions."
-    context: "Clarifying domain boundaries"

package/src/core/experts/mobile/question.md

@@ -1,72 +0,0 @@
-# Mobile Expert - Question Workflow
-
-**Purpose**: Answer questions about mobile development using expertise-first approach.
-
-## Workflow
-
-### Step 1: Load Expertise
-```
-Read: packages/cli/src/core/experts/mobile/expertise.yaml
-```
-
-Parse the expertise file to understand:
-- Known mobile file locations
-- React Native vs Flutter patterns
-- Navigation patterns
-- Native module conventions
-- Performance targets
-
-### Step 2: Validate Against Codebase
-
-Before answering, verify expertise is current:
-1. Check if mentioned files/directories exist
-2. Spot-check a few patterns mentioned in expertise
-3. Note any discrepancies for later self-improve
-
-### Step 3: Answer with Expertise
-
-When answering questions:
-
-**If expertise covers the question:**
-- Provide direct answer from expertise
-- Include specific file paths
-- Reference patterns and conventions
-- Skip unnecessary exploration
-
-**If expertise is incomplete:**
-- Search codebase for missing information
-- Answer the question
-- Note gaps for self-improve
-
-### Step 4: Flag Updates Needed
-
-If you discovered new information:
-```
-Note for self-improve:
-- New file discovered: [path]
-- Pattern not in expertise: [pattern]
-- Convention changed: [old] → [new]
-```
-
-## Example Usage
-
-**Question**: "Where are the navigation routes defined?"
-
-**Expertise-First Answer**:
-1. Check expertise.yaml → `src/mobile/navigation/` purpose: "React Navigation configuration"
-2. Verify directory exists
-3. Answer: "Navigation routes are in `src/mobile/navigation/`. Stack and tab navigators are defined there per our conventions."
-
-**Question**: "How do we handle camera permissions?"
-
-**Expertise-First Answer**:
-1. Check expertise.yaml → `src/mobile/services/` purpose: "Native module wrappers"
-2. Look for CameraService pattern
-3. Answer with specific file path and pattern
-
-## Key Principles
-
-1. **Expertise First**: Always check expertise.yaml before searching
-2. **Validate**: Verify expertise against actual code
-3. **Be Specific**: Provide exact file paths, not vague directions
-4. **Learn**: Note gaps for self-improve to fill later

package/src/core/experts/mobile/self-improve.md

@@ -1,140 +0,0 @@
-# Mobile Expert - Self-Improve Workflow
-
-**Purpose**: Automatically update expertise.yaml after completing mobile development work.
-
-## When to Run
-
-Run this workflow after:
-- Implementing a new mobile feature
-- Adding new screens or components
-- Integrating new native modules
-- Changing navigation structure
-- Discovering new patterns or conventions
-
-## Workflow
-
-### Step 1: Load Current Expertise
-```
-Read: packages/cli/src/core/experts/mobile/expertise.yaml
-```
-
-### Step 2: Analyze Changes Made
-
-Review what was just implemented:
-1. What new files were created?
-2. What existing files were modified?
-3. What patterns were used?
-4. What conventions were followed or established?
-5. What was learned during implementation?
-
-### Step 3: Generate Diff
-
-Identify what's new or changed:
-- New directories or files not in expertise
-- New patterns discovered
-- Convention changes
-- Relationship changes
-- Performance insights
-
-### Step 4: Update Expertise
-
-Add a new learning entry:
-```yaml
-learnings:
-  - date: YYYY-MM-DD
-    insight: "Brief description of what was learned"
-    files_affected:
-      - path/to/file1
-      - path/to/file2
-    context: "Story or task context"
-```
-
-Update other sections if needed:
-- Add new file locations to `files:`
-- Add new patterns to `patterns:`
-- Update conventions if they changed
-- Add new relationships discovered
-
-### Step 5: Validate Update
-
-Ensure the expertise file:
-- Is valid YAML
-- Has updated `last_updated` date
-- Doesn't exceed ~200 lines (split if too large)
-- Accurately reflects current codebase state
-
-## Learning Categories
-
-### File Discoveries
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Found gesture handling utilities in src/mobile/utils/gestures.ts"
-    files_affected: [src/mobile/utils/gestures.ts]
-    context: "US-0050: Implement swipe-to-delete"
-```
-
-### Pattern Learnings
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Bottom sheet pattern uses @gorhom/bottom-sheet library"
-    files_affected: [src/mobile/components/BottomSheet.tsx]
-    context: "US-0051: Add action sheet component"
-```
-
-### Convention Updates
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Navigation params must be typed in RootStackParamList"
-    files_affected: [src/mobile/navigation/types.ts]
-    context: "US-0052: Fix navigation type safety"
-```
-
-### Performance Insights
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "FlatList with getItemLayout improves scroll performance 40%"
-    files_affected: [src/mobile/components/ItemList.tsx]
-    context: "US-0053: Optimize long list rendering"
-```
-
-## Example Update
-
-Before work:
-```yaml
-files:
-  react_native:
-    - path: src/mobile/screens/
-      purpose: "Screen components"
-```
-
-After implementing biometric auth:
-```yaml
-files:
-  react_native:
-    - path: src/mobile/screens/
-      purpose: "Screen components"
-  native_modules:
-    - path: src/mobile/services/BiometricService.ts
-      purpose: "Face ID / Touch ID authentication wrapper"
-
-learnings:
-  - date: 2025-12-16
-    insight: "Biometric auth requires react-native-biometrics and iOS/Android native setup"
-    files_affected:
-      - src/mobile/services/BiometricService.ts
-      - ios/Podfile
-      - android/app/build.gradle
-    context: "US-0054: Add biometric login"
-```
-
-## Key Principles
-
-1. **Incremental Updates**: Small, frequent updates beat large rewrites
-2. **Specific Context**: Always include story/task context
-3. **Actionable Insights**: Learnings should help future work
-4. **File References**: Link insights to specific files
-5. **Date Everything**: Always include date for tracking