coderabbit

name	coderabbit
description	Use when processing CodeRabbit review comments, CodeRabbit CLI reports, or `$gobby coderabbit [findings]` requests.
version	1.0.0
category	core
triggers	["coderabbit","CodeRabbit findings","CodeRabbit report","$gobby coderabbit"]
metadata	{"gobby":{"audience":"all","depth":0}}

CodeRabbit

Use this skill for $gobby coderabbit [findings], pasted CodeRabbit comments, and files matching ./reports/coderabbit-*.md.

REQUIRED SKILL: task-transitions.

Plan Mode Gate

Before any CodeRabbit triage, first check whether the session is already in native Plan Mode. If it is not, you MUST enter native Plan Mode before reading reports, verifying findings, creating or claiming tasks, or editing files. Native Plan Mode is the runtime-provided planning state; session-level planning is the assistant's internal planning posture and does not satisfy this gate.

Use EnterPlanMode when the runtime provides it. When no direct Plan Mode tool is exposed, use gobby-sessions.send_keys(session_id, keys, literal=true) to send the provider's native Gobby plan command:

• Codex: $gobby plan\n
• Claude, Gemini, or Qwen sessions whose installed router is slash-based: /gobby plan\n
• Unsupported or unknown provider: stop with a blocker instead of guessing.

After sending keys, verify that the target session is actually in native Plan Mode before triage. Loading the plan skill or composing a plan in normal chat does not satisfy this gate.

Plan Mode triage is read-only: ingest supplied findings and ./reports/coderabbit-*.md, verify the current code, decide fixed or no-fix, and present the implementation plan; wait for plan approval before continuing to implementation. If native Plan Mode blocks task creation, create or claim the gobby-tasks task immediately after plan approval and before the first edit.

The Plan Mode output MUST include a finding-by-finding table. Each supplied finding gets its own row with:

• Decision: fix or no-fix.
• Checked file, symbol, or behavior.
• Reason for the decision.

No finding may be grouped away, summarized into another row, or silently omitted from the final plan.

Contract

CodeRabbit findings are leads, not patches. Verify each item against current code before changing files. Fix only findings that still apply. Include nits when they are valid.

For every finding, keep a decision record:

• fixed: current code confirms the problem and the diff addresses it.
• no-fix: current code does not match the finding, the suggested path no longer exists, the behavior is already correct, or the suggestion is harmful.

Every no-fix decision needs a short reason with the checked file, symbol, or behavior. Do not silently drop stale comments.

Workflow

1. If not already in native Plan Mode, enter Plan Mode with EnterPlanMode or the provider-aware gobby-sessions.send_keys fallback; verify native Plan Mode is active, then complete read-only triage before implementation.
2. Create or claim a gobby-tasks task before edits.
3. Ingest all supplied findings and every ./reports/coderabbit-*.md file.
4. For each report, identify whether it contains actionable findings or only a CodeRabbit CLI failure such as Too many files.
5. Inspect current code for each finding before deciding.
6. Apply valid findings, including small nits, using normal repo patterns.
7. Document stale or invalid findings as no-fix decisions.
8. Delete processed ./reports/coderabbit-*.md files after their contents are fixed or documented. Leave unrelated report artifacts alone.
9. Run focused validation for the touched areas, plus scoped lint/type checks when available.
10. Commit with the task ref as [<project_name>-#<task_number>] <type>: <summary> and close the task with commit_sha. Use the real project name in the task reference, such as [gobby-#123]; project_name is a placeholder, never a literal prefix. Allowed types: fix, feat, refactor, chore, docs, and test.

Verification Discipline

Do not claim "CodeRabbit fixed" until validation has actually run. If validation fails, fix the encountered failure before closing the task unless it genuinely requires a separate architectural task.

When a report only records a CLI failure, document that it added no findings, delete the processed report, and continue with validation for any code changes from other findings.