Appropriate use
Use before regression execution, release candidate testing, hotfix validation, or when deciding what existing automation must run.
Scope and intent
A controlled workflow specification
This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.
Non-goals
Do not use to claim unaffected areas are impossible to break or to reduce scope without recording assumptions and evidence.
- 8
- versioned workflow phases
- 3
- explicit approval gates
- 5
- defined result states
- 9
- versioned output artifacts
Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.
Workflow
The 8 phases
Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.
Phase 1: Change-set preflight Gate 1 · approve change set
Resolve the ticket, PR, diff, base and head commits, generated files, configuration, migrations, dependency updates, feature flags, and deployment topology.
change identity · repository map · build manifest · configuration diff
Phase 2: Direct impact analysis
Map changed components, functions, routes, schemas, permissions, UI surfaces, jobs, storage, and test files.
changed symbols · direct callers · data contracts · user surfaces
Phase 3: Indirect impact analysis
Trace shared libraries, consumers, events, caching, permissions, queues, APIs, rollout controls, upgrade paths, and cross-repository dependencies.
dependency graph · runtime coupling · operational coupling
Phase 4: Risk enrichment
Add incident history, escaped defects, flaky areas, customer concentration, platform variance, data sensitivity, and rollback difficulty.
historical risk · platform risk · customer risk · recoverability
Phase 5: Candidate regression set
Select required smoke, direct regression, indirect regression, platform checks, negative cases, recovery tests, and automation suites.
required tests · optional tests · excluded tests · reason
Phase 6: Coverage reduction review
Review equivalence assumptions, pairwise selections, skipped platforms, redundant tests, runtime cost, and parallelisation opportunities.
coverage value · cost · confidence · exclusion rationale
Phase 7: Approval and freeze Gate 2 · approve scope
Present the regression map, priorities, estimates as bands, stop conditions, and residual risk. Bind approval to the change-set hash.
P0/P1 required · P2/P3 optional · owner · change trigger
Phase 8: Publish execution manifest Gate 3 · publish scope
Generate stable test IDs, suite commands, manual scenarios, environment matrix, and a machine-readable manifest for downstream execution.
manifest · commands · manual plan · traceability
Approval contract
Every gate approves an exact decision object
An approval cannot be reused after its environment, source, action plan, or approved document changes.
| Gate | Decision | Required binding |
|---|---|---|
| 1 | Gate 1 · approve change set | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 2 | Gate 2 · approve scope | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 3 | Gate 3 · publish scope | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
Result model
Defined states prevent vague conclusions
Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.
MINIMAL
A small, well-isolated change supports a narrow regression set with strong confidence.
TARGETED
Direct and selected indirect regression are required.
BROAD
Shared components, data, permissions, or platform reach require wide regression.
FULL
Systemic, migration, release-platform, or highly uncertain change requires the full approved suite.
UNSCOPED
The change set or architecture evidence is insufficient to create a defensible scope.
Evidence contract
Evidence must directly support the claim
Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.
| Claim | Primary evidence | Required validation |
|---|---|---|
| Change identity | Diff and deployment manifest | Generated and configuration changes are included. |
| Direct impact | Symbol, route, schema, and UI mapping | User-visible and service-visible effects are linked. |
| Indirect impact | Dependency and event graph | Shared consumers and operational paths are considered. |
| Historical risk | Defect and incident references | Past failures are relevant to the changed area. |
| Selection | Test-to-risk traceability | Every required test has a reason. |
| Exclusion | Explicit rationale | Skipped areas state evidence, assumption, and residual risk. |
Trust and safety
Controls that must be enforced outside the prompt
These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.
Runtime control
No diff-only reasoning
Runtime configuration, migrations, generated assets, and dependency versions are part of scope.
Runtime control
No silent exclusions
Every supported platform not selected is listed.
Runtime control
Historical evidence expiry
Old risk signals are reviewed for relevance rather than copied forever.
Runtime control
Suite identity
Commands and test lists are versioned to avoid running a moving target.
Runtime control
Change invalidation
New commits or config updates invalidate the approved scope.
Runtime control
Cost transparency
Runtime savings never masquerade as risk elimination.
Decision policy
Ordered outcomes, not averaged pass counts
The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.
UNSCOPED
The change or dependency evidence is insufficient.
FULL
Systemic or uncertain impact requires complete approved regression.
BROAD
Multiple components, platforms, or operational paths require wide coverage.
TARGETED
Known direct and indirect risks support a focused set.
MINIMAL
Isolation is strong and a narrow set is defensible.
Known limitations
Uncertainty and coverage limits remain visible
The workflow documents what it cannot prove and what further evidence would change confidence.
- Limit 1. Static code analysis can miss runtime configuration and dynamic calls.
- Limit 2. Historical defects may bias scope toward old architecture.
- Limit 3. A narrow diff can still trigger broad data or deployment impact.
- Limit 4. Test-suite labels may not accurately represent real coverage.
- Limit 5. Platform equivalence must be justified, not assumed.
- Limit 6. Emergency hotfix scope should still list accepted omissions and rollback triggers.
Outputs
Versioned records for review and continuation
Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.
scope-context.jsonVersioned output produced by the workflow.
change-map.mdVersioned output produced by the workflow.
dependency-map.jsonVersioned output produced by the workflow.
risk-register.yamlVersioned output produced by the workflow.
regression-manifest.yamlVersioned output produced by the workflow.
manual-scenarios.mdVersioned output produced by the workflow.
suite-commands.shVersioned output produced by the workflow.
exclusions.mdVersioned output produced by the workflow.
regression-scope.htmlVersioned output produced by the workflow.
artifacts/qa/regression-scope/<run-id>/ ├── scope-context.json ├── change-map.md ├── dependency-map.json ├── risk-register.yaml ├── regression-manifest.yaml ├── manual-scenarios.md ├── suite-commands.sh ├── exclusions.md └── regression-scope.html
Example
Example request and controlled output
Input
Scope regression for PR 9812. It changes shared authentication headers used by Studio and Pulse, with no UI diff.
Output excerpt
Scope: BROAD Required: - Admin and Member authentication flows - Organisation switching - Direct API access - Cached sessions - Expired sessions - Studio and Pulse smoke suites - Cross-tenant denial checks Why: The diff is small, but the changed header is a shared permission boundary used across two products.
Production readiness
Required before operational use
The written skill is only one layer. The repository, runtime, connectors, evidence storage, and publication path must implement these requirements.
- Required. Tool, filesystem, repository, command, secret, and network permissions are enforced outside the model.
- Required. Every source, environment, build, plan, and approval has a version or content hash.
- Required. Untrusted values are escaped, length-bounded, path-safe, and separated from executable instructions.
- Required. Attempt outcomes, scenario verdicts, workflow decisions, and publication status remain separate.
- Required. Raw evidence, publishable evidence, access control, retention, redaction, and deletion are defined.
- Required. Concurrent runs use unique IDs, locks, idempotency keys, and conflict-aware updates.
- Required. Material changes invalidate dependent approvals and outcomes.
- Required. The repository validator passes before the skill is considered production-ready.
In one line
/regression-scope
Determines the smallest defensible regression set for a change by combining code impact, architecture, risk, historical failures, platform exposure, and operational behaviour.