agentic-qe 3.8.1 → 3.8.3

package/assets/skills/security-watch/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: security-watch
+description: "Use when working on security-sensitive code to catch secrets, eval(), innerHTML, and other dangerous patterns before they're written. Activate with /security-watch for real-time security scanning."
+user-invocable: true
+---
+
+# Security Watch Mode
+
+When activated, scans every file write for common security anti-patterns and blocks dangerous code from being committed.
+
+## What It Does
+
+Flags or blocks writes containing:
+- **Secrets**: API keys, passwords, tokens, private keys in source code
+- **Dangerous functions**: `eval()`, `Function()`, `innerHTML`, `dangerouslySetInnerHTML`
+- **Injection vectors**: Unsanitized template literals in SQL/shell commands
+- **Insecure config**: `http://` URLs, disabled TLS verification, `*` CORS origins
+
+## Activation
+
+```
+/security-watch
+```
+
+## Hook Configuration
+
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "hook": ".claude/skills/security-watch/scripts/scan-security.sh"
+      }
+    ]
+  }
+}
+```
+
+## Detection Patterns
+
+```bash
+#!/bin/bash
+# scan-security.sh
+CONTENT="$1"
+ISSUES=0
+
+# Secrets detection
+SECRET_PATTERNS=(
+  'AKIA[0-9A-Z]{16}'                    # AWS Access Key
+  'sk-[a-zA-Z0-9]{48}'                  # OpenAI API Key
+  'ghp_[a-zA-Z0-9]{36}'                 # GitHub Personal Token
+  'password\s*[:=]\s*["\x27][^"\x27]+'  # Hardcoded passwords
+  'BEGIN (RSA |EC )?PRIVATE KEY'         # Private keys
+  'sk_live_[a-zA-Z0-9]+'                # Stripe secret key
+)
+
+for pattern in "${SECRET_PATTERNS[@]}"; do
+  if echo "$CONTENT" | grep -qP "$pattern"; then
+    echo "BLOCKED: Potential secret detected matching pattern: $pattern"
+    ISSUES=$((ISSUES + 1))
+  fi
+done
+
+# Dangerous functions
+DANGER_PATTERNS=(
+  '\beval\s*\('
+  '\bFunction\s*\('
+  '\.innerHTML\s*='
+  'dangerouslySetInnerHTML'
+  'child_process.*exec\('
+  '\$\{.*\}.*(?:SELECT|INSERT|UPDATE|DELETE)'
+)
+
+for pattern in "${DANGER_PATTERNS[@]}"; do
+  if echo "$CONTENT" | grep -qP "$pattern"; then
+    echo "WARNING: Dangerous pattern detected: $pattern"
+    ISSUES=$((ISSUES + 1))
+  fi
+done
+
+if [ $ISSUES -gt 0 ]; then
+  echo "Found $ISSUES security issues. Review before proceeding."
+  exit 1
+fi
+```
+
+## Gotchas
+
+- False positives on test fixtures that intentionally contain patterns like `eval()` — use `// security-watch:ignore` comment
+- Base64-encoded secrets won't be caught — this scans for plaintext patterns only
+- Template literal injection detection has false positives on safe string interpolation — review warnings carefully
+- This is a first line of defense, not a replacement for proper security review

package/assets/skills/security-watch/scripts/scan-security.sh

@@ -0,0 +1,46 @@
+#!/bin/bash
+# scan-security.sh — Security Watch hook
+# Scans file content for security anti-patterns before writes.
+# Called by PreToolUse hook on Write/Edit.
+
+CONTENT="$1"
+ISSUES=0
+
+if [ -z "$CONTENT" ]; then
+  CONTENT=$(cat)
+fi
+
+# Secret patterns
+for pattern in 'AKIA[0-9A-Z]{16}' 'sk-[a-zA-Z0-9]{48}' 'ghp_[a-zA-Z0-9]{36}' 'BEGIN (RSA |EC )?PRIVATE KEY' 'sk_live_[a-zA-Z0-9]+'; do
+  if echo "$CONTENT" | grep -qP "$pattern" 2>/dev/null; then
+    echo "BLOCKED: Potential secret detected (pattern: $pattern)"
+    ISSUES=$((ISSUES + 1))
+  fi
+done
+
+# Hardcoded password patterns
+if echo "$CONTENT" | grep -qP 'password\s*[:=]\s*["\x27][^"\x27]{3,}' 2>/dev/null; then
+  echo "BLOCKED: Possible hardcoded password detected"
+  ISSUES=$((ISSUES + 1))
+fi
+
+# Dangerous function patterns
+for pattern in '\beval\s*\(' '\bFunction\s*\(' '\.innerHTML\s*=' 'dangerouslySetInnerHTML'; do
+  if echo "$CONTENT" | grep -qP "$pattern" 2>/dev/null; then
+    echo "WARNING: Dangerous pattern: $pattern"
+    ISSUES=$((ISSUES + 1))
+  fi
+done
+
+# SQL injection risk
+if echo "$CONTENT" | grep -qP '\$\{.*\}.*(SELECT|INSERT|UPDATE|DELETE|DROP)' 2>/dev/null; then
+  echo "WARNING: Possible SQL injection — template literal in SQL query"
+  ISSUES=$((ISSUES + 1))
+fi
+
+if [ $ISSUES -gt 0 ]; then
+  echo "Found $ISSUES security issue(s). Review before proceeding."
+  exit 1
+fi
+
+exit 0

package/assets/skills/sherlock-review/SKILL.md

@@ -15,7 +15,6 @@ trust_tier: 2
 validation:
   schema_path: schemas/output.json
   validator_path: scripts/validate-config.json
-
 ---
 
 # Sherlock Review

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

@@ -16,7 +16,6 @@ validation:
   schema_path: schemas/output.json
   validator_path: scripts/validate-config.json
   eval_path: evals/shift-left-testing.yaml
-
 ---
 
 # Shift-Left Testing
@@ -24,21 +23,15 @@ validation:
 <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)
+2. WRITE tests before implementation (TDD)
 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
+4. 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
@@ -49,24 +42,6 @@ When implementing early testing practices:
 - 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 |
 |-------|----------|------|
@@ -104,65 +79,6 @@ jobs:
 
 ---
 
-## 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
@@ -226,6 +142,18 @@ const shiftLeftFleet = await FleetManager.coordinate({
 
 ## 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.
+
+## Skill Composition
+
+- **TDD practice** → Use `/tdd-london-chicago` for specific TDD guidance
+- **Generate tests** → Use `/qe-test-generation` for AI-powered test generation
+- **CI/CD quality** → Use `/cicd-pipeline-qe-orchestrator` for pipeline setup
+
+## Gotchas
+
+- "Shift left" doesn't mean "only test left" — production monitoring (shift right) is still needed
+- Agent generates tests before understanding requirements — tests for wrong behavior are worse than no tests
+- CI pipeline tests that take >10 minutes kill the feedback loop — keep commit-stage tests under 5 minutes
+- TDD discipline degrades when agent writes test+code simultaneously — enforce Red phase separation
+- Shifting left without lightweight environments just shifts the bottleneck — fix environments first

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

@@ -16,7 +16,6 @@ validation:
   schema_path: schemas/output.json
   validator_path: scripts/validate-config.json
   eval_path: evals/shift-right-testing.yaml
-
 ---
 
 # Shift-Right Testing

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

@@ -13,7 +13,6 @@ quick_reference_card: true
 tags: [thinking, methodology, decision-making, collaboration, analysis]
 trust_tier: 0
 validation:
-
 ---
 
 # Six Thinking Hats for Testing

package/assets/skills/skill-stats/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: skill-stats
+description: "Use when reviewing which QE skills are being used, finding undertriggering skills, or analyzing skill effectiveness. Shows usage patterns and recommendations."
+user-invocable: true
+---
+
+# Skill Usage Statistics
+
+View QE skill usage patterns to identify popular skills, undertriggering skills, and optimization opportunities.
+
+## Activation
+
+```
+/skill-stats
+```
+
+## What It Reports
+
+1. **Most Used Skills** — Top 10 skills by invocation count
+2. **Undertriggering Skills** — Skills with good descriptions but low usage
+3. **Never Used Skills** — Skills that have never been triggered
+4. **Trigger Method** — How skills are activated (explicit /command vs auto-selected)
+5. **Recommendations** — Skills to improve, merge, or deprecate
+
+## Usage Log Format
+
+Skill invocations are logged to `${CLAUDE_PLUGIN_DATA}/skill-usage.log`:
+
+```
+2026-03-18T10:30:00Z|security-testing|explicit|/security-testing
+2026-03-18T10:45:00Z|qe-test-generation|auto|model-selected
+2026-03-18T11:00:00Z|mutation-testing|explicit|/mutation-testing
+```
+
+## Hook Configuration
+
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Skill",
+        "hook": ".claude/skills/skill-stats/scripts/log-usage.sh"
+      }
+    ]
+  }
+}
+```
+
+## Analysis Script
+
+```bash
+#!/bin/bash
+# analyze-usage.sh
+LOG="${CLAUDE_PLUGIN_DATA:-$HOME/.claude/plugin-data}/skill-usage.log"
+
+if [ ! -f "$LOG" ]; then
+  echo "No usage data yet. Skills will be logged as they are used."
+  exit 0
+fi
+
+echo "=== Skill Usage Report ==="
+echo ""
+echo "Top 10 Most Used:"
+cut -d'|' -f2 "$LOG" | sort | uniq -c | sort -rn | head -10
+echo ""
+echo "Trigger Method Breakdown:"
+cut -d'|' -f3 "$LOG" | sort | uniq -c | sort -rn
+echo ""
+echo "Skills Used in Last 7 Days:"
+WEEK_AGO=$(date -d '7 days ago' +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -v-7d +%Y-%m-%dT%H:%M:%S)
+awk -F'|' -v since="$WEEK_AGO" '$1 >= since' "$LOG" | cut -d'|' -f2 | sort | uniq -c | sort -rn
+```
+
+## Gotchas
+
+- Log file grows unbounded — rotate periodically with `tail -n 1000 $LOG > $LOG.tmp && mv $LOG.tmp $LOG`
+- Auto-selected skills may not always be the best match — review undertriggering skills for description improvements
+- Usage count alone doesn't indicate quality — a skill used 100x but failing 50% needs fixing, not celebrating

package/assets/skills/strict-tdd/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: strict-tdd
+description: "Use when enforcing TDD discipline — blocks writing production code unless a failing test exists first. Activate with /strict-tdd to enable session-scoped Red-Green-Refactor guardrail."
+user-invocable: true
+---
+
+# Strict TDD Mode
+
+When activated, this skill registers a session-scoped hook that enforces Red-Green-Refactor discipline.
+
+## What It Does
+
+Blocks writes to `src/` (production code) unless:
+1. A test file exists that covers the target module
+2. That test has at least one failing assertion (Red phase confirmed)
+
+This prevents the common agent failure of writing test + implementation simultaneously.
+
+## Activation
+
+```
+/strict-tdd
+```
+
+Remains active for the current session only.
+
+## Hook Configuration
+
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "hook": ".claude/skills/strict-tdd/scripts/enforce-red-phase.sh",
+        "condition": "file matches src/**/*.{ts,js} AND NOT src/**/*.test.{ts,js}"
+      }
+    ]
+  }
+}
+```
+
+## Enforcement Logic
+
+```bash
+#!/bin/bash
+# enforce-red-phase.sh
+# Called before any Write/Edit to src/ files
+
+TARGET_FILE="$1"
+TEST_FILE="${TARGET_FILE%.ts}.test.ts"
+
+if [ ! -f "$TEST_FILE" ]; then
+  echo "BLOCKED: No test file found at $TEST_FILE"
+  echo "Write a failing test first (Red phase), then implement."
+  exit 1
+fi
+
+# Check if tests are currently failing (Red phase)
+npx jest "$TEST_FILE" --passWithNoTests 2>/dev/null
+if [ $? -eq 0 ]; then
+  echo "WARNING: Tests are passing. Are you in Green/Refactor phase?"
+  echo "If adding new behavior, write a failing test first."
+fi
+```
+
+## Gotchas
+
+- Only blocks src/ files — test files and config files are always writable
+- During Refactor phase, tests should still pass — this is expected, don't treat as violation
+- If test runner isn't installed, hook will error — ensure jest/vitest is available
+- Agent may try to write to a different path to bypass — the hook should match all production code paths

package/assets/skills/strict-tdd/scripts/enforce-red-phase.sh

@@ -0,0 +1,36 @@
+#!/bin/bash
+# enforce-red-phase.sh — Strict TDD hook
+# Blocks writes to src/ unless a corresponding test file exists and has failing tests.
+# Called by PreToolUse hook on Write/Edit to src/**/*.{ts,js}
+
+TARGET_FILE="$1"
+
+# Skip non-source files
+if [[ ! "$TARGET_FILE" =~ ^src/ ]] || [[ "$TARGET_FILE" =~ \.(test|spec)\.(ts|js|tsx|jsx)$ ]]; then
+  exit 0
+fi
+
+# Derive test file path
+TEST_FILE="${TARGET_FILE%.ts}.test.ts"
+if [ ! -f "$TEST_FILE" ]; then
+  TEST_FILE="${TARGET_FILE%.js}.test.js"
+fi
+
+if [ ! -f "$TEST_FILE" ]; then
+  echo "BLOCKED: No test file found for $TARGET_FILE"
+  echo "Expected: ${TARGET_FILE%.ts}.test.ts"
+  echo "Write a failing test first (Red phase), then implement."
+  exit 1
+fi
+
+# Check if tests are currently passing (should be failing in Red phase)
+npx jest "$TEST_FILE" --passWithNoTests --silent 2>/dev/null
+TEST_EXIT=$?
+
+if [ $TEST_EXIT -eq 0 ]; then
+  echo "WARNING: Tests in $TEST_FILE are all passing."
+  echo "If adding new behavior, write a failing test first (Red phase)."
+  echo "If in Green/Refactor phase, this is expected — proceed."
+fi
+
+exit 0

package/assets/skills/tdd-london-chicago/SKILL.md

@@ -15,7 +15,6 @@ trust_tier: 2
 validation:
   schema_path: schemas/output.json
   validator_path: scripts/validate-config.json
-
 ---
 
 # Test-Driven Development: London & Chicago Schools
@@ -247,3 +246,11 @@ const tddFleet = await FleetManager.coordinate({
 Neither is "right." Choose based on context. Mix as needed. Goal: well-designed, tested code.
 
 **With Agents:** Agents excel at generating tests, validating green phase, and suggesting refactorings. Use agents to maintain TDD discipline while humans focus on design decisions.
+
+## Gotchas
+
+- Agent skips Red phase and writes test + implementation together — enforce "test must fail first" by running test before writing code
+- London school over-mocking creates brittle tests that break on any refactor — mock at architectural boundaries, not every function
+- Chicago school tests become slow as integration scope grows — keep test boundaries tight
+- Agent defaults to jest.mock() for everything — prefer dependency injection for testability
+- Refactor phase is where agent cuts corners most — verify no behavior changes by checking test output is identical

package/assets/skills/technical-writing/SKILL.md

@@ -14,7 +14,6 @@ tags: [writing, documentation, communication, blogs, tutorials]
 trust_tier: 1
 validation:
   schema_path: schemas/output.json
-
 ---
 
 # Technical Writing

package/assets/skills/test-automation-strategy/SKILL.md

@@ -16,30 +16,22 @@ validation:
   schema_path: schemas/output.json
   validator_path: scripts/validate-config.json
   eval_path: evals/test-automation-strategy.yaml
-
 ---
 
 # Test Automation Strategy
 
 <default_to_action>
 When designing or improving test automation:
-1. FOLLOW test pyramid: 70% unit, 20% integration, 10% E2E
-2. APPLY F.I.R.S.T. principles: Fast, Isolated, Repeatable, Self-validating, Timely
-3. USE patterns: Page Object Model, Builder pattern, Factory pattern
-4. INTEGRATE in CI/CD: Every commit runs tests, fail fast, clear feedback
-5. MANAGE flaky tests: Quarantine, fix, or delete - never ignore
+1. DETECT anti-patterns: Ice cream cone? Slow suite? Flaky tests?
+2. USE patterns: Page Object Model, Builder pattern, Factory pattern
+3. INTEGRATE in CI/CD: Every commit runs tests, fail fast
+4. MANAGE flaky tests: Quarantine, fix, or delete - never ignore
 
 **Quick Anti-Pattern Detection:**
 - Ice cream cone (many E2E, few unit) → Invert to pyramid
 - Slow tests (> 10 min suite) → Parallelize, mock external deps
 - Flaky tests → Fix timing, isolate data, or quarantine
-- Test duplication → Share fixtures, use page objects
 - Brittle selectors → Use data-testid, semantic locators
-
-**Critical Success Factors:**
-- Fast feedback is the goal (< 10 min full suite)
-- Automation supports testing, doesn't replace judgment
-- Invest in test infrastructure like production code
 </default_to_action>
 
 ## Quick Reference Card
@@ -50,23 +42,7 @@ When designing or improving test automation:
 - Reducing flaky test burden
 - Optimizing CI/CD pipeline speed
 
-### Test Pyramid
-| Layer | % | Speed | Isolation | Examples |
-|-------|---|-------|-----------|----------|
-| **Unit** | 70% | < 1ms | Complete | Pure functions, logic |
-| **Integration** | 20% | < 1s | Partial | API, database |
-| **E2E** | 10% | < 30s | None | User journeys |
-
-### F.I.R.S.T. Principles
-| Principle | Meaning | How |
-|-----------|---------|-----|
-| **F**ast | Quick execution | Mock external deps |
-| **I**solated | No shared state | Fresh fixtures per test |
-| **R**epeatable | Same result every time | No random data |
-| **S**elf-validating | Clear pass/fail | Assert, don't print |
-| **T**imely | Written with code | TDD, not after |
-
-### Anti-Patterns
+### Anti-Patterns to Detect
 | Problem | Symptom | Fix |
 |---------|---------|-----|
 | Ice cream cone | 80% E2E, 10% unit | Invert pyramid |
@@ -77,40 +53,6 @@ When designing or improving test automation:
 
 ---
 
-## Page Object Model
-
-```javascript
-// pages/LoginPage.js
-class LoginPage {
-  constructor(page) {
-    this.page = page;
-    this.emailInput = '[data-testid="email"]';
-    this.passwordInput = '[data-testid="password"]';
-    this.submitButton = '[data-testid="submit"]';
-    this.errorMessage = '[data-testid="error"]';
-  }
-
-  async login(email, password) {
-    await this.page.fill(this.emailInput, email);
-    await this.page.fill(this.passwordInput, password);
-    await this.page.click(this.submitButton);
-  }
-
-  async getError() {
-    return this.page.textContent(this.errorMessage);
-  }
-}
-
-// Test uses page object
-test('shows error for invalid credentials', async ({ page }) => {
-  const loginPage = new LoginPage(page);
-  await loginPage.login('bad@email.com', 'wrong');
-  expect(await loginPage.getError()).toBe('Invalid credentials');
-});
-```
-
----
-
 ## CI/CD Integration
 
 ```yaml
@@ -231,6 +173,12 @@ const automationFleet = await FleetManager.coordinate({
 
 ## Remember
 
-**Pyramid: 70% unit, 20% integration, 10% E2E.** F.I.R.S.T. principles for every test. Page Object Model for E2E. Parallelize for speed. Quarantine flaky tests - never ignore them. Treat test code like production code.
-
 **With Agents:** Agents generate pyramid-compliant tests, detect flaky patterns, optimize execution time, and maintain test infrastructure. Use agents to scale automation quality.
+
+## Gotchas
+
+- Agent generates 80% E2E tests and 20% unit tests (inverted pyramid) — explicitly enforce 70/20/10 ratio
+- Page Object Model tests become brittle when selectors change — prefer data-testid attributes over CSS selectors
+- Flaky tests quarantined but never fixed is technical debt — set a 2-week SLA to fix or delete
+- Agent treats test code as second-class — test code needs the same review standards as production code
+- Parallel test execution requires test isolation — shared state between tests causes non-deterministic failures