@sideboard-ai/core 0.1.183 → 0.1.185

package/dist/index.cjs

@@ -7694,7 +7694,7 @@ function ensureGlobalCoordinatorCwd(opts) {
     "Typical flow (Home board): list_board \u2192 create_thread (sourceType=ticket|pr|branch) \u2192 send_to_thread \u2192 wait_for_turn (loop while stillRunning) \u2192 ask_git create-draft \u2192 wait_for_turn. Merge only if the user explicitly asked (`ask_git` merge).",
     "Typical flow (branch / explicit source): list_workspaces \u2192 list_branches|list_prs|list_issues \u2192 create_thread \u2192 send_to_thread \u2192 wait_for_turn (loop while stillRunning) \u2192 ask_git create-draft.",
     "Typical flow (find work): list_workspaces \u2192 pick repo(s) matching account / project context \u2192 Sideboard list_issues / linear_* (tickets) or list_prs(queue=review) (reviews) \u2192 show the options. Never wait on Claude Linear MCP. Only create_thread + send_to_thread when they asked to start (e.g. \u201Cfind me work and start it\u201D) \u2014 then wait_for_turn (loop while stillRunning) \u2192 ask_git create-draft.",
-    'Typical flow (review inbox): list_workspaces \u2192 list_prs(queue=review, limit=N) \u2192 show those PRs (ticket ids in the title when present). create_thread sourceType=pr only when they asked to start / do the work. Do not list_issues for "tickets to review". The child writes the review in chat and ask_user (Post this review / Keep it in chat) \u2014 do not github_comment / linear_comment / update the PR or ticket, and do not tell the child to post, until the user confirms. They should work through the feedback in chat first. The PR or ticket author sees those writes immediately.',
+    'Typical flow (review inbox): list_workspaces \u2192 list_prs(queue=review, limit=N) \u2192 show those PRs (ticket ids in the title when present). create_thread sourceType=pr only when they asked to start / do the work. Do not list_issues for "tickets to review". The child writes the review in chat and stops \u2014 do not ask_user after it. Do not github_comment / linear_comment / update the PR or ticket, and do not tell the child to post, until the user types a next step. They should work through the feedback in chat first. The PR or ticket author sees those writes immediately.',
     "Typical flow (new app): Bash create/clone under repos dir \u2192 add_workspace \u2192 create_thread \u2192 send_to_thread (implement) \u2192 wait_for_turn (loop while stillRunning) \u2192 ask_git create-draft.",
     "Always ask worktree agents to commit, push, and open draft PRs (`ask_git` / `send_to_thread`). If the user gave a goal (Greptile 5/5, CI green), pass that goal through so they watch-fix-push until it lands \u2014 do not start that loop on a plain push, and do not tell the human to poll. Tell them to merge only when the user explicitly asked. The worktree agent runs git/gh; never merge from this orchestration cwd."
   ].join("\n");
@@ -7752,8 +7752,8 @@ var init_coordinator_prompt = __esm({
       '- list_branches / list_prs / list_issues \u2014 pass repoPath from list_workspaces. Review is PRs (the surface for assigned ticket work), not the tickets: "Get me N tickets to review" \u2192 list_prs(queue=review, limit=N) then create_thread sourceType=pr. That is open non-draft PRs labeled eng-review with no individual user reviewer yet. A team request (engineering-team) is not a claim \u2014 the viewer is on that team and can pick it up; claimed means an individual account is the reviewer. Bots ignored. Use Settings \u2192 Agents / Projects context (roles, teams, labels \u2014 freeform text; project adds to account) to prefer the right queues. queue=mine is review-requested:@me; queue=approved|changes uses those labels. Also: state, label, reviewer=me|unassigned|login, query, limit default 40 max 250; raise limit or tighten when truncated. list_issues (query, assignee=me|unassigned|all|user, limit default 40 max 250) lists Linear, AbleTime, or GitHub tickets \u2014 do not use it for that review-inbox ask. When they ask for tickets to work on, follow their context (assignee=me or unassigned as it says).',
       "- Find work: when they ask to find work, pick up tickets, or list reviews, use Settings \u2192 Agents (account) plus Settings \u2192 Projects (per-repo) context. Tickets \u2192 Sideboard list_issues / linear_* (Account Linear). Reviews \u2192 list_prs(queue=review). Do not call Claude Linear MCP or any other vendor Linear MCP \u2014 those HTTP connectors hang or flap on the first turn. If a vendor MCP is down or reconnecting, ignore it and keep going with Sideboard tools. Show the options \u2014 do not create_thread or start unless they also asked to start (e.g. \u201Cfind me work and start it\u201D). Do not start this unprompted. To change that context, show the proposed text, ask_user (Save this context / Do not save), wait, then update_viewer_context with confirmed=true. Never write it without confirmation.",
       "- Ticket updates: list_issues / linear_search_issues / github_search_issues with updatedSince (yesterday, 2d, or ISO). One call returns new assignments, ticket edits, and new comments \u2014 do not get_issue every ticket just to check for comments. kind=created vs updated distinguishes new tickets from existing ones.",
-      "- linear_* (when Linear is connected) \u2014 list_teams for team key/states; get/create/update/comment with ENG-123. Worktree agents have the same Account tools \u2014 prefer they comment, update status, and create spin-offs (parent=) on their own ticket when they were asked to do the work. When reviewing a PR or ticket, do not comment or update until the user confirms (ask_user: Post this review / Keep it in chat) \u2014 they should work through the feedback in chat first. Scope errors: reconnect Linear in Account settings. Prefer these over any Linear MCP the CLI may still list.",
-      "- github_* \u2014 get/comment/update/create GitHub issues via Account `gh` (#123). Worktree agents have these too. Prefer over any vendor GitHub MCP. Pass parent= for spin-offs. When reviewing a PR or ticket, do not comment, submit `gh pr review`, or update the PR/ticket until the user confirms.",
+      "- linear_* (when Linear is connected) \u2014 list_teams for team key/states; get/create/update/comment with ENG-123. Worktree agents have the same Account tools \u2014 prefer they comment, update status, and create spin-offs (parent=) on their own ticket when they were asked to do the work. When reviewing a PR or ticket, do not comment or update until the user types a next step \u2014 they should work through the feedback in chat first. Do not tell the child to ask_user after the review. Scope errors: reconnect Linear in Account settings. Prefer these over any Linear MCP the CLI may still list.",
+      "- github_* \u2014 get/comment/update/create GitHub issues via Account `gh` (#123). Worktree agents have these too. Prefer over any vendor GitHub MCP. Pass parent= for spin-offs. When reviewing a PR or ticket, do not comment, submit `gh pr review`, or update the PR/ticket until the user types a next step.",
       "- abletime_* (when AbleTime is connected) \u2014 orientation first; get/comment/update/create (parent= for spin-offs); ensure_task when work has no ticket (or create_thread from the default branch auto-creates one). Worktree agents have the same Account tools. Same review-write gate as Linear/GitHub.",
       "- list_teams / slack_list_channels / slack_list_users / slack_search / slack_read / slack_post / slack_replies \u2014 Slack workspaces from Settings \u2192 Remote; pass team_id from list_teams",
       "- Optional connectors (Vercel, Supabase, PostHog, Sentry) in Settings \u2192 Connectors inject tokens into worktree agent env when connected. Prefer official CLIs (`vercel`, `supabase`, `sentry-cli`) with those env vars. PostHog has no first-class CLI \u2014 use the HTTP API (`POSTHOG_PERSONAL_API_KEY`). Tell any worktree agent (Claude / Cursor / Codex / OpenCode) to write CLI output to `.context/cli/` (not `.context/attachments/`) and read a slice \u2014 never stream raw `--json` / `--expand` into a tool result (that crashes the turn). They can `stop_job` if a detached fetch hangs. If a CLI is missing, the user can Install CLI on that row (not auto-installed on Connect). Do not add vendor MCPs or ask the user to paste tokens again. Git (`gh`) stays Settings \u2192 Git; issue tracking stays Settings \u2192 Issues; Slack stays Settings \u2192 Remote (Sideboard MCP).",
@@ -7761,7 +7761,7 @@ var init_coordinator_prompt = __esm({
       "- get_pr_stack / open_pr_stack_layers / add_stack_layer / create_pr_stack \u2014 GitHub stacked PRs (`gh stack`); one worktree per layer",
       "- list_models \u2014 only when you need a specific model (rare); otherwise omit model so Account defaults apply",
       "- list_threads / get_thread \u2014 live thread list (parent id + last message preview). get_thread on this orchestration chat lists child worktree agents (status + lastText). Also includes usage / lastTurnUsage.",
-      "- ask_user \u2014 composer multiple-choice only when blocked on a concrete choice (approach fork, which API, Save this context / Do not save, Post this review / Keep it in chat). Never for hellos, check-ins, or invented \u201Cwhat should we do?\u201D menus \u2014 reply in chat. Explain options first, description on every option, then wait.",
+      "- ask_user \u2014 composer multiple-choice only when blocked on a concrete choice (approach fork, which API, Save this context / Do not save). Never for hellos, check-ins, invented \u201Cwhat should we do?\u201D menus, or after a review \u2014 reply in chat. Explain options first, description on every option, then wait.",
       "- get_viewer_context / update_viewer_context \u2014 read or replace Settings \u2192 Agents (account) and Settings \u2192 Projects (per-repo) context. You can update a project: pass scope=project and repoPath from list_workspaces (this cwd is not a project). update_viewer_context requires confirmed=true after ask_user. Never write context unprompted.",
       "- set_caffeinate \u2014 keep this Mac awake across turns (macOS caffeinate). Turn on for Slack / away-from-keyboard work, overnight schedules, or when the user will be away. Turn OFF when they say they are done, wrapping up, going to sleep, or no longer need the machine awake. Closing this chat also releases it.",
       "- list_schedules / create_schedule / update_schedule / delete_schedule / run_schedule \u2014 local jobs that send a prompt to an orchestration chat (threadId or self) or start a new Global chat (omit threadId). One-shot `at`, interval `every` (15m/1h/6h/1d), or 5-field `cron`. Recurring jobs without threadId open a new chat each run. Jobs fire only while Sideboard.app is running; sleep skips until wake. Overnight/unattended runs: ask the user to enable Settings \u2192 Advanced \u2192 Caffeinate while schedules are enabled, or call set_caffeinate.",
@@ -7782,7 +7782,7 @@ var init_coordinator_prompt = __esm({
       "Inspect / review / PRs:",
       "- get_diff \u2014 compact diff summary",
       "- get_pr_checks \u2014 snapshot of a worktree thread's PR checks (null = no PR). Use this to inspect status. If the user gave a goal, the worktree agent watches with `gh pr checks --watch` \u2014 do not poll for the human.",
-      '- request_review \u2014 open a Review chat tab on a worktree thread (attaches .claude/skills/review/SKILL.md when present, else .context/review.md copied from .sideboard/review.md / stock; sends "Review changes in this workspace."); then wait_for_turn (loop while stillRunning) / get_turn_result on the returned id. The review stays in that chat until the user confirms posting it \u2014 do not tell the child to comment or update the PR or ticket.',
+      '- request_review \u2014 open a Review chat tab on a worktree thread (attaches .claude/skills/review/SKILL.md when present, else .context/review.md copied from .sideboard/review.md / stock; sends "Review changes in this workspace."); then wait_for_turn (loop while stillRunning) / get_turn_result on the returned id. The review stays in that chat so they can read it and type next steps \u2014 do not tell the child to comment or update the PR or ticket.',
       "- ask_git \u2014 commit & push, open a draft PR, mark ready for review, resolve conflicts, or merge. When the worktree is clean, Sideboard pushes / opens the PR itself. When dirty, it queues the worktree agent \u2014 then wait_for_turn (loop while stillRunning). Prefer this over paraphrasing. If ask_git / get_thread lastError says the GraphQL/PR body is too long, the branch is already pushed \u2014 send_to_thread so the worktree agent runs `gh pr create --body-file` with a short description. Do not invent SSH or auth failures from that error. If the user gave a goal (Greptile 5/5, CI green), send_to_thread that goal so the worktree agent enters the watch-fix-push loop \u2014 do not tell the human to poll.",
       '- Merge (`ask_git` action=merge / send_to_thread "Merge PR.") only when the user explicitly asked to merge that PR. Do not merge because the work looks done, CI is green, or a typical flow includes it.',
       '- Or send_to_thread with those exact phrases: "Commit and push.", "Commit, push, and open a draft PR.", "Ready for review.", "Merge the remote branch (main) into your branch and resolve conflicts. Then, commit and push your changes.", "Merge PR." (draft PRs: `gh pr create --draft -R <origin-owner/name>` using the workspace `github:` slug \u2014 never upstream). Never run git/gh from this orchestration cwd, and never merge the PR yourself.',
@@ -14928,11 +14928,11 @@ People running this review are asking \u201Ccan we ship this?\u201D Treat that a
 
 ## Confirm before posting
 
-The report stays in this chat until the user posts it. Do not call \`github_comment\`, \`linear_comment\`, \`abletime_comment\`, \`github_update_issue\`, \`linear_update_issue\`, \`abletime_update_task\`, or run \`gh pr review\` / \`gh pr comment\`, until they confirm.
+The report stays in this chat until the user posts it. Do not call \`github_comment\`, \`linear_comment\`, \`abletime_comment\`, \`github_update_issue\`, \`linear_update_issue\`, \`abletime_update_task\`, or run \`gh pr review\` / \`gh pr comment\`, until they type a next step that asks you to post.
 
-After the Recommendation is in chat, ask_user (**Post this review** / **Keep it in chat**), then wait. If they already asked you to post a specific comment or update in this turn, that is confirmation.
+After the Recommendation is in chat, stop. Do not call ask_user. The user needs time to read the review and will type the next steps. If they already asked you to post a specific comment or update in this turn, that is confirmation.
 
-The user should be able to work through the feedback in chat first. The PR or ticket author sees those writes immediately \u2014 a draft review will confuse them. Do not request reviewers, change labels, or assign yourself unless they asked.
+The PR or ticket author sees those writes immediately \u2014 a draft review will confuse them. Do not request reviewers, change labels, or assign yourself unless they asked.
 
 ## Findings
 
@@ -16349,7 +16349,7 @@ function classifyWorktreeOwnership(group, viewerLogin = "") {
   const reviewing = group.some((t) => {
     const author = normalizeViewerLogin(t.prAuthorLogin);
     if (author && me && author !== me) return true;
-    if (t.sourceType === "pr" && (!author || !me || author !== me)) return true;
+    if (t.sourceType === "pr" && me && (!author || author !== me)) return true;
     if (me && loginsInclude(t.prReviewerLogins, me)) return true;
     return false;
   });
@@ -19955,13 +19955,13 @@ function formatIssueToolsDirective(opts) {
   }
   lines.push(
     "- Do not ask the user to `claude mcp login` for tickets. Reconnect the Account source in Settings \u2192 Issues (or Git for `gh`).",
-    "- When reviewing a PR or ticket (review inbox or a Review tab): write the review in chat so the user can work through the feedback first; ask_user (Post this review / Keep it in chat) before `github_comment` / `linear_comment` / `*_update_*` / `gh pr review`. The PR or ticket author sees those immediately."
+    "- When reviewing a PR or ticket (review inbox or a Review tab): write the review in chat and stop. Do not call ask_user. The user needs time to read and will type next steps. Do not `github_comment` / `linear_comment` / `*_update_*` / `gh pr review` until they ask. The PR or ticket author sees those immediately."
   );
   const ticket = opts.ticketId?.trim();
   if (ticket) {
     const provider = opts.ticketProvider ?? "linear";
     lines.push(
-      `- This thread's ticket is \`${ticket}\` (${provider}). Use that id for get. Do not comment or update it with review findings until they confirm (ask_user: Post this review / Keep it in chat) \u2014 they should work through the feedback in chat first. If they asked you to do the work, routine status and spin-offs (\`parent=\`) are OK.`
+      `- This thread's ticket is \`${ticket}\` (${provider}). Use that id for get. Do not comment or update it with review findings until they type a next step that asks you to \u2014 they should work through the feedback in chat first. If they asked you to do the work, routine status and spin-offs (\`parent=\`) are OK.`
     );
   }
   return lines.join("\n");
@@ -19984,8 +19984,8 @@ function formatIssueToolsReminder(opts) {
     opts.abletime ? "abletime_*" : null
   ].filter(Boolean);
   const ticket = opts.ticketId?.trim();
-  const ticketBit = ticket ? ` This ticket: ${ticket}${opts.ticketProvider ? ` (${opts.ticketProvider})` : ""} \u2014 get; comment/update review findings only after ask_user. Spin-offs use parent=.` : " get/comment/update/create (parent= for spin-offs).";
-  return `Issues: Sideboard ${names.join(" / ")} (Account). Ignore vendor issue MCP auth.${ticketBit} Review feedback stays in chat until ask_user (Post this review / Keep it in chat) \u2014 PR and ticket authors see comments immediately.`;
+  const ticketBit = ticket ? ` This ticket: ${ticket}${opts.ticketProvider ? ` (${opts.ticketProvider})` : ""} \u2014 get; comment/update review findings only after they ask. Spin-offs use parent=.` : " get/comment/update/create (parent= for spin-offs).";
+  return `Issues: Sideboard ${names.join(" / ")} (Account). Ignore vendor issue MCP auth.${ticketBit} Review stays in chat \u2014 do not ask_user after it; they type next steps. Authors see comments immediately.`;
 }
 function formatLinearReminder(opts) {
   return formatIssueToolsReminder({
@@ -20040,11 +20040,11 @@ function formatArtifactDirective() {
     "- Standalone documents: a fenced block tagged `html` (preferred), `svg`, or `markdown` containing the FULL document opens the side column by itself. Use that or present_artifact \u2014 never both for the same body.",
     "- present_artifact type=log appends: same artifact_id, content = new lines only (plus status/phase). Do not resend the full log or wrap it in HTML.",
     "- Data: a markdown table is enough to read. Call present_schema only when the user needs to filter/edit/publish/persist rows \u2014 including when they ask for an editable table after you already showed markdown. Never re-present rows you already wrote just to display them.",
-    "- ask_user only when work is blocked on a few concrete options (approach fork, which API, auth vs cookies): first a short chat message explaining the decision and each option, then the call (description on every option), then stop and wait. Not for greetings, check-ins, or an invented menu of next tasks \u2014 reply in chat. If one option is the obvious default, proceed."
+    "- ask_user only when work is blocked on a few concrete options (approach fork, which API, auth vs cookies): first a short chat message explaining the decision and each option, then the call (description on every option), then stop and wait. Not for greetings, check-ins, an invented menu of next tasks, or after a review \u2014 reply in chat. If one option is the obvious default, proceed."
   ].join("\n");
 }
 function formatUiReminder() {
-  return "Sideboard UI: markdown table is enough to read data; present_schema if they ask to edit/filter (even after markdown); present_files for the file manager. html fence or present_artifact, not both for the same document. type=log appends (same artifact_id, new lines only). ask_user only for a real multiple-choice (not hellos or \u201Cwhat next?\u201D) \u2014 reply in chat. Do not say artifacts/CMS UI are unavailable.";
+  return "Sideboard UI: markdown table is enough to read data; present_schema if they ask to edit/filter (even after markdown); present_files for the file manager. html fence or present_artifact, not both for the same document. type=log appends (same artifact_id, new lines only). ask_user only for a real multiple-choice (not hellos, \u201Cwhat next?\u201D, or after a review) \u2014 reply in chat. Do not say artifacts/CMS UI are unavailable.";
 }
 var import_node_fs50, import_node_path47, PR_GOAL_RE, GITHUB_TICKET_REF, KEYED_TICKET_REF;
 var init_instructions = __esm({
@@ -20077,13 +20077,13 @@ function isReviewWriteGatedThread(thread, siblings) {
 function formatReviewWriteGateDirective() {
   return [
     "Review writes are public. The PR or ticket author sees GitHub/Linear/AbleTime comments, ticket updates, and submitted reviews immediately \u2014 a draft will confuse them.",
-    "Write the recommendation in chat so the user can work through the feedback first. Do not call github_comment, linear_comment, abletime_comment, github_update_issue, linear_update_issue, abletime_update_task, or run `gh pr review` / `gh pr comment`, until the user confirms.",
-    "After the review is in chat, ask_user (Post this review / Keep it in chat), then wait. If they already asked you to post a specific comment or update in this turn, that is confirmation.",
+    "Write the recommendation in chat so the user can work through the feedback first. Do not call github_comment, linear_comment, abletime_comment, github_update_issue, linear_update_issue, abletime_update_task, or run `gh pr review` / `gh pr comment`, until they type a next step that asks you to post.",
+    "After the review is in chat, stop. Do not call ask_user. The user needs time to read and will type the next steps. If they already asked you to post a specific comment or update in this turn, that is confirmation.",
     "Do not request reviewers, change labels, or assign yourself unless they asked \u2014 those also notify the author."
   ].join("\n");
 }
 function formatReviewWriteGateReminder() {
-  return "Review writes: keep the review in chat so they can work through it. ask_user (Post this review / Keep it in chat) before github_comment / linear_comment / *_update_* / `gh pr review` on the PR or ticket. Authors see those immediately.";
+  return "Review writes: keep the review in chat. Do not ask_user after it \u2014 they read and type next steps. Do not github_comment / linear_comment / *_update_* / `gh pr review` on the PR or ticket until they ask. Authors see those immediately.";
 }
 var REVIEW_TAB_TITLE;
 var init_review_write_gate = __esm({
@@ -24622,12 +24622,27 @@ var UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
 function assigneeFilterKey(assignee) {
   return (assignee ?? "").trim();
 }
+function applyLinearIssueQueryFilter(filter, query) {
+  const term = query?.trim();
+  if (!term) return;
+  const or = [
+    { title: { containsIgnoreCase: term } },
+    { description: { containsIgnoreCase: term } }
+  ];
+  const identifierMatch = term.match(/^[A-Za-z][\w]*-(\d+)$/);
+  const asNumber = identifierMatch ? Number(identifierMatch[1]) : /^\d+$/.test(term) ? Number(term) : NaN;
+  if (Number.isFinite(asNumber) && asNumber > 0) {
+    or.push({ number: { eq: asNumber } });
+  }
+  filter.or = or;
+}
 function buildLinearIssueFilter(input) {
   const filter = {
     state: { type: { nin: ["completed", "canceled"] } }
   };
   const since = input?.updatedSince?.trim();
   if (since) filter.updatedAt = { gte: since };
+  applyLinearIssueQueryFilter(filter, input?.query);
   const raw = assigneeFilterKey(input?.assignee) || "me";
   const key = raw.toLowerCase();
   if (key === "all" || key === "*") return filter;
@@ -24693,6 +24708,11 @@ async function listLinearIssuesFiltered(opts) {
 async function listLinearCommentsSince(opts) {
   const first = Math.max(1, Math.min(250, opts.limit ?? 200));
   const query = opts.query?.trim() ?? "";
+  const restrictToIssues = opts.issueIdentifiers != null;
+  const allowed = new Set(
+    (opts.issueIdentifiers ?? []).map((id) => id.trim()).filter(Boolean)
+  );
+  if (restrictToIssues && allowed.size === 0) return [];
   const assignee = assigneeFilterKey(opts.assignee) || (query ? "all" : "me");
   const json = await linearGraphql(
     COMMENTS_SINCE_QUERY,
@@ -24700,7 +24720,7 @@ async function listLinearCommentsSince(opts) {
       first,
       filter: {
         createdAt: { gte: opts.since },
-        issue: buildLinearIssueFilter({ assignee })
+        issue: buildLinearIssueFilter({ assignee, query: query || void 0 })
       }
     },
     opts
@@ -24708,6 +24728,7 @@ async function listLinearCommentsSince(opts) {
   const out = [];
   for (const node of json.comments?.nodes ?? []) {
     const identifier = String(node.issue?.identifier ?? "").trim();
+    if (restrictToIssues && !allowed.has(identifier)) continue;
     const body = previewIssueCommentBody(String(node.body ?? ""));
     if (!identifier && !body) continue;
     out.push({
@@ -24939,10 +24960,32 @@ function issueNumberFromApiUrl(url) {
   const number = Number(match[1]);
   return Number.isFinite(number) && number > 0 ? number : null;
 }
+var GITHUB_ISSUE_COMMENTS_PAGE_SIZE = 100;
+var GITHUB_ISSUE_COMMENTS_MAX_PAGES = 5;
+function parseGitHubIssueCommentNode(item, allowed) {
+  const rec = item && typeof item === "object" ? item : null;
+  if (!rec) return null;
+  const issueUrl = typeof rec.issue_url === "string" ? rec.issue_url : "";
+  const number = issueNumberFromApiUrl(issueUrl);
+  if (number == null) return null;
+  if (allowed && !allowed.has(number)) return null;
+  const body = previewIssueCommentBody(typeof rec.body === "string" ? rec.body : "");
+  const user = rec.user && typeof rec.user === "object" ? String(rec.user.login ?? "").trim() : "";
+  const createdAt = typeof rec.created_at === "string" ? rec.created_at : typeof rec.createdAt === "string" ? rec.createdAt : void 0;
+  const url = typeof rec.html_url === "string" ? rec.html_url : void 0;
+  return {
+    identifier: `#${number}`,
+    ...user ? { author: user } : {},
+    ...createdAt ? { createdAt } : {},
+    body,
+    ...url ? { url } : {}
+  };
+}
 async function listGitHubIssueCommentsSince(opts) {
   const limit = Math.max(1, Math.min(250, opts.limit ?? 200));
   const { cwd, slug } = await resolveGitHubIssueRepo(opts.repoPath);
   if (!slug) return [];
+  const restrictToIssues = opts.issueIdentifiers != null;
   const allowed = new Set(
     (opts.issueIdentifiers ?? []).map((id) => {
       try {
@@ -24952,36 +24995,27 @@ async function listGitHubIssueCommentsSince(opts) {
       }
     }).filter((n) => n != null)
   );
-  const path2 = `repos/${slug}/issues/comments?since=${encodeURIComponent(opts.since)}&per_page=${limit + 1}`;
-  const result = await gh(["api", path2], cwd, { reject: false });
-  if (result.exitCode !== 0 || !result.stdout.trim()) return [];
-  let parsed;
-  try {
-    parsed = JSON.parse(result.stdout);
-  } catch {
-    return [];
-  }
-  if (!Array.isArray(parsed)) return [];
+  if (restrictToIssues && allowed.size === 0) return [];
+  const pageSize = Math.min(GITHUB_ISSUE_COMMENTS_PAGE_SIZE, Math.max(1, limit));
   const out = [];
-  for (const item of parsed) {
-    const rec = item && typeof item === "object" ? item : null;
-    if (!rec) continue;
-    const issueUrl = typeof rec.issue_url === "string" ? rec.issue_url : "";
-    const number = issueNumberFromApiUrl(issueUrl);
-    if (number == null) continue;
-    if (allowed.size > 0 && !allowed.has(number)) continue;
-    const body = previewIssueCommentBody(typeof rec.body === "string" ? rec.body : "");
-    const user = rec.user && typeof rec.user === "object" ? String(rec.user.login ?? "").trim() : "";
-    const createdAt = typeof rec.created_at === "string" ? rec.created_at : typeof rec.createdAt === "string" ? rec.createdAt : void 0;
-    const url = typeof rec.html_url === "string" ? rec.html_url : void 0;
-    out.push({
-      identifier: `#${number}`,
-      ...user ? { author: user } : {},
-      ...createdAt ? { createdAt } : {},
-      body,
-      ...url ? { url } : {}
-    });
-    if (out.length >= limit) break;
+  for (let page = 1; page <= GITHUB_ISSUE_COMMENTS_MAX_PAGES; page++) {
+    const path2 = `repos/${slug}/issues/comments?since=${encodeURIComponent(opts.since)}&sort=created&direction=desc&per_page=${pageSize}&page=${page}`;
+    const result = await gh(["api", path2], cwd, { reject: false });
+    if (result.exitCode !== 0 || !result.stdout.trim()) break;
+    let parsed;
+    try {
+      parsed = JSON.parse(result.stdout);
+    } catch {
+      break;
+    }
+    if (!Array.isArray(parsed) || parsed.length === 0) break;
+    for (const item of parsed) {
+      const comment = parseGitHubIssueCommentNode(item, restrictToIssues ? allowed : null);
+      if (!comment) continue;
+      out.push(comment);
+      if (out.length >= limit) return out;
+    }
+    if (parsed.length < pageSize) break;
   }
   return out;
 }
@@ -25195,20 +25229,19 @@ async function listIssues(repoPath, opts) {
   const assignee = opts?.assignee?.trim() || void 0;
   const since = opts?.updatedSince ? parseIssueSince(opts.updatedSince) : void 0;
   if (source === "linear") {
-    const [listed, comments2] = await Promise.all([
-      listLinearIssuesFiltered({
-        assignee,
-        query,
-        limit: opts?.limit,
-        updatedSince: since
-      }),
-      since ? listLinearCommentsSince({
-        since,
-        assignee,
-        query,
-        limit: opts?.limit
-      }) : Promise.resolve(void 0)
-    ]);
+    const listed = await listLinearIssuesFiltered({
+      assignee,
+      query,
+      limit: opts?.limit,
+      updatedSince: since
+    });
+    const comments2 = since ? await listLinearCommentsSince({
+      since,
+      assignee,
+      query,
+      issueIdentifiers: query ? listed.issues.map((issue) => issue.identifier) : void 0,
+      limit: opts?.limit
+    }) : void 0;
     return {
       source,
       preferredSource,
@@ -26728,7 +26761,7 @@ function registerAbleTimeTools(server) {
   );
   server.tool(
     "abletime_comment",
-    "Add a markdown comment on an AbleTime task (id or CRM-232). When reviewing a PR or ticket, show the draft in chat and ask_user (Post this review / Keep it in chat) first \u2014 the author sees this immediately.",
+    "Add a markdown comment on an AbleTime task (id or CRM-232). When reviewing a PR or ticket, show the draft in chat and wait until they type a next step \u2014 do not ask_user after the review. The author sees this immediately.",
     { id: import_zod4.z.string(), body: import_zod4.z.string() },
     async (args) => {
       try {
@@ -26740,7 +26773,7 @@ function registerAbleTimeTools(server) {
   );
   server.tool(
     "abletime_update_task",
-    "Update an AbleTime task (id or CRM-232). Pass title, description, and/or state. When reviewing a PR or ticket, ask_user (Post this review / Keep it in chat) before changing the task \u2014 the author is notified.",
+    "Update an AbleTime task (id or CRM-232). Pass title, description, and/or state. When reviewing a PR or ticket, wait until they type a next step before changing the task \u2014 do not ask_user after the review. The author is notified.",
     {
       id: import_zod4.z.string(),
       title: import_zod4.z.string().optional(),
@@ -26870,7 +26903,7 @@ function registerGithubIssueTools(server) {
   );
   server.tool(
     "github_comment",
-    "Add a markdown comment on a GitHub issue (#123 or URL). Uses Account gh. When reviewing a PR or ticket, show the draft in chat and ask_user (Post this review / Keep it in chat) first \u2014 the author sees this immediately.",
+    "Add a markdown comment on a GitHub issue (#123 or URL). Uses Account gh. When reviewing a PR or ticket, show the draft in chat and wait until they type a next step \u2014 do not ask_user after the review. The author sees this immediately.",
     { id: import_zod5.z.string(), body: import_zod5.z.string(), repoPath: repoPathSchema },
     async ({ id, body, repoPath }) => {
       try {
@@ -26882,7 +26915,7 @@ function registerGithubIssueTools(server) {
   );
   server.tool(
     "github_update_issue",
-    "Update a GitHub issue (#123). Pass title, body, and/or state (open|closed). When reviewing a PR or ticket, ask_user (Post this review / Keep it in chat) before changing the issue \u2014 the author is notified.",
+    "Update a GitHub issue (#123). Pass title, body, and/or state (open|closed). When reviewing a PR or ticket, wait until they type a next step before changing the issue \u2014 do not ask_user after the review. The author is notified.",
     {
       id: import_zod5.z.string(),
       title: import_zod5.z.string().optional(),
@@ -26955,20 +26988,19 @@ function registerLinearTools(server) {
       try {
         const page = clampMcpIssueLimit(limit);
         const since = updatedSince ? parseIssueSince(updatedSince) : void 0;
-        const [listed, comments] = await Promise.all([
-          listLinearIssuesFiltered({
-            query,
-            assignee,
-            limit: page + 1,
-            updatedSince: since
-          }),
-          since ? listLinearCommentsSince({
-            since,
-            assignee,
-            query,
-            limit: page + 1
-          }) : Promise.resolve(void 0)
-        ]);
+        const listed = await listLinearIssuesFiltered({
+          query,
+          assignee,
+          limit: page + 1,
+          updatedSince: since
+        });
+        const comments = since ? await listLinearCommentsSince({
+          since,
+          assignee,
+          query,
+          issueIdentifiers: query ? listed.issues.map((issue) => issue.identifier) : void 0,
+          limit: page + 1
+        }) : void 0;
         return mcpJson(
           formatListedIssuesForMcp(
             {
@@ -27020,7 +27052,7 @@ function registerLinearTools(server) {
   );
   server.tool(
     "linear_update_issue",
-    "Update a Linear issue (uuid or ENG-123). Pass title, description, state, assignee, and/or priority. When reviewing a PR or ticket, ask_user (Post this review / Keep it in chat) before changing the ticket \u2014 the author is notified.",
+    "Update a Linear issue (uuid or ENG-123). Pass title, description, state, assignee, and/or priority. When reviewing a PR or ticket, wait until they type a next step before changing the ticket \u2014 do not ask_user after the review. The author is notified.",
     {
       id: import_zod6.z.string(),
       title: import_zod6.z.string().optional(),
@@ -27039,7 +27071,7 @@ function registerLinearTools(server) {
   );
   server.tool(
     "linear_comment",
-    "Add a markdown comment on a Linear issue (uuid or ENG-123). When reviewing a PR or ticket, show the draft in chat and ask_user (Post this review / Keep it in chat) first \u2014 the author sees this immediately.",
+    "Add a markdown comment on a Linear issue (uuid or ENG-123). When reviewing a PR or ticket, show the draft in chat and wait until they type a next step \u2014 do not ask_user after the review. The author sees this immediately.",
     {
       id: import_zod6.z.string(),
       body: import_zod6.z.string()
@@ -28445,7 +28477,7 @@ async function startMcpServer() {
     );
     server.tool(
       "request_review",
-      'Start a merge-readiness Review on a worktree agent thread (same as the desktop Review button). Opens a new Review chat tab, attaches .claude/skills/review/SKILL.md when present (else copies .sideboard/review.md into .context/review.md, or seeds that file from the stock template), and sends "Review changes in this workspace." Expect Approve / Approve with nits / Request changes / Needs more information in that chat. Do not comment on or update the PR or ticket until the user confirms (ask_user: Post this review / Keep it in chat) \u2014 they work through the feedback in chat first. Pass a worktree thread ref \u2014 not the orchestrator. Then wait_for_turn (loop while stillRunning) / get_turn_result on the returned review tab id.',
+      'Start a merge-readiness Review on a worktree agent thread (same as the desktop Review button). Opens a new Review chat tab, attaches .claude/skills/review/SKILL.md when present (else copies .sideboard/review.md into .context/review.md, or seeds that file from the stock template), and sends "Review changes in this workspace." Expect Approve / Approve with nits / Request changes / Needs more information in that chat. The review stays there so the user can read it and type next steps \u2014 do not comment on or update the PR or ticket, and do not ask_user after the review, until they ask. Pass a worktree thread ref \u2014 not the orchestrator. Then wait_for_turn (loop while stillRunning) / get_turn_result on the returned review tab id.',
       { ref: import_zod9.z.string().describe("Worktree thread id/ref to review") },
       async ({ ref }) => {
         try {

package/dist/index.d.cts

@@ -2213,13 +2213,10 @@ type LinearAssignedIssuesResult = {
 };
 /** `me`, `unassigned`, `all`, a Linear user id, or a display name. */
 type LinearAssigneeFilter = string;
-/**
- * Linear `IssueFilter` for open issues. Default assignee is `me` so existing
- * Home / Create-from callers stay assigned-to-you unless they ask otherwise.
- */
 declare function buildLinearIssueFilter(input?: {
     assignee?: string | null;
     updatedSince?: string | null;
+    query?: string | null;
 }): Record<string, unknown>;
 /**
  * List or search open Linear issues. `assignee` is `me` (default when there is
@@ -2234,13 +2231,16 @@ declare function listLinearIssuesFiltered(opts?: {
     updatedSince?: string | null;
 }): Promise<LinearAssignedIssuesResult>;
 /**
- * Comments created at/after `since` on issues matching the same assignee filter.
- * One GraphQL query — do not get_issue each ticket to check for new comments.
+ * Comments created at/after `since` on issues matching the same assignee / search
+ * filter. One GraphQL query — do not get_issue each ticket to check for new comments.
+ * Pass `issueIdentifiers` (search hits) to keep only those tickets; an empty
+ * allowlist means no comments.
  */
 declare function listLinearCommentsSince(opts: {
     since: string;
     assignee?: string | null;
     query?: string;
+    issueIdentifiers?: string[];
     limit?: number;
     apiKey?: string | null;
 }): Promise<IssueActivityComment[]>;
@@ -2364,7 +2364,8 @@ declare function resolveGitHubIssueRepo(repoPath?: string | null): Promise<{
 declare function toGitHubIssueInfo(issue: GitHubIssue): IssueInfo;
 /**
  * Repo issue comments created at/after `since`. Pass `issueIdentifiers` (#12)
- * to keep only comments on that inbox page — one REST call, not N issue views.
+ * to keep only comments on that inbox page — paginated REST, not N issue views.
+ * An empty allowlist means no comments (do not fall through to the whole repo).
  */
 declare function listGitHubIssueCommentsSince(opts: {
     since: string;
@@ -4611,7 +4612,7 @@ declare function isSetupLastError(err: string | null | undefined): boolean;
 declare function isStaleLastErrorDuringTurn(err: string | null | undefined): boolean;
 
 /** Default Review request.md body (Conductor-style). Kept in sync with desktop review-request.ts. */
-declare const REVIEW_REQUEST_TEMPLATE = "# Review guidelines:\n\nYou are reviewing a proposed code change so a human can decide whether it is **ready to merge / land**. Findings matter, but the primary deliverable is a clear readiness recommendation \u2014 not a laundry list of style notes.\n\n## Required outcome\n\nStart your reply with a **Recommendation** section using exactly one of:\n\n- **Approve** \u2014 ready to merge as-is (or with only trivial nits the author can ignore).\n- **Approve with nits** \u2014 ready to merge; list only optional polish that should not block.\n- **Request changes** \u2014 not ready; blocking issues must be fixed first.\n- **Needs more information** \u2014 cannot judge readiness yet (missing context, incomplete diff, unclear intent).\n\nIn 1\u20133 sentences, say **why** \u2014 grounded in correctness, risk, test coverage, and scope \u2014 not vibes. If you request changes, name the blockers explicitly.\n\nPeople running this review are asking \u201Ccan we ship this?\u201D Treat that as the question you answer first.\n\n## Confirm before posting\n\nThe report stays in this chat until the user posts it. Do not call `github_comment`, `linear_comment`, `abletime_comment`, `github_update_issue`, `linear_update_issue`, `abletime_update_task`, or run `gh pr review` / `gh pr comment`, until they confirm.\n\nAfter the Recommendation is in chat, ask_user (**Post this review** / **Keep it in chat**), then wait. If they already asked you to post a specific comment or update in this turn, that is confirmation.\n\nThe user should be able to work through the feedback in chat first. The PR or ticket author sees those writes immediately \u2014 a draft review will confuse them. Do not request reviewers, change labels, or assign yourself unless they asked.\n\n## Findings\n\nBelow are guidelines for determining whether an issue is worth flagging to the original author.\n\nThese are not the final word. More specific guidelines elsewhere (developer message, user message, a file, etc.) override these.\n\nFlag something as a bug / blocking finding only when:\n\n1. It meaningfully impacts the accuracy, performance, security, or maintainability of the code.\n2. The bug is discrete and actionable (not a vague codebase-wide complaint or a bundle of unrelated issues).\n3. Fixing it does not demand rigor absent from the rest of the codebase.\n4. The issue was introduced by this change (do not flag pre-existing bugs unless they are newly exposed by this PR).\n5. The author would likely fix it if made aware.\n6. It does not rely on unstated assumptions about the codebase or author intent.\n7. Speculative breakage is not enough \u2014 identify the other code that is provably affected.\n8. It is clearly not just an intentional change by the author.\n\nWhen flagging an issue, include a short accompanying comment:\n\n1. Clear about why it is a problem.\n2. Severity must match reality \u2014 do not inflate.\n3. Brief: at most one paragraph; avoid unnecessary line breaks in prose.\n4. No code chunks longer than 3 lines; wrap code in inline ticks or a fenced block.\n5. Call out scenarios / environments / inputs needed to hit the bug when severity depends on them.\n6. Matter-of-fact tone \u2014 helpful assistant, not accusatory or effusive.\n7. Skimmable on first read.\n8. No empty flattery (\u201CGreat job\u2026\u201D, \u201CThanks for\u2026\u201D).\n\nHOW MANY FINDINGS TO RETURN:\n\nList every finding the author would fix if they knew about it. If nothing qualifies, say so and still give the Recommendation. Do not stop at the first finding.\n\nGUIDELINES:\n\n- Ignore trivial style unless it obscures meaning or violates documented standards.\n- One comment per distinct issue (or a short multi-line range if needed).\n- Use ```suggestion blocks ONLY for concrete replacement code (minimal lines; no commentary inside the block).\n- In every ```suggestion block, preserve the exact leading whitespace of the replaced lines (spaces vs tabs, number of spaces).\n- Do NOT introduce or remove outer indentation levels unless that is the actual fix.\n- Separate **blocking** findings from **nits**. Only blocking findings should drive Request changes.\n\nThe report appears in chat (and can become Sideboard diff comments). Avoid unnecessary location chatter in the body; keep line ranges as short as possible (prefer \u22645\u201310 lines).\n\n## Getting the diff\n\nUse Sideboard's diff for this thread's worktree. Prefer the `get_diff` MCP tool (pass this thread's ref) for a compact summary, then read specific files with Read/Glob as needed. In the Sideboard desktop app, the Changes panel shows the same worktree diff.\n\nIf the user asks you to address or read line comments they added in the Changes / file diff UI, those arrive as `diff-comment` attachments on the next turn \u2014 follow them precisely.\n\n## Fallback: if you don't have access to the Sideboard diff tool\n\nIf you don't have access to `get_diff`, use the following git commands to get the diff:\n\n```bash\n# Get the merge base between this branch and the target\nMERGE_BASE=$(git merge-base origin/main HEAD)\n\n# Get the committed diff against the merge base\ngit diff $MERGE_BASE HEAD\n\n# Get any uncommitted changes (staged and unstaged)\ngit diff HEAD\n```\n\nReview the combination of both outputs: the first shows all committed changes on this branch relative to the target, and the second shows any uncommitted work in progress.\n\nNo need to mention in your report whether or not you used one of the fallback strategies; it's usually irrelevant.\n\n## Output format\n\n**1. Recommendation first** (required), then **2. Findings** (may be empty).\n\nOnly report ONE finding per unique issue.\n\n<example>\n## Recommendation\n\n**Request changes** \u2014 The empty-input crash on load will break first-run users; fix that before merge. The unused helper is a nit and can wait.\n\n## Findings\n\n### **#1 Empty input causes crash** (blocking)\n\nIf the input field is empty when the page loads, the app will crash.\n\nFile: src/client/frontends/desktop/ui/Input.tsx\n\n### **#2 Dead code** (nit)\n\nThe getUserData function is now unused. It should be deleted.\n\nFile: src/client/frontends/desktop/core/UserData.ts\n</example>\n\n<example>\n## Recommendation\n\n**Approve** \u2014 Diff is scoped, behavior looks correct, and there are no blocking issues. Safe to merge.\n</example>\n\n## Growing the rules\n\nIf a blocking issue is a missing or ambiguous repo rule that will recur, add one sentence to `.claude/skills/review/SKILL.md` when that skill already exists. Otherwise write it to `.context/review.md` (do not create a review skill). Do not only patch this diff when the same miss will happen again. Do not write new skills under `.sideboard/skills/`.\n";
+declare const REVIEW_REQUEST_TEMPLATE = "# Review guidelines:\n\nYou are reviewing a proposed code change so a human can decide whether it is **ready to merge / land**. Findings matter, but the primary deliverable is a clear readiness recommendation \u2014 not a laundry list of style notes.\n\n## Required outcome\n\nStart your reply with a **Recommendation** section using exactly one of:\n\n- **Approve** \u2014 ready to merge as-is (or with only trivial nits the author can ignore).\n- **Approve with nits** \u2014 ready to merge; list only optional polish that should not block.\n- **Request changes** \u2014 not ready; blocking issues must be fixed first.\n- **Needs more information** \u2014 cannot judge readiness yet (missing context, incomplete diff, unclear intent).\n\nIn 1\u20133 sentences, say **why** \u2014 grounded in correctness, risk, test coverage, and scope \u2014 not vibes. If you request changes, name the blockers explicitly.\n\nPeople running this review are asking \u201Ccan we ship this?\u201D Treat that as the question you answer first.\n\n## Confirm before posting\n\nThe report stays in this chat until the user posts it. Do not call `github_comment`, `linear_comment`, `abletime_comment`, `github_update_issue`, `linear_update_issue`, `abletime_update_task`, or run `gh pr review` / `gh pr comment`, until they type a next step that asks you to post.\n\nAfter the Recommendation is in chat, stop. Do not call ask_user. The user needs time to read the review and will type the next steps. If they already asked you to post a specific comment or update in this turn, that is confirmation.\n\nThe PR or ticket author sees those writes immediately \u2014 a draft review will confuse them. Do not request reviewers, change labels, or assign yourself unless they asked.\n\n## Findings\n\nBelow are guidelines for determining whether an issue is worth flagging to the original author.\n\nThese are not the final word. More specific guidelines elsewhere (developer message, user message, a file, etc.) override these.\n\nFlag something as a bug / blocking finding only when:\n\n1. It meaningfully impacts the accuracy, performance, security, or maintainability of the code.\n2. The bug is discrete and actionable (not a vague codebase-wide complaint or a bundle of unrelated issues).\n3. Fixing it does not demand rigor absent from the rest of the codebase.\n4. The issue was introduced by this change (do not flag pre-existing bugs unless they are newly exposed by this PR).\n5. The author would likely fix it if made aware.\n6. It does not rely on unstated assumptions about the codebase or author intent.\n7. Speculative breakage is not enough \u2014 identify the other code that is provably affected.\n8. It is clearly not just an intentional change by the author.\n\nWhen flagging an issue, include a short accompanying comment:\n\n1. Clear about why it is a problem.\n2. Severity must match reality \u2014 do not inflate.\n3. Brief: at most one paragraph; avoid unnecessary line breaks in prose.\n4. No code chunks longer than 3 lines; wrap code in inline ticks or a fenced block.\n5. Call out scenarios / environments / inputs needed to hit the bug when severity depends on them.\n6. Matter-of-fact tone \u2014 helpful assistant, not accusatory or effusive.\n7. Skimmable on first read.\n8. No empty flattery (\u201CGreat job\u2026\u201D, \u201CThanks for\u2026\u201D).\n\nHOW MANY FINDINGS TO RETURN:\n\nList every finding the author would fix if they knew about it. If nothing qualifies, say so and still give the Recommendation. Do not stop at the first finding.\n\nGUIDELINES:\n\n- Ignore trivial style unless it obscures meaning or violates documented standards.\n- One comment per distinct issue (or a short multi-line range if needed).\n- Use ```suggestion blocks ONLY for concrete replacement code (minimal lines; no commentary inside the block).\n- In every ```suggestion block, preserve the exact leading whitespace of the replaced lines (spaces vs tabs, number of spaces).\n- Do NOT introduce or remove outer indentation levels unless that is the actual fix.\n- Separate **blocking** findings from **nits**. Only blocking findings should drive Request changes.\n\nThe report appears in chat (and can become Sideboard diff comments). Avoid unnecessary location chatter in the body; keep line ranges as short as possible (prefer \u22645\u201310 lines).\n\n## Getting the diff\n\nUse Sideboard's diff for this thread's worktree. Prefer the `get_diff` MCP tool (pass this thread's ref) for a compact summary, then read specific files with Read/Glob as needed. In the Sideboard desktop app, the Changes panel shows the same worktree diff.\n\nIf the user asks you to address or read line comments they added in the Changes / file diff UI, those arrive as `diff-comment` attachments on the next turn \u2014 follow them precisely.\n\n## Fallback: if you don't have access to the Sideboard diff tool\n\nIf you don't have access to `get_diff`, use the following git commands to get the diff:\n\n```bash\n# Get the merge base between this branch and the target\nMERGE_BASE=$(git merge-base origin/main HEAD)\n\n# Get the committed diff against the merge base\ngit diff $MERGE_BASE HEAD\n\n# Get any uncommitted changes (staged and unstaged)\ngit diff HEAD\n```\n\nReview the combination of both outputs: the first shows all committed changes on this branch relative to the target, and the second shows any uncommitted work in progress.\n\nNo need to mention in your report whether or not you used one of the fallback strategies; it's usually irrelevant.\n\n## Output format\n\n**1. Recommendation first** (required), then **2. Findings** (may be empty).\n\nOnly report ONE finding per unique issue.\n\n<example>\n## Recommendation\n\n**Request changes** \u2014 The empty-input crash on load will break first-run users; fix that before merge. The unused helper is a nit and can wait.\n\n## Findings\n\n### **#1 Empty input causes crash** (blocking)\n\nIf the input field is empty when the page loads, the app will crash.\n\nFile: src/client/frontends/desktop/ui/Input.tsx\n\n### **#2 Dead code** (nit)\n\nThe getUserData function is now unused. It should be deleted.\n\nFile: src/client/frontends/desktop/core/UserData.ts\n</example>\n\n<example>\n## Recommendation\n\n**Approve** \u2014 Diff is scoped, behavior looks correct, and there are no blocking issues. Safe to merge.\n</example>\n\n## Growing the rules\n\nIf a blocking issue is a missing or ambiguous repo rule that will recur, add one sentence to `.claude/skills/review/SKILL.md` when that skill already exists. Otherwise write it to `.context/review.md` (do not create a review skill). Do not only patch this diff when the same miss will happen again. Do not write new skills under `.sideboard/skills/`.\n";
 /** Committed Claude Code project skill — Review attaches this when present. */
 declare const REVIEW_SKILL_PATH = ".claude/skills/review/SKILL.md";
 declare const REVIEW_SKILL_NAME = "review";

package/dist/index.d.ts

@@ -2213,13 +2213,10 @@ type LinearAssignedIssuesResult = {
 };
 /** `me`, `unassigned`, `all`, a Linear user id, or a display name. */
 type LinearAssigneeFilter = string;
-/**
- * Linear `IssueFilter` for open issues. Default assignee is `me` so existing
- * Home / Create-from callers stay assigned-to-you unless they ask otherwise.
- */
 declare function buildLinearIssueFilter(input?: {
     assignee?: string | null;
     updatedSince?: string | null;
+    query?: string | null;
 }): Record<string, unknown>;
 /**
  * List or search open Linear issues. `assignee` is `me` (default when there is
@@ -2234,13 +2231,16 @@ declare function listLinearIssuesFiltered(opts?: {
     updatedSince?: string | null;
 }): Promise<LinearAssignedIssuesResult>;
 /**
- * Comments created at/after `since` on issues matching the same assignee filter.
- * One GraphQL query — do not get_issue each ticket to check for new comments.
+ * Comments created at/after `since` on issues matching the same assignee / search
+ * filter. One GraphQL query — do not get_issue each ticket to check for new comments.
+ * Pass `issueIdentifiers` (search hits) to keep only those tickets; an empty
+ * allowlist means no comments.
  */
 declare function listLinearCommentsSince(opts: {
     since: string;
     assignee?: string | null;
     query?: string;
+    issueIdentifiers?: string[];
     limit?: number;
     apiKey?: string | null;
 }): Promise<IssueActivityComment[]>;
@@ -2364,7 +2364,8 @@ declare function resolveGitHubIssueRepo(repoPath?: string | null): Promise<{
 declare function toGitHubIssueInfo(issue: GitHubIssue): IssueInfo;
 /**
  * Repo issue comments created at/after `since`. Pass `issueIdentifiers` (#12)
- * to keep only comments on that inbox page — one REST call, not N issue views.
+ * to keep only comments on that inbox page — paginated REST, not N issue views.
+ * An empty allowlist means no comments (do not fall through to the whole repo).
  */
 declare function listGitHubIssueCommentsSince(opts: {
     since: string;
@@ -4611,7 +4612,7 @@ declare function isSetupLastError(err: string | null | undefined): boolean;
 declare function isStaleLastErrorDuringTurn(err: string | null | undefined): boolean;
 
 /** Default Review request.md body (Conductor-style). Kept in sync with desktop review-request.ts. */
-declare const REVIEW_REQUEST_TEMPLATE = "# Review guidelines:\n\nYou are reviewing a proposed code change so a human can decide whether it is **ready to merge / land**. Findings matter, but the primary deliverable is a clear readiness recommendation \u2014 not a laundry list of style notes.\n\n## Required outcome\n\nStart your reply with a **Recommendation** section using exactly one of:\n\n- **Approve** \u2014 ready to merge as-is (or with only trivial nits the author can ignore).\n- **Approve with nits** \u2014 ready to merge; list only optional polish that should not block.\n- **Request changes** \u2014 not ready; blocking issues must be fixed first.\n- **Needs more information** \u2014 cannot judge readiness yet (missing context, incomplete diff, unclear intent).\n\nIn 1\u20133 sentences, say **why** \u2014 grounded in correctness, risk, test coverage, and scope \u2014 not vibes. If you request changes, name the blockers explicitly.\n\nPeople running this review are asking \u201Ccan we ship this?\u201D Treat that as the question you answer first.\n\n## Confirm before posting\n\nThe report stays in this chat until the user posts it. Do not call `github_comment`, `linear_comment`, `abletime_comment`, `github_update_issue`, `linear_update_issue`, `abletime_update_task`, or run `gh pr review` / `gh pr comment`, until they confirm.\n\nAfter the Recommendation is in chat, ask_user (**Post this review** / **Keep it in chat**), then wait. If they already asked you to post a specific comment or update in this turn, that is confirmation.\n\nThe user should be able to work through the feedback in chat first. The PR or ticket author sees those writes immediately \u2014 a draft review will confuse them. Do not request reviewers, change labels, or assign yourself unless they asked.\n\n## Findings\n\nBelow are guidelines for determining whether an issue is worth flagging to the original author.\n\nThese are not the final word. More specific guidelines elsewhere (developer message, user message, a file, etc.) override these.\n\nFlag something as a bug / blocking finding only when:\n\n1. It meaningfully impacts the accuracy, performance, security, or maintainability of the code.\n2. The bug is discrete and actionable (not a vague codebase-wide complaint or a bundle of unrelated issues).\n3. Fixing it does not demand rigor absent from the rest of the codebase.\n4. The issue was introduced by this change (do not flag pre-existing bugs unless they are newly exposed by this PR).\n5. The author would likely fix it if made aware.\n6. It does not rely on unstated assumptions about the codebase or author intent.\n7. Speculative breakage is not enough \u2014 identify the other code that is provably affected.\n8. It is clearly not just an intentional change by the author.\n\nWhen flagging an issue, include a short accompanying comment:\n\n1. Clear about why it is a problem.\n2. Severity must match reality \u2014 do not inflate.\n3. Brief: at most one paragraph; avoid unnecessary line breaks in prose.\n4. No code chunks longer than 3 lines; wrap code in inline ticks or a fenced block.\n5. Call out scenarios / environments / inputs needed to hit the bug when severity depends on them.\n6. Matter-of-fact tone \u2014 helpful assistant, not accusatory or effusive.\n7. Skimmable on first read.\n8. No empty flattery (\u201CGreat job\u2026\u201D, \u201CThanks for\u2026\u201D).\n\nHOW MANY FINDINGS TO RETURN:\n\nList every finding the author would fix if they knew about it. If nothing qualifies, say so and still give the Recommendation. Do not stop at the first finding.\n\nGUIDELINES:\n\n- Ignore trivial style unless it obscures meaning or violates documented standards.\n- One comment per distinct issue (or a short multi-line range if needed).\n- Use ```suggestion blocks ONLY for concrete replacement code (minimal lines; no commentary inside the block).\n- In every ```suggestion block, preserve the exact leading whitespace of the replaced lines (spaces vs tabs, number of spaces).\n- Do NOT introduce or remove outer indentation levels unless that is the actual fix.\n- Separate **blocking** findings from **nits**. Only blocking findings should drive Request changes.\n\nThe report appears in chat (and can become Sideboard diff comments). Avoid unnecessary location chatter in the body; keep line ranges as short as possible (prefer \u22645\u201310 lines).\n\n## Getting the diff\n\nUse Sideboard's diff for this thread's worktree. Prefer the `get_diff` MCP tool (pass this thread's ref) for a compact summary, then read specific files with Read/Glob as needed. In the Sideboard desktop app, the Changes panel shows the same worktree diff.\n\nIf the user asks you to address or read line comments they added in the Changes / file diff UI, those arrive as `diff-comment` attachments on the next turn \u2014 follow them precisely.\n\n## Fallback: if you don't have access to the Sideboard diff tool\n\nIf you don't have access to `get_diff`, use the following git commands to get the diff:\n\n```bash\n# Get the merge base between this branch and the target\nMERGE_BASE=$(git merge-base origin/main HEAD)\n\n# Get the committed diff against the merge base\ngit diff $MERGE_BASE HEAD\n\n# Get any uncommitted changes (staged and unstaged)\ngit diff HEAD\n```\n\nReview the combination of both outputs: the first shows all committed changes on this branch relative to the target, and the second shows any uncommitted work in progress.\n\nNo need to mention in your report whether or not you used one of the fallback strategies; it's usually irrelevant.\n\n## Output format\n\n**1. Recommendation first** (required), then **2. Findings** (may be empty).\n\nOnly report ONE finding per unique issue.\n\n<example>\n## Recommendation\n\n**Request changes** \u2014 The empty-input crash on load will break first-run users; fix that before merge. The unused helper is a nit and can wait.\n\n## Findings\n\n### **#1 Empty input causes crash** (blocking)\n\nIf the input field is empty when the page loads, the app will crash.\n\nFile: src/client/frontends/desktop/ui/Input.tsx\n\n### **#2 Dead code** (nit)\n\nThe getUserData function is now unused. It should be deleted.\n\nFile: src/client/frontends/desktop/core/UserData.ts\n</example>\n\n<example>\n## Recommendation\n\n**Approve** \u2014 Diff is scoped, behavior looks correct, and there are no blocking issues. Safe to merge.\n</example>\n\n## Growing the rules\n\nIf a blocking issue is a missing or ambiguous repo rule that will recur, add one sentence to `.claude/skills/review/SKILL.md` when that skill already exists. Otherwise write it to `.context/review.md` (do not create a review skill). Do not only patch this diff when the same miss will happen again. Do not write new skills under `.sideboard/skills/`.\n";
+declare const REVIEW_REQUEST_TEMPLATE = "# Review guidelines:\n\nYou are reviewing a proposed code change so a human can decide whether it is **ready to merge / land**. Findings matter, but the primary deliverable is a clear readiness recommendation \u2014 not a laundry list of style notes.\n\n## Required outcome\n\nStart your reply with a **Recommendation** section using exactly one of:\n\n- **Approve** \u2014 ready to merge as-is (or with only trivial nits the author can ignore).\n- **Approve with nits** \u2014 ready to merge; list only optional polish that should not block.\n- **Request changes** \u2014 not ready; blocking issues must be fixed first.\n- **Needs more information** \u2014 cannot judge readiness yet (missing context, incomplete diff, unclear intent).\n\nIn 1\u20133 sentences, say **why** \u2014 grounded in correctness, risk, test coverage, and scope \u2014 not vibes. If you request changes, name the blockers explicitly.\n\nPeople running this review are asking \u201Ccan we ship this?\u201D Treat that as the question you answer first.\n\n## Confirm before posting\n\nThe report stays in this chat until the user posts it. Do not call `github_comment`, `linear_comment`, `abletime_comment`, `github_update_issue`, `linear_update_issue`, `abletime_update_task`, or run `gh pr review` / `gh pr comment`, until they type a next step that asks you to post.\n\nAfter the Recommendation is in chat, stop. Do not call ask_user. The user needs time to read the review and will type the next steps. If they already asked you to post a specific comment or update in this turn, that is confirmation.\n\nThe PR or ticket author sees those writes immediately \u2014 a draft review will confuse them. Do not request reviewers, change labels, or assign yourself unless they asked.\n\n## Findings\n\nBelow are guidelines for determining whether an issue is worth flagging to the original author.\n\nThese are not the final word. More specific guidelines elsewhere (developer message, user message, a file, etc.) override these.\n\nFlag something as a bug / blocking finding only when:\n\n1. It meaningfully impacts the accuracy, performance, security, or maintainability of the code.\n2. The bug is discrete and actionable (not a vague codebase-wide complaint or a bundle of unrelated issues).\n3. Fixing it does not demand rigor absent from the rest of the codebase.\n4. The issue was introduced by this change (do not flag pre-existing bugs unless they are newly exposed by this PR).\n5. The author would likely fix it if made aware.\n6. It does not rely on unstated assumptions about the codebase or author intent.\n7. Speculative breakage is not enough \u2014 identify the other code that is provably affected.\n8. It is clearly not just an intentional change by the author.\n\nWhen flagging an issue, include a short accompanying comment:\n\n1. Clear about why it is a problem.\n2. Severity must match reality \u2014 do not inflate.\n3. Brief: at most one paragraph; avoid unnecessary line breaks in prose.\n4. No code chunks longer than 3 lines; wrap code in inline ticks or a fenced block.\n5. Call out scenarios / environments / inputs needed to hit the bug when severity depends on them.\n6. Matter-of-fact tone \u2014 helpful assistant, not accusatory or effusive.\n7. Skimmable on first read.\n8. No empty flattery (\u201CGreat job\u2026\u201D, \u201CThanks for\u2026\u201D).\n\nHOW MANY FINDINGS TO RETURN:\n\nList every finding the author would fix if they knew about it. If nothing qualifies, say so and still give the Recommendation. Do not stop at the first finding.\n\nGUIDELINES:\n\n- Ignore trivial style unless it obscures meaning or violates documented standards.\n- One comment per distinct issue (or a short multi-line range if needed).\n- Use ```suggestion blocks ONLY for concrete replacement code (minimal lines; no commentary inside the block).\n- In every ```suggestion block, preserve the exact leading whitespace of the replaced lines (spaces vs tabs, number of spaces).\n- Do NOT introduce or remove outer indentation levels unless that is the actual fix.\n- Separate **blocking** findings from **nits**. Only blocking findings should drive Request changes.\n\nThe report appears in chat (and can become Sideboard diff comments). Avoid unnecessary location chatter in the body; keep line ranges as short as possible (prefer \u22645\u201310 lines).\n\n## Getting the diff\n\nUse Sideboard's diff for this thread's worktree. Prefer the `get_diff` MCP tool (pass this thread's ref) for a compact summary, then read specific files with Read/Glob as needed. In the Sideboard desktop app, the Changes panel shows the same worktree diff.\n\nIf the user asks you to address or read line comments they added in the Changes / file diff UI, those arrive as `diff-comment` attachments on the next turn \u2014 follow them precisely.\n\n## Fallback: if you don't have access to the Sideboard diff tool\n\nIf you don't have access to `get_diff`, use the following git commands to get the diff:\n\n```bash\n# Get the merge base between this branch and the target\nMERGE_BASE=$(git merge-base origin/main HEAD)\n\n# Get the committed diff against the merge base\ngit diff $MERGE_BASE HEAD\n\n# Get any uncommitted changes (staged and unstaged)\ngit diff HEAD\n```\n\nReview the combination of both outputs: the first shows all committed changes on this branch relative to the target, and the second shows any uncommitted work in progress.\n\nNo need to mention in your report whether or not you used one of the fallback strategies; it's usually irrelevant.\n\n## Output format\n\n**1. Recommendation first** (required), then **2. Findings** (may be empty).\n\nOnly report ONE finding per unique issue.\n\n<example>\n## Recommendation\n\n**Request changes** \u2014 The empty-input crash on load will break first-run users; fix that before merge. The unused helper is a nit and can wait.\n\n## Findings\n\n### **#1 Empty input causes crash** (blocking)\n\nIf the input field is empty when the page loads, the app will crash.\n\nFile: src/client/frontends/desktop/ui/Input.tsx\n\n### **#2 Dead code** (nit)\n\nThe getUserData function is now unused. It should be deleted.\n\nFile: src/client/frontends/desktop/core/UserData.ts\n</example>\n\n<example>\n## Recommendation\n\n**Approve** \u2014 Diff is scoped, behavior looks correct, and there are no blocking issues. Safe to merge.\n</example>\n\n## Growing the rules\n\nIf a blocking issue is a missing or ambiguous repo rule that will recur, add one sentence to `.claude/skills/review/SKILL.md` when that skill already exists. Otherwise write it to `.context/review.md` (do not create a review skill). Do not only patch this diff when the same miss will happen again. Do not write new skills under `.sideboard/skills/`.\n";
 /** Committed Claude Code project skill — Review attaches this when present. */
 declare const REVIEW_SKILL_PATH = ".claude/skills/review/SKILL.md";
 declare const REVIEW_SKILL_NAME = "review";