agileflow 2.61.0 → 2.63.0

package/src/core/skills/agileflow-retro-facilitator/cookbook/glad-sad-mad.md

@@ -1,79 +0,0 @@
-# Glad/Sad/Mad Retrospective Format
-
-Best for emotional topics and team dynamics. Use when morale is low or interpersonal issues need addressing.
-
-## When to Use
-
-- Team seems frustrated or burnt out
-- Recent conflicts or tensions
-- Major changes (team composition, process, tools)
-- After particularly difficult sprints
-- When standard retro feels stale
-
-## Template
-
-```markdown
-# Glad/Sad/Mad Retrospective
-
-**Date**: YYYY-MM-DD
-**Facilitator**: [Name]
-**Attendees**: [Team members present]
-**Context**: [Why using this format]
-
-## Glad (Things that made us happy)
-
-- [Glad 1: Celebration or positive moment]
-- [Glad 2: Something that worked well]
-- [Glad 3: Team success]
-
-## Sad (Things that disappointed us)
-
-- [Sad 1: Unmet expectation]
-- [Sad 2: Missed opportunity]
-- [Sad 3: Something we hoped would go better]
-
-## Mad (Things that frustrated us)
-
-- [Mad 1: Recurring problem]
-- [Mad 2: Blocker or impediment]
-- [Mad 3: Process that isn't working]
-
-## Patterns Identified
-
-- [Pattern 1: Theme across categories]
-- [Pattern 2: Root cause analysis]
-
-## Action Items
-
-- [ ] **[Action 1]** - @Owner - Due: [Date]
-  - Addresses: [Which Sad/Mad item]
-
-- [ ] **[Action 2]** - @Owner - Due: [Date]
-  - Addresses: [Which Sad/Mad item]
-
-## What We Want to Protect
-
-- [Glad item to protect and maintain]
-- [Process or practice to keep]
-```
-
-## Facilitation Notes
-
-**Creating Psychological Safety**:
-- Acknowledge that emotions are valid
-- Focus on situations, not individuals
-- Use "I feel..." statements
-- Allow venting, then redirect to solutions
-
-**Timing**:
-- Glad: 10 minutes
-- Sad: 15 minutes
-- Mad: 15 minutes
-- Action Items: 15 minutes
-- Total: ~60 minutes
-
-**Tips**:
-- Start with Glad to set positive tone
-- Let people express frustration fully before problem-solving
-- End with concrete actions to channel emotions productively
-- Follow up on emotional items in 1:1s if needed

package/src/core/skills/agileflow-retro-facilitator/cookbook/start-stop-continue.md

@@ -1,142 +0,0 @@
-# Start/Stop/Continue Retrospective Format
-
-The standard format for sprint retrospectives. Best for regular, recurring retros.
-
-## Template
-
-```markdown
-# Sprint [Number] Retrospective
-
-**Date**: YYYY-MM-DD
-**Facilitator**: [Name]
-**Attendees**: [Team members present]
-**Sprint Duration**: [Start] - [End]
-
-## Sprint Metrics
-
-- **Committed**: X story points
-- **Completed**: Y story points
-- **Velocity**: Z%
-- **Stories Done**: A / B
-- **Bugs Found**: C
-
-## What Went Well
-
-- [Positive 1: Specific thing that worked]
-- [Positive 2: Team success]
-- [Positive 3: Process improvement]
-
-## What Didn't Go Well
-
-- [Challenge 1: Specific problem]
-- [Challenge 2: Blocker or delay]
-- [Challenge 3: Process issue]
-
-## Start (New Practices)
-
-- **[Practice 1]**
-  - Why: [Reasoning]
-  - Owner: [Who will drive this]
-  - Success metric: [How we'll measure]
-
-## Stop (Remove Practices)
-
-- **[Practice 1]**
-  - Why it's not working: [Reasoning]
-  - Alternative: [What we'll do instead]
-
-## Continue (Keep Doing)
-
-- **[Practice 1]**
-  - Why it's working: [Reasoning]
-  - How to maintain: [Keep it going]
-
-## Action Items
-
-- [ ] **[Action 1]** - @Owner - Due: [Date]
-  - Success criteria: [How we know it's done]
-
-- [ ] **[Action 2]** - @Owner - Due: [Date]
-  - Success criteria: [How we know it's done]
-
-## Previous Action Items Review
-
-- [] **[Completed Action]** - Implemented, improved X by Y%
-- [] **[In Progress Action]** - Still working on it, 60% done
-- [] **[Not Done Action]** - Blocked by Z, rolling to next sprint
-
-## Key Insights
-
-1. [Insight 1: Pattern or learning]
-2. [Insight 2: Team dynamic observation]
-3. [Insight 3: Process discovery]
-```
-
-## Metrics to Track
-
-**Sprint Health**:
-- Velocity trend (increasing, stable, decreasing?)
-- Commitment accuracy (completed vs committed)
-- Bug count (increasing, decreasing?)
-- Blocker frequency
-
-**Team Health**:
-- Meeting effectiveness
-- Communication quality
-- Collaboration level
-- Work-life balance
-
-**Process Health**:
-- Cycle time (story start to done)
-- Code review turnaround
-- Deployment frequency
-- Incident count
-
-## Common Themes to Watch For
-
-**Positive Patterns**:
-- Consistent velocity
-- Low bug count
-- Fast code reviews
-- Clear requirements
-- Good collaboration
-
-**Warning Signs**:
-- Declining velocity
-- Recurring blockers
-- Communication issues
-- Scope creep
-- Burnout indicators
-
-## Facilitator Tips
-
-**Do**:
-- Create safe space for honest feedback
-- Focus on process, not people
-- Time-box discussions (5-10 min per topic)
-- Ensure everyone participates
-- End on positive note
-- Follow up on action items
-
-**Don't**:
-- Blame individuals
-- Let discussions run too long
-- Skip retros ("too busy")
-- Create action items without owners
-- Ignore previous action items
-
-## Remote Retro Adaptations
-
-For distributed teams:
-- Use anonymous feedback tools (Retrium, Metro Retro)
-- Give time for async reflection before meeting
-- Use polls/voting for prioritization
-- Record session for absent team members
-- Use collaborative docs for brainstorming
-
-## Frequency Guidelines
-
-- **Every sprint**: Standard retros (60-90 min)
-- **Major milestones**: Extended retros (2-3 hours)
-- **Quarterly**: Big-picture retros (process, tools, culture)
-- **Post-incident**: Blameless postmortems (as needed)

package/src/core/skills/agileflow-retro-facilitator/prompts/action-items.md

@@ -1,83 +0,0 @@
-# Action Items Template
-
-Shared template for creating SMART action items across all retro formats.
-
-## SMART Action Items
-
-- **S**pecific: Clear what needs to be done
-- **M**easurable: Can verify it's complete
-- **A**ssignable: Has an owner
-- **R**elevant: Addresses the issue
-- **T**ime-bound: Has a deadline
-
-## Good vs Bad Examples
-
-**Good (Specific, Actionable)**:
-```
-- [ ] **Create PR size guideline** - @TechLead - Due: Before next sprint
-  - Success criteria: Document written, shared with team, added to CLAUDE.md
-  - Metric: 80% of PRs under 300 lines
-```
-
-**Bad (Vague, Unactionable)**:
-```
-- [ ] Fix code reviews
-- [ ] Be better at communication
-- [ ] Improve quality
-```
-
-## Good vs Bad Feedback
-
-**Good (Specific, Constructive)**:
-```
-"Daily standups ran long (20+ min) because we discussed
-implementation details. Consider moving technical discussions
-to separate sessions."
-
-"Code reviews were faster this sprint (avg 4 hours vs 24 hours
-last sprint) thanks to smaller PR sizes."
-```
-
-**Bad (Vague, Blame-Oriented)**:
-```
-"Meetings were bad"
-"Bob didn't do his job"
-"Everything was terrible"
-"Process is broken"
-```
-
-## Action Item Template
-
-```markdown
-- [ ] **[Specific Action]** - @Owner - Due: [Date]
-  - Context: [What retro item this addresses]
-  - Success criteria: [How we know it's done]
-  - Metric: [Measurable outcome if applicable]
-```
-
-## Tracking Action Items
-
-**Status Markers**:
-- `[ ]` - Not started
-- `[~]` - In progress
-- `[x]` - Completed
-- `[!]` - Blocked
-- `[-]` - Cancelled/Deferred
-
-**Review Format**:
-```markdown
-## Previous Action Items Review
-
-- [x] **[Completed Action]** - Implemented, improved X by Y%
-- [~] **[In Progress Action]** - 60% done, on track for next week
-- [!] **[Blocked Action]** - Blocked by Z, need help from [team]
-- [-] **[Cancelled Action]** - No longer relevant due to [reason]
-```
-
-## Best Practices
-
-1. **Limit to 3-5 actions per retro** - More than 5 rarely get done
-2. **Assign single owners** - Shared ownership = no ownership
-3. **Set realistic deadlines** - Usually before next retro
-4. **Review at next retro** - Accountability matters
-5. **Track completion rate** - Target: >80%

package/src/core/skills/agileflow-sprint-planner/SKILL.md

@@ -1,212 +0,0 @@
----
-name: agileflow-sprint-planner
-description: Helps plan sprints by grouping stories, calculating capacity, identifying risks, and creating sprint goals. Loads when discussing sprint planning or iteration planning.
----
-
-# AgileFlow Sprint Planner
-
-Assists with sprint planning by analyzing available stories, team capacity, dependencies, and creating balanced sprint plans.
-
-## When to Use
-
-This skill activates when:
-- Keywords: "sprint planning", "iteration planning"
-- Discussing what to work on next sprint
-- User asks "what should we work on?"
-- Calculating team capacity or velocity
-- Keywords: "sprint goal", "sprint commitment"
-
-## What This Does
-
-1. Reads backlog stories from docs/06-stories/
-2. Calculates team capacity (people × days × velocity)
-3. Selects stories by priority and dependencies
-4. Creates balanced sprint plan with goal
-5. Identifies risks and blockers
-
-## Instructions
-
-1. **Gather information**:
-   - Read backlog stories from `docs/06-stories/`
-   - Check team capacity (PTO, holidays, meetings)
-   - Review last sprint's velocity
-
-2. **Calculate capacity**:
-   - Team members × days available × points per day
-   - Account for: PTO/vacation, holidays, meetings (10-20%), support work
-
-3. **Select stories**:
-   - Start with highest priority (P0, P1)
-   - Consider dependencies
-   - Balance work across team members
-   - Add stretch goals (20% buffer)
-
-4. **Define sprint goal**:
-   - One clear, achievable objective
-   - Aligns with epic/milestone
-   - Measurable outcome
-
-5. **Validate plan**:
-   - Check for blockers/dependencies
-   - Ensure balanced workload
-   - Verify stories have clear AC
-
-## Sprint Plan Format
-
-```markdown
-# Sprint [Number]: [Sprint Goal]
-
-**Duration**: [Start Date] - [End Date] (2 weeks)
-**Team Capacity**: X story points
-**Sprint Goal**: [1-2 sentence description of what we aim to achieve]
-
-## Committed Stories
-
-### High Priority (P0/P1)
-- [ ] [STORY-###: Title](link) - X pts - @Owner
-- [ ] [STORY-###: Title](link) - X pts - @Owner
-
-### Medium Priority (P2)
-- [ ] [STORY-###: Title](link) - X pts - @Owner
-
-### Stretch Goals (if capacity allows)
-- [ ] [STORY-###: Title](link) - X pts - @Owner
-
-**Total Committed**: X story points
-**Total with Stretch**: Y story points
-
-## Capacity Breakdown
-
-| Team Member | Availability | Capacity (pts) | Assigned (pts) |
-|-------------|--------------|----------------|----------------|
-| Alice       | 10 days      | 15             | 13             |
-| Bob         | 8 days (PTO) | 12             | 11             |
-| Carol       | 10 days      | 15             | 14             |
-| **Total**   | 28 days      | **42**         | **38**         |
-
-## Dependencies & Blockers
-
-- [Dependency 1: What needs to happen]
-- [Blocker 1: Known issue]
-
-## Risks
-
-- [Risk 1: What might go wrong]
-- [Risk 2: Mitigation plan]
-
-## Sprint Schedule
-
-- **Day 1 (Mon)**: Sprint Planning
-- **Day 3 (Wed)**: Mid-sprint check-in
-- **Day 8 (Wed)**: Feature freeze / Code review
-- **Day 10 (Fri)**: Sprint Review & Retro
-
-## Definition of Done
-
-- [ ] Code reviewed and approved
-- [ ] Tests written and passing (unit + integration)
-- [ ] Documentation updated
-- [ ] Deployed to staging
-- [ ] Acceptance criteria validated
-- [ ] No open bugs
-```
-
-## Capacity Calculation
-
-**Basic Formula**:
-```
-Capacity = Team Members × Available Days × Points per Day
-```
-
-**Example**:
-- 3 developers
-- 10 working days per person
-- ~1.5 story points per day average
-- Capacity = 3 × 10 × 1.5 = 45 story points
-
-**Adjustments**:
-- Meetings overhead: -15% (6.75 pts)
-- Code reviews: -10% (4.5 pts)
-- Bug fixes: -10% (4.5 pts)
-- Realistic capacity: ~30 story points
-
-## Velocity Tracking
-
-Track historical velocity to improve estimates:
-
-| Sprint | Committed | Completed | Velocity |
-|--------|-----------|-----------|----------|
-| 12     | 40        | 38        | 95%      |
-| 11     | 35        | 35        | 100%     |
-| 10     | 42        | 30        | 71%      |
-| 9      | 38        | 40        | 105%     |
-| **Avg**| **38.75** | **35.75** | **92%**  |
-
-**Recommended commitment**: 36-40 story points (based on 92% velocity)
-
-## Sprint Goal Guidelines
-
-**Good Sprint Goals**:
-- Complete user authentication (login, signup, password reset)
-- Launch MVP of dark mode feature
-- Improve search performance to <100ms
-- Integrate Stripe payment processing
-
-**Bad Sprint Goals**:
-- Complete as many stories as possible (not specific)
-- Fix bugs (too vague)
-- Work on 10 different features (no focus)
-
-## Story Selection Strategy
-
-**Priority-Based**:
-1. P0 (Critical): Blockers, security fixes, production bugs
-2. P1 (High): Planned features, important improvements
-3. P2 (Medium): Nice-to-haves, enhancements
-4. P3 (Low): Tech debt, cleanup, future work
-
-**Dependency-Based**:
-- Group stories that depend on each other
-- Complete prerequisites first
-- Avoid half-done features
-
-**Skill-Based**:
-- Match stories to team member expertise
-- Allow learning opportunities
-- Pair complex tasks
-
-## Risk Identification
-
-**Common Risks**:
-- **Underestimated complexity**: Add buffer or spike story
-- **External dependencies**: Identify early, create fallback plan
-- **Unclear requirements**: Refine stories before sprint starts
-- **Team availability**: Plan for reduced capacity
-- **Technical unknowns**: Add research/investigation time
-
-## Quality Checklist
-
-Before finalizing sprint plan:
-- [ ] Sprint goal is clear and achievable
-- [ ] Stories sum to realistic capacity (80-90% of max)
-- [ ] All stories have defined acceptance criteria
-- [ ] Dependencies identified and resolved
-- [ ] Work balanced across team members
-- [ ] Stretch goals identified (10-20% extra)
-- [ ] Blockers documented with mitigation plans
-- [ ] Team has reviewed and committed
-
-## Integration
-
-- **agileflow-story-writer**: Ensures stories are well-formed
-- **epic-planner**: Pulls stories from epic milestones
-- **agileflow-retro-facilitator**: Uses retro insights for planning
-
-## Notes
-
-- Sprint planning should take ~2 hours for 2-week sprint
-- Don't overcommit - better to under-promise and over-deliver
-- Review velocity trends, not just last sprint
-- Leave 10-20% buffer for unknowns
-- Pair estimation with multiple team members
-- Re-estimate stories that seem unclear during planning

package/src/core/skills/agileflow-story-writer/SKILL.md

@@ -1,163 +0,0 @@
----
-name: agileflow-story-writer
-description: Automatically formats user requirements and feature discussions into proper user stories with acceptance criteria following AgileFlow templates. Loads when user describes features, requirements, or tasks to implement.
----
-
-# AgileFlow Story Writer
-
-Automatically converts user feature descriptions and requirements into properly formatted user stories with acceptance criteria, owner assignment, priority, and estimates.
-
-## When to Use
-
-This skill activates when:
-- User describes how a feature should behave or requirements
-- Discussing features to build or tasks to implement
-- Creating or reviewing user stories
-- Keywords: "user story", "feature", "build", "implement", "requirement"
-
-## What This Does
-
-1. Extracts user story components from feature discussions
-2. Determines metadata (owner, priority, estimate)
-3. Generates acceptance criteria in Given/When/Then format
-4. Shows story for approval before writing
-5. Creates story file and updates tracking
-
-## Instructions
-
-1. **Extract user story components**:
-   - **Who** (user type): As a [user type]
-   - **What** (capability): I want to [action/capability]
-   - **Why** (benefit): So that [benefit/value]
-
-2. **Determine metadata**:
-   - **Owner**: Based on work type (AG-UI, AG-API, AG-CI, AG-DEVOPS)
-   - **Priority**: P0/P1/P2/P3
-   - **Estimate**: Fibonacci scale (1,2,3,5,8,13)
-   - **Epic**: Link if part of larger epic
-
-3. **Generate acceptance criteria** (2-5 criteria):
-   - Format: **Given** [context] **When** [action] **Then** [outcome]
-   - Cover happy path, errors, edge cases
-
-4. **Show diff**: Display story and wait for YES/NO confirmation
-
-5. **After YES**:
-   - Write story file to `docs/06-stories/US-####-descriptive-name.md`
-   - Update `docs/06-stories/README.md` index
-   - Update `docs/09-agents/status.json` with new story (status: ready)
-   - Create test stub at `docs/07-testing/test-cases/US-####.md`
-
-## User Story Format
-
-```markdown
----
-story_id: US-0042
-epic: EP-0001
-title: User Login Form
-owner: AG-UI
-status: ready
-estimate: 5
-priority: P1
-created: 2025-10-30
-updated: 2025-10-30
-dependencies: [US-0040]
----
-
-## Description
-
-As a user,
-I want to log in with my email and password,
-So that I can access my account and personalized features.
-
-## Acceptance Criteria
-
-### AC1: Successful Login
-**Given** a registered user with valid credentials
-**When** user enters email and password
-**Then** user is redirected to dashboard with welcome message
-
-### AC2: Invalid Credentials
-**Given** user enters incorrect password
-**When** user submits login form
-**Then** error message "Invalid email or password" is displayed
-
-### AC3: Input Validation
-**Given** user submits empty email field
-**When** user clicks "Login" button
-**Then** validation error "Email is required" is shown
-
-## Technical Notes
-
-- Use JWT authentication with 24h expiration
-- Store tokens in httpOnly cookies
-- Implement rate limiting (5 attempts per 15 minutes)
-- Hash passwords with bcrypt
-
-## Testing Strategy
-
-- Unit tests for form validation logic
-- Integration tests for authentication flow
-- E2E test for full login journey
-- Test stub: docs/07-testing/test-cases/US-0042.md
-
-## Definition of Done
-
-- [ ] Code implemented and reviewed
-- [ ] Tests written and passing
-- [ ] Documentation updated
-- [ ] Deployed to staging
-- [ ] Acceptance criteria validated
-```
-
-## Owner Determination
-
-- **AG-UI**: Frontend components, styling, user interactions, accessibility
-- **AG-API**: Backend services, APIs, data models, business logic
-- **AG-CI**: CI/CD pipelines, testing infrastructure, quality gates
-- **AG-DEVOPS**: Infrastructure, deployment, monitoring, automation
-
-## Story Point Estimation
-
-- **1 point**: Trivial change (update text, fix typo, config tweak)
-- **2 points**: Simple feature (add form field, new button, basic validation)
-- **3 points**: Small feature (basic CRUD endpoint, simple component)
-- **5 points**: Medium feature (authentication flow, data model)
-- **8 points**: Large feature (payment integration, complex UI workflow)
-- **13 points**: Very large (consider splitting into multiple stories or epic)
-
-## Priority Guidelines
-
-- **P0 (Critical)**: Blocking users, security issues, data loss, production outage
-- **P1 (High)**: Major features, important fixes, user-facing improvements
-- **P2 (Medium)**: Nice-to-have features, minor improvements, enhancements
-- **P3 (Low)**: Tech debt, cleanup, future enhancements, optimizations
-
-## Quality Checklist
-
-Before creating story:
-- [ ] User story follows "As a...I want...So that..." format
-- [ ] At least 2 acceptance criteria with Given/When/Then
-- [ ] Owner is appropriate for work type
-- [ ] Priority reflects urgency and impact (P0-P3)
-- [ ] Estimate is in Fibonacci sequence (1,2,3,5,8,13)
-- [ ] File name matches pattern: US-####-descriptive-name.md
-- [ ] Technical notes capture implementation details
-- [ ] Definition of Done is comprehensive
-- [ ] Story will be added to status.json with status=ready
-- [ ] Test stub will be created
-
-## Integration
-
-- **epic-planner**: Stories are part of epics
-- **agileflow-sprint-planner**: Stories selected for sprints
-- **agileflow-acceptance-criteria**: AC skill enhances AC sections
-- **agileflow-adr**: Reference architectural decisions in technical notes
-
-## Notes
-
-- If user is vague, ask clarifying questions before generating story
-- Update story number based on existing stories in docs/06-stories/
-- If story is >13 points, suggest breaking into multiple stories or epic
-- Use "diff-first; YES/NO" pattern - show story before writing file
-- Create test stub to satisfy Definition of Ready