@xera-ai/skills 0.4.1 → 0.4.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xera-ai/skills",
-  "version": "0.4.1",
+  "version": "0.4.3",
   "files": [
     "*.md",
     "version.json"

package/version.json

@@ -1,5 +1,5 @@
 {
-  "skills": "0.4.1",
+  "skills": "0.4.3",
   "compatible_prompts": "^2.3.0",
   "skill_files": [
     "xera-run.md",
@@ -8,6 +8,7 @@
     "xera-script.md",
     "xera-exec.md",
     "xera-report.md",
-    "xera-promote.md"
+    "xera-promote.md",
+    "xera-impact.md"
   ]
 }

package/xera-impact.md

@@ -0,0 +1,82 @@
+---
+name: xera-impact
+description: Pre-flight impact analysis. Given a ticket, identify scenarios that may be affected by its changes (graph-walk via project knowledge graph), then optionally re-run them. Use before merging or when AC has just changed for a ticket. Available v0.6.2+.
+---
+
+The user invoked `/xera-impact <TICKET> [--depth 1|2|3] [--min-priority p0|p1|p2]`. If no key, ask.
+
+This skill walks the project knowledge graph (`.xera/graph/`) to find scenarios that depend on the modified areas of `<TICKET>`. It does NOT re-fetch or re-script — it's strictly a query + optional re-execution.
+
+## Step 1 — Verify graph snapshot is fresh
+
+Run:
+
+```bash
+bun run xera:graph-snapshot --check
+```
+
+If stale, the subcommand auto-rebuilds. If `<TICKET>` is not in the graph, this step will succeed but Step 2 will exit with code 2 — that means you must run `/xera-fetch {{TICKET}}` first.
+
+## Step 2 — Compute impact
+
+Run:
+
+```bash
+bun run xera:impact-prepare {{TICKET}} [--depth N] [--min-priority P]
+```
+
+Pass through any flags the user provided. On exit code 2, surface: *"Ticket {{TICKET}} not in graph — run `/xera-fetch {{TICKET}}` first"* and STOP.
+
+The subcommand writes:
+- `.xera/impact/{{TICKET}}.json` (machine-readable)
+- `.xera/impact/{{TICKET}}.md` (human-readable)
+
+## Step 3 — Display summary
+
+Read `.xera/impact/{{TICKET}}.json`. If `scenarios.length === 0`, show:
+
+```
+Impact analysis for {{TICKET}} → no prior scenarios in modified areas
+(this is normal for new feature areas; nothing to re-run)
+```
+
+And STOP.
+
+Otherwise, count scenarios in 3 score buckets (high ≥7.0, medium ≥4.0, low <4.0). Display:
+
+```
+Impact analysis for {{TICKET}}  →  .xera/impact/{{TICKET}}.md
+
+N scenarios impacted (H high · M medium · L low)
+
+Top 3:
+  <ticketId> / "<name>"   [Pn]   <score>   <edge-summary>
+  ...
+```
+
+## Step 4 — Prompt re-run
+
+Ask the user: `Re-run impacted scenarios?  [Y]es / [p] P0 only / [s]elect / [n]o`
+
+- **[n]:** STOP. The user can inspect `.xera/impact/{{TICKET}}.md` separately.
+
+- **[Y]:** Group impacted scenarios by their owner ticket (`scenario.ticketId`). For each owner ticket, invoke `bun run xera:exec <owner-ticket>` (the existing exec subcommand). Collect the `RUN_ID` from each. Note: this re-runs the ENTIRE spec for each impacted owner, not just the impacted scenarios — Playwright doesn't natively support per-test selection from a json list without test-name regex. Acceptable for v0.6.2; precise per-scenario selection is a v0.6.x patch.
+
+- **[p]:** Filter `scenarios` array to `priority === 'p0'` only, then proceed as [Y].
+
+- **[s]:** Show numbered list with checkboxes; let the user pick. Then proceed as [Y] with the selected subset.
+
+## Step 5 — Recommend follow-up
+
+After exec runs complete, recommend:
+
+```
+{{N}} owner tickets re-run. Run `/xera-report {{TICKET}}` next to classify failures
+(TEST_OUTDATED detection will flag failures caused by THIS ticket's AC change).
+```
+
+## Edge cases
+
+- If `xera:impact-prepare` exits non-zero for any reason other than 2 (e.g. graph corrupted), surface the stderr and STOP.
+- If a re-run via `xera:exec` fails non-recoverably, continue with remaining tickets but note the failure in the final summary.
+- Respect `xera.config.run.autoImpact.enabled = false` — skip this skill if invoked recursively from `/xera-run` and config disables it.

package/xera-run.md

@@ -18,6 +18,35 @@ Follow the same instructions as `xera-fetch.md`, but never prompt the user about
 
 If meta is missing or story_hash is older, refresh.
 
+## Step 1.5 — Auto-trigger impact analysis (v0.6.2)
+
+After `/xera-fetch` completes, check whether this ticket modifies areas that other tests depend on.
+
+Read `xera.config.run.autoImpact` (defaults: `{ enabled: true, threshold: 6.0 }`). If `enabled === false`, SKIP this step.
+
+Run:
+
+```bash
+bun run xera:impact-prepare {{TICKET}} --quiet
+```
+
+This writes `.xera/impact/{{TICKET}}.json` (no markdown). Exit code 2 means the ticket is not yet in graph — surface a warning and proceed (graph data only accumulates over time).
+
+Read the JSON. Count scenarios with `riskScore >= autoImpact.threshold`. If 0, no prompt — continue silently to Step 2.
+
+If ≥1 high-risk scenario, prompt the user:
+
+```
+{{N}} high-risk impacted scenarios detected for {{TICKET}}.
+Re-run them before generating the new script? [Y/n/details]
+```
+
+- **[Y]:** Iterate `bun run xera:exec <owner-ticket>` for each unique owner ticket. After each, check status; if all pass, continue to Step 2. If any fail, surface the failure and STOP — the user should diagnose existing-test breakage before introducing more changes.
+- **[n]:** Continue to Step 2.
+- **[details]:** Suggest the user run `/xera-impact {{TICKET}}` interactively for full details, then ask again.
+
+Non-fatal: if `xera:impact-prepare` itself exits abnormally, log the warning but continue to Step 2 — graph features are advisory, not gating.
+
 ## Step 2 — Feature
 
 Follow `xera-feature.md`. If `feature_generated_from_story_hash !== story_hash`, regenerate. If unchanged AND spec.ts exists, skip feature generation entirely.