CRITICAL: This is a READ-ONLY analysis task. Agents must NOT execute any commands that modify files, run builds, execute tests, or change system state. Only use file reading, searching, and analysis tools.
I want you to dispatch a team of agents to work in parallel to investigate the entire codebase with the goal of coming up with one number between 0 and 100, representing the codebase's "agent coverage" - how well-equipped the codebase is for autonomous agent development.
Think of this like "code coverage" for testing, but instead measuring how much of the codebase is accessible and understandable to AI agents. A score of 100 means agents have everything they need to autonomously implement well-specified features without human intervention. A score of 0 means agents would be completely blocked despite knowing exactly what to build.
Assume the feature request given to the agent is extremely detailed with clear requirements, mockups, and acceptance criteria. The score should reflect only the technical ease of execution, NOT the difficulty of figuring out what to build.
CRITICAL: Rate the codebase AS IT EXISTS TODAY. Do not consider future complexity, potential growth, or what might happen "as features are added." A skeleton project with standard patterns might have EXCELLENT agent coverage precisely because it's simple and easy to modify. The absence of documentation in a simple project is far less impactful than in a complex one.
CRITICAL CONCEPT: Agent coverage requirements scale with project complexity. Simple projects need minimal documentation to achieve high coverage, while complex projects require extensive documentation to achieve the same level of agent accessibility.
- Lines of Code: <1K = 0-20, 1K-10K = 20-40, 10K-50K = 40-60, 50K-100K = 60-80, >100K = 80-100
- Number of Dependencies: 0-5 = 0-20, 5-20 = 20-40, 20-50 = 40-60, 50-100 = 60-80, >100 = 80-100
- Architectural Layers: 1-2 = 0-20, 3-4 = 20-40, 5-6 = 40-60, 7-8 = 60-80, >8 = 80-100
- Number of Technologies/Languages: 1 = 0-20, 2-3 = 20-40, 4-5 = 40-60, 6-7 = 60-80, >7 = 80-100
- Custom Abstractions/Frameworks: None = 0-20, Few = 20-40, Some = 40-60, Many = 60-80, Extensive = 80-100
Before scoring, agents must identify ALL areas of domain-specific complexity in the codebase:
- Technical Domains: video streaming, real-time processing, machine learning, cryptography, hardware interfaces, etc.
- Business Domains: financial calculations, weather analysis, medical algorithms, game mechanics, etc.
- Integration Domains: third-party APIs, legacy systems, proprietary protocols, etc.
- Data Domains: complex data transformations, specialized formats, domain-specific schemas, etc.
For a project with complexity score C (0-100), the documentation requirements are:
- Low Complexity (C < 30): Minimal documentation needed. Even basic README + standard patterns = high agent coverage. A skeleton project with NO documentation can still score 80-90+ if it uses standard patterns.
- Medium Complexity (C 30-70): Moderate documentation needed. Requires clear patterns, some architectural docs, and build instructions
- High Complexity (C > 70): Extensive documentation critical. Needs comprehensive docs, examples, and explicit agent guidance
Weight: (20 + D × 0.6)% where D = domain complexity score (0-100)
This is the most critical factor for projects with specialized domains.
Evaluate coverage for EACH identified domain area:
- Does documentation exist for this specific domain?
- Are there code examples demonstrating domain patterns?
- Are domain-specific rules/constraints documented?
- Is domain terminology explained?
- Are there test cases showing domain logic?
Scoring approach:
- List all domain-specific complexity areas
- For each area, score documentation coverage (0-100)
- Weight by that area's contribution to overall complexity
- A single uncovered complex domain can drop the score by 30-50 points
Examples:
- Video streaming app without streaming protocol docs: -40 points
- Weather app without meteorological formula explanations: -35 points
- Financial app without calculation rule documentation: -45 points
- Game without physics/mechanics documentation: -30 points
Weight: (10 + C/3 - D/3)% (adjusted down when domain complexity is high)
Evaluate based on project complexity:
- Simple projects: Basic README and CLAUDE.md suffice. Absence of docs in a skeleton project is NOT heavily penalized
- Complex projects: Need extensive architecture docs, API docs, decision records
Elements to check:
- README completeness relative to project complexity
- Architecture documentation (more critical as complexity increases)
- API documentation (essential for service-oriented architectures)
- Code comments (more important in complex logic)
- Build/test instructions clarity
- Contributing guidelines (critical for large projects)
- Agent-specific instructions (CLAUDE.md, AI guidelines)
Weight: (30 - C/4)% (ranges from 30% for simple to 5% for complex projects)
- Consistent code organization
- Clear architectural patterns
- Obvious file naming conventions
- Predictable directory structure
- Example implementations to copy
Note: In simple projects, good patterns alone enable high agent productivity
Weight: 20% (consistent across all projects)
- Build configuration clarity
- Test framework setup
- Linting/formatting rules
- CI/CD configuration readability
- Dependency management clarity
Note: For skeleton projects, the ABSENCE of complex tooling can actually IMPROVE agent coverage by reducing complexity.
Weight: (20 + C/5 - D/5)% (adjusted based on general vs domain complexity)
Evaluate how well complexity is managed:
- Technical debt level relative to project size
- Separation of concerns effectiveness
- Module coupling appropriate for scale
- Data flow clarity given the architecture
- Amount of "magic" relative to project needs
CRITICAL: Apply multiplicative penalties for uncovered domain complexity:
Final Score = Base Score × Domain Coverage Multiplier
Where Domain Coverage Multiplier =
Π(1 - (Domain_Importance × (1 - Domain_Coverage)))
For each domain:
- Domain_Importance: 0.1 to 0.5 based on centrality to application
- Domain_Coverage: 0.0 to 1.0 based on documentation/rules coverage
Agent Coverage Score = Base_Score × Domain_Coverage_Multiplier
Where:
Base_Score = Σ(Factor Score × Adjusted Weight)
Domain_Coverage_Multiplier = Π(1 - (Domain_Importance × (1 - Domain_Coverage)))
-
Simple "Hello World" with standard patterns:
- Complexity: 10/100
- Domain complexity: None
- Even without README: 85-95 (patterns alone provide high coverage)
- With basic CLAUDE.md: 95-100
-
Weather Analysis App:
- Complexity: 60/100
- Domain complexity: High (meteorology)
- With general docs but NO weather domain docs: 20-35 (severe penalty)
- With comprehensive weather formulas/rules: 75-85
-
Video Streaming Platform:
- Complexity: 80/100
- Domain complexity: Very High (streaming protocols, codecs)
- With only SwiftUI/architecture docs: 15-25 (critical domain uncovered)
- With streaming protocol documentation: 70-80
-
E-commerce Site:
- Complexity: 50/100
- Domain complexity: Medium (payment processing, inventory)
- With general docs only: 35-45
- With payment flow and inventory rules documented: 80-90
-
Skeleton Xcode project (SwiftUI template):
- Complexity: 5/100
- Domain complexity: None
- Without any docs: 75-85 (standard patterns make it trivial to modify)
- With CLAUDE.md: 90-100
- First Pass: Assess overall project complexity (0-100)
- Domain Analysis: Identify ALL domain-specific complexity areas
- Coverage Mapping: For each domain area, assess documentation/rules coverage
- Second Pass: Evaluate each general factor considering the complexity level
- Domain Penalty: Calculate domain coverage multiplier
- Final Calculation: Apply complexity-weighted scoring with domain penalties
Remember:
- Domain coverage is CRITICAL - a complex domain without documentation should severely impact the score
- Generic documentation doesn't count for domain-specific complexity
- Rate the current state, not future potential
- Simple projects can achieve high agent coverage with minimal documentation
- Complex projects REQUIRE extensive documentation for equivalent agent coverage
- Domain-specific areas MUST have domain-specific documentation
- The score represents how much an agent can accomplish autonomously given the project's inherent complexity TODAY
- A skeleton project should score HIGH if an agent can easily add features to it
- The absence of features/docs in a simple project is not the same as missing features/docs in a complex project
Each expert agent should analyze their domain by READING files and configurations only, identifying domain-specific complexity areas, assessing coverage for those areas, then contribute to a final 0-100 agent coverage score that reflects both the project's complexity and how well that complexity (especially domain-specific complexity) is managed for agent accessibility in its CURRENT STATE.