Agent Skills › microsoft/intelligent-terminal › pr-integration-test

pr-integration-test

GitHub

为PR设计并实施智能终端集成测试，将修复转化为端到端覆盖，验证现有行为并更新发布清单。

.github/skills/pr-integration-test/SKILL.md microsoft/intelligent-terminal

触发场景

添加PR集成测试将bug修复转为E2E覆盖验证现有行为映射测试到发布清单

安装

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

更多选项

非标准路径

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

不安装直接使用

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.
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.
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

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.