qaa-agent 1.6.1 → 1.6.3

package/.claude/skills/qa-learner/SKILL.md

@@ -1,150 +1,150 @@
----
-name: qa-learner
-description: "Learns from user corrections and saves persistent QA preferences. Triggers when user expresses frustration about repeated mistakes: 'ya te dije', 'te lo repeti', 'siempre te olvidas', 'otra vez lo mismo', 'I already told you', 'stop doing X', 'always do X', 'never do X', 'remember this'. Saves rules to ~/.claude/qaa/MY_PREFERENCES.md which all QA agents read before generating output."
----
-
-# QA Learner — Persistent Preferences from User Corrections
-
-## When This Skill Activates
-
-Trigger on ANY of these patterns (Spanish or English):
-
-**Frustration / repetition signals:**
-- "ya te dije", "ya te lo dije", "te lo repeti", "otra vez", "siempre te olvidas"
-- "cuantas veces te tengo que decir", "de nuevo lo mismo", "ya hablamos de esto"
-- "I already told you", "I've said this before", "again?", "how many times"
-- "stop doing X", "don't do X", "never do X", "always do X"
-- "remember this", "don't forget", "from now on", "de ahora en mas"
-- "acordate", "no te olvides", "a partir de ahora", "siempre hacelo asi"
-
-**Explicit preference setting:**
-- "I prefer X over Y", "prefiero X", "use X not Y", "usa X no Y"
-- "the standard is X", "el estandar es X", "we always use X"
-
-## What To Do When Triggered
-
-### Step 1: Acknowledge the correction immediately
-
-Say something like: "Entendido, lo guardo para no repetirlo." or "Got it, saving this preference."
-
-Do NOT be defensive. Do NOT explain why you made the mistake. Just acknowledge and save.
-
-### Step 2: Extract the rule
-
-From the user's message, extract:
-- **What was wrong** (what you did that they're correcting)
-- **What's correct** (what they want instead)
-- **Category** (language, framework, naming, assertions, locators, format, workflow, other)
-
-If you're not sure what exactly they want saved, ASK:
-
-"Quiero guardar esta preferencia para no repetir el error. Lo que entiendo es:
-- Regla: [your interpretation]
-- Categoria: [category]
-Es correcto o lo ajusto?"
-
-### Step 3: Read existing preferences
-
-```bash
-cat ~/.claude/qaa/MY_PREFERENCES.md 2>/dev/null || echo "FILE_NOT_FOUND"
-```
-
-If FILE_NOT_FOUND, create the file with the header template (see below).
-
-### Step 4: Add the new rule
-
-Append the rule to the correct category section. If the category doesn't exist, create it.
-
-Format for each rule:
-```
-- [RULE] — (added [YYYY-MM-DD], context: "[what triggered this]")
-```
-
-### Step 5: Confirm
-
-Tell the user: "Guardado. Esto aplica para todas las sesiones futuras en esta maquina."
-
-## Preferences File Template
-
-When creating `~/.claude/qaa/MY_PREFERENCES.md` for the first time:
-
-```markdown
-# My QA Preferences
-
-Personal preferences for the QA Automation Agent. This file is LOCAL — never committed to any repo.
-All QA agents read this file before generating output.
-
-Last updated: [YYYY-MM-DD]
-
-## Language
-<!-- Rules about language: English vs Spanish, terminology, tone -->
-
-## Framework
-<!-- Preferred test frameworks, libraries, tools -->
-
-## Naming
-<!-- Naming conventions for tests, files, IDs -->
-
-## Assertions
-<!-- Rules about assertion style and specificity -->
-
-## Locators
-<!-- Preferred locator strategies for E2E tests -->
-
-## Format
-<!-- Output format preferences: file structure, comments, organization -->
-
-## Workflow
-<!-- Process preferences: what to ask, what to skip, how to present results -->
-
-## Other
-<!-- Anything that doesn't fit above -->
-```
-
-## How Other Agents Use This
-
-Every QA agent (scanner, analyzer, executor, validator, etc.) should check for this file at the start:
-
-```
-If ~/.claude/qaa/MY_PREFERENCES.md exists:
-  Read it before generating any output.
-  Apply all rules found.
-  If a rule conflicts with CLAUDE.md, the PREFERENCE wins (it's a user override).
-```
-
-The preference file is the user's personal override layer on top of the project's CLAUDE.md standards.
-
-## Examples
-
-**User says:** "Ya te dije que todo en ingles!"
-**Extract:** Language rule — all output in English
-**Save:** `## Language\n- All test cases, comments, documentation, and reports must be in ENGLISH — (added 2026-03-24, context: "user corrected language to English")`
-
-**User says:** "Stop using CSS selectors, use data-testid"
-**Extract:** Locator rule — data-testid over CSS
-**Save:** `## Locators\n- Never use CSS class selectors (.btn, .form-control). Always use data-testid first — (added 2026-03-24, context: "user corrected locator strategy")`
-
-**User says:** "Prefiero Playwright, no me pongas Cypress"
-**Extract:** Framework rule — Playwright over Cypress
-**Save:** `## Framework\n- Use Playwright for all E2E tests. Never suggest or use Cypress — (added 2026-03-24, context: "user prefers Playwright over Cypress")`
-
-**User says:** "Los test tienen que tener el ID siempre al principio del nombre"
-**Extract:** Naming rule — test ID at start of name
-**Save:** `## Naming\n- Test ID must appear at the beginning of the test name (e.g., "UT-AUTH-001: should validate email format") — (added 2026-03-24, context: "user wants ID at start of test name")`
-
-**User says:** "Las branches tienen que ser feature/{ticket}-{description}"
-**Extract:** Workflow rule — branch naming convention
-**Save:** `## Workflow\n- Branch naming convention: feature/{ticket}-{description} — (added 2026-03-24, context: "user configured branch pattern for /qa-pr")`
-
-**User says:** "Nuestras ramas siempre empiezan con test/ y el ticket de Jira"
-**Extract:** Workflow rule — branch naming convention
-**Save:** `## Workflow\n- Branch naming convention: test/{ticket}-{description} — (added 2026-03-24, context: "user specified branch pattern with Jira ticket prefix")`
-
-## Important Rules
-
-1. **NEVER push MY_PREFERENCES.md to any repo** — it's personal
-2. **If unsure what to save, ASK** — don't guess wrong and save a bad rule
-3. **Rules accumulate** — never delete old rules unless the user explicitly says to
-4. **User preference > CLAUDE.md** — if the user says "use Cypress" but CLAUDE.md says "use Playwright", the user wins
-5. **One rule per line** — keep it scannable
-6. **Include the date and context** — so the user can review later why a rule exists
+---
+name: qa-learner
+description: "Learns from user corrections and saves persistent QA preferences. Triggers when user expresses frustration about repeated mistakes: 'ya te dije', 'te lo repeti', 'siempre te olvidas', 'otra vez lo mismo', 'I already told you', 'stop doing X', 'always do X', 'never do X', 'remember this'. Saves rules to ~/.claude/qaa/MY_PREFERENCES.md which all QA agents read before generating output."
+---
+
+# QA Learner — Persistent Preferences from User Corrections
+
+## When This Skill Activates
+
+Trigger on ANY of these patterns (Spanish or English):
+
+**Frustration / repetition signals:**
+- "ya te dije", "ya te lo dije", "te lo repeti", "otra vez", "siempre te olvidas"
+- "cuantas veces te tengo que decir", "de nuevo lo mismo", "ya hablamos de esto"
+- "I already told you", "I've said this before", "again?", "how many times"
+- "stop doing X", "don't do X", "never do X", "always do X"
+- "remember this", "don't forget", "from now on", "de ahora en mas"
+- "acordate", "no te olvides", "a partir de ahora", "siempre hacelo asi"
+
+**Explicit preference setting:**
+- "I prefer X over Y", "prefiero X", "use X not Y", "usa X no Y"
+- "the standard is X", "el estandar es X", "we always use X"
+
+## What To Do When Triggered
+
+### Step 1: Acknowledge the correction immediately
+
+Say something like: "Entendido, lo guardo para no repetirlo." or "Got it, saving this preference."
+
+Do NOT be defensive. Do NOT explain why you made the mistake. Just acknowledge and save.
+
+### Step 2: Extract the rule
+
+From the user's message, extract:
+- **What was wrong** (what you did that they're correcting)
+- **What's correct** (what they want instead)
+- **Category** (language, framework, naming, assertions, locators, format, workflow, other)
+
+If you're not sure what exactly they want saved, ASK:
+
+"Quiero guardar esta preferencia para no repetir el error. Lo que entiendo es:
+- Regla: [your interpretation]
+- Categoria: [category]
+Es correcto o lo ajusto?"
+
+### Step 3: Read existing preferences
+
+```bash
+cat ~/.claude/qaa/MY_PREFERENCES.md 2>/dev/null || echo "FILE_NOT_FOUND"
+```
+
+If FILE_NOT_FOUND, create the file with the header template (see below).
+
+### Step 4: Add the new rule
+
+Append the rule to the correct category section. If the category doesn't exist, create it.
+
+Format for each rule:
+```
+- [RULE] — (added [YYYY-MM-DD], context: "[what triggered this]")
+```
+
+### Step 5: Confirm
+
+Tell the user: "Guardado. Esto aplica para todas las sesiones futuras en esta maquina."
+
+## Preferences File Template
+
+When creating `~/.claude/qaa/MY_PREFERENCES.md` for the first time:
+
+```markdown
+# My QA Preferences
+
+Personal preferences for the QA Automation Agent. This file is LOCAL — never committed to any repo.
+All QA agents read this file before generating output.
+
+Last updated: [YYYY-MM-DD]
+
+## Language
+<!-- Rules about language: English vs Spanish, terminology, tone -->
+
+## Framework
+<!-- Preferred test frameworks, libraries, tools -->
+
+## Naming
+<!-- Naming conventions for tests, files, IDs -->
+
+## Assertions
+<!-- Rules about assertion style and specificity -->
+
+## Locators
+<!-- Preferred locator strategies for E2E tests -->
+
+## Format
+<!-- Output format preferences: file structure, comments, organization -->
+
+## Workflow
+<!-- Process preferences: what to ask, what to skip, how to present results -->
+
+## Other
+<!-- Anything that doesn't fit above -->
+```
+
+## How Other Agents Use This
+
+Every QA agent (scanner, analyzer, executor, validator, etc.) should check for this file at the start:
+
+```
+If ~/.claude/qaa/MY_PREFERENCES.md exists:
+  Read it before generating any output.
+  Apply all rules found.
+  If a rule conflicts with CLAUDE.md, the PREFERENCE wins (it's a user override).
+```
+
+The preference file is the user's personal override layer on top of the project's CLAUDE.md standards.
+
+## Examples
+
+**User says:** "Ya te dije que todo en ingles!"
+**Extract:** Language rule — all output in English
+**Save:** `## Language\n- All test cases, comments, documentation, and reports must be in ENGLISH — (added 2026-03-24, context: "user corrected language to English")`
+
+**User says:** "Stop using CSS selectors, use data-testid"
+**Extract:** Locator rule — data-testid over CSS
+**Save:** `## Locators\n- Never use CSS class selectors (.btn, .form-control). Always use data-testid first — (added 2026-03-24, context: "user corrected locator strategy")`
+
+**User says:** "Prefiero Playwright, no me pongas Cypress"
+**Extract:** Framework rule — Playwright over Cypress
+**Save:** `## Framework\n- Use Playwright for all E2E tests. Never suggest or use Cypress — (added 2026-03-24, context: "user prefers Playwright over Cypress")`
+
+**User says:** "Los test tienen que tener el ID siempre al principio del nombre"
+**Extract:** Naming rule — test ID at start of name
+**Save:** `## Naming\n- Test ID must appear at the beginning of the test name (e.g., "UT-AUTH-001: should validate email format") — (added 2026-03-24, context: "user wants ID at start of test name")`
+
+**User says:** "Las branches tienen que ser feature/{ticket}-{description}"
+**Extract:** Workflow rule — branch naming convention
+**Save:** `## Workflow\n- Branch naming convention: feature/{ticket}-{description} — (added 2026-03-24, context: "user configured branch pattern for /qa-pr")`
+
+**User says:** "Nuestras ramas siempre empiezan con test/ y el ticket de Jira"
+**Extract:** Workflow rule — branch naming convention
+**Save:** `## Workflow\n- Branch naming convention: test/{ticket}-{description} — (added 2026-03-24, context: "user specified branch pattern with Jira ticket prefix")`
+
+## Important Rules
+
+1. **NEVER push MY_PREFERENCES.md to any repo** — it's personal
+2. **If unsure what to save, ASK** — don't guess wrong and save a bad rule
+3. **Rules accumulate** — never delete old rules unless the user explicitly says to
+4. **User preference > CLAUDE.md** — if the user says "use Cypress" but CLAUDE.md says "use Playwright", the user wins
+5. **One rule per line** — keep it scannable
+6. **Include the date and context** — so the user can review later why a rule exists

package/.claude/skills/qa-repo-analyzer/SKILL.md

@@ -1,88 +1,88 @@
----
-name: qa-repo-analyzer
-description: QA Repository Analyzer. Analyzes a dev repository and produces a complete QA baseline package including testability report, test inventory, and repo blueprint. Use when user wants to analyze a repo for testing, assess testability, generate test inventory, create QA baseline, understand test coverage needs, evaluate a codebase for QA, or produce a testing strategy. Triggers on "analyze repo", "testability report", "test inventory", "QA analysis", "QA baseline", "coverage assessment", "what should we test", "testing strategy".
----
-
-# QA Repository Analyzer
-
-## Purpose
-
-Analyze a developer repository and produce a complete QA baseline package: Testability Report, Test Inventory (pyramid-based), and QA Repo Blueprint.
-
-## Core Rule
-
-**Every analysis must be specific to the actual codebase — never generic advice. Every test case must have an explicit expected outcome.**
-
-## Execution Steps
-
-### Step 0: Collect Repo Context
-
-Scan the repository systematically:
-- Folder tree (entry points, structure)
-- Package files (dependencies, scripts, framework detection)
-- Service/controller files (API surface area)
-- Model files (data structures, validation)
-- Database layer (ORM, migrations, schemas)
-- External integrations (payment, email, storage, queues)
-- Existing test coverage (test files, config, CI)
-- Configuration (env vars, feature flags)
-
-### Step 1: Pre-Analysis — Assumptions & Questions
-
-Before generating deliverables, list:
-- **Assumptions**: What you're inferring from the code (e.g., "Auth uses JWT based on middleware")
-- **Questions**: What's ambiguous (e.g., "Is the Stripe integration in production or test mode?")
-
-Present to user for confirmation before proceeding.
-
-### Step 2: Deliverable A — QA_ANALYSIS.md (Testability Report)
-
-Produce with ALL these sections:
-- **Architecture Overview**: System type, language, runtime, entry points table, internal layers
-- **External Dependencies**: Table with purpose and risk level (HIGH/MEDIUM/LOW)
-- **Risk Assessment**: Prioritized risks with justification
-- **Top 10 Unit Test Targets**: Table with module/function, why it's high-priority, complexity assessment
-- **API/Contract Test Targets**: Endpoints that need contract testing
-- **Recommended Testing Pyramid**: Percentages adjusted to this specific app's architecture
-
-### Step 3: Deliverable B — TEST_INVENTORY.md (Test Cases)
-
-Generate pyramid-based test inventory:
-
-**Unit Tests** (60-70%): For each target:
-- Test ID (UT-MODULE-NNN)
-- Target (file path + function)
-- What to validate
-- Concrete inputs
-- Mocks needed
-- Explicit expected outcome
-
-**Integration/Contract Tests** (10-15%): Component interactions, API contracts
-
-**API Tests** (20-25%): For each endpoint:
-- Test ID (API-RESOURCE-NNN)
-- Method + endpoint
-- Request body/params
-- Expected status + response shape
-
-**E2E Smoke Tests** (3-5%): Max 3-8 critical user paths
-
-### Step 4: QA_REPO_BLUEPRINT.md
-
-If no QA repo exists, generate:
-- Suggested repo name and folder structure
-- Recommended stack (framework, runner, reporter)
-- Config files needed
-- Execution scripts (npm scripts, CI commands)
-- CI/CD strategy (smoke on PR, regression nightly)
-- Definition of Done checklist
-
-## Quality Gate
-
-- [ ] Architecture overview matches actual codebase (not generic)
-- [ ] Every test case has explicit expected outcome with concrete values
-- [ ] No vague assertions ("works correctly", "returns proper data")
-- [ ] Test IDs follow naming convention
-- [ ] Priority (P0/P1/P2) assigned to every test case
-- [ ] Risks are specific with evidence from the code
-- [ ] Testing pyramid percentages are justified for this architecture
+---
+name: qa-repo-analyzer
+description: QA Repository Analyzer. Analyzes a dev repository and produces a complete QA baseline package including testability report, test inventory, and repo blueprint. Use when user wants to analyze a repo for testing, assess testability, generate test inventory, create QA baseline, understand test coverage needs, evaluate a codebase for QA, or produce a testing strategy. Triggers on "analyze repo", "testability report", "test inventory", "QA analysis", "QA baseline", "coverage assessment", "what should we test", "testing strategy".
+---
+
+# QA Repository Analyzer
+
+## Purpose
+
+Analyze a developer repository and produce a complete QA baseline package: Testability Report, Test Inventory (pyramid-based), and QA Repo Blueprint.
+
+## Core Rule
+
+**Every analysis must be specific to the actual codebase — never generic advice. Every test case must have an explicit expected outcome.**
+
+## Execution Steps
+
+### Step 0: Collect Repo Context
+
+Scan the repository systematically:
+- Folder tree (entry points, structure)
+- Package files (dependencies, scripts, framework detection)
+- Service/controller files (API surface area)
+- Model files (data structures, validation)
+- Database layer (ORM, migrations, schemas)
+- External integrations (payment, email, storage, queues)
+- Existing test coverage (test files, config, CI)
+- Configuration (env vars, feature flags)
+
+### Step 1: Pre-Analysis — Assumptions & Questions
+
+Before generating deliverables, list:
+- **Assumptions**: What you're inferring from the code (e.g., "Auth uses JWT based on middleware")
+- **Questions**: What's ambiguous (e.g., "Is the Stripe integration in production or test mode?")
+
+Present to user for confirmation before proceeding.
+
+### Step 2: Deliverable A — QA_ANALYSIS.md (Testability Report)
+
+Produce with ALL these sections:
+- **Architecture Overview**: System type, language, runtime, entry points table, internal layers
+- **External Dependencies**: Table with purpose and risk level (HIGH/MEDIUM/LOW)
+- **Risk Assessment**: Prioritized risks with justification
+- **Top 10 Unit Test Targets**: Table with module/function, why it's high-priority, complexity assessment
+- **API/Contract Test Targets**: Endpoints that need contract testing
+- **Recommended Testing Pyramid**: Percentages adjusted to this specific app's architecture
+
+### Step 3: Deliverable B — TEST_INVENTORY.md (Test Cases)
+
+Generate pyramid-based test inventory:
+
+**Unit Tests** (60-70%): For each target:
+- Test ID (UT-MODULE-NNN)
+- Target (file path + function)
+- What to validate
+- Concrete inputs
+- Mocks needed
+- Explicit expected outcome
+
+**Integration/Contract Tests** (10-15%): Component interactions, API contracts
+
+**API Tests** (20-25%): For each endpoint:
+- Test ID (API-RESOURCE-NNN)
+- Method + endpoint
+- Request body/params
+- Expected status + response shape
+
+**E2E Smoke Tests** (3-5%): Max 3-8 critical user paths
+
+### Step 4: QA_REPO_BLUEPRINT.md
+
+If no QA repo exists, generate:
+- Suggested repo name and folder structure
+- Recommended stack (framework, runner, reporter)
+- Config files needed
+- Execution scripts (npm scripts, CI commands)
+- CI/CD strategy (smoke on PR, regression nightly)
+- Definition of Done checklist
+
+## Quality Gate
+
+- [ ] Architecture overview matches actual codebase (not generic)
+- [ ] Every test case has explicit expected outcome with concrete values
+- [ ] No vague assertions ("works correctly", "returns proper data")
+- [ ] Test IDs follow naming convention
+- [ ] Priority (P0/P1/P2) assigned to every test case
+- [ ] Risks are specific with evidence from the code
+- [ ] Testing pyramid percentages are justified for this architecture