version: "1.0.0"

name: pr-integration-test description: 'Design, implement, and validate Intelligent Terminal integration tests for a target pull request or regression. Use when asked to add PR integration tests, convert a bug fix into E2E coverage, prove existing behavior still works, map tests to the release checklist, or verify E2E reports mark checklist cases complete.'

PR Integration Test

Turn a target PR into durable, behavior-focused integration coverage that proves the fixed path, protects existing behavior, and updates the generated release checklist.

When to Use This Skill

• Convert an open or merged PR into cross-component regression coverage.
• Extend doc/release-check-list.md and make report scripts check the new rows.
• Audit whether a PR's existing tests cover the user-visible behavior rather

than only its implementation details.

Prerequisites

• Read test/e2e/README.md and reuse the ItE2E framework instead of creating a

parallel harness.

• Treat the source revision and deployed package as separate decisions. For a

PR, test the intended PR head/feature-branch revision through a Dev build by default; a previously installed Dev package is not proof that the PR code ran.

• Before running any live integration test, identify the target package from

the user's request. If the user did not explicitly choose Dev or Store/production, use ask_user and wait for the answer. In a PR context, make Dev built from the PR head/feature branch the recommended/default choice. Never select a package solely from installed-package discovery.

• Use Store only when the user explicitly asks to test the production/shipped

build. Store results establish a production baseline; they do not validate unshipped changes in the PR.

• Pin the chosen package through $env:ITE2E_PACKAGE = 'Dev' or

$env:ITE2E_PACKAGE = 'Store' for every live validation command.

• Run pwsh -File test/e2e/bootstrap.ps1 -Check before live E2E validation.

Workflow

Follow workflow.md. Track the phases with a TODO list.

analyze PR -> reconstruct behavior -> audit coverage -> design matrix -> write ItE2E -> wire checklist -> validate -> deliver

Test Design Standard

For every proposed case, record:

Oracle Priority

Prefer the earliest deterministic product-owned signal:

1. Protocol/event stream
2. Persisted or queryable application state
3. Structured diagnostic log
4. Rendered terminal or UI state
5. LLM-generated text

Use model output only when it is the behavior under test; never use it to prove routing, triggers, suppression, or idempotency.

Release Checklist Contract

• Add one unchecked [E2E] checklist item per independently releasable behavior.
• Give each item a concise bold title that appears verbatim in the matching

Pester full name (Describe.Context.It).

• Prefer exact-title matching. Add test/e2e/release-coverage-map.psd1 entries

only when an exact test name would be misleading or one case intentionally covers multiple checklist items.

• Assign stable IDs and verify [x] output through the full and incremental

report paths in workflow.md.

Completion Gate

Do not call the work complete until all of these are true:

• Pre-fix evidence identifies the regression, and the fixed path crosses the

real integration boundary.

• For PR validation against Dev, the tested package is proven to contain the

intended PR head/feature-branch revision.

• Relevant false positives, replay risks, and existing behavior are covered.
• The correct build passes related suites and marks new checklist IDs [x];

every skip is explained.

Gotchas

• **Never run a live integration test with an implicit or Auto package

selector.** Ask first, then pin ITE2E_PACKAGE. Installed-package discovery cannot establish user intent or prove that a Dev package contains PR code.

• Do not use Store to validate a PR's unshipped code. Prefer a Dev package

built and deployed from the PR head/feature branch. Use Store only for an explicitly requested production baseline and label the result accordingly.

• Do not test only the implementation detail named in the PR. Reconstruct

the end-to-end user path and assert the observable contract.

• Do not duplicate a unit test at E2E level. Add the missing process,

protocol, persistence, packaging, or UI boundary.

• Do not use a successful lower-layer event as proof of the final feature.

When the contract is downstream, assert both the trigger and its downstream effect.

• Do not turn product failures into skips. Skip only when an external

prerequisite is genuinely unavailable. A connected product that behaves incorrectly must fail.

References

• Detailed PR-to-integration-test workflow
• ItE2E framework
• Release checklist