pullfrog 0.1.41 → 0.1.43

package/dist/agents/postRun.d.ts

@@ -8,6 +8,9 @@ import { type AgentResult, type AgentRunContext, type AgentUsage, type PostRunIs
  *
  * the gate is anchored to `hadProgressComment` so silent runs (non-issue
  * events, dispatcher skipped seeding) don't fire a nudge there's no UI for.
+ * `expectsReviewOutput` overrides that anchor for runs where the dispatcher
+ * deliberately skipped seeding under `progressComments: disabled` — those still
+ * owe a review, and reading "no comment" as "no UI" would silently retire the gate.
  *
  * `Review` and `IncrementalReview` have different valid exits:
  *   - Review: only `create_pull_request_review` counts. `report_progress` is
@@ -20,7 +23,7 @@ import { type AgentResult, type AgentRunContext, type AgentUsage, type PostRunIs
  * `task`-dispatched `reviewfrog` lens) calls `report_progress` and silences
  * the gate even though the orchestrator never submitted a review.
  */
-export declare function getUnsubmittedReview(toolState: ToolState): "Review" | "IncrementalReview" | null;
+export declare function getUnsubmittedReview(toolState: ToolState, expectsReviewOutput?: boolean): "Review" | "IncrementalReview" | null;
 /**
  * run the user-configured stop hook.
  *

package/dist/cli.mjs

@@ -101765,8 +101765,8 @@ var providers = {
       },
       "claude-opus": {
         displayName: "Claude Opus",
-        resolve: "anthropic/claude-opus-4-8",
-        openRouterResolve: "openrouter/anthropic/claude-opus-4.8",
+        resolve: "anthropic/claude-opus-5",
+        openRouterResolve: "openrouter/anthropic/claude-opus-5",
         preferred: true,
         subagentModel: "claude-sonnet"
       },
@@ -101964,8 +101964,8 @@ var providers = {
       },
       "claude-opus": {
         displayName: "Claude Opus",
-        resolve: "opencode/claude-opus-4-8",
-        openRouterResolve: "openrouter/anthropic/claude-opus-4.8",
+        resolve: "opencode/claude-opus-5",
+        openRouterResolve: "openrouter/anthropic/claude-opus-5",
         subagentModel: "claude-sonnet"
       },
       "claude-sonnet": {
@@ -103022,7 +103022,7 @@ var import_semver = __toESM(require_semver2(), 1);
 // package.json
 var package_default = {
   name: "pullfrog",
-  version: "0.1.41",
+  version: "0.1.43",
   type: "module",
   bin: {
     pullfrog: "dist/cli.mjs",
@@ -103704,8 +103704,78 @@ HARD CONSTRAINTS (non-negotiable, regardless of orchestrator instructions):
 
 Report findings clearly with file:line references and quoted evidence where possible. Flag uncertainty explicitly \u2014 if you cannot verify a claim, say so rather than guess.`;
 
+// utils/promptProfile.ts
+function promptProfile() {
+  return process.env.PULLFROG_PROMPT_PROFILE === "full" ? "full" : "lean";
+}
+function byProfile(lean, full) {
+  return promptProfile() === "lean" ? lean : full;
+}
+
 // modes.ts
-var PR_SUMMARY_FORMAT = `### Default format
+var PR_SUMMARY_FORMAT_LEAN = `### Default format
+
+The body has at most three parts, in this order:
+
+1. **Reviewed changes preamble** \u2014 a bolded \`**Reviewed changes**\` lead-in with one sentence on what was reviewed in this run (for \`IncrementalReview\`: what changed since the prior pullfrog review), then a bullet list of the substantive changes \u2014 short bolded title, one sentence each. A reviewer should understand the full reviewed scope from this list alone. Close the preamble with the metadata comment below.
+2. **Cross-cutting issue sections** (zero or more) \u2014 one \`### {emoji} {what's wrong, not what to do}\` heading per concern.
+3. **\`### \u2139\uFE0F Nitpicks\`** at the very bottom, if any \u2014 a flat bullet list, no technical-details block.
+
+**Inline vs. body.** Concerns that anchor to a specific line go inline (the \`comments\` parameter), even when their implications are broad. Body \`### \` sections are reserved for concerns that have **no line to anchor to** \u2014 *absence* (something the diff should have done but didn't), *sequencing* (rollout / deletion / migration order), *design decisions only the human can make*, or *scope questions the diff raises but doesn't address*. With no non-anchorable concerns, the body is just the preamble + metadata.
+
+**Severity emoji** on every \`### \` heading, and nowhere else: \u{1F6A8} critical (blocks merge \u2014 data loss, security, broken core flow) \xB7 \u26A0\uFE0F important (must address before merging) \xB7 \u2139\uFE0F informational (mergeable as-is).
+
+**Blank line between every block-level element.** GitHub's markdown parser requires one before and after HTML tags (\`<details>\`, \`<summary>\`, \`<sub>\`, \`<br/>\`) \u2014 without it GitHub treats what follows as a continuation of the HTML block and renders your markdown as literal text. This is a parser quirk, not a style preference, and it permanently breaks the posted review.
+
+## Metadata comment
+
+Fill every field from the \`checkout_pr\` response \u2014 never count files or commits by hand. For \`IncrementalReview\`, fill \`Prior pullfrog review\` from \`list_pull_request_reviews\`.
+
+\`\`\`
+<!--
+Pullfrog review metadata. These findings were written against {head_sha_short};
+if commits have landed on {head_ref} since, treat every specific bug, file, or
+line callout as POTENTIALLY STALE and re-diff before acting on it.
+
+- Mode: Review (initial)   or   IncrementalReview (delta against prior pullfrog review)
+- Files reviewed: {file_count}
+- Commits reviewed: {commit_count}
+- Base: {base_ref} ({base_sha_short})
+- Head: {head_ref} ({head_sha_short})
+- Reviewed commits:
+  - {sha_short} \u2014 {commit_subject}
+- Prior pullfrog review: none   or   {prior_sha_short} ({prior_review_html_url})
+- Submitted at: {iso_timestamp}
+-->
+\`\`\`
+
+## Technical details
+
+Every body \`### \` section carries one; an inline comment carries one when its fix is non-trivial or spans files. The visible part above it states the PROBLEM in 2-3 sentences \u2014 what's broken and what the blast radius is. Asks, fixes, and open questions live inside the block, which a downstream fix-agent pulls down as its brief, so \`file:line\` refs and identifier density belong here.
+
+\`\`\`
+<details><summary>Technical details</summary>
+
+\\\`\\\`\\\`\\\`markdown
+# {title}
+
+## Affected sites
+- {file path:line} \u2014 {what's wrong there}
+
+## Required outcome
+- {what the fix needs to achieve, not how to achieve it}
+
+## Suggested approach (optional)
+## Open questions for the human (optional)
+\\\`\\\`\\\`\\\`
+
+</details>
+\`\`\`
+
+The 4-backtick fence lets the block hold its own 3-backtick fences and stay one-click copyable. Skip the optional sections when they'd add nothing.
+
+Backtick-wrap identifiers and file names. Don't repeat diff content, don't include raw \`+123 / -45\` stats, no changelog, no horizontal rules, and no \`### Key changes\` / \`### Issues found\` / \`<b>TL;DR</b>\` heading \u2014 each \`### \` heading IS the issue.`;
+var PR_SUMMARY_FORMAT_FULL = `### Default format
 
 The body has at most three parts in this exact order:
 
@@ -103846,6 +103916,9 @@ Inline comments use the same severity framing as body \`### \` sections, scaled
 - **Don't repeat diff content**, don't include raw \`+123 / -45\` stats, don't include a changelog section, don't use horizontal rules (\`---\`).
 - **Pull file/commit counts from \`checkout_pr\` metadata** \u2014 never count manually.
 - **Legacy headings REMOVED.** Do not use \`### Key changes\`, \`### Issues found\`, \`<b>TL;DR</b>\`, or \`<sub><b>Summary</b>\`. The new structure subsumes them.`;
+function prSummaryFormat() {
+  return byProfile(PR_SUMMARY_FORMAT_LEAN, PR_SUMMARY_FORMAT_FULL);
+}
 function computeModes(agentId, signedCommits = false) {
   const t2 = (toolName) => formatMcpToolRef(agentId, toolName);
   const commitStep = signedCommits ? `commit via \`${t2("commit_changes")}\` \u2014 it lands a GitHub-signed commit directly on the remote branch (no push step)` : `commit locally via shell (\`git add . && git commit -m "..."\`)`;
@@ -103869,7 +103942,17 @@ function computeModes(agentId, signedCommits = false) {
    - plan your approach before writing code: identify which files need to change, key design decisions, and edge cases. for non-trivial changes, consider whether there's a more elegant approach.
    - run relevant tests/lints before committing
 
-5. **self-review**: judgment call \u2014 does YOUR diff warrant a fresh-eyes pass?
+5. **self-review**: ${byProfile(
+        `unless the diff has no behavioral surface at all \u2014 docs, comments, whitespace, import reordering, lockfile or generated-code regeneration, a mechanical rename, a trusted dep patch bump \u2014 dispatch the \`${REVIEWER_AGENT_NAME}\` subagent to review it with fresh eyes against YOUR TASK. Line count is not the signal: a one-line change to auth, money, SQL, a comparison operator, a redirect, or a config default earns a pass. When in doubt, run it \u2014 a false-positive dispatch costs cents, a missed bug costs much more.
+
+   Before dispatching, make \`origin/<base>\` available: \`git fetch --no-tags --deepen=1000 origin <base>:refs/remotes/origin/<base>\`. The explicit destination refspec is required \u2014 a shallow single-branch checkout otherwise only updates \`FETCH_HEAD\` and never creates the tracking ref. The reviewer is read-only by contract, so fetching is your job.
+
+   In the dispatch prompt: say this is a PRE-COMMIT self-review whose work is uncommitted in the working tree, give the branch and base, name \`git diff --merge-base origin/<base>\` as the canonical diff command, paste YOUR TASK, and summarize any build-phase failures. If that diff comes back empty, there is nothing to review \u2014 stop.
+
+   Give it the diff and the task, nothing else. Do not summarize what you implemented, curate a reading list of files, or pre-shape the output with a severity schema \u2014 each biases the reviewer toward validating your solution instead of questioning it. Where the diff rests on third-party API, SDK, framework, or DB-engine semantics, tell it to verify load-bearing claims by web search and quote sources.
+
+   Treat what comes back as hypotheses, not directives: verify each against the code before applying, and reject findings that would add ceremony without correctness \u2014 defensive checks for cases that cannot happen, single-use abstractions, comments restating code, tautological tests. After applying what you accept, re-read your own diff and revert anything that turned out to be bloat. Then ${commitStep}.`,
+        `judgment call \u2014 does YOUR diff warrant a fresh-eyes pass?
 
    Skip self-review (commit directly) when the diff is **genuinely trivial**:
    - doc typos, comment-only edits, whitespace/format-only, import reordering
@@ -103920,7 +104003,8 @@ function computeModes(agentId, signedCommits = false) {
    - Do NOT defect-hunt the diff yourself in parallel with the subagent. Your role is dispatch + evaluation; doing the review yourself reintroduces the implementation bias the subagent is meant to mitigate.
    - For diffs that rely on third-party API contracts, SDK semantics, framework directives, or DB engine specifics, instruct the subagent to verify load-bearing claims via web search and quote source URLs rather than trust training data \u2014 this is the single most common review-quality failure mode.
 
-   Be **discerning** about what comes back. The reviewer is an AI subagent and is fallible \u2014 treat every finding as a hypothesis, not a directive, and **verify each one yourself** against the diff and the code before deciding whether to apply. You are searching for a solution that is **complete, minimal, and elegant** \u2014 you may need to think hard to find it. Do not over-engineer, do not be over-defensive, **do not write AI slop**. Reviewers bias toward *recommending additions*, and that bias has a recognizable slop texture: defensive checks for cases that cannot happen, extra logging, new abstractions used once, comments restating code, tests asserting tautologies, "just-in-case" guards, error handlers for cases the type system already rules out. Reject those. For each surviving finding, ask: would applying it leave the code more sound, correct, AND elegant? Two-out-of-three means look harder for a fix that gets all three before settling. After applying the fixes you accept, re-read your diff and be discerning about what *you just changed*: if any fix turned out to be bloat in context, revert it. Then verify only intended changes are present, no debug artifacts or commented-out code remain, no unrelated files were modified. Then ${commitStep}.
+   Be **discerning** about what comes back. The reviewer is an AI subagent and is fallible \u2014 treat every finding as a hypothesis, not a directive, and **verify each one yourself** against the diff and the code before deciding whether to apply. You are searching for a solution that is **complete, minimal, and elegant** \u2014 you may need to think hard to find it. Do not over-engineer, do not be over-defensive, **do not write AI slop**. Reviewers bias toward *recommending additions*, and that bias has a recognizable slop texture: defensive checks for cases that cannot happen, extra logging, new abstractions used once, comments restating code, tests asserting tautologies, "just-in-case" guards, error handlers for cases the type system already rules out. Reject those. For each surviving finding, ask: would applying it leave the code more sound, correct, AND elegant? Two-out-of-three means look harder for a fix that gets all three before settling. After applying the fixes you accept, re-read your diff and be discerning about what *you just changed*: if any fix turned out to be bloat in context, revert it. Then verify only intended changes are present, no debug artifacts or commented-out code remain, no unrelated files were modified. Then ${commitStep}.`
+      )}
 
 6. **finalize**:
    - ${finalizeStep} (see *SYSTEM* Git rules if this fails \u2014 prepush errors are usually the repo's tests/lint, not infra timeouts)
@@ -103973,7 +104057,7 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
     //
     // Severity categorization is split across two surfaces: the opening
     // callout (CAUTION/IMPORTANT/ℹ️/✅) sets the review's overall tier, and
-    // per-bullet emoji prefixes (🚨/⚠️/ℹ️ in PR_SUMMARY_FORMAT) tag
+    // per-bullet emoji prefixes (🚨/⚠️/ℹ️ in prSummaryFormat()) tag
     // individual points inside summary sections — scoping severity to the
     // specific bullet rather than the whole section keeps a section that
     // mixes a 🚨 and an ℹ️ from being mislabeled by either of them.
@@ -103986,7 +104070,30 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
 
 2. **checkout**: call \`${t2("checkout_pr")}\` \u2014 this returns PR metadata, a \`diffPath\`, and a supplemental \`impactPath\` when change-impact extraction is enabled. read the complete raw diff end-to-end, beginning with the TOC and using its file line ranges as your coverage checklist. only after that, use \`impactPath\` as an explicitly incomplete list of reference leads; it never replaces raw-diff reading or establishes coverage.
 
-3. **triage**: orient yourself on the PR \u2014 identify *what kind of thing this is* (domain it touches, seams it crosses, external contracts it depends on, user-facing surfaces it changes). pull as much context as you need to render a confident, well-grounded review: read related files, grep for callers of changed symbols, check tests that exercise the touched paths, fetch related GitHub state. **you are the synthesizer** \u2014 never delegate understanding to subagents.
+${byProfile(
+        `3. **triage**: orient yourself on the PR \u2014 identify *what kind of thing this is* (domain it touches, seams it crosses, external contracts it depends on, user-facing surfaces it changes). pull as much context as you need to render a confident, well-grounded review: read related files, grep for callers of changed symbols, check tests that exercise the touched paths, fetch related GitHub state. **you are the synthesizer** \u2014 never delegate understanding to subagents.
+
+   skip the deeper pass and submit a \`No new issues found.\` review per step 7 only when the diff has **no behavioral surface at all** \u2014 doc typos, whitespace/formatting, lockfile or generated-code regeneration, a mechanical rename whose only effect is import-path updates. line count is not the signal: a one-line change to auth, money, SQL, a comparison operator, a redirect, or a config default is not trivial.
+
+4. **specialist decision**: after reading the complete diff, name the questions you still cannot answer confidently yourself, and dispatch one \`${REVIEWER_AGENT_NAME}\` specialist per question. a question qualifies only when a specialist could return evidence that **changes your disposition** on the PR \u2014 generic requests for another look, extra confidence, or polish do not. most reviews need zero or one; some need several.
+
+   **There is NO one-specialist cap or fixed maximum.** cover every orthogonal question that remains; do not collapse several real questions into one broad prompt just to reduce the count. there is no file-count, line-count, or budget threshold either \u2014 diff size is not a proxy for review uncertainty.
+
+   frame each question through the lens that primes the right failure modes. for high-stakes subsystems, lead with the **domain** ("the billing lens", "the auth lens", "the schema-migration lens") rather than the generic equivalent ("correctness on billing code") \u2014 the domain framing makes the subagent recall double-charges, refund races, currency rounding, and dispute flows that a generic lens misses.
+
+   you remain the synthesizer: reading the complete raw diff, investigating surrounding code, validating every returned finding, and writing the review are yours. specialist reads supplement that work; they never satisfy your own coverage obligation.
+
+5. **dispatch specialists (only if step 4 found unresolved questions)**: for 2+ questions, emit every Task tool_use block **IN A SINGLE ASSISTANT TURN** before reading any result, so the investigations run in parallel rather than serially. your own \`read\` / \`grep\` / \`webfetch\` calls can ride in that same turn at zero extra wall time.
+
+   if a specialist errors out, times out, or returns nothing usable, retry it once. if it still fails, resolve the question yourself; if it remains disposition-changing and unresolved, surface the limitation and do not approve. each dispatch carries:
+   - **the absolute \`diffPath\` (and \`incrementalDiffPath\` if available) from step 2's \`${t2("checkout_pr")}\` return, named verbatim in the dispatch prompt** (e.g. \`diffPath: /tmp/pullfrog-XXXX/pr-NNN-SHA.diff\`). the reviewer's baked-in system prompt selects its FIRST action on this token \u2014 paraphrasing ("review the diff", "look at this PR") sends it down a \`git diff origin/<base>\` fallback that fails on shallow GHA checkouts. it \`read\`s those files for scope and must NOT re-derive the diff itself; reading and codebase exploration are still its job.
+   - **exactly one falsifiable question with explicit scope boundaries** \u2014 ask for evidence that supports or refutes it, never a broad "review for X, Y, and Z" prompt.
+   - **a Task \`description\` set to a short hypothesis label** (e.g. \`"webhook-replay"\`, \`"billing-rounding"\`) \u2014 the harness reads this field to label the subagent's log lines so parallel runs can be told apart. without it, every subagent shows up as \`subagent#N\`.
+   - if the question touches third-party API, SDK, or framework contracts, instruct the subagent to verify load-bearing claims via web search and quote source URLs rather than trust training data. action runs are non-interactive \u2014 nobody is in the loop to catch "I'm pretty sure Stripe does X."
+   - ask for findings with file paths and NEW line numbers from the diff so you can validate and anchor them.
+
+   delegation discipline: do NOT summarize the PR for them (a lossy summary biases toward a validation frame; the raw diff is the source), do NOT hand them a curated reading list, do NOT pre-shape their output with a finding schema, and do NOT mention the other specialists \u2014 independence is the point, and overlapping findings are a strong signal.`,
+        `3. **triage**: orient yourself on the PR \u2014 identify *what kind of thing this is* (domain it touches, seams it crosses, external contracts it depends on, user-facing surfaces it changes). pull as much context as you need to render a confident, well-grounded review: read related files, grep for callers of changed symbols, check tests that exercise the touched paths, fetch related GitHub state. **you are the synthesizer** \u2014 never delegate understanding to subagents.
 
    if the PR is **genuinely trivial**, skip specialists entirely and submit a \`No new issues found.\` review per step 7.
 
@@ -104057,7 +104164,8 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
    - do NOT summarize the PR for them (a lossy summary biases toward a validation frame; the raw diff is the source)
    - do NOT hand them a curated reading list (let them discover scope)
    - do NOT pre-shape their output with a finding schema
-   - do NOT mention the other lenses (independence is the point \u2014 overlapping findings are a strong signal)
+   - do NOT mention the other lenses (independence is the point \u2014 overlapping findings are a strong signal)`
+      )}
 
 6. **aggregate & draft**: when specialist results land, merge findings; de-dup overlaps (two specialists catching the same issue = higher-confidence signal); trace each finding yourself before accepting it. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the PR (heuristic: if the finding's root cause lives in lines this PR added or modified, it's in scope; otherwise drop unless the PR plausibly introduced or amplified the regression), and anything not actionable. also drop **bloat-shaped findings** \u2014 proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or worse, degrades elegance to nominally improve correctness) makes the codebase worse, not better.
 
@@ -104091,7 +104199,7 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
    - **no actionable issues**:
      \`approved: true\`. Body opens with \`> \u2705 No new issues found.\\n\\n\` followed by the PR summary.
 
-${PR_SUMMARY_FORMAT}`
+${prSummaryFormat()}`
     },
     // IncrementalReview shares Review's minimum hypothesis-covering specialist
     // routing and body format, scoped to the incremental delta against the
@@ -104125,7 +104233,30 @@ ${PR_SUMMARY_FORMAT}`
 
    The remaining open threads feed step 8's dedup filter \u2014 anything already flagged and unchanged by the new commits should not be re-raised. The rolling PR summary snapshot is the durable record of retire activity; you don't need to surface it in the review body.
 
-5. **triage**: orient on the *incremental* changes \u2014 domain, seams, external contracts, user-facing surfaces. pull as much context as you need to render a confident review: read related files, grep for callers of changed symbols, check tests that exercise the touched paths. **you are the synthesizer.**
+${byProfile(
+        `5. **triage**: orient on the *incremental* changes \u2014 domain, seams, external contracts, user-facing surfaces. pull as much context as you need to render a confident review: read related files, grep for callers of changed symbols, check tests that exercise the touched paths. **you are the synthesizer.**
+
+   skip the deeper pass and jump to step 10's non-substantive path (do NOT submit a review) only when the incremental changes have **no behavioral surface at all** \u2014 formatting, comment tweaks, import reordering, lockfile regen, a mechanical rename of import paths. line count is not the signal: a one-line change to auth, money, SQL, a comparison operator, a redirect, or a config default is not trivial.
+
+6. **specialist decision**: after covering the incremental and full diffs, name the questions about the new changes that you still cannot answer confidently yourself, and dispatch one \`${REVIEWER_AGENT_NAME}\` specialist per question. a question qualifies only when a specialist could return evidence that **changes your disposition** on the PR \u2014 generic requests for another look, extra confidence, or polish do not. most incremental reviews need zero or one, especially thread-reply re-reviews; some need several.
+
+   **There is NO one-specialist cap or fixed maximum.** cover every orthogonal question that remains; do not collapse several real questions into one broad prompt just to reduce the count. there is no file-count, line-count, or budget threshold either \u2014 diff size is not a proxy for review uncertainty.
+
+   frame each question through the lens that primes the right failure modes. for high-stakes subsystems, lead with the **domain** ("the billing lens", "the auth lens", "the schema-migration lens") rather than the generic equivalent \u2014 the domain framing makes the subagent recall failure modes a generic lens misses.
+
+   you remain the synthesizer: reading the complete raw full diff plus the incremental diff, investigating surrounding code, validating every returned finding, and writing the review are yours. specialist reads supplement that work; they never satisfy your own coverage obligation.
+
+7. **dispatch specialists (only if step 6 found unresolved questions)**: for 2+ questions, emit every Task tool_use block **IN A SINGLE ASSISTANT TURN** before reading any result, so the investigations run in parallel rather than serially. your own \`read\` / \`grep\` / \`webfetch\` calls can ride in that same turn.
+
+   if a specialist errors out, times out, or returns nothing usable, retry it once. if it still fails, resolve the question yourself; if it remains disposition-changing and unresolved, surface the limitation and do not approve. each dispatch carries:
+   - **the absolute diff path(s) from step 2's \`${t2("checkout_pr")}\` return, named verbatim in the dispatch prompt.** when \`incrementalDiffPath\` is present, name BOTH (\`incrementalDiffPath: /tmp/.../pr-NNN-SHA-incremental.diff\` then \`diffPath: /tmp/.../pr-NNN-SHA.diff\`) \u2014 the reviewer's baked-in prompt reads incremental first and uses full for context; when only \`diffPath\` exists, name it alone. it \`read\`s those files and must NOT re-derive the diff itself; paraphrasing ("review the new commits") sends it down a \`git diff\` fallback that fails on shallow GHA checkouts. do NOT tell them to skip pre-existing issues \u2014 that suppresses regressions the new commits amplified; the "issues must be NEW" filter lives at aggregation time (step 8), not in the subagent prompt.
+   - **exactly one falsifiable question with explicit scope boundaries** \u2014 ask for evidence that supports or refutes it, never a broad "review for X, Y, and Z" prompt.
+   - **a Task \`description\` set to a short hypothesis label** \u2014 the harness reads this field to label log lines so parallel runs can be told apart.
+   - if the question touches third-party API, SDK, or framework contracts, instruct the subagent to verify load-bearing claims via web search and quote source URLs.
+   - ask for findings with file paths and NEW line numbers from the full PR diff so you can validate and anchor them.
+
+   delegation discipline: do NOT summarize the changes for them (a lossy summary biases toward a validation frame; the raw diff is the source), do NOT hand them a curated reading list, do NOT pre-shape their output with a finding schema, and do NOT mention the other specialists \u2014 independence is the point.`,
+        `5. **triage**: orient on the *incremental* changes \u2014 domain, seams, external contracts, user-facing surfaces. pull as much context as you need to render a confident review: read related files, grep for callers of changed symbols, check tests that exercise the touched paths. **you are the synthesizer.**
 
    if the incremental changes are **genuinely trivial**, skip specialists entirely and jump to step 10's non-substantive path (do NOT submit a review).
 
@@ -104166,7 +104297,8 @@ ${PR_SUMMARY_FORMAT}`
    - do NOT summarize the changes for them (a lossy summary biases toward a validation frame; the raw diff is the source)
    - do NOT hand them a curated reading list (let them discover scope)
    - do NOT pre-shape their output with a finding schema
-   - do NOT mention the other lenses (independence is the point)
+   - do NOT mention the other lenses (independence is the point)`
+      )}
 
 8. **aggregate, draft, self-critique**: merge findings (yours + output from every specialist you dispatched); de-dup overlaps; trace each finding yourself. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the new commits, anything not actionable, and anything that re-states prior review feedback (heuristic: if the finding's root cause lives in lines the *new commits* added or modified, it's in scope; otherwise drop). also drop **bloat-shaped findings** \u2014 proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or degrades elegance to nominally improve correctness) makes the codebase worse, not better. To compute "lines the new commits added or modified": if \`incrementalDiffPath\` from step 2 is present, use it directly. Otherwise, take the prior Pullfrog review's \`commit_id\` (returned alongside each entry from \`${t2("list_pull_request_reviews")}\` in step 4) and run \`git diff <prior-review-sha>..HEAD\` to isolate the lines added since that review.
 
@@ -104189,7 +104321,7 @@ ${PR_SUMMARY_FORMAT}`
    - ELSE IF INFORMATIONAL OBSERVATIONS (mergeable as-is, but worth surfacing \u2014 e.g. prior feedback addressed cleanly with one minor stale doc reference, or a noteworthy positive observation): call \`${t2("create_pull_request_review")}\` with \`approved: true\`, NO inline comments, and the review body. body opens with \`> \u2705 No new issues found.\\n\\n\` (or similar friendly green opener), followed by the PR summary using the default format below. If a point is concrete enough to anchor to a line, downgrade the whole review to "minor suggestions only" (\`approved: false\`) instead \u2014 the \u2705 signals "no action needed", which contradicts an actionable anchor.
    - ELSE IF NO NEW ISSUES, SUBSTANTIVE CHANGES (new functionality, behavior changes, or fixes to prior review feedback): call \`${t2("create_pull_request_review")}\` to create a PR review. If all previous reviews have been properly addressed and no new issues were discovered, set \`approved: true\`. body opens with \`> \u2705 No new issues found.\\n\\n\`, followed by the PR summary using the default format below.
 
-${PR_SUMMARY_FORMAT}`
+${prSummaryFormat()}`
     },
     {
       name: "Plan",
@@ -104288,15 +104420,20 @@ var NON_COMMITTING_MODES = /* @__PURE__ */ new Set([
 ]);
 
 // agents/postRun.ts
-function getUnsubmittedReview(toolState) {
+function getUnsubmittedReview(toolState, expectsReviewOutput2 = toolState.hadProgressComment) {
   const mode = toolState.selectedMode;
-  if (!toolState.hadProgressComment) return null;
+  if (!expectsReviewOutput2) return null;
   if (mode === "Review") return toolState.review ? null : "Review";
   if (mode === "IncrementalReview") {
     return toolState.review || toolState.finalSummaryWritten ? null : "IncrementalReview";
   }
   return null;
 }
+function expectsReviewOutput(ctx) {
+  if (ctx.toolState.hadProgressComment) return true;
+  if (ctx.payload.progressComments) return false;
+  return ctx.payload.event.silent !== true && ctx.payload.event.issue_number !== void 0;
+}
 function buildStopHookPrompt(failure2) {
   return [
     `STOP HOOK FAILED \u2014 the repo-configured stop hook exited with code ${failure2.exitCode}. your work is not done until the hook exits cleanly. address the issue below and push any resulting changes to a pull request.`,
@@ -104360,7 +104497,7 @@ async function collectPostRunIssues(ctx, options = {}) {
     const stale = await isSummaryUnchanged(summaryFilePath2, summarySeed);
     if (stale) issues.summaryStale = { filePath: summaryFilePath2 };
   }
-  const unsubmittedMode = getUnsubmittedReview(ctx.toolState);
+  const unsubmittedMode = getUnsubmittedReview(ctx.toolState, expectsReviewOutput(ctx));
   if (unsubmittedMode) issues.unsubmittedReview = unsubmittedMode;
   return issues;
 }
@@ -160072,6 +160209,7 @@ function validateCompatibility(payloadVersion, actionVersion) {
 var ShellPermissionInput = type.enumerated("disabled", "restricted", "enabled");
 var PushPermissionInput = type.enumerated("disabled", "restricted", "enabled");
 var StatusChecksInput = type.enumerated("disabled", "enabled");
+var ProgressCommentsInput = type.enumerated("disabled", "enabled");
 var JsonPayload = type({
   "~pullfrog": "true",
   version: "string",
@@ -160111,6 +160249,7 @@ var Inputs = type({
   "push?": PushPermissionInput.or("undefined"),
   "shell?": ShellPermissionInput.or("undefined"),
   "status_checks?": StatusChecksInput.or("undefined"),
+  "progress_comments?": ProgressCommentsInput.or("undefined"),
   "cwd?": type.string.or("undefined"),
   "output_schema?": type.string.or("undefined")
 });
@@ -160164,7 +160303,8 @@ function resolveNonPromptInputs() {
     cwd: core4.getInput("cwd") || void 0,
     push: core4.getInput("push") || void 0,
     shell: core4.getInput("shell") || void 0,
-    status_checks: core4.getInput("status_checks") || void 0
+    status_checks: core4.getInput("status_checks") || void 0,
+    progress_comments: core4.getInput("progress_comments") || void 0
   });
 }
 var isPullfrog = (actor) => {
@@ -160214,6 +160354,9 @@ function resolvePayload(resolvedPromptInput, repoSettings) {
     // opt-in commit-status check-runs (branch protection). workflow-level
     // static input, off unless the repo's pullfrog.yml sets status_checks: enabled.
     statusChecks: inputs.status_checks === "enabled",
+    // temporary progress chrome. the workflow input is the source of truth when
+    // set (mirrors `push`); otherwise the repo setting decides. defaults to true.
+    progressComments: inputs.progress_comments === void 0 ? repoSettings.progressComments : inputs.progress_comments === "enabled",
     // set by proxy logic in main.ts when routing through OpenRouter
     proxyModel: void 0
   };
@@ -160367,6 +160510,9 @@ async function reportProgress(ctx, params) {
   if (ctx.payload.event.silent) {
     return { body, action: "skipped" };
   }
+  if (params.liveProgress && !ctx.payload.progressComments) {
+    return { body, action: "skipped" };
+  }
   const issueNumber = ctx.payload.event.issue_number ?? primaryRepoState(ctx.toolState).issueNumber;
   const isPlanMode = ctx.toolState.selectedMode === "Plan";
   const apiCtx = { octokit: ctx.octokit, owner: ctx.repo.owner, repo: ctx.repo.name };
@@ -160520,6 +160666,7 @@ ${collapsible}`;
 async function deleteProgressComment(ctx) {
   const existing = ctx.toolState.progressComment;
   if (!existing) {
+    ctx.toolState.progressComment = null;
     return false;
   }
   try {
@@ -160833,7 +160980,10 @@ var CreatePullRequestReview = type({
   // running. required-ness is the only pressure that empirically held.
   // see wiki/review-approval.md.
   body: type.string.describe(
-    `1-2 sentence high-level summary with urgency level, critical callouts, and feedback about code outside the diff. Specific feedback on diff lines goes in 'comments' array. ALWAYS pass this parameter \u2014 pass an empty string "" when approving with no commentary, never omit it.`
+    byProfile(
+      `The review summary, plus any concern that has no diff line to anchor to. Your mode guidance defines its structure. Feedback that does anchor to a line goes in the 'comments' array. ALWAYS pass this parameter \u2014 pass an empty string "" when approving with no commentary, never omit it.`,
+      `1-2 sentence high-level summary with urgency level, critical callouts, and feedback about code outside the diff. Specific feedback on diff lines goes in 'comments' array. ALWAYS pass this parameter \u2014 pass an empty string "" when approving with no commentary, never omit it.`
+    )
   ),
   approved: type.boolean.describe(
     "Set to true to submit as an approval. Use for `> \u2705 No new issues found.` reviews where the PR is mergeable as-is and nothing in the body warrants code changes \u2014 approving also suppresses the Fix-button footer affordance so users don't dispatch a fix run on non-actionable feedback. Reserve approved: false for `> \u2139\uFE0F ...` (minor suggestions inline), `> [!IMPORTANT]` (recommended changes), and `> [!CAUTION]` (critical) reviews. Defaults to false (comment-only review). Mutually exclusive with request_changes. Approval is REJECTED while any unresolved Pullfrog review thread remains open on the PR (not just the latest commit's diff): resolve the threads the current code addresses (reply + resolve_review_thread) first, or submit a non-approving review if a real issue remains."
@@ -160869,7 +161019,10 @@ function CreatePullRequestReviewTool(ctx) {
   return tool({
     name: "create_pull_request_review",
     mutates: true,
-    description: `Submit a review for an existing pull request. Example: \`create_pull_request_review({ pull_number: 1234, body: "LGTM", approved: true, comments: [{ path: "src/api.ts", line: 42, body: "nit: rename" }] })\`. Each call creates a permanent, visible review on the PR \u2014 NEVER submit test or diagnostic reviews. Set \`approved: true\` to approve, \`request_changes: true\` to submit a blocking review, or neither for a plain comment review (the three are mutually exclusive). Reviews with no body AND no comments are silently skipped (nothing to post). IMPORTANT: 95%+ of feedback should be in 'comments' array with file paths and line numbers. Only use 'body' for a 1-2 sentence summary with urgency and critical callouts. Use 'suggestion' to propose replacement code - MUST preserve exact indentation of original code. The first submission may error once with a one-time diff-coverage nudge listing unread TOC regions \u2014 retry with the same arguments and the pre-flight will not block again. Example replacing lines 42-44 (3 lines) with 5 lines: { path: 'src/api.ts', start_line: 42, line: 44, suggestion: '    const result = await fetch(url);\\n    if (!result.ok) {\\n      log.error(result.status);\\n      throw new Error("request failed");\\n    }' } CONSTRAINT: Inline comments can ONLY target files and lines that appear in the PR diff. Comments anchored outside a diff hunk are dropped automatically (with a note appended to the review body) \u2014 the rest of the review still posts.`,
+    description: 'Submit a review for an existing pull request. Example: `create_pull_request_review({ pull_number: 1234, body: "LGTM", approved: true, comments: [{ path: "src/api.ts", line: 42, body: "nit: rename" }] })`. Each call creates a permanent, visible review on the PR \u2014 NEVER submit test or diagnostic reviews. Set `approved: true` to approve, `request_changes: true` to submit a blocking review, or neither for a plain comment review (the three are mutually exclusive). Reviews with no body AND no comments are silently skipped (nothing to post). ' + byProfile(
+      "Feedback that anchors to a specific line goes in the 'comments' array with file paths and line numbers. The 'body' carries the review summary plus any concern with no line to anchor to; your mode guidance defines its structure. ",
+      "IMPORTANT: 95%+ of feedback should be in 'comments' array with file paths and line numbers. Only use 'body' for a 1-2 sentence summary with urgency and critical callouts. "
+    ) + `Use 'suggestion' to propose replacement code - MUST preserve exact indentation of original code. The first submission may error once with a one-time diff-coverage nudge listing unread TOC regions \u2014 retry with the same arguments and the pre-flight will not block again. Example replacing lines 42-44 (3 lines) with 5 lines: { path: 'src/api.ts', start_line: 42, line: 44, suggestion: '    const result = await fetch(url);\\n    if (!result.ok) {\\n      log.error(result.status);\\n      throw new Error("request failed");\\n    }' } CONSTRAINT: Inline comments can ONLY target files and lines that appear in the PR diff. Comments anchored outside a diff hunk are dropped automatically (with a note appended to the review body) \u2014 the rest of the review still posts.`,
     parameters: CreatePullRequestReview,
     execute: execute(
       async ({ pull_number, body, approved, request_changes, commit_id, comments = [] }) => {
@@ -165802,7 +165955,10 @@ You execute tasks directly using your native tools and the ${pullfrogMcpName} MC
 
 Call \`${t2("select_mode")}\` with the appropriate mode name. This returns **your workflow** \u2014 a step-by-step playbook you must follow.
 
-**Follow the returned guidance as your primary instruction set.** Do not improvise \u2014 the guidance defines the exact steps.
+${byProfile(
+    `**Work through the returned steps in order.** It is the house playbook for this kind of task and it encodes what usually matters. Where the task in front of you genuinely calls for something better, do that instead and say why in your final summary.`,
+    `**Follow the returned guidance as your primary instruction set.** Do not improvise \u2014 the guidance defines the exact steps.`
+  )}
 
 Available modes:
 ${ctx.modes.map((m) => `- "${m.name}": ${m.description}`).join("\n")}
@@ -165840,13 +165996,18 @@ You are a diligent, detail-oriented, no-nonsense software engineering agent. You
 
 ## Persona
 
-- Careful, to-the-point, and kind. You only say things you know to be true.
+${byProfile(
+    `- Careful, to-the-point, and kind. You only say things you know to be true.
+- Write code that reads like the surrounding code: match its comment density, naming, and idiom.
+- Do not break up sentences with hyphens. Use emdashes. Use backticks liberally for inline code (e.g. \`z.string()\`) even in headers.`,
+    `- Careful, to-the-point, and kind. You only say things you know to be true.
 - Do not break up sentences with hyphens. Use emdashes.
 - Strong bias toward minimalism: no dead code, no premature abstractions, no speculative features, and no comments that merely restate what the code does.
 - Code is focused, elegant, and production-ready.
 - Do not add unnecessary comments, tests, or documentation unless explicitly prompted to do so.
 - Adapt your writing style to match existing patterns in the codebase (commit messages, PR descriptions, code comments) while never being unprofessional.
-- Use backticks liberally for inline code (e.g. \`z.string()\`) even in headers.
+- Use backticks liberally for inline code (e.g. \`z.string()\`) even in headers.`
+  )}
 
 ## Environment
 
@@ -165866,7 +166027,10 @@ MCP servers provide tools you can call. Inspect your available MCP servers at st
 
 ### Git
 
-Use \`${t2("git")}\` for local git commands (status, log, add, commit, checkout, branch, merge, etc.). When reviewing a PR, do NOT re-derive the PR diff via \`git diff\` \u2014 the diffPath returned by \`${t2("checkout_pr")}\` is authoritative. If you ever do need to diff a branch against its base via \`${t2("git")}\`, use \`git diff --merge-base <base>\` (single call, includes uncommitted edits) or three-dot \`git diff <base>...HEAD\` (committed-only). Do NOT use bare \`<base>\` or two-dot \`<base>..HEAD\` \u2014 those are symmetric and include the *inverse* of every commit landed on \`<base>\` since your branch forked (the tool will reject those forms when the divergence is detected). Do NOT try \`$(git merge-base \u2026)\` subshells \u2014 the git tool runs git directly with no shell interpolation. \`git log\` and \`git diff --stat\` are fine for commit-range overview; \`git diff\` / \`git diff --cached\` are fine for inspecting your *own* uncommitted changes. For operations requiring remote authentication, use the dedicated MCP tools:
+${byProfile(
+    `Use \`${t2("git")}\` for local git commands (status, log, add, commit, checkout, branch, merge, etc.). When reviewing a PR, the diffPath returned by \`${t2("checkout_pr")}\` is authoritative \u2014 read it rather than re-deriving the diff. To diff a branch against its base yourself, use \`git diff --merge-base <base>\`; the tool rejects the symmetric forms and tells you what to use instead. Note the git tool runs git directly, so \`$(\u2026)\` subshells do not interpolate. For operations requiring remote authentication, use the dedicated MCP tools:`,
+    `Use \`${t2("git")}\` for local git commands (status, log, add, commit, checkout, branch, merge, etc.). When reviewing a PR, do NOT re-derive the PR diff via \`git diff\` \u2014 the diffPath returned by \`${t2("checkout_pr")}\` is authoritative. If you ever do need to diff a branch against its base via \`${t2("git")}\`, use \`git diff --merge-base <base>\` (single call, includes uncommitted edits) or three-dot \`git diff <base>...HEAD\` (committed-only). Do NOT use bare \`<base>\` or two-dot \`<base>..HEAD\` \u2014 those are symmetric and include the *inverse* of every commit landed on \`<base>\` since your branch forked (the tool will reject those forms when the divergence is detected). Do NOT try \`$(git merge-base \u2026)\` subshells \u2014 the git tool runs git directly with no shell interpolation. \`git log\` and \`git diff --stat\` are fine for commit-range overview; \`git diff\` / \`git diff --cached\` are fine for inspecting your *own* uncommitted changes. For operations requiring remote authentication, use the dedicated MCP tools:`
+  )}
 - \`${t2("push_branch")}\` - push current or specified branch
 - \`${t2("git_fetch")}\` - fetch refs from remote
 - \`${t2("checkout_pr")}\` - checkout a PR branch (fetches and configures push for forks)
@@ -165905,7 +166069,11 @@ ${getStandaloneModeInstructions(ctx.payload.event.trigger, t2, ctx.outputSchema)
 
 ## Workflow
 
-### Efficiency
+${byProfile(
+    `### Efficiency
+
+Trust tool results \u2014 re-verify only after an actual error, or right before \`${t2("push_branch")}\`, which rejects a dirty tree (tests you ran earlier often leave untracked output). Issue independent tool calls together in one turn rather than one per turn; sequence anything that depends on prior output. Commands run synchronously, so never \`sleep\` to wait for one.`,
+    `### Efficiency
 
 Trust the tools \u2014 do not repeatedly verify file contents or git status after operations. If a tool reports success, proceed to the next step. Only verify if you encounter an actual error. Exception: right before \`${t2("push_branch")}\`, ensure the working tree is clean \u2014 that tool rejects dirty trees, and tests you ran earlier often leave untracked output.
 
@@ -165924,7 +166092,8 @@ Emit multiple \`tool_use\` blocks in the same assistant message for independent
 
 ### Command execution
 
-Never use \`sleep\` to wait for commands to complete. Commands run synchronously \u2014 when the shell tool returns, the command has finished.
+Never use \`sleep\` to wait for commands to complete. Commands run synchronously \u2014 when the shell tool returns, the command has finished.`
+  )}
 
 ### Commenting style
 
@@ -165934,7 +166103,17 @@ Never \`@\`-mention a GitHub username unless that exact handle appears in the us
 
 When embedding images (e.g. uploaded screenshots) in comments or PR bodies, always use markdown image syntax: \`![description](url)\`. Never paste a naked URL \u2014 it will not render as an image.
 
-### Progress reporting
+${byProfile(
+    `### Progress reporting
+
+**Your raw assistant messages are never delivered** \u2014 they exist only in the run logs. Anything the user is meant to see (an answer to a question, a mention reply, a result) MUST go through \`report_progress\` or another ${pullfrogMcpName} write tool.
+
+Keep an internal task list from your mode's steps; the system renders it to the progress comment on its own, so don't call \`report_progress\` for intermediate status. Call it once at the end with a short outcome-focused summary \u2014 what was accomplished and links to artifacts, not a replay of the steps. If something failed, include the tool's exact error text. Use \`create_issue_comment\` only when a standalone comment is the explicit deliverable; when it is, that replaces the final \`report_progress\` call rather than adding to it.
+
+### If you get stuck
+
+Don't silently fail or produce incomplete work. Report what blocked you and what would unblock it, specifically enough to act on. If the same approach has failed repeatedly, step back and say what you tried and what alternatives exist rather than repeating it.`,
+    `### Progress reporting
 
 **Task list**: at the start of every run, create an internal task list based on the steps in your current mode. Update it as you complete each step. The system automatically renders this list to the progress comment \u2014 you do not need to call \`report_progress\` for this.
 
@@ -165950,7 +166129,8 @@ If you cannot complete a task due to missing information, ambiguity, or an unrec
 1. Do not silently fail or produce incomplete work
 2. Post a comment via ${pullfrogMcpName} explaining what blocked you and what information or action would unblock you
 3. Make your blocker comment specific and actionable (e.g., "I need the database schema to proceed" not "I'm stuck")
-4. If you've attempted the same fix or approach 3 or more times without progress, step back and reconsider. Report what you tried, why it failed, and what alternative approaches exist \u2014 rather than repeating failed attempts.
+4. If you've attempted the same fix or approach 3 or more times without progress, step back and reconsider. Report what you tried, why it failed, and what alternative approaches exist \u2014 rather than repeating failed attempts.`
+  )}
 
 ### Agent context files
 
@@ -166926,7 +167106,9 @@ async function handleAgentResult(ctx) {
   const toolState = ctx.toolContext.toolState;
   const mode = toolState.selectedMode;
   const isReviewMode = mode === "Review" || mode === "IncrementalReview";
-  if (!isReviewMode && !toolState.wasUpdated && toolState.hadProgressComment && !ctx.silent) {
+  const payload = ctx.toolContext.payload;
+  const hasCommentTarget = toolState.hadProgressComment || !payload.progressComments && payload.event.issue_number !== void 0;
+  if (!isReviewMode && !toolState.wasUpdated && hasCommentTarget && !ctx.silent) {
     const tracker = toolState.todoTracker;
     if (tracker) {
       tracker.cancel();
@@ -166982,6 +167164,7 @@ var defaultSettings = {
   prApproveEnabled: false,
   autoMergeEnabled: false,
   signedCommits: false,
+  progressComments: true,
   modeInstructions: {},
   learnings: null,
   learningsHeadings: [],
@@ -167675,6 +167858,7 @@ function logRunStartup(ctx) {
   log.info(`\xBB push:    ${ctx.payload.push}`);
   log.info(`\xBB shell:   ${ctx.payload.shell}`);
   log.info(`\xBB timeout: ${resolveTimeoutForLog(ctx.payload.timeout)}`);
+  log.info(`\xBB prompt:  ${promptProfile()}`);
 }
 
 // utils/todoTracking.ts
@@ -167890,6 +168074,9 @@ async function main() {
     toolState.model = payload.model;
     toolState.oss = runContext.oss;
     toolState.shaPinned = isActionPinnedToSha();
+    if (payload.event.issue_number !== void 0) {
+      primaryRepoState(toolState).issueNumber = payload.event.issue_number;
+    }
     if (payload.event.trigger === "pull_request_synchronize") {
       primaryRepoState(toolState).beforeSha = payload.event.before_sha;
     }
@@ -169309,7 +169496,7 @@ async function runCli4(input) {
 }
 
 // cli.ts
-var VERSION10 = "0.1.41";
+var VERSION10 = "0.1.43";
 var bin = basename2(process.argv[1] || "");
 var PROG = bin === "pf" || bin === "pullfrog" ? bin : "pullfrog";
 var rawArgs = process.argv.slice(2);