@muggleai/works 4.10.0 → 4.11.0

package/plugin/skills/muggle-test-regenerate-missing/SKILL.md

@@ -1,13 +1,15 @@
 ---
 name: muggle-test-regenerate-missing
-description: "Bulk-regenerate test scripts for every test case in a Muggle AI project that doesn't currently have an active script. Scans the project, finds test cases stuck in DRAFT or GENERATION_PENDING (no usable script attached), shows the user the list, and on approval kicks off bulk remote test script generation via the Muggle cloud. Use this skill whenever the user asks to 'regenerate missing scripts', 'fill in missing test scripts', 'generate scripts for test cases without one', 'regen all the test cases that don't have scripts', 'rebuild scripts for stale test cases', 'fix test cases with no script', 'bulk regenerate', or any phrasing that means 'kick off script generation across a project for the cases that need it'. Triggers on: 'regenerate missing test scripts', 'generate scripts for all empty test cases', 'fill the gaps in my test scripts', 'bulk test script regen', 'all my test cases without active scripts'. This is the go-to skill for project-wide script catch-up — it handles discovery, filtering, confirmation, and remote workflow dispatch end-to-end."
+description: "Bulk-regenerate test scripts for every test case in a Muggle AI project that doesn't currently have an active script. Scans the project, finds test cases stuck in DRAFT or GENERATION_PENDING (no usable script attached), shows the user the list, and on approval kicks off bulk remote test script generation via the Muggle Test cloud. Use this skill whenever the user asks to 'regenerate missing scripts', 'fill in missing test scripts', 'generate scripts for test cases without one', 'regen all the test cases that don't have scripts', 'rebuild scripts for stale test cases', 'fix test cases with no script', 'bulk regenerate', or any phrasing that means 'kick off script generation across a project for the cases that need it'. Triggers on: 'regenerate missing test scripts', 'generate scripts for all empty test cases', 'fill the gaps in my test scripts', 'bulk test script regen', 'all my test cases without active scripts'. This is the go-to skill for project-wide script catch-up — it handles discovery, filtering, confirmation, and remote workflow dispatch end-to-end."
 ---
 
 # Muggle Test — Regenerate Missing Test Scripts
 
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-test-regenerate-missing"`.
+
 A bulk maintenance skill for Muggle AI projects. It finds every test case in a project that does **not** currently have an active (ready-to-run) test script, shows the list to the user, and on approval triggers a remote test script generation workflow for each one. Useful after creating a batch of new test cases or when cleaning up a project that has drifted.
 
-Execution is **remote only** — Muggle's cloud generates the scripts in parallel against the project URL. The user's machine is not involved beyond making API calls.
+Execution is **remote only** — Muggle Test's cloud generates the scripts in parallel against the project URL. The user's machine is not involved beyond making API calls.
 
 ## Preferences
 
@@ -16,11 +18,11 @@ Gates run per `preference-gates/README.md`.
 | Preference | Step | Decision it gates |
 |------------|------|-------------------|
 | `autoLogin` | 1 | Reuse saved credentials when auth is required |
-| `autoSelectProject` | 2 | Reuse last-used Muggle project for this repo |
+| `autoSelectProject` | 2 | Reuse last-used Muggle Test project for this repo |
 
 ## Concept: what counts as "no active script"
 
-In the Muggle data model, a test case carries a status that reflects whether it has a usable script attached:
+In the Muggle Test data model, a test case carries a status that reflects whether it has a usable script attached:
 
 | Status | Meaning | Regenerate? |
 |:-------|:--------|:-----------:|
@@ -38,9 +40,9 @@ Treat this filter as a default, not a law. If the user explicitly says "include
 
 ## UX Guidelines — Minimize Typing
 
-**Every selection-based question MUST use the `AskQuestion` tool** (or the platform's equivalent structured selection tool). Never ask the user to "reply with a number" — always present clickable options.
+**Every selection-based question MUST use the `AskUserQuestion` tool** (or the platform's equivalent structured selection tool). Never ask the user to "reply with a number" — always present clickable options.
 
-- **Selections** (project, which test cases to include): Use `AskQuestion`, with `allow_multiple: true` for the test case picker.
+- **Selections** (project, which test cases to include): Use `AskUserQuestion`, with `allow_multiple: true` for the test case picker.
 - **Free-text inputs** (project URL when creating, override filters): Only ask as plain text when the option set isn't finite.
 - **Batch related questions** when independent. Don't ask sequentially what could be one screen.
 
@@ -50,8 +52,9 @@ Treat this filter as a default, not a law. If the user explicitly says "include
 
 1. Call `muggle-remote-auth-status`.
 2. If **authenticated and not expired** → gate `autoLogin` (per `preference-gates/README.md`):
-   - Pro-action: proceed with saved session.
-   - Skip-action: `muggle-remote-auth-login` with `forceNewSession: true`, then `muggle-remote-auth-poll`.
+   - `always` → proceed with saved session.
+   - `never` → `muggle-remote-auth-login` with `forceNewSession: true`, then `muggle-remote-auth-poll`.
+   - `ask` → run Picker 1 from `preference-gates/autoLogin.md` via `AskUserQuestion`; map the answer back to one of the actions above.
 3. If **not authenticated or expired** → call `muggle-remote-auth-login`, then poll with `muggle-remote-auth-poll`.
 4. Do not skip auth and do not assume a stale token still works.
 
@@ -61,9 +64,9 @@ If auth keeps failing, suggest the user run `muggle logout && muggle login` from
 
 A **project** is the unit on the Muggle AI dashboard that groups test cases, scripts, and runs. The user must pick the one to scan — never auto-select from repo name, branch, or URL heuristics.
 
-The per-repo project cache lives at `<cwd>/.muggle-ai/last-project.json` (via the `muggle-local-last-project-get` / `muggle-local-last-project-set` MCP tools). Look for `Muggle Last Project: id=… url=… name="…"` in session context.
+The per-repo project cache lives at `<cwd>/.muggle-ai/last-project.json` (via the `muggle-local-last-project-get` / `muggle-local-last-project-set` MCP tools). Look for `Muggle Test Last Project: id=… url=… name="…"` in session context.
 
-Gate `autoSelectProject` (per `preference-gates/README.md`). Cache: `Muggle Last Project` session line.
+Gate `autoSelectProject` (per `preference-gates/README.md`). Cache: `Muggle Test Last Project` session line.
 - `always` + cache → use cached `projectId`, proceed to Step 3. No cache → fall through to `ask`.
 - `never` → full project list; skip Picker 2.
 - `ask` → project list picker (see gate file for spec + Picker 2 override). Skip Picker 2 if "Create new project".
@@ -71,7 +74,7 @@ Gate `autoSelectProject` (per `preference-gates/README.md`). Cache: `Muggle Last
 ### Logic
 
 1. Call `muggle-remote-project-list` (only when not satisfied by the `always` cache).
-2. Use `AskQuestion` to present projects as clickable options. Include the project URL in each label so the user can disambiguate. Always include "Create new project" as the last option.
+2. Use `AskUserQuestion` to present projects as clickable options. Include the project URL in each label so the user can disambiguate. Always include "Create new project" as the last option.
 3. Wait for explicit selection.
 4. If the user picks "Create new project": collect `projectName`, `description`, and `url`, then call `muggle-remote-project-create`.
 
@@ -107,7 +110,7 @@ If after filtering the list is empty, congratulate the user — every test case
 
 ### Step 5 — Present and Confirm Selection
 
-Use `AskQuestion` with `allow_multiple: true` to present every candidate test case as a clickable option. The user must explicitly approve which ones to regenerate.
+Use `AskUserQuestion` with `allow_multiple: true` to present every candidate test case as a clickable option. The user must explicitly approve which ones to regenerate.
 
 For each option label, show enough context for the user to make a real decision:
 
@@ -120,12 +123,12 @@ For example:
 - `[GENERATION_PENDING] Add item to cart — use case: Checkout Flow`
 
 Default behavior:
-- If there are **≤ 25** candidates, present all of them in a single `AskQuestion` with everything pre-checked and let the user deselect anything they want to skip.
+- If there are **≤ 25** candidates, present all of them in a single `AskUserQuestion` with everything pre-checked and let the user deselect anything they want to skip.
 - If there are **> 25** candidates, show the first 25 ranked by status priority (`DRAFT` → `GENERATION_PENDING`), plus a tail option **"Include all N — don't make me click each one"**. The user can also pick "Show next batch" to see more.
 
-After selection, call `AskQuestion` once more for a final confirmation:
+After selection, call `AskUserQuestion` once more for a final confirmation:
 
-> "About to start remote test script generation for **N** test cases against `<projectUrl>`. This will consume Muggle workflow budget. Proceed?"
+> "About to start remote test script generation for **N** test cases against `<projectUrl>`. This will consume Muggle Test workflow budget. Proceed?"
 >
 > - "Yes, start all N"
 > - "No, cancel"
@@ -162,6 +165,19 @@ Total: 17 dispatched | 16 started | 1 failed
 
 For failures: include a one-line error excerpt from the item's error field and (where possible) a hint at the cause (e.g., "missing instructions field — edit the test case in the dashboard, then re-run this skill").
 
+### Per-item failure routing (regen)
+
+For every item with a non-success dispatch status, follow [`_shared/failure-mode-handling.md`](../_shared/failure-mode-handling.md) section C (regen failure buckets: `transient` / `infra` / `agent-course` / `product-uxux`).
+
+Because this skill is bulk-dispatch (no live user attention per item), batch the routing — don't ask the user per item:
+
+1. Group failed items by AI-classified bucket using the signal heuristics in the shared doc (most failures here will be `transient` or `infra` since dispatch failures rarely surface product-uxux signals).
+2. Emit one `regen-failure-classified` event per failed item via `muggle-local-telemetry-event-emit`.
+3. Present the buckets to the user via a single `AskUserQuestion` summarizing counts: e.g., "12 transient (recommend retry), 3 infra (recommend report-bug). What do you want to do?" Options: "Retry transient items", "Report all to Muggle AI", "muggle-feedback for selected items", "Skip — leave them as-is".
+4. Emit one `regen-failure-resolved` event per item with the user's batch decision applied.
+
+Bulk regen does not run replays, so the section B (replay) router does not apply here.
+
 ### Step 8 — Open the Dashboard
 
 Open the Muggle AI dashboard so the user can watch progress visually:
@@ -200,11 +216,11 @@ Add item to cart         rt-ghi789   COMPLETED   12
 
 ## Non-negotiables
 
-- **The user MUST select the project** — present projects via `AskQuestion`, never infer from cwd, repo name, or URL guesses.
-- **The user MUST approve which test cases to regenerate** — show the candidates via `AskQuestion`, let them deselect, then confirm again before any dispatch. Bulk-regenerating without approval can waste meaningful workflow budget.
+- **The user MUST select the project** — present projects via `AskUserQuestion`, never infer from cwd, repo name, or URL guesses.
+- **The user MUST approve which test cases to regenerate** — show the candidates via `AskUserQuestion`, let them deselect, then confirm again before any dispatch. Bulk-regenerating without approval can waste meaningful workflow budget.
 - **Default filter is `DRAFT` + `GENERATION_PENDING`** — never include `GENERATING`, `ACTIVE`, `DEPRECATED`, `ARCHIVED`, `REPLAYING`, or `REPLAY_PENDING` unless the user explicitly says so. `GENERATING` already has a workflow in flight and dispatching another races against it. `ACTIVE` test cases already have working scripts. The rest reflect deliberate user decisions or in-flight replays the skill should not interfere with.
 - **Use the bulk endpoint for dispatch** — call `muggle-remote-workflow-start-test-script-generation-bulk` once with all selected test case IDs rather than dispatching one-by-one. The backend resolves full test case details internally.
 - **Failures don't abort the batch** — the bulk API returns per-item status. Surface failures in the report. Partial progress beats no progress.
 - **Open the dashboard, don't poll by default** — the runs page is the canonical view of progress. Only poll if the user explicitly asks.
-- **Use `AskQuestion` for every selection** — never ask the user to type a number.
+- **Use `AskUserQuestion` for every selection** — never ask the user to type a number.
 - **Can be invoked at any state** — if the user already has a project chosen in conversation context, skip Step 2 and go straight to scanning.

package/plugin/skills/muggle-test-regenerate-missing/evals/evals.json

@@ -1,6 +1,6 @@
 {
   "skill_name": "muggle-test-regenerate-missing",
-  "notes": "These evals test the PLAN behavior. Because Muggle MCP tools require live auth and a real project, the subagents can't actually execute the workflow — each prompt tells them to write a step-by-step plan instead. The assertions check whether the plan reflects the skill's non-negotiables (correct filter, AskQuestion-based selection, no auto-select, dispatch via the remote workflow tool, batch-failure tolerance, dashboard open-at-end).",
+  "notes": "These evals test the PLAN behavior. Because Muggle MCP tools require live auth and a real project, the subagents can't actually execute the workflow — each prompt tells them to write a step-by-step plan instead. The assertions check whether the plan reflects the skill's non-negotiables (correct filter, AskUserQuestion-based selection, no auto-select, dispatch via the remote workflow tool, batch-failure tolerance, dashboard open-at-end).",
   "evals": [
     {
       "id": 0,
@@ -9,13 +9,13 @@
       "files": [],
       "assertions": [
         { "name": "calls_auth_status_first", "text": "Plan starts by calling muggle-remote-auth-status (and login/poll if needed) before any other Muggle tool." },
-        { "name": "project_selection_via_AskQuestion", "text": "Plan calls muggle-remote-project-list and presents projects via AskQuestion rather than auto-selecting 'Acme Checkout QA' by name match." },
+        { "name": "project_selection_via_AskQuestion", "text": "Plan calls muggle-remote-project-list and presents projects via AskUserQuestion rather than auto-selecting 'Acme Checkout QA' by name match." },
         { "name": "default_filter_is_draft_and_generation_pending", "text": "Plan states that the status filter is DRAFT + GENERATION_PENDING and explicitly excludes GENERATING, ACTIVE, DEPRECATED, ARCHIVED, REPLAYING, and REPLAY_PENDING." },
         { "name": "uses_test_case_list_paginated", "text": "Plan calls muggle-remote-test-case-list with pagination (or equivalent full-enumeration) for the project scan step." },
         { "name": "test_case_get_before_dispatch", "text": "Plan calls muggle-remote-test-case-get for each candidate before dispatching generation, to obtain the full payload (goal, precondition, instructions, expectedResult, url)." },
         { "name": "dispatch_via_remote_workflow_tool", "text": "Plan dispatches each regeneration via muggle-remote-workflow-start-test-script-generation (not a local Electron tool)." },
-        { "name": "candidate_list_via_AskQuestion_multi_select", "text": "Plan presents the candidate test cases via AskQuestion with multi-select (allow_multiple: true) so the user can deselect individuals." },
-        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no confirmation AskQuestion before any dispatch, showing the count of test cases about to be regenerated." },
+        { "name": "candidate_list_via_AskQuestion_multi_select", "text": "Plan presents the candidate test cases via AskUserQuestion with multi-select (allow_multiple: true) so the user can deselect individuals." },
+        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no confirmation AskUserQuestion before any dispatch, showing the count of test cases about to be regenerated." },
         { "name": "batch_failure_tolerance", "text": "Plan explicitly states that a single dispatch failure does not abort the batch — failures are logged and the loop continues." },
         { "name": "opens_dashboard_runs_page_at_end", "text": "Plan ends by opening the Muggle dashboard project runs page for the user to watch progress." }
       ]
@@ -27,12 +27,12 @@
       "files": [],
       "assertions": [
         { "name": "calls_auth_status_first", "text": "Plan starts by calling muggle-remote-auth-status before any other Muggle tool." },
-        { "name": "project_selection_via_AskQuestion", "text": "Plan uses AskQuestion to let the user confirm project choice; does not auto-select 'Tanka Staging' by name match alone." },
+        { "name": "project_selection_via_AskQuestion", "text": "Plan uses AskUserQuestion to let the user confirm project choice; does not auto-select 'Tanka Staging' by name match alone." },
         { "name": "honors_override_to_include_generating", "text": "Plan explicitly honors the user's override and includes GENERATING in the filter for this run, noting that this is a deliberate override of the default filter." },
         { "name": "still_excludes_active_deprecated_archived", "text": "Even with the override, the plan still excludes ACTIVE, DEPRECATED, ARCHIVED, REPLAY_PENDING, and REPLAYING — it only widens the filter to include GENERATING, not everything." },
         { "name": "handles_large_candidate_list", "text": "Plan acknowledges that with ~200 test cases the candidate list may exceed 25 and describes paging or bulk-include handling (e.g., 'Include all N' tail option)." },
         { "name": "dispatch_via_remote_workflow_tool", "text": "Plan dispatches each regeneration via muggle-remote-workflow-start-test-script-generation." },
-        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no AskQuestion confirmation before any dispatch, showing the total count." },
+        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no AskUserQuestion confirmation before any dispatch, showing the total count." },
         { "name": "batch_failure_tolerance", "text": "Plan states that a single dispatch failure does not abort the batch." },
         { "name": "opens_dashboard_runs_page_at_end", "text": "Plan ends by opening the Muggle dashboard project runs page." }
       ]
@@ -44,12 +44,12 @@
       "files": [],
       "assertions": [
         { "name": "calls_auth_status_first", "text": "Plan starts by calling muggle-remote-auth-status before any other Muggle tool." },
-        { "name": "project_selection_via_AskQuestion", "text": "Plan uses AskQuestion to let the user pick the project — does not infer it." },
+        { "name": "project_selection_via_AskQuestion", "text": "Plan uses AskUserQuestion to let the user pick the project — does not infer it." },
         { "name": "default_filter_is_draft_and_generation_pending", "text": "Plan states that the status filter is DRAFT + GENERATION_PENDING by default." },
-        { "name": "small_list_all_preselected", "text": "Plan describes presenting all candidates in a single AskQuestion with everything pre-checked (since the candidate list is ≤ 25)." },
+        { "name": "small_list_all_preselected", "text": "Plan describes presenting all candidates in a single AskUserQuestion with everything pre-checked (since the candidate list is ≤ 25)." },
         { "name": "test_case_get_before_dispatch", "text": "Plan calls muggle-remote-test-case-get for each candidate before dispatching generation." },
         { "name": "dispatch_via_remote_workflow_tool", "text": "Plan dispatches each regeneration via muggle-remote-workflow-start-test-script-generation." },
-        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no AskQuestion confirmation before any dispatch." },
+        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no AskUserQuestion confirmation before any dispatch." },
         { "name": "batch_failure_tolerance", "text": "Plan states that a single dispatch failure does not abort the batch." },
         { "name": "opens_dashboard_runs_page_at_end", "text": "Plan ends by opening the Muggle dashboard project runs page." }
       ]

package/plugin/skills/muggle-upgrade/SKILL.md

@@ -1,9 +1,11 @@
 ---
 name: muggle-upgrade
-description: Update Muggle AI to latest version. Use when user types muggle upgrade or asks to update Muggle tools.
+description: Update Muggle AI to latest version. Use when user types muggle upgrade or asks to update Muggle Test tools.
 ---
 
-# Muggle Upgrade
+# Muggle Test Upgrade
+
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-upgrade"`.
 
 Update all Muggle AI components to the latest published version. This means **both** the `@muggleai/works` CLI on npm **and** the Electron runner the CLI manages.
 

package/plugin/skills/muggle-works-npm-release/SKILL.md

@@ -1,13 +1,15 @@
 ---
 name: muggle-works-npm-release
 description: >-
-  Cut @muggleai/works release: AskQuestion (major/minor/patch), sync master, stop if
+  Cut @muggleai/works release: AskUserQuestion (major/minor/patch), sync master, stop if
   nothing ships, semver baseline + Electron from GitHub, confirm plan, bump
   package.json + sync:versions, full local verify, chore(release) PR, merge via gh,
   dispatch publish-works-to-npm.yml—no local npm publish.
 ---
 
-# Muggle Works — npm release (single playbook)
+# Muggle Test Works — npm release (single playbook)
+
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-works-npm-release"`.
 
 Repo: **`multiplex-ai/muggle-ai-works`**. Workflow: **`.github/workflows/publish-works-to-npm.yml`** (“Publish Works to npm”). **Never** run local **`npm publish`** (OIDC trusted publishing in CI).
 
@@ -17,7 +19,7 @@ Repo: **`multiplex-ai/muggle-ai-works`**. Workflow: **`.github/workflows/publish
 
 **Stop until the user answers.**
 
-**Prefer `AskQuestion`** with exactly these three options: **major**, **minor**, **patch** (fix). If the environment has no structured question tool, ask the same in plain text:
+**Prefer `AskUserQuestion`** with exactly these three options: **major**, **minor**, **patch** (fix). If the environment has no structured question tool, ask the same in plain text:
 
 > Is this release a **major**, **minor**, or **patch** (fix)?
 
@@ -185,7 +187,7 @@ Give the user the **Actions run URL**. If npm lags, wait ~60s and retry.
 ## Rules
 
 - **No local `npm publish`.**
-- **Phase 1:** use **`AskQuestion`** for major / minor / patch when available (see Phase 1).
+- **Phase 1:** use **`AskUserQuestion`** for major / minor / patch when available (see Phase 1).
 - Phases 1–3: keep chat concise; Phase 4–5 can be terse status lines.
 - If the user cancels after Phase 3, **do not** merge or dispatch CI.
 - **Tag vs npm:** **`v*`** tags are for the **npm** package; **`electron-app-v*`** is separate — **`electronAppVersion`** can move independently of **`version`**.

package/plugin/skills/mupgrade/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mupgrade
+description: Explicit short alias for the `muggle-upgrade` skill. ONLY invoke when the user explicitly types `mupgrade` or `/mupgrade` — never auto-trigger from any other phrasing.
+---
+
+# mupgrade — alias for muggle-upgrade
+
+Invoke the `muggle-upgrade` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/scripts/postinstall.mjs

@@ -34,6 +34,16 @@ const VERSION_OVERRIDE_FILE_NAME = "electron-app-version-override.json";
 const CURSOR_SKILLS_DIRECTORY_NAME = ".cursor";
 const CURSOR_SKILLS_SUBDIRECTORY_NAME = "skills";
 const MUGGLE_SKILL_PREFIX = "muggle";
+const ALIAS_SKILLS_MANIFEST_PATH = join(
+    dirname(fileURLToPath(import.meta.url)),
+    "..",
+    "plugin",
+    "skills",
+    "_aliases.json",
+);
+const MUGGLE_ALIAS_SKILLS = new Set(
+    JSON.parse(readFileSync(ALIAS_SKILLS_MANIFEST_PATH, "utf-8")).aliases,
+);
 
 /**
  * Get the path to the postinstall log file.
@@ -241,7 +251,7 @@ function syncCursorSkills() {
             continue;
         }
 
-        if (!skillEntry.name.startsWith(MUGGLE_SKILL_PREFIX)) {
+        if (!skillEntry.name.startsWith(MUGGLE_SKILL_PREFIX) && !MUGGLE_ALIAS_SKILLS.has(skillEntry.name)) {
             continue;
         }
 

package/dist/plugin/skills/do/validate-code.md

@@ -1,38 +0,0 @@
-# Code Validation Agent (Stage 4/7)
-
-You are validating that each repository's git state is ready for the dev cycle pipeline.
-
-## Turn preamble
-
-Start the turn with:
-
-```
-**Stage 4/7 — Validate code** — checking branch and commit state for each repo with changes.
-```
-
-## Input
-
-You receive:
-- A list of repos with changes (from impact analysis), including their paths and branch names
-
-## Your Job
-
-For each repo:
-
-1. **Verify the branch is a feature branch** (not main/master/the default branch). This should already be validated by impact analysis, but double-check.
-2. **Check for uncommitted changes:** Run `git status --porcelain` in the repo. If there are uncommitted changes, warn the user — uncommitted changes won't be included in PRs.
-3. **Get the branch diff:** Run `git diff <default-branch>...HEAD --stat` for a summary of changes.
-4. **Verify commits exist on the branch:** Run `git log <default-branch>..HEAD --oneline` to confirm there are commits to push.
-
-## Output
-
-Per repo:
-
-**Repo: (name)**
-- Branch: (name)
-- Commits on branch: (count and one-line summaries)
-- Uncommitted changes: yes/no (with warning if yes)
-- Diff stat: (file change summary)
-- Status: READY | WARNING | ERROR
-
-**Overall:** READY to proceed / BLOCKED (with reasons)

package/plugin/skills/do/validate-code.md

@@ -1,38 +0,0 @@
-# Code Validation Agent (Stage 4/7)
-
-You are validating that each repository's git state is ready for the dev cycle pipeline.
-
-## Turn preamble
-
-Start the turn with:
-
-```
-**Stage 4/7 — Validate code** — checking branch and commit state for each repo with changes.
-```
-
-## Input
-
-You receive:
-- A list of repos with changes (from impact analysis), including their paths and branch names
-
-## Your Job
-
-For each repo:
-
-1. **Verify the branch is a feature branch** (not main/master/the default branch). This should already be validated by impact analysis, but double-check.
-2. **Check for uncommitted changes:** Run `git status --porcelain` in the repo. If there are uncommitted changes, warn the user — uncommitted changes won't be included in PRs.
-3. **Get the branch diff:** Run `git diff <default-branch>...HEAD --stat` for a summary of changes.
-4. **Verify commits exist on the branch:** Run `git log <default-branch>..HEAD --oneline` to confirm there are commits to push.
-
-## Output
-
-Per repo:
-
-**Repo: (name)**
-- Branch: (name)
-- Commits on branch: (count and one-line summaries)
-- Uncommitted changes: yes/no (with warning if yes)
-- Diff stat: (file change summary)
-- Status: READY | WARNING | ERROR
-
-**Overall:** READY to proceed / BLOCKED (with reasons)