define-smoke-scope

name

define-smoke-scope

description

Use to define the smallest high-signal confidence slice for a product, feature, or release. Triggers include "what should be in smoke", "define the minimum checks", "smoke scope for...", "critical-path confidence for...", or "what must never break before release". This skill owns smoke intent and prioritization; it does NOT own exploration evidence, shared coverage planning, detailed TC-ID specs, or framework-specific automation.

Define Smoke Scope

What this skill is for

Smoke testing is about identifying the smallest set of checks that proves the product's most critical paths still work. This skill defines that scope and the reasoning behind it.

It produces a smoke charter that names the must-not-break flows, what confidence they provide, and what downstream automation should target first.

This skill does NOT:

• Explore live apps (use capture-feature-evidence from app-exploration)
• Write coverage plans (use plan-test-coverage from test-analysis)
• Generate test case specs (use generate-test-cases from test-analysis)
• Write Playwright or Robot code
• Orchestrate the full cross-plugin workflow (workflow sequencing lives in workflow.md)

Integration with shared artifacts

This skill consumes:

• docs/qa/exploration-report.md when available
• docs/qa/coverage-plan.md when available
• existing docs/qa/test-cases/*.md specs and automated coverage when available

This skill produces:

• docs/qa/smoke-charter.md — an optional plugin-owned artifact. It is not part of the core shared artifact contract.

Workflow

1. Gather evidence

• Read the exploration report first when real product evidence exists.
• Read the coverage plan and existing specs to avoid redefining work that is already prioritized.
• Search the repo for existing automated coverage so the smoke scope reflects what is already runnable.
• If evidence is missing for a risky critical path, call that out and recommend capture-feature-evidence rather than guessing.

Evidence sufficiency rule

• Treat repo context, existing specs, and prior automation as supporting evidence, not as proof of current live behavior.
• If the smoke decision depends on current validation behavior, redirects, auth walls, conditional UI, or the actual entry/completion path, require fresh or clearly relevant capture-feature-evidence evidence.
• If docs/qa/exploration-report.md is missing, stale, or incomplete for a must-not-break flow, do one of two things only:
  • run capture-feature-evidence before finalizing the scope, or
  • publish a clearly labeled preliminary smoke charter with explicit evidence gaps
• Do not present a high-confidence smoke scope when critical-path evidence is still inferred.

2. Identify the must-not-break paths

Define the flows that would block release confidence if they failed. Typical candidates:

• sign in or session establishment
• the primary revenue or submission flow
• one critical read path that confirms the system is usable after entry
• one failure-handling path when it is central to trust or safety

Prefer 3-7 smoke scenarios. If the list is getting longer, it is probably regression scope instead.

3. Score each candidate

For every candidate scenario, capture:

Flow	Why it matters	Failure impact	Evidence basis	Include in smoke?
Login	Users cannot access anything without it	Release blocker	Exploration report + existing test coverage	Yes

Use evidence basis labels like: exploration report, coverage plan, existing automation, user input, or inference.

4. Decide what stays out

A good smoke scope is small on purpose. Explicitly exclude:

• long-tail validation variants
• rare edge cases
• broad cross-role matrices
• non-critical cosmetic checks

If an excluded area is still important, name it as regression follow-up rather than forcing it into smoke.

5. Write the charter

Write docs/qa/smoke-charter.md:

# Smoke Charter: <Feature/Product>

**Date:** <date>
**Evidence basis:** exploration-report | coverage-plan | existing-automation | mixed

## Release Mission

<one paragraph on what this smoke scope proves>

## Included Smoke Scenarios

| # | Flow | Why Included | Evidence Basis | Suggested Downstream Target |
|---|------|--------------|----------------|-----------------------------|
| 1 | ... | ... | ... | Playwright / Robot / manual |

## Explicitly Out Of Scope

- <what is intentionally excluded from smoke>

## Evidence Gaps

- <what still needs exploration or clarification>

## Recommended Next Steps

- Run `capture-feature-evidence` if critical evidence gaps remain
- Run `plan-test-coverage` if the product still needs shared prioritization
- Hand the included smoke scenarios to the execution workflow if runnable automation is requested

Quality bar

• Smoke scope is small enough to run quickly and often.
• Every included flow has a concrete reason tied to release confidence.
• Exclusions are explicit, not accidental.
• The charter uses evidence where available and labels inferences honestly.
• The charter does not treat old specs or existing automation as proof that the live path still works.

What to avoid

• Turning smoke into a full regression suite.
• Including every validation rule just because it exists.
• Writing framework-specific automation steps here.
• Claiming ownership of coverage-plan.md or docs/qa/test-cases/*.md.
• Presenting an inferred critical path as confirmed when live evidence is missing.