agentic-qe 1.9.4 → 2.1.0

package/.claude/skills/xp-practices/SKILL.md

@@ -1,665 +1,229 @@
 ---
 name: xp-practices
-description: Apply XP practices including pair programming, ensemble programming, continuous integration, and sustainable pace. Use when implementing agile development practices, improving team collaboration, or adopting technical excellence practices.
+description: "Apply XP practices including pair programming, ensemble programming, continuous integration, and sustainable pace. Use when implementing agile development practices, improving team collaboration, or adopting technical excellence practices."
+category: methodology
+priority: medium
+tokenEstimate: 1000
+agents: [qe-quality-analyzer, qe-test-executor, qe-code-reviewer]
+implementation_status: optimized
+optimization_version: 1.0
+last_optimized: 2025-12-03
+dependencies: []
+quick_reference_card: true
+tags: [xp, agile, pair-programming, tdd, continuous-integration, collaboration]
 ---
 
 # Extreme Programming (XP) Practices
 
-## Core Philosophy
-
-XP emphasizes technical excellence, rapid feedback, and sustainable pace. It's about doing the simple thing that could possibly work, then iterating based on real feedback.
-
-## The Five Values
-
-1. **Communication** - Everyone knows what everyone else is doing
-2. **Simplicity** - Do the simplest thing that could possibly work
-3. **Feedback** - Get feedback early and often
-4. **Courage** - Tell the truth about progress and estimates, adapt when needed
-5. **Respect** - Everyone contributes value, treat team members well
-
-## Core XP Practices
+<default_to_action>
+When applying XP practices:
+1. START with practices that give immediate value
+2. BUILD supporting practices gradually
+3. ADAPT to your context
+4. MEASURE results
+
+**Core XP Practices (Prioritized):**
+| Practice | Start Here | Why First |
+|----------|------------|-----------|
+| TDD | ✅ Yes | Foundation for everything |
+| Continuous Integration | ✅ Yes | Fast feedback |
+| Pair Programming | ✅ Yes | Knowledge sharing |
+| Collective Ownership | After CI+TDD | Needs safety net |
+| Small Releases | After CI | Infrastructure dependent |
+
+**Pairing Quick Start:**
+```
+Driver-Navigator (Classic):
+- Driver: Writes code
+- Navigator: Reviews, thinks ahead
+- Rotate every 20-30 min
 
-### 1. Pair Programming
+Ping-Pong (with TDD):
+A: Write failing test
+B: Make test pass + refactor
+B: Write next failing test
+A: Make test pass + refactor
+```
+</default_to_action>
 
-**Definition:** Two developers working together at one workstation. One writes code (driver), the other reviews each line as it's typed (navigator).
+## Quick Reference Card
 
-#### Pairing Styles
+### The Five XP Values
 
-**Driver-Navigator (Classic)**
-- Driver: Writes code
-- Navigator: Reviews, suggests, thinks ahead
-- Rotate every 20-30 minutes
+| Value | Meaning | Practice |
+|-------|---------|----------|
+| **Communication** | Everyone knows what everyone does | Daily standups, pairing |
+| **Simplicity** | Simplest thing that works | YAGNI, small design |
+| **Feedback** | Get feedback early and often | TDD, CI, short iterations |
+| **Courage** | Tell truth, adapt | Refactor, admit mistakes |
+| **Respect** | Everyone contributes value | Sustainable pace, pairing |
 
-**Ping-Pong Pairing (with TDD)**
-```
-Person A: Writes failing test
-Person B: Makes test pass
-Person B: Refactors
-Person B: Writes next failing test
-Person A: Makes test pass
-[Continue...]
-```
+### Core Practices
 
-**Strong-Style Pairing**
-- "For an idea to go from your head to the computer, it must go through someone else's hands"
-- Great for mentoring/knowledge transfer
+| Practice | Description | Benefit |
+|----------|-------------|---------|
+| **Pair Programming** | Two devs, one workstation | Quality + knowledge sharing |
+| **TDD** | Red-Green-Refactor | Confidence + design |
+| **CI** | Integrate multiple times/day | Fast feedback |
+| **Collective Ownership** | Anyone can change anything | No bottlenecks |
+| **Sustainable Pace** | 40-hour weeks | Long-term productivity |
+| **Small Releases** | Ship frequently | Risk reduction |
 
-#### When to Pair
+---
 
-**ALWAYS pair for:**
-- Complex or risky code
-- Learning new technology
-- Onboarding new team members
-- Critical bug fixes
-- Architectural decisions
+## Pair Programming
 
-**CAN pair for:**
-- Regular feature development
-- Refactoring sessions
-- Code reviews (live pairing review)
+### When to Pair
 
-**DON'T pair for:**
-- Simple, well-understood tasks
-- Spikes/research (pair to discuss findings)
-- Personal learning time
-- Admin work
+| Context | Pair? | Why |
+|---------|-------|-----|
+| Complex/risky code | ✅ Always | Needs multiple perspectives |
+| New technology | ✅ Always | Learning accelerator |
+| Onboarding | ✅ Always | Knowledge transfer |
+| Critical bugs | ✅ Always | Two heads better |
+| Simple tasks | ❌ Skip | Not worth overhead |
+| Research spikes | ❌ Skip | Pair to discuss findings |
 
-#### Making Pairing Work
+### Pairing Dos and Don'ts
 
 **Do:**
-- ✅ Switch roles regularly (20-30 min)
+- ✅ Switch roles every 20-30 min
 - ✅ Take breaks together
-- ✅ Speak your thoughts aloud
+- ✅ Think out loud
 - ✅ Ask questions
-- ✅ Challenge ideas respectfully
 - ✅ Keep sessions 2-4 hours max
 
 **Don't:**
 - ❌ Grab keyboard without asking
-- ❌ Check phone/email while pairing
-- ❌ Dominate the conversation
-- ❌ Pair all day every day (exhausting)
-- ❌ Pair with same person exclusively
-
-#### Remote Pairing Tools
+- ❌ Check phone while pairing
+- ❌ Dominate conversation
+- ❌ Pair all day (exhausting)
 
-- **VS Code Live Share** - Shared editing, debugging
-- **Tuple** - Low-latency screen sharing for pairing
-- **Zoom/Meet** - Standard video with screen share
-- **tmux/screen** - Terminal sharing for CLI work
-
-### 2. Ensemble Programming (Mob Programming)
+---
 
-**Definition:** 3+ developers working together on the same code at the same workstation.
+## Ensemble (Mob) Programming
 
-#### Ensemble Setup
+**Setup:** 3+ developers, one screen, rotating driver
 
 ```
-[Projector/Large Screen]
-        ↓
-[Computer with Code]
-        ↓
-    [Driver]
-      ← ← ←
+[Screen]
+   ↓
+[Driver] ← Directions from navigators
+   ↑
 [Navigator 1] [Navigator 2] [Navigator 3]
 ```
 
-**Rotation:** Driver switches every 5-10 minutes
-
-#### Ensemble Patterns
-
-**Strong-Style Mob**
-- Navigators direct, driver types
-- Driver doesn't add own ideas while driving
-- Forces clear communication
-
-**Rotating Facilitator**
-- One person manages time/rotation
-- Keeps discussion focused
-- Rotates like driver position
-
-**Expert Learning**
-- Expert explains while driving
-- Others learn and ask questions
-- Useful for knowledge transfer
+**Rotation:** Driver switches every 5-10 min
 
-#### When to Ensemble
-
-**Great for:**
+**Best for:**
 - Complex problem solving
-- Architectural decisions  
+- Architectural decisions
 - Learning new frameworks
-- Kickstarting difficult features
 - Resolving blockers
 
-**Not great for:**
-- Simple, well-understood tasks
-- When people need deep focus
-- Long-term (unsustainable)
-
-### 3. Continuous Integration
-
-**Definition:** Integrate code into shared repository frequently (multiple times per day), with automated build and tests.
+---
 
-#### CI Workflow
+## Continuous Integration
 
+**CI Workflow:**
 ```
-Developer:
 1. Pull latest from main
-2. Make small change (<2 hours work)
+2. Make small change (<2 hrs work)
 3. Run tests locally (all pass)
-4. Commit and push to main
+4. Commit and push
 5. CI runs tests automatically
-6. If tests fail → fix immediately
-
-Pipeline:
-main ← commit
-  ↓
-[Run Tests]
-  ↓
-[Build]
-  ↓
-[Deploy to Staging]
-```
-
-#### CI Best Practices
-
-**Commit frequently:**
-- Small commits (< 2 hours of work)
-- Each commit should pass all tests
-- Commit to main/trunk (no long-lived branches)
-
-**Keep build fast:**
-- Full build + tests < 10 minutes
-- Faster feedback = more valuable
-- Parallelize slow tests
-
-**Fix broken builds immediately:**
-- Broken build = top priority
-- Don't commit more code until fixed
-- Revert commit if fix takes too long
-
-**Automate everything:**
-- Tests run automatically
-- Build happens automatically
-- Deploy to staging automatically
-
-### 4. Test-Driven Development (TDD)
-
-(See `tdd-london-chicago` skill for deep dive)
-
-**Red-Green-Refactor cycle:**
-1. Write failing test (Red)
-2. Write minimal code to pass (Green)
-3. Refactor while keeping tests green
-
-**XP emphasis:** Tests as executable specifications, safety net for refactoring.
-
-### 5. Simple Design
-
-**Four Rules of Simple Design** (Kent Beck):
-1. Passes all tests
-2. Reveals intention (clear, expressive)
-3. No duplication (DRY principle)
-4. Fewest elements (no speculative code)
-
-**Apply in order - tests first!**
-
-#### Examples
-
-**Not simple:**
-```javascript
-// Speculative generalization
-class PaymentProcessor {
-  process(payment, options = {}) {
-    // Supports 15 payment types we might need someday
-    // Has configuration for every possible scenario
-    // 500 lines of "just in case" code
-  }
-}
-```
-
-**Simple:**
-```javascript
-// Just what we need today
-class PaymentProcessor {
-  processCreditCard(cardInfo) {
-    // Does one thing well
-    // 30 lines of clear code
-  }
-}
-
-// Add complexity only when needed
-```
-
-### 6. Refactoring
-
-**Definition:** Improving code structure without changing behavior.
-
-#### When to Refactor
-
-**The Rule of Three:**
-1. First time: Just do it
-2. Second time: Wince and duplicate
-3. Third time: Refactor
-
-**Refactor when:**
-- Tests are green
-- You see duplication
-- Code is hard to understand
-- Adding feature reveals poor design
-- During green phase of TDD
-
-**Don't refactor when:**
-- Tests are failing
-- Under deadline pressure (address later)
-- Code works and rarely changes
-
-#### Safe Refactoring
-
-**Always:**
-1. Have tests that pass
-2. Refactor in small steps
-3. Run tests after each step
-4. Commit working code frequently
-
-**Common Refactorings:**
-- Extract method
-- Rename for clarity
-- Remove duplication
-- Introduce parameter object
-- Replace conditional with polymorphism
-
-### 7. Collective Code Ownership
-
-**Principle:** Anyone can improve any part of the codebase.
-
-**Benefits:**
-- No bottlenecks (no waiting for "that one person")
-- Knowledge spreads across team
-- Code quality improves (more eyes)
-- Bus factor > 1
-
-**Requirements:**
-- Comprehensive test suite (safety net)
-- Coding standards (consistency)
-- Continuous integration (catch issues fast)
-- Code reviews or pairing (maintain quality)
-
-**In practice:**
-```
-❌ "That's Alice's module, only she can change it"
-✅ "I see an issue in this module, I'll pair with Alice to fix it"
-✅ "I need to change this module, I'll write tests first"
-```
-
-### 8. Coding Standards
-
-**Purpose:** Consistency makes collaboration easier.
-
-**What to standardize:**
-- Formatting (use auto-formatter: Prettier, Black)
-- Naming conventions
-- File structure
-- Testing patterns
-- Documentation style
-
-**How to maintain:**
-- Automated linting (ESLint, Pylint)
-- Pre-commit hooks
-- CI enforcement
-- Pair/ensemble programming (natural alignment)
-
-**Don't:**
-- Have 50-page style guides no one reads
-- Enforce arbitrary preferences
-- Spend hours debating tabs vs spaces (use formatter)
-
-### 9. Sustainable Pace
-
-**Principle:** Team should work at a pace they can sustain indefinitely.
-
-**40-hour work week:**
-- No routine overtime
-- Regular hours = sustainable productivity
-- Tired developers write bugs
-
-**Warning signs of unsustainable pace:**
-- Regular late nights/weekends
-- Increasing bug rate
-- Declining code quality
-- Team burnout/turnover
-- Decreased morale
-
-**How to maintain:**
-- Realistic estimates
-- Buffer time in plans
-- Say no to unrealistic deadlines
-- Measure velocity, plan accordingly
-- Take vacations
-
-### 10. Small Releases
-
-**Principle:** Release working software frequently.
-
-**Benefits:**
-- Fast feedback from users
-- Reduced risk (small changes)
-- Easier to debug (what changed?)
-- Business value delivered sooner
-
-**How small?**
-- Deploy to production: daily or weekly
-- Internal release: multiple times per day
-- Feature flags for incomplete work
-
-**Continuous Deployment:**
-```
-Commit → CI Tests → Deploy Staging → Automated Tests → Deploy Production
-[All automated, happens multiple times per day]
-```
-
-### 11. On-Site Customer
-
-**Modern interpretation:** Product Owner embedded with team.
-
-**Customer responsibilities:**
-- Writes user stories
-- Prioritizes backlog
-- Answers questions immediately  
-- Accepts completed work
-- Makes scope decisions
-
-**Not realistic:** Customer physically present 40hrs/week
-
-**Practical compromise:**
-- Daily standup attendance
-- Available for questions (Slack/quick calls)
-- Sprint planning and review
-- Regular demo sessions
-
-### 12. Metaphor / Ubiquitous Language
-
-**Principle:** Shared vocabulary between technical and non-technical team members.
-
-**Example - E-commerce System:**
-```
-Shared language:
-- "Cart" (not "session shopping container")
-- "Checkout" (not "payment initialization workflow")
-- "Order" (not "purchase transaction record")
-
-Everyone uses same terms:
-- Product owner writes stories using these words
-- Developers name classes/methods using these words
-- Tests use these words
-- Documentation uses these words
-```
-
-**Benefits:**
-- Clearer communication
-- Code reflects business domain
-- Less translation needed
-- Easier onboarding
-
-## Combining XP Practices
-
-### Practice Synergies
-
-**TDD + Pair Programming**
+6. If fail → fix immediately
 ```
-Ping-pong pairing with TDD:
-Person A writes test → Person B makes it pass
-High quality code, fast feedback, knowledge sharing
-```
-
-**Collective Ownership + CI + Tests**
-```
-Anyone can change anything because:
-- Tests catch regressions immediately
-- CI runs tests on every commit  
-- Broken builds fixed immediately
-No fear of stepping on toes
-```
-
-**Simple Design + Refactoring**
-```
-Start with simplest design
-When requirements change → refactor
-Tests give confidence to refactor
-Never build more than needed
-```
-
-## Adapting XP for Your Context
-
-### Startup Context
-- **Keep:** TDD, CI, Simple Design, Small Releases
-- **Adapt:** Pair occasionally (not always), lighter standards
-- **Skip:** Might not need dedicated on-site customer
-
-### Enterprise Context
-- **Keep:** All practices, especially sustainable pace
-- **Adapt:** More formal standards, documentation requirements
-- **Add:** Architecture reviews, security scans
-
-### Remote Team
-- **Keep:** All core practices  
-- **Adapt:** Remote pairing tools, async communication
-- **Add:** Over-communicate, document decisions
-
-### Legacy Codebase
-- **Start with:** Tests for changes, CI, Refactoring
-- **Build towards:** TDD for new code, Collective ownership
-- **Be patient:** Can't adopt everything at once
-
-## Common Objections (and Responses)
-
-**"Pair programming is twice as slow"**
-→ Studies show 15% slower to write, 15% fewer bugs, better design. Net positive.
-
-**"We don't have time for TDD"**
-→ You don't have time NOT to. Debugging takes longer than writing tests.
-
-**"Continuous integration is too hard to set up"**
-→ Start simple: GitHub Actions with one test. Build from there.
-
-**"Collective ownership will create chaos"**
-→ Only with poor tests and no CI. Fix those first.
-
-**"40-hour weeks won't work for our deadlines"**
-→ Your deadlines are based on unsustainable pace. Adjust estimates.
 
-## XP in Quality Engineering
+**Best Practices:**
+- Commit frequently (small changes)
+- Keep build fast (<10 min)
+- Fix broken builds immediately
+- Never commit to broken build
 
-### QE-Specific Applications
-
-**Ensemble Testing Sessions**
-- 3-5 people exploring together
-- Share testing heuristics in real-time
-- Rapid bug discovery and investigation
-
-**Test Code Pairing**
-- Pair on test automation
-- Share testing patterns
-- Improve test quality
-
-**Quality as Team Responsibility**
-- Developers write tests
-- QE does exploratory testing
-- Everyone owns quality
-
-**Continuous Testing**
-- Tests run on every commit
-- Fast feedback on quality
-- No separate QE phase
-
-## Measuring XP Success
-
-**Code Quality Metrics:**
-- Test coverage trend
-- Defect density
-- Code churn
-
-**Team Health Metrics:**
-- Velocity consistency
-- Team satisfaction surveys
-- Turnover rate
-
-**Delivery Metrics:**
-- Deployment frequency
-- Lead time for changes
-- Mean time to recovery
-
-**Don't measure:**
-- Lines of code written
-- Hours worked
-- Number of commits
-
-## Resources
+---
 
-**Books:**
-- **Extreme Programming Explained** by Kent Beck
-- **Extreme Programming Installed** by Jeffries, Anderson, Hendrickson
-- **Pair Programming Illuminated** by Williams & Kessler
+## Four Rules of Simple Design
 
-**Modern Practices:**
-- Remote mob programming techniques
-- DevOps integration with XP
-- Continuous deployment patterns
+(In priority order)
+1. **Passes all tests** - Works correctly
+2. **Reveals intention** - Clear, expressive code
+3. **No duplication** - DRY principle
+4. **Fewest elements** - No speculative code
 
-## Using with QE Agents
+---
 
-### Agent-Human Pair Testing
+## Agent Integration
 
-**qe-test-generator** + Human QE:
 ```typescript
-// Ping-pong pattern with AI agent
-// Human writes test charter
-const charter = "Test payment processing edge cases";
+// Agent-human pair testing
+const charter = "Test payment edge cases";
+const tests = await Task("Generate Tests", { charter }, "qe-test-generator");
+const reviewed = await human.review(tests);
+await Task("Implement", { tests: reviewed }, "qe-test-generator");
 
-// Agent generates test code
-const test = await qe-test-generator.generate(charter);
+// Continuous integration with agents
+await Task("Risk Analysis", { prDiff }, "qe-regression-risk-analyzer");
+await Task("Generate Tests", { changes: prDiff }, "qe-test-generator");
+await Task("Execute Tests", { scope: 'affected' }, "qe-test-executor");
 
-// Human reviews and refines
-const refinedTest = await human.review(test);
-
-// Agent implements refinements
-await qe-test-generator.implement(refinedTest);
+// Sustainable pace: agents handle grunt work
+const agentWork = ['regression', 'data-generation', 'coverage-analysis'];
+const humanWork = ['exploratory', 'risk-assessment', 'strategy'];
 ```
 
-### Ensemble Testing with Multiple Agents
-
-```typescript
-// Mob testing: Multiple agents + human coordinator
-const ensemble = await FleetManager.startEnsemble({
-  facilitator: 'human',
-  participants: [
-    'qe-test-generator',
-    'qe-coverage-analyzer',
-    'qe-security-scanner'
-  ],
-  rotation: '10min',
-  charter: 'Design test strategy for new payment API'
-});
-
-// Human directs, agents execute and suggest
-// Rotate which agent is "driving" every 10 minutes
-```
-
-### Continuous Integration with Agents
-
-```yaml
-# AI agents in CI pipeline
-name: XP CI with Agents
-
-on: [push]
-
-jobs:
-  test:
-    steps:
-      # Agent runs risk analysis
-      - name: Risk Analysis
-        run: aqe agent run qe-regression-risk-analyzer
-
-      # Agent generates tests for changes
-      - name: Generate Tests
-        run: aqe agent run qe-test-generator
+---
 
-      # Agent executes all tests
-      - name: Execute Tests
-        run: aqe agent run qe-test-executor
+## Agent Coordination Hints
 
-      # Agent analyzes coverage
-      - name: Coverage Check
-        run: aqe agent run qe-coverage-analyzer
+### Memory Namespace
 ```
-
-### Collective Code & Test Ownership
-
-```typescript
-// Agents help maintain collective ownership
-// Any team member can improve any test
-// Agents ensure consistency
-
-await qe-quality-analyzer.enforceStandards({
-  scope: 'all-tests',
-  standards: ['naming-conventions', 'test-structure', 'assertions'],
-  autoFix: true  // Agent fixes simple violations
-});
+aqe/xp-practices/
+├── pairing-sessions/*   - Pair/ensemble session logs
+├── ci-metrics/*         - CI health metrics
+├── velocity/*           - Team velocity data
+└── retrospectives/*     - XP retrospective notes
 ```
 
-### Sustainable Pace with Agent Assistance
-
+### Fleet Coordination
 ```typescript
-// Agents handle grunt work, humans focus on high-value tasks
-const workDistribution = {
+const xpFleet = await FleetManager.coordinate({
+  strategy: 'xp-workflow',
   agents: [
-    'Repetitive regression testing',
-    'Log analysis and pattern detection',
-    'Test data generation',
-    'Coverage gap analysis',
-    'Performance monitoring'
+    'qe-test-generator',   // TDD support
+    'qe-test-executor',    // CI integration
+    'qe-code-reviewer'     // Collective ownership
   ],
-  humans: [
-    'Exploratory testing',
-    'Risk assessment',
-    'Test strategy decisions',
-    'Domain-specific edge cases',
-    'Stakeholder communication'
-  ]
-};
-
-// Result: 40-hour work week, sustainable, high productivity
+  topology: 'parallel'
+});
 ```
 
 ---
 
-## Related Skills
+## Common Objections
 
-**Core Quality Practices:**
-- [agentic-quality-engineering](../agentic-quality-engineering/) - Agents as pair partners
-- [holistic-testing-pact](../holistic-testing-pact/) - Whole-team quality practices
-- [context-driven-testing](../context-driven-testing/) - Adapt XP to context
+| Objection | Response |
+|-----------|----------|
+| "Pairing is 2x slower" | 15% slower writing, 15% fewer bugs, net positive |
+| "No time for TDD" | Debugging takes longer than testing |
+| "CI is hard to setup" | Start simple: one action, one test |
+| "Collective ownership = chaos" | Only without tests + CI |
 
-**Development Practices:**
-- [tdd-london-chicago](../tdd-london-chicago/) - TDD within XP workflow
-- [refactoring-patterns](../refactoring-patterns/) - Safe refactoring techniques
-- [code-review-quality](../code-review-quality/) - Review as pairing alternative
+---
 
-**Testing Specializations:**
-- [exploratory-testing-advanced](../exploratory-testing-advanced/) - Ensemble exploration
-- [test-automation-strategy](../test-automation-strategy/) - CI/CD integration
+## Related Skills
+- [tdd-london-chicago](../tdd-london-chicago/) - TDD deep dive
+- [refactoring-patterns](../refactoring-patterns/) - Safe refactoring
+- [pair-programming](../pair-programming/) - AI-assisted pairing
 
 ---
 
 ## Remember
 
-XP practices work together as a system. Don't cherry-pick randomly:
-- Start with practices that give immediate value
-- Build supporting practices gradually
-- Adapt to your context
-- Measure results
-
-**The goal:** Sustainable delivery of high-quality software through technical excellence and teamwork.
+**XP practices work as a system.** Don't cherry-pick randomly:
+- TDD enables collective ownership
+- CI enables small releases
+- Pairing enables collective ownership
+- Sustainable pace enables everything
 
-**With Agents**: XP practices amplify agent effectiveness. Pair humans with agents for best results. Agents handle repetitive work, humans provide judgment and creativity.
+**With Agents:** Agents amplify XP. Pair humans with agents. Agents handle repetitive work, humans provide judgment and creativity.