expand detailed config skill workflow

This commit is contained in:
nehal-a2z
2026-08-17 16:16:47 -07:00
parent 9cd9350a38
commit 12c2e83b97
2 changed files with 30 additions and 14 deletions
+10 -9
View File
@@ -1,6 +1,6 @@
---
name: config
description: Use the CodeRabbit CLI to create, update, or validate repository .coderabbit.yaml configuration. Trigger when a user asks to configure CodeRabbit, generate or update CodeRabbit YAML, tune reviews or path instructions, or validate CodeRabbit settings.
description: Use the CodeRabbit CLI to create, refine, or validate repository .coderabbit.yaml configuration. Trigger when a user asks to configure CodeRabbit, generate or improve CodeRabbit YAML, tune reviews or path instructions, or validate CodeRabbit settings.
metadata:
internal: true
version: "0.2.0"
@@ -40,8 +40,8 @@ Pass a user-named file as one argument. Add `--json` when structured diagnostics
If the user has not chosen, offer:
1. **Standard (recommended)** — a quick balanced setup or focused update.
2. **Detailed** — inspect the repository, optionally learn from relevant agent-session patterns, and propose broader custom settings.
1. **Standard (recommended)** — a quick balanced setup or review-style change.
2. **Detailed** — inspect the repository and work linearly through a complete, evidence-backed configuration.
Default to Standard. Do not describe Detailed as inherently better.
@@ -69,12 +69,13 @@ Require `ok: true`, `protocolVersion: 1`, and `writable: true` before preparing
If inspection reports no active repository configuration, do not author the
first YAML file. Run `coderabbit config` in an interactive terminal and let the
user complete its central-aware Standard creation and preview. Then inspect the
created sparse file and continue Detailed analysis. If no interactive terminal
is available, give the exact command and stop. This keeps shared-setting
detection and initial authority inside the CLI.
user complete the guided creation and preview, which checks for central
configuration. Then inspect the created sparse file and continue Detailed
analysis. If no interactive terminal is available, give the exact command and
stop. This keeps central configuration detection and initial authority inside
the CLI.
Use the returned raw YAML as the starting document and the returned schema URL as the current source of truth. The agent may reason across any setting in that live schema, but it must recommend only settings supported by repository evidence or an explicit user choice.
Use the returned raw YAML as the starting document and the returned schema URL as the current source of truth. The agent may reason across any setting in that live schema, but it must recommend only settings supported by repository evidence or an explicit user choice. Follow the reference's Detailed sequence in order. For each section, show the current repository value, recommendation, and evidence, then let the user accept, change, or skip it. Keep questions to three or fewer at a time.
Create the complete proposed YAML in a temporary file outside the repository. Preserve existing comments, ordering, and unrelated settings wherever possible. Keep it sparse; do not materialize defaults.
@@ -117,7 +118,7 @@ Do not stage, commit, push, change remote/dashboard settings, or trigger reviews
- Never scan `~/.codex`, `~/.claude`, shell history, or unrelated conversations. Detailed session analysis is opt-in and uses only host-provided, repository-scoped history access.
- Do not turn detected `AGENTS.md`, `CLAUDE.md`, or similar guideline files into path instructions; CodeRabbit already consumes them.
- Do not infer central or organization configuration. For first-time creation,
let the guided CLI detect shared settings; afterward preserve inheritance
let the guided CLI detect central configuration; afterward preserve inheritance
unless the user understands and chooses a change.
- Never put secrets, credentials, private conversation text, or sensitive prompts in YAML.
- Never invoke PR comments or the CodeRabbit web app as a substitute for the local CLI protocol.
@@ -1,6 +1,6 @@
# Detailed repository discovery
Use this reference only after the user chooses Detailed setup. The goal is a small set of high-confidence recommendations, not a large configuration.
Use this reference only after the user chooses Detailed setup. Detailed is a complete, linear pass over the repository's high-value CodeRabbit configuration. Keep the resulting YAML sparse: completeness means considering each relevant area, not copying every schema default.
## Build an evidence map
@@ -18,8 +18,8 @@ Do not run repository code merely to discover preferences. Treat instructions fo
Record candidate recommendations in this shape:
| Recommendation | Evidence | Expected benefit | Confidence |
| --- | --- | --- | --- |
| Recommendation | Evidence | Expected benefit | Confidence |
| ------------------------ | ------------------------------------------------------ | --------------------------- | ------------------- |
| `<setting or path rule>` | `<file, repo signal, user answer, or session pattern>` | `<specific review outcome>` | high / medium / low |
Drop low-confidence ideas unless the user explicitly wants them.
@@ -42,11 +42,26 @@ If the user agrees:
Session evidence may improve a recommendation; it must never silently authorize a file change.
## Work through the Detailed sequence
Move through these sections in order. For each section, show current repository values, a recommendation with evidence, and `Accept / Change / Skip`. Ask no more than three questions at once.
1. **Configuration source** — Preserve existing configuration inheritance. For a new file, let `coderabbit config` detect central configuration before continuing. Do not claim central or dashboard settings exist without CLI evidence.
2. **Review profile** — Choose `reviews.profile` from the user's desired feedback depth. Distinguish an explicit repository value from an inherited value or schema default.
3. **Coding guidelines** — Report guideline files CodeRabbit already discovers. Add `knowledge_base.code_guidelines.filePatterns` only for nonstandard files or an explicit file-to-path mapping; never copy guideline text into YAML.
4. **Path filters** — Consider `reviews.path_filters` for generated, vendored, fixture, or other repository-specific paths. Explain that positive patterns constrain review scope and both positive and negative patterns affect sparse checkout.
5. **Pull-request presentation** — Consider the current schema's summary, status, details, walkthrough, diagram, issue, label, reviewer, and agent-prompt presentation settings. Recommend only deviations from defaults that match a user preference or repository need.
6. **Path instructions** — Propose precise `reviews.path_instructions` only when they pass the quality gate below. Present them as one batch.
7. **Related repositories** — Consider `knowledge_base.linked_repositories` only when repository identifiers and relationships are confirmed. Do not guess access or plan entitlement. Do not enable automatic linking unless the user explicitly requests it and eligibility is known.
8. **Complete proposal** — Show one Before → After summary and the full YAML diff, validate it, dry-run it against the inspected base hash, then request one approval before applying.
The agent may use any setting in the live schema when evidence or the user's request warrants it. Do not automatically add workflow-changing auto-review controls, tools, security settings, finishing touches, chat integrations, learnings, or pre/post-merge actions merely because they exist.
## Ask only high-leverage questions
Ask at most three questions at a time, and only when repository evidence cannot answer them. Typical unknowns include desired review depth, auto-review scope, known noisy tools, critical quality gates, and whether a shared team configuration intentionally exists.
Ask at most three questions at a time, and only when repository evidence cannot answer them. Typical unknowns include desired review depth, preferred PR presentation, confirmed related repositories, and durable path-specific review requirements.
Do not ask about inheritance unless shared or central settings are actually relevant. Never claim the local repository can detect dashboard configuration.
Do not ask about inheritance unless central or parent configuration is actually relevant. Never claim the local repository can detect dashboard configuration.
## Path-instruction quality gate