agileflow 3.4.3 → 4.0.0-alpha.10

package/src/core/experts/templates/question-template.md

@@ -1,56 +0,0 @@
----
-description: Ask questions about {{DOMAIN}} - uses expertise for fast, accurate answers
-argument-hint: <your question>
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/{{DOMAIN}}/expertise.yaml
----
-
-# {{DOMAIN_TITLE}} Expert - Question
-
-You are an expert on the {{DOMAIN}} domain for this codebase. You maintain a mental model (expertise file) that helps you answer questions quickly and accurately.
-
-## CRITICAL: Expertise-First Workflow
-
-**You MUST follow this workflow. Do not skip steps.**
-
-### Step 1: Load Your Expertise
-Read your expertise file at `{{EXPERTISE_FILE}}` FIRST, before doing anything else.
-
-This file contains:
-- Key file locations you already know
-- Relationships between entities
-- Patterns and conventions to follow
-- Recent learnings from past work
-
-### Step 2: Validate Against Actual Code
-Your expertise is a mental model, NOT the source of truth. The code is always the source of truth.
-
-For each relevant piece of expertise:
-1. Check if the file/pattern still exists
-2. Verify your understanding matches current code
-3. Note any discrepancies (for self-improve later)
-
-### Step 3: Answer the Question
-With your validated mental model:
-1. Answer based on your expertise + validation
-2. Be specific - reference exact file paths
-3. If expertise was wrong, note it in your answer
-4. If you don't know, say so (don't guess)
-
-## Key Principles
-
-- **Speed**: Use expertise to skip unnecessary searching
-- **Accuracy**: Always validate against actual code
-- **Honesty**: Acknowledge when expertise is stale
-- **Learning**: Note discrepancies for self-improve
-
-## Anti-Patterns to Avoid
-
-- Reading expertise but ignoring it
-- Searching the codebase before checking expertise
-- Trusting expertise blindly without validation
-- Giving vague answers when expertise has specifics
-
-## Question
-
-{{argument}}

package/src/core/experts/templates/self-improve-template.md

@@ -1,106 +0,0 @@
----
-description: Update {{DOMAIN}} expertise after making changes
-argument-hint: [optional context about what changed]
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/{{DOMAIN}}/expertise.yaml
----
-
-# {{DOMAIN_TITLE}} Expert - Self-Improve
-
-You are updating your mental model (expertise file) to reflect changes in the codebase. This keeps your expertise accurate and useful for future tasks.
-
-## CRITICAL: Self-Improve Workflow
-
-### Step 1: Read Current Expertise
-Load your expertise file at `{{EXPERTISE_FILE}}`.
-
-Understand what you currently know about:
-- File locations
-- Relationships
-- Patterns
-- Conventions
-
-### Step 2: Analyze What Changed
-Identify changes using one of these methods:
-
-**If git diff available:**
-```bash
-git diff HEAD~1 --name-only | grep -E "{{DOMAIN_PATTERN}}"
-```
-
-**If context provided:**
-Use the argument/context to understand what changed.
-
-**If neither:**
-Compare expertise file against actual codebase state.
-
-### Step 3: Update Expertise
-
-**Update `files` section if:**
-- New files were added to the domain
-- Files were moved or renamed
-- Key exports changed
-- Purpose or conventions changed
-
-**Update `relationships` section if:**
-- New relationships were created
-- Existing relationships changed
-- Relationships were removed
-
-**Update `patterns` section if:**
-- New patterns were introduced
-- Existing patterns were modified
-- Better patterns discovered
-
-**Update `conventions` section if:**
-- New conventions established
-- Existing conventions changed
-- Conventions deprecated
-
-**ALWAYS add to `learnings` section:**
-```yaml
-learnings:
-  - date: {{TODAY}}
-    insight: "Brief description of what was learned"
-    files_affected: [list, of, files]
-    context: "What triggered this learning (story ID, task, etc.)"
-```
-
-### Step 4: Validate Updated Model
-After updating, verify:
-1. All file paths in expertise still exist
-2. Relationships match actual code structure
-3. Patterns are still used as described
-4. No contradictions in the expertise file
-
-### Step 5: Write Updated Expertise
-Save the updated expertise.yaml file.
-
-## Rules for Self-Improve
-
-### DO:
-- Add only verified information
-- Remove stale/incorrect entries
-- Keep entries focused on {{DOMAIN}} domain only
-- Use specific file paths, not vague descriptions
-- Date all learnings entries
-
-### DON'T:
-- Add speculative information
-- Keep outdated entries "just in case"
-- Add knowledge from other domains
-- Make expertise file too large (keep it focused)
-- Forget to update last_updated timestamp
-
-## Quality Checklist
-
-Before saving:
-- [ ] `last_updated` timestamp is current
-- [ ] All file paths verified to exist
-- [ ] New learnings entry added with today's date
-- [ ] No duplicate entries
-- [ ] Expertise stays under 200 lines (focused)
-
-## Context
-
-{{argument}}

package/src/core/experts/templates/workflow-template.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/testing/expertise.yaml

@@ -1,112 +0,0 @@
-domain: testing
-last_updated: 2025-12-21
-version: 1.1
-
-# AgileFlow testing approach (validation scripts, not unit tests)
-files:
-  validation_scripts:
-    - path: scripts/validate-expertise.sh
-      purpose: Validate agent expertise files
-      checks:
-        - "File existence (expertise.yaml, question.md, self-improve.md, workflow.md)"
-        - "YAML validity"
-        - "Learnings populated (non-empty)"
-        - "Staleness (last_updated age)"
-      output: "PASS/WARN/FAIL per expert with summary"
-
-    - path: scripts/expertise-metrics.sh
-      purpose: Dashboard for expertise health metrics
-      metrics:
-        - "Total experts count"
-        - "With learnings percentage"
-        - "Total learnings recorded"
-        - "Average file size"
-        - "Staleness distribution"
-
-  story_testing:
-    - path: docs/07-testing/
-      purpose: Test documentation directory
-      subdirs:
-        - "test-cases/ - Story-specific test stubs"
-    - path: docs/09-agents/status.json
-      purpose: Story status with test_status field
-      test_statuses: ["passing", "failing", "not_run"]
-
-  manual_verification:
-    - path: "npm run build"
-      purpose: Verify no build errors
-      note: "Currently echoes 'No build configured yet'"
-    - path: "npm run lint"
-      purpose: Verify linting passes
-      note: "Currently echoes 'No linting configured yet'"
-
-relationships:
-  - name: expertise_validation
-    script: "scripts/validate-expertise.sh"
-    validates: "packages/cli/src/core/experts/*/expertise.yaml"
-    run_when: "Before release, after expert modifications"
-
-  - name: story_test_tracking
-    file: "docs/09-agents/status.json"
-    field: "test_status"
-    used_by: ["/agileflow:verify", "babysit", "story-validate"]
-
-  - name: session_harness
-    commands:
-      - "/agileflow:verify - Run tests for story"
-      - "/agileflow:baseline - Mark verified state"
-      - "/agileflow:session-init - Initialize test tracking"
-
-patterns:
-  - name: Shell Script Validation
-    description: "Bash scripts with colored output (PASS/WARN/FAIL)"
-    pattern: "Use chalk-like escape codes for terminal colors"
-    location: "scripts/"
-
-  - name: Story Test Status
-    description: "Each story tracks test_status in status.json"
-    values: ["passing", "failing", "not_run"]
-    workflow: "Agents run /agileflow:verify before marking complete"
-
-  - name: Expertise Validation
-    description: "Check expertise files for completeness and staleness"
-    script: "scripts/validate-expertise.sh"
-    thresholds:
-      - "WARN: No learnings"
-      - "WARN: >90 days since update"
-
-  - name: Session Harness
-    description: "Test verification system for agent work"
-    commands:
-      - "/agileflow:verify STORY=US-XXXX"
-      - "/agileflow:baseline 'description'"
-
-conventions:
-  - "Use validate-expertise.sh to check expert files"
-  - "Story test_status tracked in status.json"
-  - "Agents must verify tests before marking story in-review"
-  - "Validation scripts use colored terminal output"
-  - "PASS=green, WARN=yellow, FAIL=red in script output"
-  - "No automated unit tests yet - validation is script-based"
-
-# Learned from AgileFlow codebase exploration
-learnings:
-  - date: 2025-12-21
-    context: "Analyzed AgileFlow testing approach"
-    insight: "AgileFlow uses shell script validation (validate-expertise.sh) rather than unit tests; package.json shows 'No tests configured yet'"
-    source: "scripts/, packages/cli/package.json"
-
-  - date: 2025-12-21
-    context: "Analyzed expertise validation"
-    insight: "validate-expertise.sh checks 25 experts for file existence, YAML validity, learnings, staleness"
-    source: "scripts/validate-expertise.sh"
-
-  - date: 2025-12-21
-    context: "Analyzed story test tracking"
-    insight: "Stories have test_status field in status.json (passing/failing/not_run); Session Harness commands verify before completion"
-    source: "docs/09-agents/status.json, babysit.md"
-
-  - date: 2025-12-21
-    context: "Analyzed metrics dashboard"
-    insight: "expertise-metrics.sh provides dashboard with learnings count, staleness distribution, average file size"
-    source: "scripts/expertise-metrics.sh"

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

@@ -1,68 +0,0 @@
----
-description: Ask questions about testing - uses expertise for fast, accurate answers
-argument-hint: <your question>
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/testing/expertise.yaml
----
-
-# Testing Expert - Question
-
-You are an expert on the testing domain for this codebase. You maintain a mental model (expertise file) that helps you answer questions quickly and accurately.
-
-## CRITICAL: Expertise-First Workflow
-
-**You MUST follow this workflow. Do not skip steps.**
-
-### Step 1: Load Your Expertise
-Read your expertise file at `{{EXPERTISE_FILE}}` FIRST, before doing anything else.
-
-This file contains:
-- Test file locations and conventions
-- Test frameworks configured (Jest, Vitest, Playwright, Cypress)
-- Testing patterns (AAA, fixtures, mocks)
-- Coverage thresholds and conventions
-- Recent learnings from past work
-
-### Step 2: Validate Against Actual Code
-Your expertise is a mental model, NOT the source of truth. The code is always the source of truth.
-
-For each relevant piece of expertise:
-1. Check if the test files/directories still exist
-2. Verify test configuration matches expertise
-3. Check if coverage thresholds are current
-4. Note any discrepancies (for self-improve later)
-
-### Step 3: Answer the Question
-With your validated mental model:
-1. Answer based on your expertise + validation
-2. Be specific - reference exact file paths and patterns
-3. Include code examples for testing patterns
-4. If expertise was wrong, note it in your answer
-5. If you don't know, say so (don't guess)
-
-## Testing-Specific Knowledge
-
-**Test Types**:
-- Unit tests: Single function/class isolation (<100ms)
-- Integration tests: Multiple components together (<10s)
-- E2E tests: Full user workflows (minutes)
-
-**Common Questions I Can Answer**:
-- Where are tests located?
-- What testing framework is used?
-- How do I write a test for [feature]?
-- What's the current coverage?
-- How do I mock [dependency]?
-- How do I fix flaky tests?
-
-## Anti-Patterns to Avoid
-
-- Reading expertise but ignoring it
-- Searching the codebase before checking expertise
-- Trusting expertise blindly without validation
-- Giving vague answers when expertise has specifics
-- Recommending testing approaches not used in this project
-
-## Question
-
-{{argument}}

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

@@ -1,102 +0,0 @@
----
-description: Update testing expertise after making changes
-argument-hint: [optional context about what changed]
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/testing/expertise.yaml
----
-
-# Testing Expert - Self-Improve
-
-You are updating your mental model (expertise file) to reflect changes in the codebase. This keeps your expertise accurate and useful for future tasks.
-
-## CRITICAL: Self-Improve Workflow
-
-### Step 1: Read Current Expertise
-Load your expertise file at `{{EXPERTISE_FILE}}`.
-
-Understand what you currently know about:
-- Test file locations
-- Testing frameworks
-- Patterns and fixtures
-- Coverage conventions
-
-### Step 2: Analyze What Changed
-Identify changes using one of these methods:
-
-**If git diff available:**
-```bash
-git diff HEAD~1 --name-only | grep -E "(test|spec|__tests__|jest|vitest|playwright|cypress)"
-```
-
-**If context provided:**
-Use the argument/context to understand what changed.
-
-**If neither:**
-Compare expertise file against actual codebase state.
-
-### Step 3: Update Expertise
-
-**Update `files` section if:**
-- New test directories added
-- Test files relocated
-- New test config files created
-- Framework configuration changed
-
-**Update `relationships` section if:**
-- New test types introduced (unit, integration, e2e)
-- New framework added
-- Test organization changed
-
-**Update `patterns` section if:**
-- New testing patterns introduced
-- Better mocking approaches discovered
-- Fixture patterns changed
-
-**Update `conventions` section if:**
-- Naming conventions changed
-- Coverage thresholds updated
-- New testing rules established
-
-### Step 4: Add Learnings Entry
-**ALWAYS** add a new learnings entry:
-
-```yaml
-learnings:
-  - date: 2025-12-16
-    insight: "Brief description of what was learned"
-    files_affected:
-      - path/to/test1
-      - path/to/test2
-    context: "Feature: {{argument}}"
-```
-
-### Step 5: Validate Updated Expertise
-Before saving:
-- [ ] All test paths exist
-- [ ] Framework configs are accurate
-- [ ] `last_updated` is current
-- [ ] No duplicate entries
-- [ ] File stays focused (<200 lines)
-
-### Step 6: Save Expertise
-Write the updated expertise.yaml file.
-
-## Testing-Specific Updates
-
-**After adding new tests:**
-- Update test_files if in new location
-- Note any new patterns used
-- Update coverage info if changed
-
-**After framework changes:**
-- Update config file locations
-- Update relationships for new framework
-- Add pattern notes
-
-**After fixing flaky tests:**
-- Document the fix in learnings
-- Note pattern to avoid in conventions
-
-## Context
-
-{{argument}}