Quick Start
Learn how to install Impact Gate, run diff-aware impact analysis, and turn the result into a release-ready test plan in minutes. The same commands work for pull requests, release branches, and previous shipped tags.
Go from diff to test plan in one short loop
All three steps below are free-tier, require no API key, and work for pull requests, release branches, and previous shipped tags.
The default path stays deterministic
npx impact-gate impact --path . --since origin/main
npx impact-gate plan --path . --since origin/main
npx impact-gate gate --threshold 80 --path .
Step 1: Install
Install the package into the repo
Add the CLI as a dev dependency so impact analysis and planning run next to the test suite.
npm install -D @yasserkhanorg/impact-gateStep 2: Run Impact Analysis
Compare the current branch to a known baseline
Start with the base branch for pull requests, then swap in the previous shipped tag when you want release-readiness planning.
Point the tool at your project and diff against your base branch:
npx impact-gate impact --path . --since origin/mainThis parses the git diff, maps changed files to route families, and reports which E2E test flows are impacted.
For release readiness, point the same workflow at the previous shipped tag or release branch:
npx impact-gate impact --path . --since v2.1.0Step 3: View the Results
Turn the same diff into a written coverage plan
The plan command writes the artifacts you can inspect in CI, release review, and downstream automation.
The impact command prints a deterministic summary to stdout. To write coverage artifacts with gap analysis, run plan:
npx impact-gate plan --path . --since origin/mainThis produces:
.e2e-ai-agents/plan.json— structured plan with run sets and confidence scores.e2e-ai-agents/ci-summary.md— markdown summary suitable for PR comments
Use the exact same command for a release-diff test plan:
npx impact-gate plan --path . --since v2.1.0That gives you a release-focused view of impacted flows, current coverage, and what still needs tests or manual validation before shipping.
Why The AI Path Is Safer Than Raw Generation
The plan exists before the model does
Diff analysis, impact mapping, and coverage planning happen before generation enters the loop.
Prompts are constrained by local API knowledge
Page objects, helpers, signatures, and inherited methods are discovered before prompting.
Suspicious calls are flagged after generation
Invented methods and fabricated helpers are caught instead of silently landing in the main suite.
Generated specs still need to earn trust
Compile checks and smoke runs are used before a generated spec counts as verified.
When you later enable generation or healing, impact-gate does not just trust whatever the LLM writes.
- The diff and coverage plan are established first with deterministic analysis
- Generation prompts are grounded in your repository’s discovered page objects and helpers
- The generator is told to use only known methods and fall back to raw Playwright selectors when needed
- Suspicious method calls are detected after generation and blocked into
generated-needs-review/ - Written specs are compile-checked and smoke-run before they count as verified
What Next?
Make the deterministic path trustworthy first
- Run
train --no-enrichto improve route-family accuracy - Add
gate --threshold 80in CI once plan output looks trustworthy - Add a CI integration to gate PRs on coverage
Layer in graph bootstrap and optional AI later
- If you already have an Understand-Anything knowledge graph, run
bootstrapinstead oftrain - Try
crew --workflow quick-checkfor strategy recommendations on top of the core CI loop - Set up cost controls before enabling AI features