@xera-ai/skills 0.4.2 → 0.4.4

package/package.json

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

package/version.json

@@ -1,5 +1,5 @@
 {
-  "skills": "0.4.2",
+  "skills": "0.4.4",
   "compatible_prompts": "^2.3.0",
   "skill_files": [
     "xera-run.md",

package/xera-impact.md

@@ -60,11 +60,19 @@ 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.
+- **[Y]:** Group impacted scenarios by their owner ticket (`scenario.ticketId`). For each owner ticket, build a regex from the impacted scenario names — e.g. `"user signs in|user resets password"` — and invoke:
 
-- **[p]:** Filter `scenarios` array to `priority === 'p0'` only, then proceed as [Y].
+  ```bash
+  bun run xera:exec <owner-ticket> --grep "<NAME_REGEX>"
+  ```
 
-- **[s]:** Show numbered list with checkboxes; let the user pick. Then proceed as [Y] with the selected subset.
+  The `--grep` flag (added in v0.6.4) makes Playwright run **only the named scenarios**, not the entire spec. Build the regex by joining `impacted[].name` with `|` and escaping any regex special characters in the names. If a scenario name contains characters like `(`, `)`, or `|`, escape them with `\\`.
+
+  Collect each invocation's `RUN_ID` and surface them in the final summary.
+
+- **[p]:** Filter to `priority === 'p0'` scenarios, then proceed as [Y] above (use `--grep` per owner ticket).
+
+- **[s]:** Show numbered list with checkboxes; let the user pick a subset. Proceed as [Y] using the selected subset for the `--grep` regex.
 
 ## Step 5 — Recommend follow-up
 

package/xera-run.md

@@ -22,7 +22,7 @@ If meta is missing or story_hash is older, refresh.
 
 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.
+Read `xera.config.run.autoImpact` (defaults: `{ enabled: true, threshold: 8.0 }`). If `enabled === false`, SKIP this step.
 
 Run:
 
@@ -32,14 +32,12 @@ 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.
+Read the JSON. Count scenarios with `riskScore >= autoImpact.threshold` (default **8.0** per v0.6.4).
 
-If ≥1 high-risk scenario, prompt the user:
+- If **0** scenarios above threshold → continue **silently** to Step 2. Do not show any prompt; do not log the result. The impact analysis ran but found nothing actionable.
+- If **≥1** above threshold → prompt the user as before: `[Y]es / [n]o / [details]`.
 
-```
-{{N}} high-risk impacted scenarios detected for {{TICKET}}.
-Re-run them before generating the new script? [Y/n/details]
-```
+This means the auto-trigger is effectively a "high-risk alarm" rather than a per-run interruption. With the default threshold raised to 8.0, prompts only fire for tickets that genuinely affect P0 scenarios in heavily-shared SUT areas. Teams that want the older, chatty behavior can lower the threshold via `xera.config.run.autoImpact.threshold`.
 
 - **[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.