/dyl-review

name: dyl-review
description: >-
  Review one or more PRs in Dylan's style: up to 7 copy-pasteable asks and one
  🟢/🟡/🔴 call. Quick by default; "deep" adds thermos and Bugbot. Use for
  /dyl-review, "review this PR like me", or terse design/correctness comments.
  Never posts to the PR.
disable-model-invocation: true
icon: search
color: blue

Dyl review

Produce a draft PR review the human can paste. This is the one review: thermos and Bugbot run inside it at deep depth, never as separate steps.

Input: one or more PR links or numbers. Multiple PRs get one review block each.

**Requires** `pstack`, plus `thermos` at deep depth. Check first with [../dyl-mode/references/requirements.md](../dyl-mode/references/requirements.md). Missing → stop and tell the user to run `/add-plugin <name>`.

**Forge.** Use `origin pr` when the repo lives on Origin, `gh pr` otherwise. Commands below show both.

Depth

• **quick** (default): the Dylan-lens worker only.
• **deep**: adds both thermos subagents and Bugbot, in parallel with the Dylan-lens worker. Roughly doubles wall-clock, bounded by the thermos bug/security pass.

Deep when the invoking skill or the human asks for it (deep / thorough / thermo). Otherwise quick.

Main-thread rules (strict)

1. Resolve PR URLs/numbers. `<base>` below is the PR's base branch (`gh pr view <n> --json baseRefName`, or `origin pr view <n> --json baseRef`), not assumed `main`. For deep, the PR head must be checked out locally: the current branch, or a throwaway worktree (`git fetch origin <base> <branch>`, then `git worktree add /tmp/dyl-review-<pr> origin/<branch>`, removed when done). Thermos and Bugbot audit a checkout. 2. Gather once, then fan out. The main thread writes the PR diff to a file (`git diff origin/<base>...HEAD` from the checkout when there is one, with `origin/<base>` freshly fetched, else `gh pr diff <n>` / `origin pr diff <n>`), then launches every worker the depth calls for in one message, pointing each at that file and at the checkout when there is one:

• One Dylan-lens worker (below). Always.
• Deep only: `thermo-nuclear-review-subagent` and `thermo-nuclear-code-quality-review-subagent` (the pair the `thermos` skill from the Thermos plugin launches), plus exactly one `bugbot` subagent with `Diff: branch changes` (Cursor's built-in `/review-bugbot`).

Analysis happens in the workers, not on the main thread. 3. Every worker uses auto / inherit intelligence (`Task` `model: inherit`, or omit `model`). Do not pin a cheap/fast model for the review judgment pass. 4. Keep the main thread thin: launch, wait, synthesize. Nothing user-facing until every worker finishes. 5. On a re-review (same PR, new tip), tell the Dylan-lens worker and the thermos subagents what changed since the last pass and which earlier asks were deliberately skipped, with the reason, so they re-judge instead of repeating. Bugbot takes a fixed prompt and gets no such context.

Dylan-lens worker

Use `generalPurpose`, not `dyl-agent`: `dyl-agent` routes review asks back into this skill. Scope it to this section (steps 1 to 3): the worker does not spawn workers or synthesize. It must:

1. Gather PR context

Read the diff file the main thread wrote. Open surrounding files from the checkout when one exists. Pull title and body read-only via `gh pr view` / `origin pr view`. Focus on the priority list below.

2. Lenses (apply in full when relevant)

• **Dyl-mode.** Read the `dyl-mode` skill's Dylan gates and pstack `poteto-mode`'s Principles index. Ask whether applying them would shrink or clarify the change (The Algorithm, reuse, simplify, flag scope, prove-it, laziness, measure-before-code for UI).
• **Repo standards.** Read the repo's `AGENTS.md`, `.cursor/rules/`, and any repo-local best-practices skill for the surface the PR touches. Apply them as a lens.
• **Grug.** Complexity is the enemy. 80/20 over completeness. No factoring before the second real caller. Keep behavior near the code that triggers it. Chesterton's fence: understand why something exists before deleting it.
• **Priorities, in order.** Correctness, then simplicity, types, concurrency and performance, boundaries, context and observability, naming, tests. A lower item never outranks a higher one.

3. Return candidates

Up to 7 candidates for the shortlist below, each anchored to file:line when known.

Synthesis (main thread)

Inputs: the Dylan-lens candidates, plus in deep both thermos reports and the Bugbot report.

1. Merge, then filter skeptically

• Dedupe across reviewers. The same issue from two or more reviewers is a strong signal.
• Assume any finding can be wrong, noisy, or out of scope. Keep one only when it is real, in the diff, and worth the author's time: correctness, security, breakages, feature-flag leaks, clear maintainability bugs, high-signal structure problems, or a Dylan-lens ask (reuse, simplify, flag scope, prove-it). Drop speculative rewrites, taste-only churn, and duplicates.

2. Shortlist up to 7 comments

Prefer high-signal issues you can anchor to a file/line. Every bullet is an ask or a concern. No praise, "nice catch", or other compliments as bullets (tagged nit or otherwise). Zero bullets is fine on a clean PR.

3. Compression pass (Dylan voice)

For each finding:

• One or two sentences max.
• Question-led when possible. Suggestions with "Let's" or "Can we".
• Bake in uncertainty when real: "I might be wrong", "I might be mistaken".
• Terse, direct, pragmatic. Minimal jargon. No fake politeness or motivational fluff.
• Actionable. One ask per bullet.
• Normal sentence capitalization.
• No em dashes. Use periods or commas. Write like a human.

4. Recommendation

Pick exactly one mark and lead with it on its own line (no "Rec:" label). In that same clause, call out the shape of the asks when it matters:

| Mark | Meaning | Clause habit | |------|---------|--------------| | 🟢 | Ship shape / small nits only | Say "nits only" (or "no as