Refine weekly claude command and subagent architecture#760
Refine weekly claude command and subagent architecture#760PhilippMatthes merged 2 commits intomainfrom
Conversation
Restructure the weekly review workflow so subagents only report findings while the orchestrator handles PR creation, deduplication, contributor assignment, and build verification. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 42 minutes and 51 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe PR refactors the weekly orchestration command and its subagents to separate investigation from PR creation. Subagents now only report findings with importance assessments; the orchestrator handles deduplication against existing PRs, prioritization with PR-fatigue constraints, and creation of PRs through dedicated PR-generation phases including make verification and reviewer selection. Changes
Sequence Diagram(s)sequenceDiagram
participant Orchestrator as Weekly Orchestrator
participant BugAgent as Bug Detective Agent
participant DocsAgent as Docs Expert Agent
participant PRRepo as Open PRs Index
participant PRCreator as PR Creation Subagent
Orchestrator->>Orchestrator: Read AGENTS.md (setup)
Orchestrator->>BugAgent: Investigate & Report findings<br/>(no PR creation)
BugAgent-->>Orchestrator: Findings with importance scores
Orchestrator->>DocsAgent: Investigate & Report findings<br/>(no PR creation)
DocsAgent-->>Orchestrator: Findings with importance scores
Orchestrator->>PRRepo: Fetch existing open PRs
PRRepo-->>Orchestrator: Current PR list
Orchestrator->>Orchestrator: Deduplicate findings<br/>against open PRs
Orchestrator->>Orchestrator: Apply PR-fatigue constraints<br/>& re-prioritize by importance
Orchestrator->>PRCreator: Create PR for high-priority<br/>finding with reviewer candidates
PRCreator->>PRCreator: Verify make runs
PRCreator->>PRCreator: Format commit message<br/>(uppercase, no markdown)
PRCreator-->>PRRepo: New PR created
Orchestrator-->>Orchestrator: Report findings (prioritized),<br/>backlog (deprioritized items)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (5)
.claude/agents/bug-detective.md (1)
76-76: Clarify the format for "Key contributors" field.The description "contributors who recently touched these files, from git log" doesn't specify the expected format. This is the same ambiguity as in docs-expert.md. Consider standardizing the format across both subagents, specifying:
- Whether to use git author names or GitHub usernames
- How many contributors to include
- The delimiter format (comma-separated, newline-separated, etc.)
Consistent formatting will ensure the orchestrator can reliably parse and use this information for reviewer assignment in Phase 6.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.claude/agents/bug-detective.md at line 76, Update the "Key contributors" line to specify a standardized, parseable format: state that the field must list the top 3 recent contributors as GitHub usernames (not full names), separated by commas (e.g., `@alice`,`@bob`,`@carol`), and add a note to mirror the same format in docs-expert.md so both subagents use identical parsing rules for Phase 6 reviewer assignment..claude/commands/weekly.md (3)
113-113: Provide clearer guidance for extracting GitHub login from API response.The instruction mentions using
gh api repos/{owner}/{repo}/commits?path=<file>&per_page=5to get GitHub logins, but doesn't specify:
- How to extract the login field from the JSON response (likely needs
jqor similar)- How to determine
{owner}and{repo}dynamically- What to do if the API call fails or returns no commits
Consider adding a concrete example or clearer instructions for parsing the API response.
💡 Suggested improvement
- - If git log names don't map cleanly to GitHub usernames, use `gh api repos/{owner}/{repo}/commits?path=<file>&per_page=5` to get the GitHub login from recent commits to that file. + - If git log names don't map cleanly to GitHub usernames, use `gh api repos/{owner}/{repo}/commits?path=<file>&per_page=5 | jq -r '.[].author.login'` to extract GitHub usernames from recent commits to that file. You can get {owner} and {repo} from `gh repo view --json owner,name`.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.claude/commands/weekly.md at line 113, Update the guidance that suggests using `gh api repos/{owner}/{repo}/commits?path=<file>&per_page=5` by explaining how to obtain `{owner}` and `{repo}` (use `gh repo view` or `git remote get-url origin`), how to parse the JSON to extract the GitHub login (pipe the API output to a JSON parser like `jq` and read the `[].author.login` or `[].commit.author.name` fields), and add failure handling guidance (check HTTP/exit status and fall back to the most recent commit author from `git log --pretty=format:%an` if the API returns no commits or errors). Include a short example invocation pattern in the docs showing the API call piped to `jq` and the fallback sequence so users can reliably derive the GitHub username for `gh pr edit --add-assignee`.
105-105: Clarify branch cleanup when abandoning a PR.The instruction says "abandon the PR if the fix is not straightforward" but at this point a branch has already been created (line 103). Should the subagent:
- Delete the branch before switching back to main?
- Leave the branch in place for manual review?
- Report the abandoned attempt back to the orchestrator?
Without explicit guidance, subagents may handle this inconsistently, potentially leaving orphaned branches.
📝 Suggested clarification
-4. Run `make` to verify the build passes. If it fails, fix the issues or abandon the PR if the fix is not straightforward. +4. Run `make` to verify the build passes. If it fails, fix the issues. If the fix is not straightforward, delete the branch (`git checkout main && git branch -D <branch-name>`) and report the abandoned attempt back to the orchestrator.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.claude/commands/weekly.md at line 105, Update the "abandon the PR" guidance in .claude/commands/weekly.md (the step after the branch creation step near line 103 and the "Run `make`" check) to specify branch cleanup and reporting: instruct the subagent to delete both the local and remote branches created for the PR, switch back to main, and then report the abandoned attempt to the orchestrator with a short summary (reason, tests that failed, and branch name) so reviewers can pick it up; include exact commands or placeholders for deleting local and remote branches and a short template for the report.
115-115: Specify the git command for switching back to main.The instruction says "switch back to main before returning" but doesn't specify the command. While experienced developers know this is
git checkout mainorgit switch main, being explicit ensures consistency and prevents potential errors.🔧 Suggested clarification
-8. After opening the PR, switch back to main before returning. +8. After opening the PR, switch back to main (`git checkout main`) before returning.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.claude/commands/weekly.md at line 115, Update the sentence "After opening the PR, switch back to main before returning." to explicitly specify the git command to use, e.g., instruct the user to switch back to main using git switch main (or git checkout main) so there's no ambiguity; edit the line in the .claude/commands/weekly.md content where that sentence appears to include the explicit command..claude/agents/docs-expert.md (1)
93-93: Clarify the format for "Key contributors" field.The description says "contributors who recently touched the related code/docs, from git log" but doesn't specify the expected format. Should this be:
- A comma-separated list of names?
- GitHub usernames or git author names?
- The top N contributors?
This ambiguity could lead to inconsistent output that the orchestrator may struggle to parse. Consider specifying the exact format, e.g., "top 3 contributors as comma-separated GitHub usernames" or "comma-separated list of git author names from recent commits."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.claude/agents/docs-expert.md at line 93, The "Key contributors" field is ambiguous; update the description for "Key contributors" to define a precise, machine-parsable format — e.g., "Top 3 contributors as a comma-separated list of GitHub usernames (derived from recent git log), e.g., alice,bob,charlie" — and ensure the docs state the sourcing rule ("top 3 by most recent commits") and the exact output format (comma-separated GitHub usernames, no spaces). This replaces the vague placeholder so the orchestrator can consistently parse the field.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.claude/agents/bug-detective.md:
- Line 76: Update the "Key contributors" line to specify a standardized,
parseable format: state that the field must list the top 3 recent contributors
as GitHub usernames (not full names), separated by commas (e.g.,
`@alice`,`@bob`,`@carol`), and add a note to mirror the same format in docs-expert.md
so both subagents use identical parsing rules for Phase 6 reviewer assignment.
In @.claude/agents/docs-expert.md:
- Line 93: The "Key contributors" field is ambiguous; update the description for
"Key contributors" to define a precise, machine-parsable format — e.g., "Top 3
contributors as a comma-separated list of GitHub usernames (derived from recent
git log), e.g., alice,bob,charlie" — and ensure the docs state the sourcing rule
("top 3 by most recent commits") and the exact output format (comma-separated
GitHub usernames, no spaces). This replaces the vague placeholder so the
orchestrator can consistently parse the field.
In @.claude/commands/weekly.md:
- Line 113: Update the guidance that suggests using `gh api
repos/{owner}/{repo}/commits?path=<file>&per_page=5` by explaining how to obtain
`{owner}` and `{repo}` (use `gh repo view` or `git remote get-url origin`), how
to parse the JSON to extract the GitHub login (pipe the API output to a JSON
parser like `jq` and read the `[].author.login` or `[].commit.author.name`
fields), and add failure handling guidance (check HTTP/exit status and fall back
to the most recent commit author from `git log --pretty=format:%an` if the API
returns no commits or errors). Include a short example invocation pattern in the
docs showing the API call piped to `jq` and the fallback sequence so users can
reliably derive the GitHub username for `gh pr edit --add-assignee`.
- Line 105: Update the "abandon the PR" guidance in .claude/commands/weekly.md
(the step after the branch creation step near line 103 and the "Run `make`"
check) to specify branch cleanup and reporting: instruct the subagent to delete
both the local and remote branches created for the PR, switch back to main, and
then report the abandoned attempt to the orchestrator with a short summary
(reason, tests that failed, and branch name) so reviewers can pick it up;
include exact commands or placeholders for deleting local and remote branches
and a short template for the report.
- Line 115: Update the sentence "After opening the PR, switch back to main
before returning." to explicitly specify the git command to use, e.g., instruct
the user to switch back to main using git switch main (or git checkout main) so
there's no ambiguity; edit the line in the .claude/commands/weekly.md content
where that sentence appears to include the explicit command.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b5fa6a7d-53f2-4fba-a64a-9e495cdf48ba
📒 Files selected for processing (3)
.claude/agents/bug-detective.md.claude/agents/docs-expert.md.claude/commands/weekly.md
|
@claude please consider the comments coderabbit made and check them in |
Addressing CodeRabbit Review CommentsCodeRabbit left 5 nitpick comments. All addressed in commit e82d29d:
All changes pushed to branch |
Standardize "Key contributors" field format in both bug-detective and docs-expert subagents to specify top 3 comma-separated GitHub usernames with an example, ensuring the orchestrator can reliably parse and use the data for reviewer assignment. In weekly.md, add concrete jq and gh repo view guidance for extracting GitHub logins, add branch cleanup instructions when abandoning a failed make build, and specify the explicit git checkout main command. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Test Coverage ReportTest Coverage 📊: 70.0% |
Summary
makebuild verification requirement before any PR is openedTest plan
makebefore opening PRsCloses #759
🤖 Generated with Claude Code