@muggleai/works 4.10.1 → 4.11.1

package/dist/plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "muggle",
   "description": "Run real-browser end-to-end (E2E) acceptance tests on your web app from any AI coding agent. Generate test scripts from plain English, replay them on localhost, capture screenshots, and validate user flows like signup, checkout, and dashboards. Works across Claude Code, Cursor, Codex, and Windsurf.",
-  "version": "4.10.1",
+  "version": "4.11.1",
   "author": {
     "name": "Muggle AI",
     "email": "support@muggle-ai.com"

package/dist/plugin/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "muggle",
   "displayName": "Muggle AI",
   "description": "Ship quality products with AI-powered end-to-end (E2E) acceptance testing that validates your web app like a real user — from Claude Code and Cursor to PR.",
-  "version": "4.10.1",
+  "version": "4.11.1",
   "author": {
     "name": "Muggle AI",
     "email": "support@muggle-ai.com"

package/dist/plugin/skills/_shared/pr-followup-helpers.md

@@ -0,0 +1,151 @@
+# PR follow-up helpers
+
+Generic operational guidance for running a PR-comment follow-up loop on GitHub: reviewer allow-list resolution, reply routing across the different comment endpoints, and a classification rule for reviewer comments with worked examples and a borderline test. Caller-agnostic — any loop that picks one comment per tick and decides what to do with it can drive off this doc.
+
+The classification produces an **action shape** (in-place change, deep-cycle through the caller's implementation pipeline, reply only, escalate, etc.) — the caller maps each shape to its specific routing (which stage to dispatch, which terminal-message template to use, which reply endpoint to hit).
+
+## Resolving the reviewer allow-list
+
+Stage 8 only acts on comments authored by users in the **allow-list** = (requested reviewers ∪ CODEOWNERS) − bots − PR author. Re-resolve every tick (decision 9 in the design doc).
+
+### Step 1: requested reviewers
+
+```bash
+gh pr view <number> --repo <owner>/<repo> --json reviewRequests,author
+```
+
+`reviewRequests` is an array of `{ login? , slug? }`. User reviewers have `login`; team reviewers have `slug` (and `name`). Expand teams to member logins:
+
+```bash
+gh api orgs/<org>/teams/<slug>/members --jq '.[].login'
+```
+
+Record `prAuthor = author.login` for the exclusion step.
+
+### Step 2: CODEOWNERS
+
+Look for the file in this order — first hit wins:
+
+1. `.github/CODEOWNERS`
+2. `CODEOWNERS`
+3. `docs/CODEOWNERS`
+
+Read from the PR's **head branch** (not master), because a PR that adds CODEOWNERS should be allowed to take effect once merged but is informational while open. In practice this means:
+
+```bash
+gh api repos/<owner>/<repo>/contents/.github/CODEOWNERS?ref=<head_sha> --jq '.content' | base64 -d
+```
+
+Parse line-by-line:
+
+- Skip blank lines and lines starting with `#`.
+- Each line is `<pattern> <owner1> <owner2> ...`.
+- Owners are either `@user` or `@org/team`. Strip the leading `@`.
+- For our purposes we don't need to match `<pattern>` against changed files — CODEOWNERS membership for the *repo* is enough. Collect the union of all owners across all lines.
+
+Expand `@org/team` to member logins via the orgs/teams/members endpoint (same as Step 1).
+
+If no CODEOWNERS file exists in any of the three locations, the CODEOWNERS contribution is empty. Don't fail.
+
+### Step 3: filter
+
+Allow-list = (requested reviewers ∪ CODEOWNERS) − `{prAuthor}` − bot logins.
+
+Bot logins are any login matching:
+
+- Ends with `[bot]` (e.g. `dependabot[bot]`)
+- Exact match in the standard list: `dependabot`, `github-actions`, `renovate`, `mergify`
+
+A comment author not in the allow-list is silently ignored — do not reply, do not address.
+
+## Reply routing
+
+GitHub's PR APIs are not uniform across comment types. Route by parent type.
+
+### Line-level review comment
+
+A comment attached to a specific file:line that belongs to a review thread. This is the **most common** path.
+
+```bash
+gh api \
+  --method POST \
+  -H "Accept: application/vnd.github+json" \
+  /repos/<owner>/<repo>/pulls/<number>/comments/<comment_id>/replies \
+  -f body="Done in $(git rev-parse --short HEAD) — renamed \`fooBar\` to \`foo_bar\`."
+```
+
+The reply lands in the same review thread. The reply itself becomes a new line-level comment with `in_reply_to_id = <comment_id>`.
+
+### Review body (CHANGES_REQUESTED with no inline comments)
+
+A reviewer left a summary review with `state: CHANGES_REQUESTED` and a body, but **no** inline comments. GitHub has no "reply to review body" endpoint — post a top-level PR comment that references the review:
+
+```bash
+gh pr comment <number> --repo <owner>/<repo> --body "Re: review #<review_id> — done in $(git rev-parse --short HEAD)."
+```
+
+### Failing CI check
+
+No reply. The fix commit IS the response. Include the failing check name in the commit subject so the connection is obvious in `git log`:
+
+```
+fix(ci): typecheck — narrow type of foo
+fix(ci): lint — remove unused import
+```
+
+### Never
+
+- Never post a top-level comment in reply to a line-level comment. It loses thread context and pollutes the PR conversation tab.
+- Never `gh pr review --comment` for replies — that endpoint is for *new* reviews, not replies.
+- Never reply twice to the same comment. The cursor in `last_seen.json` is the only re-entry guard; advance it after every reply.
+
+## Classify
+
+Classify the **review as a unit** — but reply per line comment (threaded), not per review.
+
+| Class | Signal | Action |
+| :---- | :----- | :----- |
+| **actionable** | Review names at least one concrete change or asks an answerable question. Soft phrasing counts when there's a concrete referent. | Treat as amended requirements; run **one** implementation cycle for the whole review; reply **threaded per line comment** referencing the new SHA (top-level only when the review is body-only). |
+| **ambiguous** | No actionable signal — pure vibes, contradictory, or depends on knowledge the loop can't access. | Escalate once with two interpretations; pause the PR. |
+
+Default to **actionable**. CI catches wrong attempts; reviewers correct on the next round. Escalation is a round-trip with an absent user — reserve it.
+
+Reply shape (all replies for one review reference the same SHA):
+
+- **threaded** (default): `Done in <sha> — <attribution>. (Review #<review_id>, cycle <status>.)`
+- **top-level** (fallback, body-only reviews): `Re: review #<review_id> — addressed in <sha>, cycle <status>.`
+- **ambiguous**: no bot reply.
+
+### Worked examples — Actionable reviews
+
+| Review (summarized) | Why actionable |
+| :------------------ | :------------- |
+| 3 comments: "rename `fooBar` to `foo_bar`", "use `const` here", "fix this typo" | Three concrete edits |
+| 1 comment: "could the procedure be simpler?" | Soft-phrased but the intent is clear — simplify; pick the best interpretation, run the cycle, reply with what was changed |
+| Review body: "Mostly looks good. Two things: extract the validation into a helper, and add a null check before the lookup." Plus 0 line comments. | Two concrete directives in the body |
+| 4 comments: "why this approach?", "is this called from X?", "does this need to handle empty array?", "what's the perf here?" | All questions but each is answerable; cycle dispatches an "answer + maybe-fix" pass and the reply summary captures each answer |
+| 1 comment: "rewrite this module — the architecture doesn't match the spec" | Substantive rebuild, but the direction is clear: redo the module per the spec |
+| 1 comment: "I'd lean toward the bar.ts pattern" | Concrete referent (bar.ts) — apply that pattern |
+
+The single review goes through one full cycle regardless of comment count.
+
+### Worked examples — Ambiguous reviews
+
+| Review (summarized) | Why ambiguous |
+| :------------------ | :------------ |
+| 1 comment: "👀" / "hmm" / ":thinking:" | No signal at all |
+| 1 comment: "this is wrong" with no target or direction | Asserts a problem but doesn't propose a fix |
+| 2 comments: "use X" + "but actually don't use X" | Self-contradicting — can't reconcile without the reviewer |
+| 1 comment: "we discussed this offline — please address" | References context the loop doesn't have |
+| 1 comment: "won't this break the prod migration we did last week?" | Implicit change request gated on knowledge the loop can't access |
+| Mixed: 2 concrete directives + 1 comment "but also, rethink the whole approach" | The "rethink the whole approach" subverts the other two; escalate to confirm scope |
+
+Escalate per the caller's escalation procedure (write the review id to the cursor's escalated set, emit one terminal message with both interpretations, pause the PR until the user resolves).
+
+### Borderline rule
+
+If you can paraphrase the review's intent as **"do X"** with X being a concrete change (one or several) — it's actionable. Pick the best interpretation and dispatch the cycle.
+
+If you can paraphrase it only as **"the reviewer is dissatisfied but I can't tell with what"** — it's ambiguous.
+
+When the review mixes both ("3 concrete directives + 1 dissatisfaction"), the safer move is usually to action the concrete directives and ask about the dissatisfaction in the reply summary. Pure ambiguity means *nothing* in the review is actionable.

package/dist/plugin/skills/do/build.md

@@ -0,0 +1,51 @@
+# Build Agent (Stage 3)
+
+Implement the code change for this dev cycle. Read the frozen requirements from stage 2, produce the edits in each affected repo's worktree, and commit.
+
+## Turn preamble
+
+```
+**Stage 3 — Build** — implementing the change per the frozen requirements.
+```
+
+## Inputs
+
+- `requirements.md` from stage 2: goal, acceptance criteria, affected repos.
+- `state.md` from pre-flight: worktree path per repo, target branch, anything else the build needs to know about the environment.
+
+## Your job
+
+For each affected repo:
+
+1. **Re-read `requirements.md`.** Treat goal + AC as frozen. If something is unclear at this stage, that's a pre-flight bug — escalate, do not improvise.
+2. **Apply the change** in the repo's worktree. Edit existing files first; create new files only when the requirements demand it. Match the surrounding code's style, naming, and file layout.
+3. **Don't add what wasn't asked for.** No speculative abstractions, no extra logging, no "while I'm here" refactors. Three similar lines is better than a premature abstraction.
+4. **Commit** with a conventional-commit subject:
+   - `feat(<scope>): <short>` for new behavior
+   - `fix(<scope>): <short>` for bug fixes
+   - `refactor(<scope>): <short>` for reshape
+   - `docs(...)`, `chore(...)`, `test(...)` as appropriate
+
+   The body explains *why* when the why is non-obvious. The diff already says *what*.
+
+## Output
+
+Per repo:
+
+**Repo:** name
+- Files edited / created: list
+- Commit subject: `<conventional commit>`
+- Notable choices: anything that needed a judgment call (briefly)
+
+**Overall:** READY for impact analysis | BLOCKED — reason
+
+If a requirement is fundamentally unimplementable as written, halt and escalate with the specific blocker — do not ship a half-finished implementation.
+
+## Re-entry from stage 8
+
+Stage 8 (PR follow-up) may dispatch back to this stage when a reviewer comment requires real implementation work rather than an in-place doc edit. When re-entered:
+
+- The dispatch from stage 8 carries the comment(s) that triggered the re-build as additional context; treat them as amendments to the goal/AC for this iteration.
+- Continue on the existing branch — do not re-create the worktree.
+- Cycle forward through impact analysis → unit tests → E2E → open PR (which is a no-op since the PR already exists; just push).
+- Stage 8 resumes polling after the push lands.

package/dist/plugin/skills/do/e2e-acceptance.md

@@ -1,4 +1,4 @@
-# E2E Acceptance Agent (Stage 6/7)
+# E2E Acceptance Agent (Stage 6)
 
 You are executing E2E acceptance validation for the muggle-do cycle.
 
@@ -11,7 +11,7 @@ Standalone subagent (different invocation path, used by `muggle-test` Mode C): [
 Start the turn with:
 
 ```
-**Stage 6/7 — E2E acceptance** — running browser tests against the validation target from pre-flight.
+**Stage 6 — E2E acceptance** — running browser tests against the validation target from pre-flight.
 ```
 
 ## Design

package/dist/plugin/skills/do/impact-analysis.md

@@ -1,4 +1,4 @@
-# Impact Analysis Agent (Stage 3/7)
+# Impact Analysis Agent (Stage 4)
 
 You are analyzing git repositories to determine which ones have actual code changes that need to go through the dev cycle pipeline.
 
@@ -7,7 +7,7 @@ You are analyzing git repositories to determine which ones have actual code chan
 Start the turn with:
 
 ```
-**Stage 3/7 — Impact analysis** — diffing each affected repo against its default branch.
+**Stage 4 — Impact analysis** — diffing each affected repo against its default branch.
 ```
 
 ## Input

package/dist/plugin/skills/do/open-prs.md

@@ -1,114 +1,103 @@
-# PR Creation Agent (Stage 7/7)
+# PR Creation Agent (Stage 7 — Open PR)
 
-You are creating pull requests for each repository that has changes after a successful dev cycle run.
+Open a pull request for each repo that has changes. If an E2E walkthrough report is available from the previous stage, attach it. Honor preference gates. Hand off to stage 8 once done.
 
 ## Turn preamble
 
-Start the turn with:
-
 ```
-**Stage 7/7 — Open PR** — rendering the visual walkthrough and pushing the PR.
+**Stage 7 — Open PR** — pushing the branch and opening the PR.
 ```
 
-## Non-negotiable: visual walkthrough is required
-
-**You MUST invoke `muggle-pr-visual-walkthrough` (Mode B) to render the E2E section of the PR body.** Hand-writing the PR body with a text summary and `gh pr create` is a stage failure — reviewers rely on the dashboard links and per-step screenshots the walkthrough produces.
-
-If the E2E stage was skipped (validation was `unit-only` or `skip`), you may omit the walkthrough section — but mark the PR title with `[UNVERIFIED]` or `[UNIT-ONLY]` accordingly, and record the reason in the PR body under `## Validation`.
-
-Before calling `gh pr create`, self-check:
+## Inputs
 
-- [ ] `muggle-pr-visual-walkthrough` was invoked (or the skip reason is recorded).
-- [ ] The `body` returned by the skill is embedded verbatim in the PR body.
-- [ ] If `comment` is non-null, it will be posted as a follow-up after the PR is created.
+- Per-repo: name, path, branch.
+- Requirements: goal, acceptance criteria.
+- **Optional** E2E acceptance report from stage 6 — only present when validation ran. Produced by [`e2e-acceptance.md`](e2e-acceptance.md); schema is canonical in [`muggle-pr-visual-walkthrough/SKILL.md`](../muggle-pr-visual-walkthrough/SKILL.md) (Zod-validated by the CLI).
 
-If you cannot check all three, **halt** — do not create the PR. Fix the upstream stage first.
+## Per repo
 
-## Input
+0. **`autoCreatePR` gate** — apply per [`../muggle-preferences/preference-gates/autoCreatePR.md`](../muggle-preferences/preference-gates/autoCreatePR.md). On skip, record the reason in `result.md` and move on.
 
-You receive:
-- Per-repo: repo name, path, branch name
-- Requirements: goal, acceptance criteria
-- E2E acceptance report: passed/failed test cases, each with:
-  - `testCaseId`, `testScriptId`, `runId`, `projectId`
-  - `viewUrl`: link to view run on muggle-ai.com
-  - `steps`: array of `{ stepIndex, action, screenshotUrl }`
-  - `failureStepIndex` and `error` (if failed)
-  - `artifactsDir` (for local debugging)
-  - `description` and `useCaseName` (optional but recommended) — test case one-liner and parent use case title; drive the grouped overview and the per-test collapsible headers in the rendered walkthrough. Prefer values already in the `e2e-acceptance.md` stage's conversation context; only call `muggle-remote-test-case-get` / `muggle-remote-use-case-get` for anything you don't already have.
+1. **Push:** `git push -u origin <branch>` in the repo directory.
 
-## Your Job
+2. **Title** (under 70 chars):
+   - E2E report exists and has failures → `[E2E FAILING] <goal>`
+   - No E2E report at all (validation was `unit-only` or `skip`) → `[UNVERIFIED] <goal>` or `[UNIT-ONLY] <goal>` to match the validation strategy
+   - Otherwise → `<goal>`
 
-For each repo with changes:
+3. **Body** — assemble in order:
+   - `## Goal` — from requirements.
+   - `## Acceptance Criteria` — bulleted; omit section if empty.
+   - `## Changes` — summary of what changed in this repo.
+   - `## Validation` — one line: link to E2E report, or `unit-only`, or `skip — <reason>`.
+   - **If an E2E report exists,** invoke [`muggle-pr-visual-walkthrough`](../muggle-pr-visual-walkthrough/SKILL.md) Mode B to render the walkthrough block. Embed the returned `body` verbatim (it brings its own `## E2E Acceptance Results` heading). If no report, skip this block entirely.
 
-0. **Apply the `autoCreatePR` gate** per [`../muggle-preferences/preference-gates/README.md`](../muggle-preferences/preference-gates/README.md) + [`autoCreatePR.md`](../muggle-preferences/preference-gates/autoCreatePR.md). On the skip path, record the reason in `result.md` and move to the next repo.
-
-1. **Push the branch** to origin: `git push -u origin <branch-name>` in the repo directory.
-2. **Build the PR title:**
-   - If E2E acceptance tests have failures: `[E2E FAILING] <goal>`
-   - Otherwise: `<goal>`
-   - Keep under 70 characters
-3. **Render the E2E acceptance block** by invoking the shared `muggle-pr-visual-walkthrough` skill in **Mode B** (render-only for embedding). See "Rendering the E2E acceptance block via the shared skill" below. You receive `{body, comment}` where `body` is the E2E markdown block and `comment` is a non-null overflow comment only when the content exceeds the CLI's byte budget.
-4. **Build the PR body** by concatenating, in order:
-   - `## Goal` — the requirements goal
-   - `## Acceptance Criteria` — bulleted list (omit section if empty)
-   - `## Changes` — summary of what changed in this repo
-   - The `body` field from the skill output (already contains its own `## E2E Acceptance Results` header — do not add another)
-5. **Create the PR** using `gh pr create --title "..." --body "..." --head <branch>` in the repo directory.
-6. **Capture the PR URL** and extract the PR number.
-7. **Post the overflow `comment` only if it is non-null.** In the common case, `comment` is `null` and nothing is posted. Never post speculatively.
+4. **Create:** `gh pr create --title "..." --body "..." --head <branch>`. Capture the PR URL and number.
 
+5. **Overflow comment:** if the walkthrough skill returned a non-null `comment`, post it once:
    ```bash
    jq -r '.comment' /tmp/muggle-pr-section.json | gh pr comment <PR#> --body-file -
    ```
+   Never post when `comment` is `null`.
 
-## Rendering the E2E acceptance block via the shared skill
-
-**Do not hand-write the `## E2E Acceptance Results` markdown, and do not call `muggle build-pr-section` directly from this stage.** The rendering workflow is owned by the shared **`muggle-pr-visual-walkthrough`** skill (see `plugin/skills/muggle-pr-visual-walkthrough/SKILL.md`), which wraps the CLI and enforces the `E2eReport` input contract with a Zod schema.
-
-### Input — the `E2eReport` JSON
-
-The `e2e-acceptance.md` stage already produces an `E2eReport` with the exact shape the skill expects (`projectId` + `tests[]` with per-test `name`, `testCaseId`, `testScriptId`, `runId`, `viewUrl`, `status`, and `steps[]` of `{stepIndex, action, screenshotUrl}`; failed tests additionally have `failureStepIndex`, `error`, and optionally `artifactsDir`; every test may additionally carry `description` and `useCaseName` — optional but recommended — which drive the grouped overview and per-test collapsible headers in the rendered walkthrough). Pass it through unchanged — do not reshape it. The full schema is documented in the shared skill.
+## Stage 8 handoff
 
-### Invocation — Mode B (render-only)
+After every repo is processed, build the manifest and dispatch **one follow-up loop per opened PR**. The dispatches are the LAST action this stage takes — once they fire, the original session is free.
 
-Invoke `muggle-pr-visual-walkthrough` via the `Skill` tool with the `E2eReport` already in context. The skill will:
+Write `.muggle-do/sessions/<slug>/prs.json` with one entry per **opened** PR (skip repos where `autoCreatePR` short-circuited or PR creation failed):
 
-1. Validate the `E2eReport` and call `muggle build-pr-section` (piping the JSON to stdin).
-2. Parse the CLI's `{body, comment}` stdout.
-3. **Return `{body, comment}` to this stage's conversation** without posting anything — because Mode B is render-only. `body` is the E2E markdown block; `comment` is a non-null overflow follow-up comment only when content exceeds the byte budget, otherwise `null`.
-
-Mode A (where the skill itself finds an existing PR and posts a `gh pr comment`) is **not used by `muggle-do`** — it's for interactive callers like `muggle-test` that are mid-development with a PR already open. `muggle-do` always creates new PRs, so it always uses Mode B.
+```json
+[{ "repo": "owner/repo", "number": 142, "url": "...", "head_sha": "...", "state": "open" }]
+```
 
-### After rendering
+Seed `.muggle-do/sessions/<slug>/last_seen.json` keyed by `"<owner>/<repo>#<n>"` with the empty-cursor shape (full shape in [`../muggle-pr-followup/contract.md`](../muggle-pr-followup/contract.md)). Stage 7 only seeds; each per-PR loop owns advancing its own cursor.
+
+Also seed `.muggle-do/sessions/<slug>/cycle.json` — the muggle-do implementation cycle declaration the follow-up loop will invoke on each actionable review:
+
+```json
+{
+  "cycleName": "muggle-do dev cycle",
+  "steps": [
+    { "stage": 3, "file": "../do/build.md" },
+    { "stage": 4, "file": "../do/impact-analysis.md" },
+    { "stage": 5, "file": "../do/unit-tests.md" },
+    { "stage": 6, "file": "../do/e2e-acceptance.md" },
+    { "name": "post-walkthrough", "skill": "muggle-pr-visual-walkthrough", "mode": "A" }
+  ],
+  "pushHandler": "git push origin <branch>",
+  "useSubagent": false
+}
+```
 
-Back in this stage:
+For each entry in `prs.json`, dispatch its own loop as the final action:
+```
+/loop 1m /muggle:muggle-pr-followup <slug> <pr-number>
+```
+Resolve `<slug>` from the session directory's basename. One loop per PR — multi-repo sessions opening N PRs result in N independent loops, each tracking its own PR's review thread.
 
-- Embed `body` in the `gh pr create --body` body (see step 4 above).
-- Post the overflow `comment` as a follow-up **only when it is non-null** (see step 7 above).
-- If the CLI exited non-zero, the skill surfaces the stderr error — do not swallow it, surface it to the user.
+If `prs.json` is empty (all repos skipped, or all PR creations failed), **do not dispatch** — record the reason in `result.md` and exit.
 
-### Notes on fit vs. overflow
+## Self-check before exit
 
-- **Common case (fit):** the full evidence (summary, per-test rows, collapsible failure details) lives in the PR description, `comment` is `null`, no follow-up comment is posted.
-- **Overflow case:** the CLI detects the full body would exceed its byte budget; `body` contains the summary, per-test rows, and a pointer line; `comment` contains the overflow details. Post both.
-- You do not make the fit-vs-overflow decision — the CLI does. Never post the comment when it is `null`.
+- [ ] Every non-skipped repo got `gh pr create` to succeed.
+- [ ] When an E2E report existed, the walkthrough block was rendered via Mode B (not hand-written).
+- [ ] Overflow `comment` was posted only when non-null.
+- [ ] `prs.json` and `last_seen.json` reflect the PRs actually opened.
+- [ ] If `prs.json` is non-empty, the `/loop` dispatch was the last action.
 
 ## Output
 
-**PRs Created:**
-- (repo name): (PR URL)
-
-**E2E acceptance overflow comments posted:** (only include repos where an overflow comment was actually posted)
-- (repo name): comment posted to PR #(number)
-
-**Errors:** (any repos where PR creation or comment posting failed, with the error message)
+**PRs Created:** repo → URL
+**Skipped:** repo → reason (when `autoCreatePR` short-circuited)
+**Overflow comments posted:** repo → PR #
+**Stage 8:** `Watching <N> PR(s) — one /loop 1m /muggle:muggle-pr-followup <slug> <pr#> per PR` | `No PRs to watch — stage 8 not dispatched`
+**Errors:** repo → message
 
-## Post-merge cleanup (gated by `autoCleanup`)
+## Post-merge cleanup
 
-Cleanup fires in a follow-up turn after merge — never from this stage. See [`../_shared/post-merge-cleanup.md`](../_shared/post-merge-cleanup.md).
+Gated by `autoCleanup`. Fires in a follow-up turn after merge — never from this stage. See [`../_shared/post-merge-cleanup.md`](../_shared/post-merge-cleanup.md).
 
-After printing PR URLs, append one short reminder tied to the gate's current value:
+Append one short reminder tied to the gate value:
 
 - `always` → `Once merged, I'll run the cleanup sequence automatically.`
 - `never` → omit.

package/dist/plugin/skills/do/pre-flight.md

@@ -1,4 +1,4 @@
-# Pre-flight Agent (Stage 1/7)
+# Pre-flight Agent (Stage 1)
 
 You are running the **only user-facing stage** of the muggle-do dev cycle. Your job is to consolidate every ambiguity — task scope, repos, validation strategy, environment, credentials, PR target — into a **single turn** so the rest of the cycle can run unattended.
 
@@ -9,7 +9,7 @@ You are running the **only user-facing stage** of the muggle-do dev cycle. Your
 Start the turn with:
 
 ```
-**Stage 1/7 — Pre-flight** — consolidating everything the cycle needs before going silent.
+**Stage 1 — Pre-flight** — consolidating everything the cycle needs before going silent.
 ```
 
 ## Input
@@ -94,7 +94,7 @@ Also initialize `iterations/001.md` with a header:
 ```markdown
 # Iteration 001 — <ISO-8601 timestamp>
 
-### Stage 1/7 — Pre-flight (<timestamp>)
+### Stage 1 — Pre-flight (<timestamp>)
 
 <verbatim copy of pre-flight answers>
 ```

package/dist/plugin/skills/do/requirements.md

@@ -1,4 +1,4 @@
-# Requirements Analysis Agent (Stage 2/7)
+# Requirements Analysis Agent (Stage 2)
 
 You are analyzing a user's task description to extract structured requirements for an autonomous development cycle.
 
@@ -7,7 +7,7 @@ You are analyzing a user's task description to extract structured requirements f
 Start the turn with:
 
 ```
-**Stage 2/7 — Requirements** — extracting structured goals from the pre-flight-clarified task.
+**Stage 2 — Requirements** — extracting structured goals from the pre-flight-clarified task.
 ```
 
 Pre-flight already resolved ambiguity via the consolidated questionnaire. **Do not ask the user any questions here** — infer silently and record assumptions in Notes.

package/dist/plugin/skills/do/unit-tests.md

@@ -1,4 +1,4 @@
-# Unit Test Runner Agent (Stage 5/7)
+# Unit Test Runner Agent (Stage 5)
 
 You are running unit tests for each repository that has changes in the dev cycle pipeline.
 
@@ -7,7 +7,7 @@ You are running unit tests for each repository that has changes in the dev cycle
 Start the turn with:
 
 ```
-**Stage 5/7 — Unit tests** — running each repo's test suite.
+**Stage 5 — Unit tests** — running each repo's test suite.
 ```
 
 ## Input