@agentic-qe/v3 3.0.0-alpha.5 → 3.0.0-alpha.7

package/assets/skills/shift-left-testing/SKILL.md

@@ -0,0 +1,225 @@
+---
+name: shift-left-testing
+description: "Move testing activities earlier in the development lifecycle to catch defects when they're cheapest to fix. Use when implementing TDD, CI/CD, or early quality practices."
+category: testing-methodologies
+priority: high
+tokenEstimate: 900
+agents: [qe-test-generator, qe-requirements-validator, qe-regression-risk-analyzer]
+implementation_status: optimized
+optimization_version: 1.0
+last_optimized: 2025-12-02
+dependencies: []
+quick_reference_card: true
+tags: [shift-left, early-testing, tdd, bdd, ci-cd, prevention]
+---
+
+# Shift-Left Testing
+
+<default_to_action>
+When implementing early testing practices:
+1. VALIDATE requirements before coding (testability, BDD scenarios)
+2. WRITE tests before implementation (TDD red-green-refactor)
+3. AUTOMATE in CI pipeline (every commit triggers tests)
+4. FOLLOW test pyramid: Many unit (70%), some integration (20%), few E2E (10%)
+5. FIX defects immediately - never let them accumulate
+
+**Quick Shift-Left Levels:**
+- Level 1: Unit tests with each PR (developer responsibility)
+- Level 2: TDD practice (tests before code)
+- Level 3: BDD/Example mapping in refinement (requirements testing)
+- Level 4: Risk analysis in design (architecture testing)
+
+**Critical Success Factors:**
+- Defects found in requirements cost 1x; in production cost 100x
+- Every commit must run automated tests
+- Quality is built in, not tested in
+</default_to_action>
+
+## Quick Reference Card
+
+### When to Use
+- Reducing cost of defects
+- Implementing CI/CD pipelines
+- Starting TDD practice
+- Improving requirements quality
+
+### Cost of Defects by Phase
+| Phase | Relative Cost | Example |
+|-------|--------------|---------|
+| Requirements | 1x | Fix doc: 30 min |
+| Design | 5x | Redesign: few hours |
+| Development | 10x | Code fix: 1 day |
+| Testing | 20x | Fix + retest: 2 days |
+| Production | 100x | Hotfix + rollback + investigation |
+
+### Test Pyramid
+```
+       /\        E2E (10%) - Critical user journeys
+      /  \
+     /    \      Integration (20%) - Component interactions
+    /      \
+   /________\    Unit (70%) - Fast, isolated, comprehensive
+```
+
+### Shift-Left Levels
+| Level | Practice | When |
+|-------|----------|------|
+| 1 | Unit tests in PR | Before merge |
+| 2 | TDD | Before implementation |
+| 3 | BDD/Example Mapping | During refinement |
+| 4 | Risk Analysis | During design |
+
+---
+
+## Level 1: Tests in Every PR
+
+```yaml
+# CI pipeline - tests run on every commit
+name: CI
+on: [push, pull_request]
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - run: npm ci
+      - run: npm run test:unit
+      - run: npm run test:integration
+      - run: npm run lint
+
+  quality-gate:
+    needs: test
+    steps:
+      - name: Coverage Check
+        run: npx coverage-check --min 80
+      - name: No New Warnings
+        run: npm run lint -- --max-warnings 0
+```
+
+---
+
+## Level 2: TDD Practice
+
+```javascript
+// Red: Write failing test first
+test('calculates discount for orders over $100', () => {
+  const order = new Order([{ price: 150 }]);
+  expect(order.discount).toBe(15); // 10% off
+});
+
+// Green: Minimal implementation
+class Order {
+  get discount() {
+    return this.total > 100 ? this.total * 0.1 : 0;
+  }
+}
+
+// Refactor: Improve while keeping green
+```
+
+---
+
+## Level 3: BDD in Refinement
+
+```gherkin
+# Example mapping before coding
+Feature: Loyalty Discount
+  Scenario: Gold member gets 15% discount
+    Given a customer with "gold" membership
+    When they checkout with $200 in cart
+    Then discount applied is $30
+    And order total is $170
+
+  Scenario: New customer gets no discount
+    Given a customer with no membership
+    When they checkout with $200 in cart
+    Then no discount is applied
+```
+
+---
+
+## Level 4: Risk Analysis in Design
+
+```typescript
+// During architecture review
+await Task("Risk Analysis", {
+  phase: 'design',
+  component: 'payment-service',
+  questions: [
+    'What happens when payment gateway times out?',
+    'How do we handle duplicate submissions?',
+    'What if inventory changed during checkout?'
+  ]
+}, "qe-requirements-validator");
+
+// Output: Testability requirements, failure mode tests
+```
+
+---
+
+## Agent-Assisted Shift-Left
+
+```typescript
+// Validate requirements testability
+await Task("Requirements Validation", {
+  requirements: userStories,
+  check: ['INVEST-criteria', 'testability', 'ambiguity'],
+  generateBDD: true
+}, "qe-requirements-validator");
+
+// Generate tests from requirements
+await Task("Generate Tests", {
+  source: 'requirements',
+  types: ['unit', 'integration', 'e2e'],
+  coverage: 'comprehensive'
+}, "qe-test-generator");
+
+// Smart test selection for changes
+await Task("Select Regression Tests", {
+  changedFiles: prFiles,
+  algorithm: 'risk-based',
+  targetReduction: 0.7  // 70% time savings
+}, "qe-regression-risk-analyzer");
+```
+
+---
+
+## Agent Coordination Hints
+
+### Memory Namespace
+```
+aqe/shift-left/
+├── requirements/*       - Validated requirements
+├── generated-tests/*    - Auto-generated tests
+├── coverage-targets/*   - Coverage goals by component
+└── pipeline-results/*   - CI/CD test history
+```
+
+### Fleet Coordination
+```typescript
+const shiftLeftFleet = await FleetManager.coordinate({
+  strategy: 'shift-left',
+  agents: [
+    'qe-requirements-validator',     // Level 3-4
+    'qe-test-generator',             // Level 2
+    'qe-regression-risk-analyzer'    // Smart selection
+  ],
+  topology: 'sequential'
+});
+```
+
+---
+
+## Related Skills
+- [tdd-london-chicago](../tdd-london-chicago/) - TDD practices
+- [holistic-testing-pact](../holistic-testing-pact/) - Proactive testing
+- [cicd-pipeline-qe-orchestrator](../cicd-pipeline-qe-orchestrator/) - Pipeline integration
+- [shift-right-testing](../shift-right-testing/) - Production feedback
+
+---
+
+## Remember
+
+**Earlier = Cheaper.** Requirements defects cost 1x; production defects cost 100x. Test pyramid: 70% unit, 20% integration, 10% E2E. Every commit runs tests. TDD builds quality in.
+
+**With Agents:** Agents validate requirements testability, generate tests from specs, and select optimal regression suites. Use agents to implement shift-left practices consistently.

package/assets/skills/shift-right-testing/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: shift-right-testing
+description: "Testing in production with feature flags, canary deployments, synthetic monitoring, and chaos engineering. Use when implementing production observability or progressive delivery."
+category: testing-methodologies
+priority: high
+tokenEstimate: 1000
+agents: [qe-production-intelligence, qe-chaos-engineer, qe-performance-tester, qe-quality-analyzer]
+implementation_status: optimized
+optimization_version: 1.0
+last_optimized: 2025-12-02
+dependencies: []
+quick_reference_card: true
+tags: [shift-right, production-testing, canary, feature-flags, chaos-engineering, monitoring]
+---
+
+# Shift-Right Testing
+
+<default_to_action>
+When testing in production or implementing progressive delivery:
+1. IMPLEMENT feature flags for progressive rollout (1% → 10% → 50% → 100%)
+2. DEPLOY with canary releases (compare metrics before full rollout)
+3. MONITOR with synthetic tests (proactive) + RUM (reactive)
+4. INJECT failures with chaos engineering (build resilience)
+5. ANALYZE production data to improve pre-production testing
+
+**Quick Shift-Right Techniques:**
+- Feature flags → Control who sees what, instant rollback
+- Canary deployment → 5% traffic, compare error rates
+- Synthetic monitoring → Simulate users 24/7, catch issues before users
+- Chaos engineering → Netflix-style failure injection
+- RUM (Real User Monitoring) → Actual user experience data
+
+**Critical Success Factors:**
+- Production is the ultimate test environment
+- Ship fast with safety nets, not slow with certainty
+- Use production data to improve shift-left testing
+</default_to_action>
+
+## Quick Reference Card
+
+### When to Use
+- Progressive feature rollouts
+- Production reliability validation
+- Performance monitoring at scale
+- Learning from real user behavior
+
+### Shift-Right Techniques
+| Technique | Purpose | When |
+|-----------|---------|------|
+| Feature Flags | Controlled rollout | Every feature |
+| Canary | Compare new vs old | Every deployment |
+| Synthetic Monitoring | Proactive detection | 24/7 |
+| RUM | Real user metrics | Always on |
+| Chaos Engineering | Resilience validation | Regularly |
+| A/B Testing | User behavior validation | Feature decisions |
+
+### Progressive Rollout Pattern
+```
+1% → 10% → 25% → 50% → 100%
+↓      ↓      ↓      ↓
+Check  Check  Check  Monitor
+```
+
+### Key Metrics to Monitor
+| Metric | SLO Target | Alert Threshold |
+|--------|------------|-----------------|
+| Error rate | < 0.1% | > 1% |
+| p95 latency | < 200ms | > 500ms |
+| Availability | 99.9% | < 99.5% |
+| Apdex | > 0.95 | < 0.8 |
+
+---
+
+## Feature Flags
+
+```javascript
+// Progressive rollout with LaunchDarkly/Unleash pattern
+const newCheckout = featureFlags.isEnabled('new-checkout', {
+  userId: user.id,
+  percentage: 10,  // 10% of users
+  allowlist: ['beta-testers']
+});
+
+if (newCheckout) {
+  return <NewCheckoutFlow />;
+} else {
+  return <LegacyCheckoutFlow />;
+}
+
+// Instant rollback on issues
+await featureFlags.disable('new-checkout');
+```
+
+---
+
+## Canary Deployment
+
+```yaml
+# Flagger canary config
+apiVersion: flagger.app/v1beta1
+kind: Canary
+spec:
+  targetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: checkout-service
+  progressDeadlineSeconds: 60
+  analysis:
+    interval: 1m
+    threshold: 5      # Max failed checks
+    maxWeight: 50     # Max traffic to canary
+    stepWeight: 10    # Increment per interval
+    metrics:
+      - name: request-success-rate
+        threshold: 99
+      - name: request-duration
+        threshold: 500
+```
+
+---
+
+## Synthetic Monitoring
+
+```javascript
+// Continuous production validation
+await Task("Synthetic Tests", {
+  endpoints: [
+    { path: '/health', expected: 200, interval: '30s' },
+    { path: '/api/products', expected: 200, interval: '1m' },
+    { path: '/checkout', flow: 'full-purchase', interval: '5m' }
+  ],
+  locations: ['us-east', 'eu-west', 'ap-south'],
+  alertOn: {
+    statusCode: '!= 200',
+    latency: '> 500ms',
+    contentMismatch: true
+  }
+}, "qe-production-intelligence");
+```
+
+---
+
+## Chaos Engineering
+
+```typescript
+// Controlled failure injection
+await Task("Chaos Experiment", {
+  hypothesis: 'System handles database latency gracefully',
+  steadyState: {
+    metric: 'error_rate',
+    expected: '< 0.1%'
+  },
+  experiment: {
+    type: 'network-latency',
+    target: 'database',
+    delay: '500ms',
+    duration: '5m'
+  },
+  rollback: {
+    automatic: true,
+    trigger: 'error_rate > 5%'
+  }
+}, "qe-chaos-engineer");
+```
+
+---
+
+## Production → Pre-Production Feedback Loop
+
+```typescript
+// Convert production incidents to regression tests
+await Task("Incident Replay", {
+  incident: {
+    id: 'INC-2024-001',
+    type: 'performance-degradation',
+    conditions: { concurrent_users: 500, cart_items: 10 }
+  },
+  generateTests: true,
+  addToRegression: true
+}, "qe-production-intelligence");
+
+// Output: New test added to prevent recurrence
+```
+
+---
+
+## Agent Coordination Hints
+
+### Memory Namespace
+```
+aqe/shift-right/
+├── canary-results/*      - Canary deployment metrics
+├── synthetic-tests/*     - Monitoring configurations
+├── chaos-experiments/*   - Experiment results
+├── production-insights/* - Issues → test conversions
+└── rum-analysis/*        - Real user data patterns
+```
+
+### Fleet Coordination
+```typescript
+const shiftRightFleet = await FleetManager.coordinate({
+  strategy: 'shift-right-testing',
+  agents: [
+    'qe-production-intelligence',  // RUM, incident replay
+    'qe-chaos-engineer',           // Resilience testing
+    'qe-performance-tester',       // Synthetic monitoring
+    'qe-quality-analyzer'          // Metrics analysis
+  ],
+  topology: 'mesh'
+});
+```
+
+---
+
+## Related Skills
+- [shift-left-testing](../shift-left-testing/) - Pre-production testing
+- [chaos-engineering-resilience](../chaos-engineering-resilience/) - Failure injection deep dive
+- [performance-testing](../performance-testing/) - Load testing
+- [agentic-quality-engineering](../agentic-quality-engineering/) - Agent coordination
+
+---
+
+## Remember
+
+**Production is the ultimate test environment.** Feature flags enable instant rollback. Canary catches issues before 100% rollout. Synthetic monitoring detects problems before users. Chaos engineering builds resilience. RUM shows real user experience.
+
+**With Agents:** Agents monitor production, replay incidents as tests, run chaos experiments, and convert production insights to pre-production tests. Use agents to maintain continuous production quality.

package/assets/skills/six-thinking-hats/README.md

@@ -0,0 +1,190 @@
+# Six Thinking Hats for Testing
+
+A comprehensive Claude Code skill that applies Edward de Bono's Six Thinking Hats methodology to software testing contexts.
+
+## Quick Overview
+
+**What It Does**: Enables structured exploration of quality concerns from six distinct perspectives (facts, emotions, risks, benefits, creativity, and process) to uncover blind spots and make better testing decisions.
+
+**When to Use**:
+- Designing test strategies for new features
+- Conducting test retrospectives
+- Analyzing test failures or production incidents
+- Evaluating testing approaches
+- Facilitating testing discussions with teams
+- Overcoming analysis paralysis in testing decisions
+
+## The Six Hats
+
+| Hat | Focus | Testing Application | Time |
+|-----|-------|---------------------|------|
+| 🤍 **White** | Facts & Data | Test metrics, coverage, defect data | 5 min |
+| ❤️ **Red** | Feelings & Intuition | Gut instincts about quality, confidence | 3 min |
+| 🖤 **Black** | Risks & Problems | What could go wrong, coverage gaps | 7 min |
+| 💛 **Yellow** | Benefits & Opportunities | Testing strengths, quick wins | 5 min |
+| 💚 **Green** | Creativity & Alternatives | Innovative test approaches | 7 min |
+| 🔵 **Blue** | Process & Organization | Test strategy, action plan | 5 min |
+
+**Total**: 30 minutes for solo session, 60-90 minutes for team session
+
+## Quick Start
+
+### Solo Session (30 minutes)
+
+```bash
+# 1. Copy the template
+cp .claude/skills/six-thinking-hats/resources/templates/solo-session-template.md my-analysis.md
+
+# 2. Define your testing focus
+# Example: "Test strategy for user authentication feature"
+
+# 3. Work through each hat sequentially (use timer!)
+# White Hat (5 min): List facts, metrics, data
+# Red Hat (3 min): Capture gut feelings, no justification
+# Black Hat (7 min): Identify risks, gaps, problems
+# Yellow Hat (5 min): Find strengths, opportunities
+# Green Hat (7 min): Generate creative testing ideas
+# Blue Hat (5 min): Create action plan
+
+# 4. Synthesize into actionable test plan
+```
+
+### Team Session (90 minutes)
+
+```bash
+# 1. Copy the team template
+cp .claude/skills/six-thinking-hats/resources/templates/team-session-template.md team-session.md
+
+# 2. Pre-session: Gather data (White Hat prep)
+
+# 3. Run session with strict time boundaries
+# - Blue Hat opening: 5 min (set context)
+# - White Hat: 10 min (collect facts round-robin)
+# - Red Hat: 5 min (silent reflection + sharing)
+# - Black Hat: 12 min (brainstorm risks)
+# - Yellow Hat: 8 min (identify opportunities)
+# - Green Hat: 15 min (rapid ideation)
+# - Blue Hat: 10 min (synthesize action plan)
+
+# 4. Post-session: Document and share (20 min)
+```
+
+## File Structure
+
+```
+.claude/skills/six-thinking-hats/
+├── SKILL.md                           # Main skill documentation
+├── README.md                          # This file (human-readable overview)
+├── resources/
+│   ├── templates/
+│   │   ├── solo-session-template.md  # Template for individual use
+│   │   └── team-session-template.md  # Template for team sessions
+│   └── examples/
+│       └── api-testing-example.md    # Complete worked example
+```
+
+## When to Use Which Format
+
+### Solo Session (30 min)
+✅ **Use when**:
+- Quick decision needed
+- Individual test analysis
+- Personal exploration
+- Preparing for team discussion
+
+### Team Session (90 min)
+✅ **Use when**:
+- Complex testing challenges
+- Cross-functional alignment needed
+- Multiple perspectives valuable
+- Shared understanding required
+
+### Async Session (2-3 days)
+✅ **Use when**:
+- Distributed team
+- Deep thinking needed
+- Time zone challenges
+- Written documentation desired
+
+## Integration with Other QE Skills
+
+Works exceptionally well with:
+- `context-driven-testing` - Choose practices based on context
+- `risk-based-testing` - Prioritize using Black Hat
+- `exploratory-testing-advanced` - Use Green Hat for creative charters
+- `holistic-testing-pact` - Comprehensive quality model (all hats)
+
+## Key Benefits
+
+1. **Uncovers Blind Spots**: Each hat reveals different insights
+2. **Balances Perspectives**: Black Hat pessimism balanced by Yellow Hat optimism
+3. **Structures Discussion**: Prevents chaotic brainstorming
+4. **Builds Consensus**: Team alignment through shared process
+5. **Saves Time**: 30-90 min investment prevents days of rework
+6. **Validates Intuition**: Red Hat legitimizes gut feelings
+7. **Drives Creativity**: Green Hat forces innovative thinking
+
+## Common Pitfalls to Avoid
+
+❌ **Hat Mixing**: Combining perspectives (e.g., "Tests are passing (White) but I'm worried (Red)")
+- ✅ **Solution**: Strict separation, use timer
+
+❌ **Justifying Red Hat**: Rationalizing feelings instead of trusting intuition
+- ✅ **Solution**: "I feel X" not "I feel X because..."
+
+❌ **Skipping Hats**: "We don't need Green Hat"
+- ✅ **Solution**: Every hat reveals insights, wear all six
+
+❌ **Rushing**: 5 minutes for all hats
+- ✅ **Solution**: Minimum 5 min per hat, use timer
+
+❌ **Judging Contributions**: Criticizing ideas during Green Hat
+- ✅ **Solution**: All ideas valid, evaluate later in Blue Hat
+
+## Success Metrics
+
+A successful Six Hats session should produce:
+- ✅ 10+ facts documented (White Hat)
+- ✅ Honest feelings captured (Red Hat)
+- ✅ 5+ risks identified (Black Hat)
+- ✅ 3+ opportunities found (Yellow Hat)
+- ✅ 5+ creative ideas generated (Green Hat)
+- ✅ Clear action plan with owners (Blue Hat)
+
+## Resources
+
+### Templates
+- `resources/templates/solo-session-template.md` - Individual analysis
+- `resources/templates/team-session-template.md` - Team facilitation
+
+### Examples
+- `resources/examples/api-testing-example.md` - Complete worked example with real test strategy
+
+### Further Reading
+- **SKILL.md** - Complete documentation with all use cases
+- **"Six Thinking Hats" by Edward de Bono** - Original methodology
+- **"Context-Driven Testing"** - Related testing philosophy
+
+## Quick Tips
+
+1. **Use Timer**: Strict time boundaries improve quality
+2. **Start with Black Hat**: Teams love identifying risks
+3. **Trust Red Hat**: Intuition catches what analysis misses
+4. **Go Wild in Green Hat**: No idea too crazy
+5. **Close with Blue Hat**: Always end with action plan
+6. **Document Everything**: Especially Green Hat wild ideas
+7. **Practice Solo First**: Get comfortable before facilitating teams
+
+## Support
+
+- Main documentation: `SKILL.md`
+- Templates: `resources/templates/`
+- Examples: `resources/examples/`
+- Related skills: `context-driven-testing`, `risk-based-testing`, `exploratory-testing-advanced`
+
+---
+
+**Created**: 2025-11-13
+**Category**: Testing Methodologies
+**Difficulty**: Intermediate
+**Best Used With**: context-driven-testing, risk-based-testing, exploratory-testing-advanced