Trigger Scenarios

添加 PR 集成测试将 Bug 修复转换为 E2E 覆盖验证现有行为是否正常

Install

npx skills add microsoft/intelligent-terminal --skill pr-integration-test -g -y

More Options

Non-standard path

npx skills add https://github.com/microsoft/intelligent-terminal/tree/main/.github/skills/pr-integration-test -g -y

Use without installing

npx skills use microsoft/intelligent-terminal@pr-integration-test

指定 Agent (Claude Code)

npx skills add microsoft/intelligent-terminal --skill pr-integration-test -a claude-code -g -y

安装 repo 全部 skill

npx skills add microsoft/intelligent-terminal --all -g -y

预览 repo 内 skill

npx skills add microsoft/intelligent-terminal --list

SKILL.md

Frontmatter

{
    "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:

Field	Required answer
Contract	What user-visible behavior must remain true?
Trigger	What exact action or input exercises it?
Boundary	Which real component handoff does this test add beyond unit tests?
Oracle	What deterministic observable proves success or suppression?
Negative control	What similar input must not trigger the behavior?
Existing protection	Which existing tests protect old behavior and must still run?
Checklist title	Which exact bold release-checklist title contains the Pester test name?

Oracle Priority

Prefer the earliest deterministic product-owned signal:

Protocol/event stream
Persisted or queryable application state
Structured diagnostic log
Rendered terminal or UI state
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.