Remove --max-turns limit from review panel workflow

[not-stbenjam]

Summary

• Removes the --max-turns 50 constraint from the skillsaw-review-panel.yml workflow
• The review panel was hitting this cap and failing (see job run)
• Follows the same change made in Remove --max-turns limits from issue_solver and pr_followup #456 for the issue_solver and pr_followup workflows

Test plan

• Verify the review panel workflow runs without hitting a turn limit on the next panel-review label trigger

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@not-stbenjam, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 16 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 4f28a7cf-9ea1-4aab-a2af-740898abfa45

📥 Commits

Reviewing files that changed from the base of the PR and between 4dbd92e and 095d155.

📒 Files selected for processing (1)

• .github/workflows/skillsaw-review-panel.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch remove-panel-review-turns

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Remove max-turns cap from review panel GitHub Actions workflow

⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Removes the --max-turns 50 limit from the review panel workflow.
• Prevents panel-review runs from failing due to turn-cap exhaustion.
• Aligns review panel behavior with other workflows that removed the same cap.

Diagram

graph TD
  A["skillsaw-review-panel.yml"] --> B["Review panel job"] --> C["Claude run step"] --> D["claude-opus-5"] --> E["Artifacts/logs"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Increase the cap (e.g., `--max-turns 200`)

• ➕ Reduces risk of runaway conversations/costs compared to no cap
• ➕ Likely fixes current failures if 50 was simply too low
• ➖ Still brittle: may fail again if reviews require more turns
• ➖ Requires guessing an appropriate limit and revisiting later

2. Make `max-turns` configurable via workflow input/variable

• ➕ Allows tuning per repo/run type without code changes
• ➕ Can set a safe default while enabling override for edge cases
• ➖ Adds configuration surface area and maintenance overhead
• ➖ Doesn’t solve failures unless the default is raised/removed anyway

Recommendation: Removing the cap is reasonable if the panel-review workload legitimately exceeds 50 turns and the workflow already has other guardrails (timeouts, logging, human oversight). If cost/runaway risk is a concern, prefer a configurable (or higher) cap paired with GitHub job timeouts to prevent infinite runs.

Files changed (1) +0 / -1

Other (1) +0 / -1

skillsaw-review-panel.ymlRemove '--max-turns 50' from review panel Claude args +0/-1

Remove '--max-turns 50' from review panel Claude args

• Deletes the '--max-turns 50' argument from the workflow’s Claude invocation. This prevents panel-review runs from failing when they exceed the previous turn limit.

.github/workflows/skillsaw-review-panel.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 136 rules

✅ Skills: 5 invoked

  skillsaw-pr-review

  skillsaw-issue-solver

  skillsaw-pr-followup

  skillsaw-create-plugin

  skillsaw-review-panel

1. Unbounded panel review runtime 🐞 Bug ☼ Reliability

Description

Removing --max-turns from skillsaw-review-panel.yml leaves the Claude run without an explicit
iteration bound or job timeout, so a stalled/looping session can consume the full Actions runtime
and delay subsequent panel-review triggers for the same PR due to the workflow’s concurrency
grouping.

Code

.github/workflows/skillsaw-review-panel.yml[R41-45]

          show_full_output: true
          claude_args: |
            --allowedTools Edit,Write,Read,Bash,WebFetch,WebSearch,Skill,Glob,Grep,TaskCreate,TaskUpdate,TaskList,TaskGet
-            --max-turns 50
            --model claude-opus-5

Relevance

⭐⭐ Medium

Repo just merged similar removals of --max-turns; no precedent for adding runtime bounds back.

PR-#456

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The review-panel job uses concurrency keyed by PR number, so a long-running job can occupy that
group and delay subsequent runs; and after this PR the Claude invocation no longer has an explicit
--max-turns bound. Other workflows in this repo still enforce --max-turns 200, showing an
established pattern of bounding agent runs.

.github/workflows/skillsaw-review-panel.yml[7-9]
.github/workflows/skillsaw-review-panel.yml[33-45]
.github/workflows/skillsaw-ecosystem-scout.yml[19-29]
.github/workflows/skillsaw-maintenance.yml[20-30]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The review panel workflow no longer passes a `--max-turns` guard, and the job also doesn’t set `timeout-minutes`. This makes the run length depend on external defaults and GitHub Actions hard limits, increasing the chance that a loop/stall consumes excessive runtime and delays later triggers.

## Issue Context
Other Skillsaw workflows in this repo still use an explicit turn cap (e.g., `--max-turns 200`), indicating a convention to keep agent runs bounded.

## Fix Focus Areas
- .github/workflows/skillsaw-review-panel.yml[7-9]
- .github/workflows/skillsaw-review-panel.yml[33-45]

### Suggested fix
- Add a job-level `timeout-minutes` (e.g. 60–120) to cap worst-case runtime.
- Optionally reintroduce a higher `--max-turns` value (e.g. 200) instead of removing it entirely, matching other workflows’ guardrails.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. Unbounded panel review runtime 🐞 Bug ☼ Reliability

Removing --max-turns from skillsaw-review-panel.yml leaves the Claude run without an explicit
iteration bound or job timeout, so a stalled/looping session can consume the full Actions runtime
and delay subsequent panel-review triggers for the same PR due to the workflow’s concurrency
grouping.

Agent Prompt

## Issue description
The review panel workflow no longer passes a `--max-turns` guard, and the job also doesn’t set `timeout-minutes`. This makes the run length depend on external defaults and GitHub Actions hard limits, increasing the chance that a loop/stall consumes excessive runtime and delays later triggers.

## Issue Context
Other Skillsaw workflows in this repo still use an explicit turn cap (e.g., `--max-turns 200`), indicating a convention to keep agent runs bounded.

## Fix Focus Areas
- .github/workflows/skillsaw-review-panel.yml[7-9]
- .github/workflows/skillsaw-review-panel.yml[33-45]

### Suggested fix
- Add a job-level `timeout-minutes` (e.g. 60–120) to cap worst-case runtime.
- Optionally reintroduce a higher `--max-turns` value (e.g. 200) instead of removing it entirely, matching other workflows’ guardrails.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.54%. Comparing base (4dbd92e) to head (095d155).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #457   +/-   ##
=======================================
  Coverage   93.54%   93.54%           
=======================================
  Files         145      145           
  Lines       11418    11418           
=======================================
  Hits        10681    10681           
  Misses        737      737           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.