agileflow 3.4.3 → 4.0.0-alpha.2

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

@@ -1,59 +0,0 @@
----
-description: Plan, build, and improve accessibility with expertise-driven workflow
-argument-hint: <accessibility task description>
-variables:
-  EXPERTISE_FILE: packages/cli/src/core/experts/accessibility/expertise.yaml
----
-
-# Accessibility Expert: Plan → Build → Self-Improve
-
-## Step 1: PLAN
-
-### 1.1 Load Expertise
-Read `{{EXPERTISE_FILE}}` - know WCAG requirements, ARIA patterns.
-
-### 1.2 Audit First
-```bash
-# Run accessibility audit
-npx axe --dir src/
-```
-
-### 1.3 Create Plan
-```markdown
-## Accessibility Plan
-- Issue identified: [WCAG criterion]
-- Component affected: [name]
-- Fix approach: [pattern]
-- Testing: [screen reader, keyboard]
-```
-
-## Step 2: BUILD
-
-### 2.1 Execute Plan
-- Add ARIA attributes
-- Implement keyboard navigation
-- Ensure color contrast
-
-### 2.2 Capture Changes
-```bash
-git diff --name-only | grep -E "(component|tsx)"
-```
-
-### 2.3 Validate
-- Axe audit passes
-- Keyboard navigation works
-- Screen reader announces correctly
-
-## Step 3: SELF-IMPROVE
-
-### 3.1 Update Expertise
-- Update component requirements
-- Note new ARIA patterns
-- Add learnings
-
-### 3.2 Save
-Update `{{EXPERTISE_FILE}}` with learnings.
-
-## Accessibility Request
-
-{{argument}}

package/src/core/experts/adr-writer/expertise.yaml

@@ -1,138 +0,0 @@
-# ADR Writer Expert - Domain Knowledge
-# This file is the agent's "mental model" of the ADR domain
-# AUTO-UPDATED by self-improve.md after completing work
-
-domain: adr-writer
-last_updated: 2025-12-21
-version: 1.1
-
-# AgileFlow-specific ADR patterns (learned from actual codebase)
-files:
-  decisions:
-    - path: docs/03-decisions/
-      purpose: "Architecture Decision Records"
-      conventions: "adr-NNNN-slug.md naming (e.g., adr-0001-agent-expert-system.md)"
-      example: "adr-0001-agent-expert-system.md"
-    - path: docs/03-decisions/README.md
-      purpose: "ADR index listing all decisions"
-
-  research:
-    - path: docs/10-research/
-      purpose: "Research supporting ADR alternatives"
-      naming: "YYYYMMDD-slug.md format"
-    - path: docs/10-research/README.md
-      purpose: "Research index"
-
-  context:
-    - path: CLAUDE.md
-      purpose: "Project context informing decisions (internal)"
-    - path: docs/04-architecture/
-      purpose: "Architecture documentation"
-    - path: docs/05-epics/
-      purpose: "Epics link to ADRs for context"
-
-relationships:
-  - parent: research
-    child: adrs
-    type: informs
-    notes: "Research provides alternatives for ADRs (see ADR-0001 referencing research)"
-  - parent: adrs
-    child: epics
-    type: linked_from
-    notes: "Epics reference ADRs (EP-0001 → ADR-0001)"
-  - parent: adrs
-    child: implementation
-    type: constrains
-    notes: "ADRs constrain implementation choices"
-  - parent: adrs
-    child: superseding_adrs
-    type: superseded_by
-    notes: "Old ADRs can be superseded by new ones"
-
-patterns:
-  - name: ADR Structure (AgileFlow)
-    description: "Status, Date, Decision Makers, Epic link, then sections"
-    location: docs/03-decisions/adr-0001-agent-expert-system.md
-    sections:
-      - "Context (problem statement with research foundation)"
-      - "Decision (what we're doing)"
-      - "Options Considered (3-4 alternatives with rationale)"
-      - "Consequences (Benefits and Trade-offs)"
-      - "Implementation Plan (phased approach)"
-      - "Risks and Mitigations (table format)"
-      - "Success Criteria (qualitative and quantitative)"
-      - "Related Documents (links to epic, research)"
-
-  - name: ADR Header Format
-    description: "Markdown frontmatter style at top"
-    location: docs/03-decisions/
-    example: |
-      # ADR-0001: Agent Expert System
-      **Status**: Accepted
-      **Date**: 2025-12-16
-      **Decision Makers**: Development Team
-      **Epic**: [EP-0001](../05-epics/EP-0001-agent-expert-pilot.md)
-
-  - name: Options Considered Format
-    description: "Each option with brief rationale"
-    location: docs/03-decisions/
-    example: |
-      ### Option 1: Single Global Expert (Rejected)
-      - Description
-      - **Rejected**: Reason why not selected
-
-  - name: Risks Table Format
-    description: "Risk and Mitigation columns"
-    location: docs/03-decisions/
-    example: "| Stale expertise | Mandatory validation step |"
-
-  - name: Research-First ADR
-    description: "Always reference research that informed decision"
-    location: docs/10-research/
-    example: "See: docs/10-research/20251216-agent-experts-self-improving-agents.md"
-
-conventions:
-  - "Research alternatives before writing ADR"
-  - "Link ADR to epic that drove the decision"
-  - "Document 3-4 alternatives with rationale for rejection/deferral"
-  - "Include Implementation Plan with phases"
-  - "Add Risks and Mitigations table"
-  - "Define Success Criteria (qualitative + quantitative)"
-  - "Link to Related Documents (epic, research, other ADRs)"
-  - "Use lowercase-hyphenated naming: adr-0001-slug.md"
-
-adr_statuses:
-  proposed: "Under review, not yet approved"
-  accepted: "Approved, should be followed"
-  deprecated: "No longer recommended"
-  superseded: "Replaced by newer ADR"
-
-decision_categories:
-  - "Technology choices (framework, database, language)"
-  - "Architecture patterns (Agent Expert system)"
-  - "Data modeling (schema design, caching)"
-  - "Security approaches (auth, encryption)"
-  - "Infrastructure (hosting, CI/CD)"
-  - "Development practices (testing, branching)"
-
-# Learned from AgileFlow codebase exploration
-learnings:
-  - date: 2025-12-21
-    context: "Analyzed ADR-0001 structure"
-    insight: "ADRs have rich structure: Status/Date/Epic header, Context with research, Decision, Options Considered, Consequences, Implementation Plan, Risks table, Success Criteria, Related Docs"
-    source: "docs/03-decisions/adr-0001-agent-expert-system.md"
-
-  - date: 2025-12-21
-    context: "Analyzed ADR-Epic relationship"
-    insight: "ADRs link to epics that drove the decision; epics link back to ADRs for context"
-    source: "docs/03-decisions/adr-0001-agent-expert-system.md, docs/05-epics/ep-0001-agent-expert-pilot.md"
-
-  - date: 2025-12-21
-    context: "Analyzed Options Considered format"
-    insight: "Options include: Selected, Rejected (with reason), Deferred (for future consideration)"
-    source: "docs/03-decisions/adr-0001-agent-expert-system.md"
-
-  - date: 2025-12-21
-    context: "Analyzed Implementation Plan"
-    insight: "ADRs include phased implementation: Phase 1 (Pilot), Phase 2 (Full Rollout), Phase 3 (Refinement) with checkboxes"
-    source: "docs/03-decisions/adr-0001-agent-expert-system.md"

package/src/core/experts/adr-writer/question.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/adr-writer/self-improve.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/adr-writer/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/analytics/expertise.yaml

@@ -1,119 +0,0 @@
-# Analytics Expert - Domain Knowledge
-# This file is the agent's "mental model" of the analytics domain
-# AUTO-UPDATED by self-improve.md after completing work
-
-domain: analytics
-last_updated: 2025-12-21
-version: 1.1
-
-files:
-  tracking:
-    - path: src/analytics/
-      purpose: "Analytics tracking implementation"
-      key_exports: [track, identify, page]
-      conventions: "Single analytics facade for all tracking"
-    - path: src/analytics/events/
-      purpose: "Event definitions and schemas"
-      conventions: "One file per event category"
-    - path: src/analytics/providers/
-      purpose: "Analytics provider integrations (Segment, Amplitude)"
-      conventions: "Named *Provider.ts"
-
-  schemas:
-    - path: src/analytics/schemas/
-      purpose: "Event schema definitions for validation"
-      conventions: "JSON Schema or Zod schemas"
-    - path: src/analytics/events/catalog.ts
-      purpose: "Master event catalog with all tracked events"
-      conventions: "Exported EVENT_CATALOG constant"
-
-  dashboards:
-    - path: docs/analytics/
-      purpose: "Dashboard specifications and metric definitions"
-      conventions: "Markdown documentation"
-    - path: docs/analytics/events.md
-      purpose: "Event tracking documentation"
-    - path: docs/analytics/metrics.md
-      purpose: "Key business metrics definitions"
-
-  privacy:
-    - path: src/analytics/consent.ts
-      purpose: "GDPR consent management"
-      conventions: "Check consent before tracking"
-    - path: src/analytics/privacy.ts
-      purpose: "PII filtering and anonymization"
-      conventions: "Strip PII before sending events"
-
-relationships:
-  - parent: tracking_facade
-    child: providers
-    type: routes_to
-    notes: "Facade routes events to configured providers"
-  - parent: events
-    child: schemas
-    type: validated_by
-    notes: "Events validated against schemas before sending"
-  - parent: ui_components
-    child: tracking
-    type: calls
-    notes: "UI components call tracking facade"
-  - parent: api_endpoints
-    child: tracking
-    type: calls
-    notes: "Backend also tracks server-side events"
-
-patterns:
-  - name: Event Tracking Facade
-    description: "Single interface for all analytics tracking"
-    location: src/analytics/
-    example: |
-      analytics.track('button_clicked', { button_name: 'signup' });
-      analytics.identify(userId, { plan: 'pro' });
-      analytics.page('landing');
-
-  - name: Event Schema Validation
-    description: "Validate events against schema before sending"
-    location: src/analytics/schemas/
-    example: |
-      const schema = z.object({
-        event_name: z.string(),
-        properties: z.object({ ... })
-      });
-
-  - name: Consent-First Tracking
-    description: "Check GDPR consent before any tracking"
-    location: src/analytics/consent.ts
-    example: |
-      if (hasConsent('analytics')) {
-        analytics.track(event);
-      }
-
-  - name: Event Naming Convention
-    description: "object_action format in snake_case"
-    location: src/analytics/events/
-    example: "button_clicked, form_submitted, page_viewed"
-
-  - name: Anonymous User Tracking
-    description: "Track anonymous users with session ID, not PII"
-    location: src/analytics/
-    example: "Use anonymous_id until user identifies"
-
-conventions:
-  - "NEVER track PII (email, name, phone) in event properties"
-  - "ALWAYS check consent before tracking (GDPR/CCPA)"
-  - "Use object_action naming: button_clicked, form_submitted"
-  - "Use snake_case for event names and properties"
-  - "Validate events against schema before sending"
-  - "Include timestamp, session_id, anonymous_id with every event"
-  - "Document all events in event catalog"
-  - "Test tracking in development before production"
-
-# Learnings (trimmed - keep 2 most actionable)
-learnings:
-  - date: 2025-12-21
-    context: "Expertise metrics"
-    insight: "scripts/expertise-metrics.sh analyzes expertise.yaml files for health: total experts, learnings count, staleness distribution"
-
-  - date: 2025-12-21
-    context: "Story metrics from status.json"
-    insight: "Parse status.json for: completion %, stories by status/epic, WIP count, average story age"