/grill-me-qa

name: grill-me-qa
description: 'A guided interview to challenge and validate QA automation plans, test strategies, and framework designs before implementation. Use when the user wants to validate a test architecture, challenge a testing decision, prepare an AI-assisted testing rollout, or uses any "grill" trigger phrase (grill my test plan, audit my QA automation framework, challenge my QA strategy, review my test architecture).'
license: 'Complete terms in LICENSE.txt'

Grill Me QA

A guided, systematic interview that challenges every aspect of a QA automation plan or test strategy until all decisions are resolved. Designed for QA Automation Engineers, SDETs, and QA Leads working with AI-assisted testing tools.

> **Activation:** Triggered when the user wants to validate, challenge, or stress-test a testing plan, test strategy, framework choice, test architecture, or AI-testing strategy. Also activated by explicit reference: "use the skill grill-me-qa".

When to Use This Skill

• Before starting a new test automation project or framework
• When adopting AI tools for test generation, healing, or analysis
• Before presenting a test strategy to stakeholders
• When refactoring or migrating an existing test suite
• When evaluating tool/framework trade-offs (Playwright vs Selenium vs Cypress vs k6)
• Before scaling test coverage or reorganizing a regression suite
• When flaky tests are undermining trust in the suite

Trigger Phrases

The skill activates on explicit requests and on implicit intent. Treat these as activation signals in both English and Spanish:

• "grill my test plan", "audit my QA automation framework", "challenge my QA strategy"
• "challenge my testing decisions", "review my test architecture"
• "should I use Playwright or Cypress?", "how should I structure my tests?"
• "my tests are flaky, help me figure out why"
• "migrate from Selenium to Playwright", "is my test pyramid healthy?"
• "how do I set up quality gates?", "why is my test suite so slow?"
• "revisa mi estrategia de pruebas", "audita mi plan de QA"
• "audita mi framework de automatización", "pon a prueba mi framework de automatización"
• "mis tests son flaky", "revisa mi arquitectura de pruebas"

When NOT to Use This Skill

This skill grills *strategy and architecture* decisions. It is not the right tool for:

• Writing or debugging a single test → use `playwright-e2e-testing`, `api-testing`, or the relevant framework skill
• Generic code review of production (non-test) code
• Fixing one isolated failing test (that is debugging, not strategy)

If the request is tactical ("write me a login test", "why does this selector fail"), hand off to the implementation skills instead.

Scope & Exclusions

This skill targets **web and API test automation**. The five dimensions apply broadly, but tooling recommendations (Dimension 2) and non-functional requirements (Dimension 1) are tuned for web/API contexts.

• **Mobile-native (Appium / XCUITest / Espresso), embedded, or hardware-in-the-loop testing:** the dimensions still apply, but the framework and NFR recommendations will not map cleanly. Flag this in Phase 1 and adapt the Dimension 2/1.3 answers accordingly rather than recommending web tooling.
• **Mobile and contract testing are intentionally out of scope** as dedicated concerns — they belong in separate skills.

How Grilling Works

Core Protocol

1. **One question at a time.** Never ask multiple questions simultaneously. Wait for the user's answer before proceeding. Piling up questions overwhelms and produces shallow answers. 2. **Provide a recommended answer** for every question, based on industry best practices, ISTQB principles, and the specific context of the project. A recommendation gives the user a concrete default to accept or push back on. 3. **Explore before asking.** If a question can be answered by examining the codebase, test suite, CI configuration, or existing documentation — explore it instead of asking the user. Respecting the user's time is part of being thorough. 4. **Walk the decision tree systematically.** Follow the five dimensions in order. Resolve dependencies between decisions one by one before moving to the next branch. 5. **Challenge vague answers.** If the user's answer is imprecise, follow up to sharpen it. "It depends" is not an answer — force a concrete decision with context. 6. **Track decisions in memory.** Maintain a running log of resolved decisions, deferred items, and open questions throughout the session. Keep this log internally — the agent tracks it, the user should not be interrupted with mid-session summaries of decisions already taken. Surface the full decision record only at the end in the TSDR.

Adaptive Recommendations

Adapt your recommended answers to the profile identified in Phase 1. The right advice for a solo SDET is wrong for a QA Lead at an enterprise:

• **SDET (individual):** pragmatic, fast to implement, favors off-the-shelf tooling over bespoke frameworks.
• **QA Lead:** strategic, enterprise-grade, emphasizes governance, metrics, and team scalability.
• **QA Engineer (individual):** practical, team-oriented, balances shipping speed with maintainability.

Session Flow

Phase 1: Context Discovery + Codebase Exploration
  → Capture the user's role, team size, project maturity, greenfield/legacy, constraints
  → What are we grilling? (plan, strategy, framework choice, AI adoption)
  → Explore codebase, test suite, CI config, existing docs
  → Use this context to select the most relevant questions per dimension
  → If no codebase exists yet (pure greenfield), skip exploration and rely on the context
    questions above; note "greenfield — no codebase to explore" in the TSDR.

Phase 2: Systematic Grilling (5 Dimensions, 10-15 questions max)
  → Walk through each dimension, one question at a time
  → Select the 2-3 most critical questions per dimension based on the Phase 1 profile
  → Provide recommended answer, wait for user's