chore: Streamline CodeRabbit config to only non-default values

[jeremyeder]

Summary

Reduced .coderabbit.yaml from 240 to 154 lines (-35%) by removing all default values. Config now only specifies deviations from CodeRabbit's schema defaults.

Changes

Removed (all defaults):

• language: en-US (default)
• early_access: false (default)
• enable_free_tier: true (default)
• reviews.profile: "chill" (default)
• reviews.high_level_summary: true (default)
• reviews.collapse_walkthrough: true (changed to false default, removed)
• reviews.review_status: true (default)
• reviews.auto_review.enabled: true (default)
• reviews.auto_review.drafts: false (default)
• reviews.tools.actionlint.enabled: true (default)
• reviews.tools.shellcheck.enabled: true (default)
• reviews.tools.markdownlint.enabled: true (default)
• reviews.tools.gitleaks.enabled: true (default)

Kept (non-defaults only):

• reviews.poem: false (default: true)
• reviews.request_changes_workflow: true (default: false)
• reviews.tools.ruff.enabled: false (default: true)
• reviews.tools.flake8.enabled: false (default: true)
• reviews.tools.pylint.enabled: false (default: true)
• reviews.tools.biome.enabled: false (default: true)
• Path instructions (8 areas)
• Path filters (generated files)
• Knowledge base learnings (6 AgentReady patterns)
• Tone instructions

Benefits

1. Clarity: Immediately obvious what's customized vs defaults
2. Maintainability: Less likely to conflict with future schema updates
3. Signal-to-noise: Config file itself has high signal-to-noise ratio
4. Documentation: Comments indicate default values for context

Validation

• Checked against schema: https://coderabbit.ai/integrations/schema.v2.json
• Extracted all defaults using schema parser
• Verified removed values match documented defaults

🤖 Generated with Claude Code

Summary by CodeRabbit

Release Notes

• Chores
  • Updated CodeRabbit configuration with streamlined review workflow settings and modified behavior parameters.
  • Enhanced path-specific review instructions with explicit guidance and targeted checks for core assessors, data models, services, tests, CLI components, GitHub actions, and documentation files.
  • Implemented filtering rules to exclude build artifacts, dependency caches, virtual environments, example files, and auto-generated cache from code reviews.
  • Consolidated code guidelines and tone instructions with updated formatting and requirements.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Caution

Review failed

The pull request is closed.

Warning

.coderabbit.yaml has a parsing error

The CodeRabbit configuration file in this repository has a parsing error and default settings were used instead. Please fix the error(s) in the configuration file. You can initialize chat with CodeRabbit to get help with the configuration file.

💥 Parsing errors (1)

Validation error: String must contain at most 250 character(s) at "tone_instructions"

⚙️ Configuration instructions

• Please see the configuration documentation for more information.
• You can also validate your configuration using the online YAML validator.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Walkthrough

The .coderabbit.yaml configuration file is restructured to replace verbose, multi-section defaults with a streamlined, targeted approach. Settings consolidate around explicit path instructions, simplified tooling, clearer review behavior, and prescriptive guidance for code assessments.

Changes

Cohort / File(s)

Summary

Configuration Restructuring \.coderabbit\.yaml

Replaces extensive default/optional configuration with explicit non-default values; switches review behavior to request_changes_workflow mode; disables most tools except ruff; consolidates path-specific instructions for assessors, data models, services, tests, CLI, GitHub actions, docs, and scripts; streamlines knowledge_base into code_guidelines; expands tone_instructions with concise, action-oriented requirements; adds comprehensive path_filters to exclude noisy and irrelevant paths (caches, virtual environments, build artifacts, examples, etc.).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Areas requiring attention:

• Verify all critical path_filters are correctly specified and don't inadvertently exclude important paths
• Confirm path_instructions cover all necessary code directories with appropriate guidance
• Review consolidated code_guidelines and tone_instructions for completeness and alignment with intended review behavior
• Cross-check request_changes_workflow and disabled tool defaults against project needs

Poem

A rabbit hops through configs dense,
Trimming verbosity, restoring sense.
From sprawling rules to focused guides,
Clarity blooms where noise subsides. 🐰✨

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore/streamline-coderabbit-config

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 248467f and eefded7.

📒 Files selected for processing (1)

• .coderabbit.yaml (2 hunks)

---

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

[github-actions]

🤖 AgentReady Assessment Report

Repository: agentready
Path: /home/runner/work/agentready/agentready
Branch: HEAD | Commit: 6772a55c
Assessed: November 25, 2025 at 3:49 PM
AgentReady Version: 2.7.1
Run by: runner@runnervmg1sw1

---

📊 Summary

Metric	Value
Overall Score	69.9/100
Certification Level	Silver
Attributes Assessed	20/30
Attributes Not Assessed	10
Assessment Duration	1.5s

Languages Detected

• Python: 137 files
• Markdown: 98 files
• YAML: 21 files
• JSON: 9 files
• Shell: 6 files

Repository Stats

• Total Files: 316
• Total Lines: 175,048

🎖️ Certification Ladder

• 💎 Platinum (90-100)
• 🥇 Gold (75-89)
• 🥈 Silver (60-74) → YOUR LEVEL ←
• 🥉 Bronze (40-59)
• ⚠️ Needs Improvement (0-39)

📋 Detailed Findings

API Documentation

Attribute	Tier	Status	Score
OpenAPI/Swagger Specifications	T3	⊘ not_applicable	—

Build & Development

Attribute	Tier	Status	Score
One-Command Build/Setup	T2	✅ pass	100
Container/Virtualization Setup	T4	⊘ not_applicable	—

Code Organization

Attribute	Tier	Status	Score
Separation of Concerns	T2	✅ pass	98

Code Quality

Attribute	Tier	Status	Score
Type Annotations	T1	❌ fail	41
Cyclomatic Complexity Thresholds	T3	✅ pass	100
Semantic Naming	T3	✅ pass	100
Structured Logging	T3	❌ fail	0
Code Smell Elimination	T4	⊘ not_applicable	—

❌ Type Annotations

Measured: 32.8% (Threshold: ≥80%)

Evidence:

• Typed functions: 449/1369
• Coverage: 32.8%

📝 Remediation Steps

Add type annotations to function signatures

1. For Python: Add type hints to function parameters and return types
2. For TypeScript: Enable strict mode in tsconfig.json
3. Use mypy or pyright for Python type checking
4. Use tsc --strict for TypeScript
5. Add type annotations gradually to existing code

Commands:

# Python
pip install mypy
mypy --strict src/

# TypeScript
npm install --save-dev typescript
echo '{"compilerOptions": {"strict": true}}' > tsconfig.json

Examples:

# Python - Before
def calculate(x, y):
    return x + y

# Python - After
def calculate(x: float, y: float) -> float:
    return x + y

// TypeScript - tsconfig.json
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

❌ Structured Logging

Measured: not configured (Threshold: structured logging library)

Evidence:

• No structured logging library found
• Checked files: pyproject.toml
• Using built-in logging module (unstructured)

📝 Remediation Steps

Add structured logging library for machine-parseable logs

1. Choose structured logging library (structlog for Python, winston for Node.js)
2. Install library and configure JSON formatter
3. Add standard fields: timestamp, level, message, context
4. Include request context: request_id, user_id, session_id
5. Use consistent field naming (snake_case for Python)
6. Never log sensitive data (passwords, tokens, PII)
7. Configure different formats for dev (pretty) and prod (JSON)

Commands:

# Install structlog
pip install structlog

# Configure structlog
# See examples for configuration

Examples:

# Python with structlog
import structlog

# Configure structlog
structlog.configure(
    processors=[
        structlog.stdlib.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        structlog.processors.JSONRenderer()
    ]
)

logger = structlog.get_logger()

# Good: Structured logging
logger.info(
    "user_login",
    user_id="123",
    email="user@example.com",
    ip_address="192.168.1.1"
)

# Bad: Unstructured logging
logger.info(f"User {user_id} logged in from {ip}")

Context Window Optimization

Attribute	Tier	Status	Score
CLAUDE.md Configuration Files	T1	✅ pass	100
File Size Limits	T2	❌ fail	55

❌ File Size Limits

Measured: 2 huge, 8 large out of 137 (Threshold: <5% files >500 lines, 0 files >1000 lines)

Evidence:

• Found 2 files >1000 lines (1.5% of 137 files)
• Largest: tests/unit/test_models.py (1184 lines)

📝 Remediation Steps

Refactor large files into smaller, focused modules

1. Identify files >1000 lines
2. Split into logical submodules
3. Extract classes/functions into separate files
4. Maintain single responsibility principle

Examples:

# Split large file:
# models.py (1500 lines) → models/user.py, models/product.py, models/order.py

Dependency Management

Attribute	Tier	Status	Score
Lock Files for Reproducibility	T1	❌ fail	0
Dependency Freshness & Security	T2	⊘ not_applicable	—

❌ Lock Files for Reproducibility

Measured: none (Threshold: at least one lock file)

Evidence:

• No lock files found

📝 Remediation Steps

Add lock file for dependency reproducibility

1. Use npm install, poetry lock, or equivalent to generate lock file

Commands:

npm install  # generates package-lock.json

Documentation

Attribute	Tier	Status	Score
Concise Documentation	T2	❌ fail	70
Inline Documentation	T2	✅ pass	100

❌ Concise Documentation

Measured: 276 lines, 40 headings, 38 bullets (Threshold: <500 lines, structured format)

Evidence:

• README length: 276 lines (excellent)
• Heading density: 14.5 per 100 lines (target: 3-5)
• 1 paragraphs exceed 10 lines (walls of text)

📝 Remediation Steps

Make documentation more concise and structured

1. Break long README into multiple documents (docs/ directory)
2. Add clear Markdown headings (##, ###) for structure
3. Convert prose paragraphs to bullet points where possible
4. Add table of contents for documents >100 lines
5. Use code blocks instead of describing commands in prose
6. Move detailed content to wiki or docs/, keep README focused

Commands:

# Check README length
wc -l README.md

# Count headings
grep -c '^#' README.md

Examples:

# Good: Concise with structure

## Quick Start
```bash
pip install -e .
agentready assess .

Features

• Fast repository scanning
• HTML and Markdown reports
• 25 agent-ready attributes

Documentation

See docs/ for detailed guides.

Bad: Verbose prose

This project is a tool that helps you assess your repository
against best practices for AI-assisted development. It works by
scanning your codebase and checking for various attributes that
make repositories more effective when working with AI coding
assistants like Claude Code...

[Many more paragraphs of prose...]

</details>

### Documentation Standards

| Attribute | Tier | Status | Score |
|-----------|------|--------|-------|
| README Structure | T1 | ✅ pass | 100 |
| Architecture Decision Records (ADRs) | T3 | ❌ fail | 0 |
| Architecture Decision Records | T3 | ⊘ not_applicable | — |

#### ❌ Architecture Decision Records (ADRs)

**Measured**: no ADR directory (Threshold: ADR directory with decisions)

**Evidence**:
- No ADR directory found (checked docs/adr/, .adr/, adr/, docs/decisions/)

<details><summary><strong>📝 Remediation Steps</strong></summary>


Create Architecture Decision Records (ADRs) directory and document key decisions

1. Create docs/adr/ directory in repository root
2. Use Michael Nygard ADR template or MADR format
3. Document each significant architectural decision
4. Number ADRs sequentially (0001-*.md, 0002-*.md)
5. Include Status, Context, Decision, and Consequences sections
6. Update ADR status when decisions are revised (Superseded, Deprecated)

**Commands**:

```bash
# Create ADR directory
mkdir -p docs/adr

# Create first ADR using template
cat > docs/adr/0001-use-architecture-decision-records.md << 'EOF'
# 1. Use Architecture Decision Records

Date: 2025-11-22

## Status
Accepted

## Context
We need to record architectural decisions made in this project.

## Decision
We will use Architecture Decision Records (ADRs) as described by Michael Nygard.

## Consequences
- Decisions are documented with context
- Future contributors understand rationale
- ADRs are lightweight and version-controlled
EOF

Examples:

# Example ADR Structure

```markdown
# 2. Use PostgreSQL for Database

Date: 2025-11-22

## Status
Accepted

## Context
We need a relational database for complex queries and ACID transactions.
Team has PostgreSQL experience. Need full-text search capabilities.

## Decision
Use PostgreSQL 15+ as primary database.

## Consequences
- Positive: Robust ACID, full-text search, team familiarity
- Negative: Higher resource usage than SQLite
- Neutral: Need to manage migrations, backups

</details>

### Git & Version Control

| Attribute | Tier | Status | Score |
|-----------|------|--------|-------|
| Conventional Commit Messages | T2 | ❌ fail | 0 |
| .gitignore Completeness | T2 | ✅ pass | 100 |
| Branch Protection Rules | T4 | ⊘ not_applicable | — |
| Issue & Pull Request Templates | T4 | ⊘ not_applicable | — |

#### ❌ Conventional Commit Messages

**Measured**: not configured (Threshold: configured)

**Evidence**:
- No commitlint or husky configuration

<details><summary><strong>📝 Remediation Steps</strong></summary>


Configure conventional commits with commitlint

1. Install commitlint
2. Configure husky for commit-msg hook

**Commands**:

```bash
npm install --save-dev @commitlint/cli @commitlint/config-conventional husky

Performance

Attribute	Tier	Status	Score
Performance Benchmarks	T4	⊘ not_applicable	—

Repository Structure

Attribute	Tier	Status	Score
Standard Project Layouts	T1	✅ pass	100
Issue & Pull Request Templates	T3	✅ pass	100
Separation of Concerns	T2	⊘ not_applicable	—

Security

Attribute	Tier	Status	Score
Security Scanning Automation	T4	⊘ not_applicable	—

Testing & CI/CD

Attribute	Tier	Status	Score
Test Coverage Requirements	T2	✅ pass	100
Pre-commit Hooks & CI/CD Linting	T2	✅ pass	100
CI/CD Pipeline Visibility	T3	✅ pass	80

🎯 Next Steps

Priority Improvements (highest impact first):

1. Lock Files for Reproducibility (Tier 1) - +10.0 points potential
   • Add lock file for dependency reproducibility
2. Type Annotations (Tier 1) - +10.0 points potential
   • Add type annotations to function signatures
3. Conventional Commit Messages (Tier 2) - +3.0 points potential
   • Configure conventional commits with commitlint
4. File Size Limits (Tier 2) - +3.0 points potential
   • Refactor large files into smaller, focused modules
5. Concise Documentation (Tier 2) - +3.0 points potential
   • Make documentation more concise and structured

---

📝 Assessment Metadata

• Tool Version: AgentReady v1.0.0
• Research Report: Bundled version
• Repository Snapshot: 6772a55
• Assessment Duration: 1.5s

🤖 Generated with Claude Code

[github-actions]

🎉 This PR is included in version 2.8.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀