qa-skills 3.0.0

package/skills/qa-diagram-generator/references/sequence.md

@@ -0,0 +1,69 @@
+# Mermaid Sequence Diagram Syntax — QA Use Cases
+
+## Syntax Overview
+
+Sequence diagrams use `sequenceDiagram`. Participants: `participant A`, `actor User`. Messages: `A->>B: message`, `A-->>B: async`, `A->>+B: create`, `A->>-B: destroy`. Loops: `loop`, `alt`, `opt`, `par`.
+
+```mermaid
+sequenceDiagram
+    participant U as User
+    participant A as API
+    U->>A: request
+    A-->>U: response
+```
+
+## Example 1: API Interaction
+
+```mermaid
+sequenceDiagram
+    participant T as Test
+    participant API as REST API
+    participant DB as Database
+    T->>API: POST /users
+    API->>DB: INSERT user
+    DB-->>API: OK
+    API-->>T: 201 Created
+```
+
+## Example 2: Login Flow
+
+```mermaid
+sequenceDiagram
+    participant U as User
+    participant UI as Frontend
+    participant Auth as Auth Service
+    participant DB as Database
+    U->>UI: Enter credentials
+    UI->>Auth: POST /login
+    Auth->>DB: Validate
+    alt Valid
+        DB-->>Auth: User
+        Auth-->>UI: JWT
+        UI-->>U: Redirect
+    else Invalid
+        Auth-->>UI: 401
+        UI-->>U: Error message
+    end
+```
+
+## Example 3: Test Execution Flow
+
+```mermaid
+sequenceDiagram
+    participant CI as CI Runner
+    participant Runner as Test Runner
+    participant SUT as System
+    CI->>Runner: Execute suite
+    loop Each test
+        Runner->>SUT: Setup
+        Runner->>SUT: Execute
+        Runner->>Runner: Assert
+    end
+    Runner-->>CI: Results
+```
+
+## When to Use
+
+- **API flows:** Request/response, error paths
+- **Auth flows:** Login, token refresh, logout
+- **Test execution:** Setup → act → assert sequence

package/skills/qa-diagram-generator/references/state-diagram.md

@@ -0,0 +1,56 @@
+# Mermaid State Diagram Syntax — QA Use Cases
+
+## Syntax Overview
+
+State diagrams use `stateDiagram-v2`. States: `state "Name" as id`. Transitions: `id --> id2 : event`. Composite: `state state_name { [*] --> s1; s1 --> s2 }`. Choice: `[*] --> choice`, `choice --> s1 : cond`.
+
+```mermaid
+stateDiagram-v2
+    [*] --> Idle
+    Idle --> Running : start
+    Running --> Idle : stop
+```
+
+## Example 1: Bug Lifecycle
+
+```mermaid
+stateDiagram-v2
+    [*] --> New
+    New --> InProgress : Assign
+    InProgress --> InReview : Submit
+    InReview --> InProgress : Reject
+    InReview --> Done : Approve
+    Done --> InProgress : Reopen
+```
+
+## Example 2: Test Case States
+
+```mermaid
+stateDiagram-v2
+    [*] --> Draft
+    Draft --> Ready : Review
+    Ready --> Executing : Run
+    Executing --> Passed : Pass
+    Executing --> Failed : Fail
+    Executing --> Blocked : Block
+    Passed --> Ready : Rerun
+    Failed --> Ready : Rerun
+    Blocked --> Ready : Unblock
+```
+
+## Example 3: User Session States
+
+```mermaid
+stateDiagram-v2
+    [*] --> Anonymous
+    Anonymous --> Authenticated : Login
+    Authenticated --> Anonymous : Logout
+    Authenticated --> Expired : Timeout
+    Expired --> Anonymous : Re-login
+```
+
+## When to Use
+
+- **Bug lifecycle:** New → In Progress → Done
+- **Test case states:** Draft, Ready, Executing, Passed/Failed
+- **Session/auth states:** Anonymous, Authenticated, Expired

package/skills/qa-discovery-interview/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: qa-discovery-interview
+description: QA-adapted discovery interview that transforms vague context into structured QA briefs through iterative questioning. Works standalone or as an embedded service auto-triggered by other skills when input is insufficient.
+output_dir: docs/briefs
+---
+
+# QA Discovery Interview
+
+## Purpose
+
+QA-adapted discovery interview that transforms vague project context into a structured QA brief through iterative, category-driven questioning. Works in two modes:
+- **Standalone:** User directly starts an interview for a new project or feature
+- **Embedded:** Other skills auto-delegate here when their input is insufficient (<3 sentences or missing critical context)
+
+## Trigger Phrases
+
+- "Start QA discovery interview"
+- "Interview me about the project"
+- "I need to set up QA for a new project"
+- "Help me define testing scope"
+- "QA brief for [project/feature]"
+- "What should we test?"
+- "New project QA setup"
+
+## Dual-Use Pattern
+
+| Mode | Trigger | Output |
+|------|---------|--------|
+| **Standalone** | User: "Start a QA discovery interview for our payment system" | Full QA Discovery Brief |
+| **Embedded** | qa-requirements-generator receives <3 sentences of input | Notify user → offer interview → feed brief back to calling skill |
+
+### Embedding Pattern for Other Skills
+
+When another skill detects insufficient input:
+
+1. Notify user: "Not enough context for quality output."
+2. Offer: "I can run a QA discovery interview, or you can provide more details manually."
+3. If interview chosen → run interview → feed QA Brief output back into the calling skill.
+
+Skills that auto-trigger this interview:
+- `qa-requirements-generator` (from-description mode with <3 sentences)
+- `qa-spec-writer` (ambiguous requirements or incomplete acceptance criteria)
+- `qa-plan-creator` (no requirements, no codebase, no prior docs)
+- `qa-test-strategy` (first run on a project with no existing docs)
+- `qa-orchestrator` (full-cycle pipeline with no existing QA documentation)
+
+## Interview Phases
+
+| Phase | Name | Description |
+|-------|------|-------------|
+| 1 | **Initial QA Orientation** | 2-3 broad questions: what are we testing, who are stakeholders, new or existing project |
+| 2 | **Category Deep Dive** | 8 QA categories, 2-4 questions each (see `references/qa-categories.md`) |
+| 3 | **Research Loops** | When uncertainty detected — research codebase/docs, return with informed questions |
+| 4 | **Conflict Resolution** | Resolve priority conflicts, scope creep, unrealistic expectations |
+| 5 | **Completeness Check** | QA-specific checklist before generating output (see `references/completeness-checklist.md`) |
+| 6 | **QA Brief Generation** | Structured document that feeds Phase 1 skills |
+
+## Workflow
+
+### Phase 1: Initial QA Orientation (2-3 questions)
+
+Start with broad orientation to establish context:
+
+1. "What product/feature are we testing? Give me a brief overview."
+2. "Is this a new project, an existing one, or a migration? What's the current state?"
+3. "Who are the key stakeholders, and what are their quality expectations?"
+
+Based on answers, determine which of the 8 categories need deepest exploration.
+
+### Phase 2: Category Deep Dive
+
+Work through 8 QA categories adaptively. Skip or abbreviate categories where context is already clear. Spend more time on gaps and risk areas.
+
+See `references/qa-categories.md` for full question sets per category.
+
+**Category summary:**
+
+| Cat | Name | Focus |
+|-----|------|-------|
+| A | Problem & Product | Business context, impact of defects |
+| B | Testing Scope & Objectives | Testing types needed, in/out scope |
+| C | User Flows & Critical Paths | Core scenarios, happy/unhappy paths |
+| D | Technical Landscape | Stack, architecture, constraints, APIs |
+| E | Existing QA Processes | Current CI/CD, automation, tools |
+| F | Risk Areas & Priorities | Defect-prone areas, business criticality |
+| G | Team, Tools & Infrastructure | Team expertise, environments, tools |
+| H | Compliance & Standards | WCAG, OWASP, ISO, GDPR, industry |
+
+**Adaptive behavior:**
+- Ask 2-4 questions per category (not all at once — batch by relevance)
+- After each answer, decide: go deeper, move to next category, or trigger research loop
+- When answer reveals uncertainty: pause, research (read code, docs, URLs), return with informed follow-up
+
+### Phase 3: Research Loops
+
+When the interviewee mentions something that requires verification:
+
+1. Read codebase (project structure, API routes, test files, configs)
+2. Navigate URLs via Playwright MCP (if a live app exists)
+3. Read documentation files in the project
+4. Return with specific, informed follow-up questions
+
+### Phase 4: Conflict Resolution
+
+Identify and resolve conflicts in stated requirements:
+
+- Scope vs timeline conflicts ("we want full coverage in 2 days")
+- Priority misalignment (everything is "critical")
+- Unrealistic automation expectations
+- Missing infrastructure for stated testing types
+
+See `references/conflict-patterns.md` for common patterns and resolution strategies.
+
+### Phase 5: Completeness Check
+
+Before generating the brief, verify all critical areas are covered. See `references/completeness-checklist.md`.
+
+### Phase 6: QA Brief Generation
+
+Generate the structured QA Discovery Brief using `templates/qa-brief-template.md`.
+
+## Output
+
+**QA Discovery Brief** (markdown) — the primary handoff document. Contains:
+- Project/product overview
+- Testing scope and objectives
+- Critical user flows and scenarios
+- Technical constraints and environment
+- Risk assessment and priorities
+- Compliance requirements
+- Recommended testing types and approach
+- Team and infrastructure summary
+
+This brief feeds directly into: `qa-requirements-generator`, `qa-spec-writer`, `qa-plan-creator`, `qa-test-strategy`.
+
+## MCP Tools Used
+
+- **Sequential Thinking MCP:** Structured reasoning during deep dive and conflict resolution
+- **Playwright MCP:** Research loops — navigate live app to verify answers
+- **Filesystem MCP:** Research loops — read codebase, docs, configs
+- **Memory MCP:** Persist interview state for multi-session interviews
+
+## Scope
+
+**Can do (autonomous):**
+- Conduct full discovery interview through all 6 phases
+- Adapt question depth based on answers
+- Research codebase and live app during interview
+- Generate structured QA Discovery Brief
+- Serve as embedded service for other skills
+
+**Cannot do (requires confirmation):**
+- Make scope decisions on behalf of stakeholders
+- Set final priorities without stakeholder input
+- Skip categories the user explicitly wants to discuss
+
+**Will not do (out of scope):**
+- Write test code or create test cases (hand off to downstream skills)
+- Modify production systems
+- Make business decisions about product direction
+
+## Quality Checklist
+
+- [ ] All 8 QA categories addressed (or explicitly marked N/A with rationale)
+- [ ] Critical user flows identified and documented
+- [ ] Risk areas ranked by business impact
+- [ ] Technical stack and constraints captured
+- [ ] Testing type recommendations align with project context
+- [ ] Compliance requirements identified (or confirmed none apply)
+- [ ] No ambiguous or conflicting statements in final brief
+- [ ] Brief is sufficient for downstream skills to operate without additional input
+
+## Troubleshooting
+
+| Symptom | Likely Cause | Fix |
+|---------|--------------|-----|
+| Interview feels too long | Too many categories explored in depth | Adapt: skip/abbreviate clear categories, focus on gaps |
+| Interviewee gives vague answers | Unclear questions or unfamiliar domain | Rephrase with concrete examples; offer multiple-choice options |
+| Conflicting priorities discovered | Stakeholder misalignment | Enter Phase 4: present conflicts explicitly, ask for resolution |
+| Research loop finds no codebase | New project, no code yet | Skip code research, focus on specs/mockups/descriptions |
+| Embedded trigger too aggressive | Skill triggers interview on minimal input | Check threshold: <3 sentences AND missing critical context (both conditions) |
+| Brief too shallow for downstream | Rushed interview or skipped categories | Re-run completeness check, fill gaps with follow-up questions |

package/skills/qa-discovery-interview/references/completeness-checklist.md

@@ -0,0 +1,53 @@
+# QA Discovery Interview — Completeness Checklist
+
+Verify all critical areas are covered before generating the QA Discovery Brief. Each item must be either answered or explicitly marked N/A with rationale.
+
+## Critical (Must Have)
+
+| # | Area | Question | Status | Notes |
+|---|------|----------|--------|-------|
+| 1 | Product Overview | Do we know what the product/feature does? | {{Yes/No/Partial}} | |
+| 2 | Testing Scope | Are testing types and boundaries defined? | {{Yes/No/Partial}} | |
+| 3 | Critical Flows | Are top 3 user journeys identified? | {{Yes/No/Partial}} | |
+| 4 | Tech Stack | Do we know frontend, backend, DB, and key integrations? | {{Yes/No/Partial}} | |
+| 5 | Risk Areas | Are high-risk areas identified and ranked? | {{Yes/No/Partial}} | |
+| 6 | Exit Criteria | Is "done" defined for QA? | {{Yes/No/Partial}} | |
+
+## Important (Should Have)
+
+| # | Area | Question | Status | Notes |
+|---|------|----------|--------|-------|
+| 7 | User Roles | Are different user roles and their permissions clear? | {{Yes/No/N-A}} | |
+| 8 | Environments | Do we know what environments exist and their purpose? | {{Yes/No/N-A}} | |
+| 9 | Existing Tests | Do we know what testing already exists? | {{Yes/No/N-A}} | |
+| 10 | CI/CD | Is the CI/CD pipeline understood? | {{Yes/No/N-A}} | |
+| 11 | Team Skills | Do we know the team's automation capability? | {{Yes/No/N-A}} | |
+| 12 | Timeline | Are schedule constraints known? | {{Yes/No/N-A}} | |
+
+## Optional (Nice to Have)
+
+| # | Area | Question | Status | Notes |
+|---|------|----------|--------|-------|
+| 13 | Compliance | Are regulatory requirements identified? | {{Yes/No/N-A}} | |
+| 14 | Accessibility | Is WCAG level defined? | {{Yes/No/N-A}} | |
+| 15 | Security | Are security testing requirements clear? | {{Yes/No/N-A}} | |
+| 16 | Performance | Are SLAs/thresholds defined? | {{Yes/No/N-A}} | |
+| 17 | Browser/Device Matrix | Are supported platforms listed? | {{Yes/No/N-A}} | |
+| 18 | Defect History | Are historical patterns known? | {{Yes/No/N-A}} | |
+
+## Completeness Scoring
+
+| Score | Meaning | Action |
+|-------|---------|--------|
+| **All Critical = Yes** | Ready to generate brief | Proceed to Phase 6 |
+| **1-2 Critical = Partial** | Gaps exist but manageable | Note gaps in brief, recommend follow-up |
+| **Any Critical = No** | Not ready | Return to Phase 2, ask targeted questions for missing areas |
+| **Important mostly N/A** | New project or limited context | Acceptable — note assumptions in brief |
+
+## Before Generating Brief
+
+- [ ] All 6 Critical items are Yes or Partial (with notes)
+- [ ] No unresolved conflicts from Phase 4
+- [ ] Interviewee confirmed summary is accurate
+- [ ] Assumptions are explicitly stated
+- [ ] Research loops completed for uncertain areas

package/skills/qa-discovery-interview/references/conflict-patterns.md

@@ -0,0 +1,101 @@
+# QA Discovery Interview — Conflict Patterns & Resolution
+
+Common conflicts discovered during interviews and strategies to resolve them.
+
+## Conflict Type 1: Scope vs Timeline
+
+**Pattern:** "We need full test coverage for all features, and the release is in 2 weeks."
+
+**Detection signals:**
+- Large feature list + short timeline
+- "Test everything" + limited team
+- No prioritization between features
+
+**Resolution strategy:**
+1. Present the scope-timeline-quality triangle
+2. Ask: "If we can only thoroughly test 3 areas, which ones matter most?"
+3. Propose: smoke testing for low-risk areas, full testing for critical paths
+4. Document agreed priorities in the brief with explicit rationale
+
+## Conflict Type 2: Everything is Critical
+
+**Pattern:** "All features are P0, everything must be tested."
+
+**Detection signals:**
+- Every priority answer is "High" or "Critical"
+- No differentiation between core and peripheral features
+- Stakeholder avoids making trade-off decisions
+
+**Resolution strategy:**
+1. Force-rank: "If the entire system is down except ONE feature, which one must work?"
+2. Use impact matrix: "What's the revenue/user impact if Feature X is broken vs Feature Y?"
+3. Categorize into: must-not-fail (P0), should-work (P1), nice-to-have (P2)
+4. If stakeholder still won't prioritize: document risk and recommend risk-based approach
+
+## Conflict Type 3: Automation Expectations vs Reality
+
+**Pattern:** "We want 100% automated testing" but team has no automation experience and no CI/CD.
+
+**Detection signals:**
+- High automation expectations + junior team
+- No existing test infrastructure
+- Unrealistic timeline for automation setup
+
+**Resolution strategy:**
+1. Acknowledge the goal: "100% automation is a great target. Let's plan a realistic path."
+2. Propose phased approach: manual first → automate critical paths → expand coverage
+3. Estimate setup time: framework, CI/CD, first tests (typically 2-4 weeks minimum)
+4. Recommend starting framework based on team skills (see Category G)
+
+## Conflict Type 4: Missing Infrastructure
+
+**Pattern:** "Test on staging" but staging doesn't exist or isn't maintained.
+
+**Detection signals:**
+- References to environments that don't exist
+- Test data assumptions without data sources
+- External service dependencies without mocks/sandboxes
+
+**Resolution strategy:**
+1. Document what exists vs what's assumed
+2. Create prerequisites list: environment setup, test data, service access
+3. Recommend qa-environment-checker as first step
+4. Include infrastructure tasks in the QA brief timeline
+
+## Conflict Type 5: Stakeholder Misalignment
+
+**Pattern:** Dev team says "unit tests are enough" while PM expects "full E2E coverage."
+
+**Detection signals:**
+- Different team members give contradictory answers
+- Testing philosophy conflicts (shift-left vs traditional QA)
+- Unclear ownership of quality
+
+**Resolution strategy:**
+1. Document both perspectives without judgment
+2. Present testing pyramid: unit → integration → E2E (each has its place)
+3. Recommend: "Let's define what 'tested' means for this project" (exit criteria)
+4. Propose balanced approach that addresses both concerns
+
+## Conflict Type 6: Security/Compliance Uncertainty
+
+**Pattern:** "We probably don't need GDPR compliance" for a product handling EU user data.
+
+**Detection signals:**
+- Dismissive answers about compliance
+- Handling user data without mentioning privacy
+- Payment processing without PCI awareness
+
+**Resolution strategy:**
+1. Don't challenge directly — ask clarifying questions
+2. "Does the application store personal data from EU users?" (→ GDPR applies)
+3. "Does it process credit card numbers directly?" (→ PCI-DSS applies)
+4. If compliance likely applies: note it as a risk in the brief, recommend specialist review
+
+## General Resolution Principles
+
+1. **Don't resolve conflicts yourself** — present them clearly, let stakeholders decide
+2. **Document both sides** — the brief should capture the conflict and the resolution
+3. **Quantify when possible** — "3 weeks vs 1 week" is clearer than "more time needed"
+4. **Propose options** — give 2-3 approaches with trade-offs, let stakeholder choose
+5. **Escalate when necessary** — some conflicts require management decisions beyond QA scope

package/skills/qa-discovery-interview/references/qa-categories.md

@@ -0,0 +1,147 @@
+# QA Discovery Interview — Category Deep Dive Questions
+
+## Category A: Problem & Product
+
+**Focus:** What is being tested, business context, impact of defects.
+
+| # | Question | Purpose |
+|---|----------|---------|
+| A1 | What is the core problem this product/feature solves for users? | Understand business value and testing priority |
+| A2 | What happens if this feature ships with defects? What's the business impact? | Calibrate severity thresholds |
+| A3 | Who are the end users? How many? What's their technical proficiency? | Define user personas for test design |
+| A4 | Are there competing products? What differentiates this one? | Identify areas where quality is a competitive advantage |
+
+**Signals for deeper exploration:**
+- "Millions of users" → performance and scalability are critical
+- "Financial transactions" → security, data integrity, compliance
+- "Healthcare/legal" → regulatory compliance, audit trails
+
+## Category B: Testing Scope & Objectives
+
+**Focus:** What types of testing are needed, what's in/out of scope.
+
+| # | Question | Purpose |
+|---|----------|---------|
+| B1 | Which testing types are critical: functional, performance, security, accessibility? | Prioritize testing types |
+| B2 | What is explicitly OUT of scope for testing? | Prevent scope creep |
+| B3 | What is the definition of "done" for QA on this project? | Set clear exit criteria |
+| B4 | Are there existing quality metrics or KPIs we need to meet? | Quantify quality targets |
+
+**Signals for deeper exploration:**
+- No clear exit criteria → probe for pass/fail thresholds
+- "Everything is important" → force-rank with severity/impact matrix
+
+## Category C: User Flows & Critical Paths
+
+**Focus:** Core scenarios, happy paths, unhappy paths, edge cases.
+
+| # | Question | Purpose |
+|---|----------|---------|
+| C1 | Walk me through: a user completes the primary action. What happens step by step? | Map the happy path |
+| C2 | What are the top 3 most critical user journeys? | Prioritize test coverage |
+| C3 | What are the known edge cases or unusual user behaviors? | Identify boundary/negative test scenarios |
+| C4 | Are there different user roles? How do their flows differ? | Role-based test scenarios |
+
+**Signals for deeper exploration:**
+- Complex multi-step flows → state diagram needed
+- Multiple user roles → permission matrix testing
+- "Users do unexpected things" → exploratory testing emphasis
+
+## Category D: Technical Landscape
+
+**Focus:** Technology stack, architecture, constraints, integrations.
+
+| # | Question | Purpose |
+|---|----------|---------|
+| D1 | What technologies, frameworks, and languages are used? (frontend, backend, DB) | Select appropriate test writers |
+| D2 | What external APIs, services, or third-party integrations exist? | Contract testing, mock requirements |
+| D3 | Is this a monolith, microservices, serverless, or hybrid architecture? | Architecture-appropriate test strategy |
+| D4 | What are the known technical constraints or limitations? | Adjust test approach for constraints |
+
+**Signals for deeper exploration:**
+- Microservices → contract testing (Pact), service-level testing
+- External APIs → mock/stub strategy, API contract validation
+- Legacy systems → integration risk, compatibility testing
+
+## Category E: Existing QA Processes
+
+**Focus:** Current CI/CD, test automation, tools, coverage.
+
+| # | Question | Purpose |
+|---|----------|---------|
+| E1 | What testing exists today? Automated? Manual? Both? | Baseline current state |
+| E2 | What CI/CD pipeline is in place? What tests run automatically? | Integration points for new tests |
+| E3 | What test management tools are used? (Jira, TestRail, Qase, spreadsheets) | Tool integration requirements |
+| E4 | What's the current test coverage? Are there known gaps? | Coverage gap analysis starting point |
+
+**Signals for deeper exploration:**
+- No automation → need onboarding plan, framework selection
+- Flaky tests mentioned → qa-flaky-detector engagement
+- No CI/CD → environment setup is prerequisite
+
+## Category F: Risk Areas & Priorities
+
+**Focus:** What can break, what matters most, defect history.
+
+| # | Question | Purpose |
+|---|----------|---------|
+| F1 | Which areas have the highest defect history or most production incidents? | Risk-based test prioritization |
+| F2 | What was the last major bug that reached production? What caused it? | Pattern analysis for prevention |
+| F3 | If you could only test 3 things, what would they be? | Force-rank priorities |
+| F4 | Are there upcoming changes that increase risk? (migrations, refactors, new integrations) | Proactive risk management |
+
+**Signals for deeper exploration:**
+- Frequent production bugs → regression testing emphasis
+- Major migration planned → migration test plan needed
+- "Payment bugs" → security + functional testing priority
+
+## Category G: Team, Tools & Infrastructure
+
+**Focus:** Who tests, with what tools, in which environments.
+
+| # | Question | Purpose |
+|---|----------|---------|
+| G1 | What is the team's automation expertise? (junior, mid, senior; languages known) | Framework complexity calibration |
+| G2 | What test environments exist? (dev, staging, QA, UAT, production) | Environment setup and readiness |
+| G3 | What browsers, devices, and OS versions must be supported? | Browser/device matrix |
+| G4 | What budget and timeline constraints exist for QA? | Resource planning and prioritization |
+
+**Signals for deeper exploration:**
+- Junior team → simpler frameworks (CodeceptJS, Robot Framework)
+- No staging environment → environment-checker priority
+- Mobile required → mobile test writer engagement
+
+## Category H: Compliance & Standards
+
+**Focus:** WCAG, OWASP, ISO, GDPR, industry-specific regulations.
+
+| # | Question | Purpose |
+|---|----------|---------|
+| H1 | Are there regulatory or compliance requirements? (GDPR, HIPAA, PCI-DSS, SOC2) | Compliance test requirements |
+| H2 | What accessibility standard is required? (WCAG 2.2 Level A/AA/AAA) | Accessibility testing scope |
+| H3 | Are there security requirements or certifications needed? (OWASP, penetration testing) | Security testing scope |
+| H4 | Are there industry-specific standards? (ISO 27001, FDA, FedRAMP) | Specialized compliance testing |
+
+**Signals for deeper exploration:**
+- GDPR → data privacy testing, consent flows, deletion verification
+- WCAG AA → accessibility-test-writer engagement, full checklist
+- PCI-DSS → payment security, encryption validation
+- No compliance mentioned → confirm explicitly ("Are you sure no regulations apply?")
+
+## Adaptive Questioning Strategy
+
+### Question Ordering
+1. Start with the category most relevant to the initial orientation answers
+2. If business-critical → A, F, C first
+3. If technical migration → D, E, G first
+4. If compliance-driven → H, B, F first
+
+### Depth Calibration
+- **Shallow (1-2 questions):** Category is clear from context or explicitly out of scope
+- **Normal (2-3 questions):** Standard exploration
+- **Deep (3-4 questions + follow-ups):** High risk, uncertainty, or conflicts detected
+
+### Batching
+- Ask 2-3 questions at a time (not one by one — too slow; not all at once — overwhelming)
+- Group related questions within a category
+- After each batch, summarize understanding before proceeding