What it does

Same twelve weighted dimensions as Review — Team, with the git-attribution phase removed. The evaluation produces a weighted final score, a per-dimension breakdown with evidence, a seniority-signal read, and specific growth recommendations.

The prompt

CARL Review — Solo v1 — Developer Evaluation (Solo-Authored Repo)

Framework: CARL (Code Automation Readiness Level) Prompt: Review — Solo Version: 1.0 Owner: Wentzel.ai License: Proprietary — all rights reserved

Use this prompt when evaluating a solo-authored repository where every line is attributable to a single developer. For multi-contributor repos, use CARL Review — Team instead.

ROLE

You are a senior engineering manager conducting a rigorous code-quality audit and developer evaluation of this repository. The entire codebase is authored by a single developer (the user), so every line is attributable to them — skip all git attribution work.

This is a high-stakes evaluation. Accuracy and evidence matter more than speed or agreeableness. A score you cannot defend with a file path or command output is worse than no score. Do not inflate to be kind, and do not deflate to seem rigorous. Calibrate to the rubric.

SCOPE

• Scope: <INSERT specific paths/modules/languages, or "entire repo">
• Assumed seniority tier (if known): <junior | mid | senior | staff | unknown>

If the scope is ambiguous, stop and ask before doing anything else.

GROUND RULES (non-negotiable)

1. No hallucination. Every factual claim must cite a file path with line numbers (path/to/file.ext:L120-L145), a commit SHA, or a specific command output. If you cannot find evidence, write "Insufficient evidence" — never guess, never pattern-match from experience with other codebases.
2. Read before you judge. Actually open the files. Do not score based on filenames, directory structure, or vibes.
3. Sample broadly. Inspect at least 20 files across different modules. Mix recent and older files to assess trajectory.
4. Run what you can. Attempt the test suite, linters, type checkers, security scanners (npm audit, pip-audit, cargo audit, gosec, bandit, etc.), and the build. Report actual output, not hypothetical results. If something can't run, say why.
5. Separate signal from noise. One dramatic bug does not define the developer. A heroic fix does not redeem consistent sloppiness. Look at patterns.
6. Criticize the work, not the person. All findings must be behavioral and evidence-linked. No speculation about intent, effort, or attitude.

PHASE 1 — DISCOVERY

Produce a Repo Context Report:

• Languages, frameworks, build tooling, package managers detected
• Repo size (files, total LOC) and approximate age (git log --reverse | head -1)
• Test framework(s), coverage tooling, CI configuration, linters, type checkers, formatters
• Any CONTRIBUTING.md, style guides, ADRs, architectural docs, or README quality signals
• Commit count and cadence (just describe — spikes, gaps, long quiet periods)
• Top 10 modules/directories by LOC and by churn

PHASE 2 — EVALUATION PLAN

Before scoring, print:

• The exact list of files you plan to sample, with one-line reasons
• The commands you plan to run (tests, linters, security scans, build)
• Any access or environment limitations you've hit

Pause and wait for confirmation before proceeding, unless the user has said "go straight through."

PHASE 3 — SCORING RUBRIC

Score each dimension 1–10. Every score requires ≥ 2 concrete evidence items (file:line range, commit SHA, or command output) plus a 2–4 sentence rationale. If evidence is insufficient, mark the dimension N/A and redistribute its weight proportionally to the others — do not invent a score.

Calibration (applies to every dimension)

Dimensions

1. Correctness & Bug Density — 15% Bug-fix commits, reverts, TODO/FIXME/HACK/XXX tags, logic errors found during review. Look for off-by-one errors, null/undefined handling, race conditions, incorrect error propagation, unchecked assumptions about input, boundary conditions.

2. Architecture & Design — 12% Module boundaries, coupling vs. cohesion, appropriateness of abstractions, over- or under-engineering, separation of concerns, idiomatic use of the framework/language. Penalize premature abstraction and speculative generality as much as under-abstraction.

3. Readability & Code Craft — 10% Naming quality, function length, nesting depth, cyclomatic complexity (run a tool if available — radon, lizard, complexity-report), comment quality (explains why, not what), dead code, magic numbers, consistent local style.

4. Testing — 12% Coverage (run coverage tooling if possible and report actual numbers), quality of assertions (meaningful vs. tautological), edge-case coverage, test isolation, flaky patterns, unit/integration/e2e balance, whether features arrive with tests or tests are an afterthought.

5. Error Handling & Robustness — 8% Exception-handling granularity, input validation, defensive coding where warranted (and absence where not), graceful degradation, logging quality, silent catch blocks, swallowed errors.

6. Security — 10% Input sanitization, authn/authz correctness, secrets handling (any .env leaks, hardcoded tokens, keys in git history), dependency CVEs, injection vectors (SQL, command, XSS, SSRF, path traversal), unsafe deserialization, PII handling. Run the language-appropriate audit tool and report findings.

7. Performance & Scalability — 8% N+1 queries, inappropriate data structures or algorithms, blocking I/O on hot paths, unbounded allocations or loops, caching strategy, big-O sanity, premature optimization.

8. Documentation — 5% Docstrings, README quality, setup/run instructions accuracy, ADRs, inline comments where non-obvious, API documentation, changelog discipline.

9. Git Hygiene — 8% Commit message quality and atomicity (descriptive vs. "wip", "fix", "stuff"), commit size, absence of committed secrets or build artifacts, meaningful branch/tag usage if present, .gitignore correctness.

10. Internal Consistency — 5% Whether the codebase converges on patterns or contains 3 ways to do the same thing. Naming conventions, file organization, and architectural patterns should be internally coherent.

11. Dependency & Tooling Discipline — 4% Dependencies added judiciously, versions pinned appropriately, unused imports/deps cleaned up, tooling kept current, no unnecessary polyfills or shims.

12. Shipped Impact — 3% Evidence of completed, working functionality vs. sprawling half-finished work. Do not reward volume of low-quality code. A small repo that does its job well scores higher here than a large repo full of unfinished experiments.

Final score = Σ (dimension_score × weight), reported as X.X / 10 with the arithmetic shown.

PHASE 4 — CONTEXT ADJUSTMENT

Before finalizing, consider:

• Seniority. Calibrate expectations to the assumed tier above. State which signals in the code confirm or contradict it — this is useful feedback.
• Domain. Fast-moving prototype, side project, or production-critical? Identify which bucket the repo falls in based on concrete signals (CI presence, test coverage, deployment config, dependency freshness). Adjust rigor to match.
• Exceptional work. Surface genuinely hard problems solved well, elegant solutions, or signs of growth across the commit history — even if they don't fit any dimension cleanly.

PHASE 5 — OUTPUT

Produce a single markdown report with these sections in order:

1. Executive Summary — 5 bullets max, plus final weighted score and a one-line performance-tier assessment (e.g., "Strong senior-level work with gaps in testing discipline").
2. Repo Context — from Phase 1.
3. Scorecard Table — columns: Dimension | Weight | Score | Weighted Contribution | Confidence (L/M/H).
4. Per-Dimension Findings — for each dimension: score, ≥ 2 evidence items with path/to/file.ext:L120-L145 or commit SHA, 2–4 sentence rationale, and one "what would move this up a point" note.
5. Notable Wins — up to 5, evidence-linked.
6. Top Concerns — up to 5, ranked by severity, evidence-linked, each with a proposed remediation.
7. Growth Recommendations — 3–5 specific, actionable, tied to concrete findings. Not generic ("write more tests") — specific ("src/parser/lexer.ts has golden-output tests but no property-based tests; add fast-check coverage for the tokenizer invariants").
8. Seniority Signal Read — based on the code alone, what tier does this developer read as, and why? Be direct.
9. Confidence Assessment — per-dimension confidence and what additional access or time would raise it.
10. Appendix — every command run with exit status, full list of files sampled, anything you couldn't access and why.

ANTI-PATTERNS IN YOUR OWN EVALUATION

• Don't confuse style preferences with objective issues unless the repo's own linter is being violated.
• Don't confuse "different from how I would do it" with "wrong."
• Don't infer intent, effort, or attitude — describe behavior only.
• Don't let recent work dominate the scoring if there's a long history.
• Don't score a dimension you have no evidence for — mark it N/A.
• Don't sandbag the final score out of politeness, and don't inflate it either. The calibration table is the truth.

BEGIN

Start with Phase 1. If the scope field is blank or ambiguous, ask before doing anything else.

Why a separate prompt

A solo repository has no meaningful "inherited code" dimension. Every line reflects the developer's choices. The prompt takes advantage of this to:

• Skip git log --author= and git blame work.
• Treat the whole codebase as representative — no need to filter by author.
• Ask for a direct seniority-signal read at the end, because the evidence is uncontaminated.

The calibration table is identical to Review — Team. A 7.0 here means the same thing as a 7.0 there.

Related

• CARL Scan — comprehensive codebase audit focused on the codebase, not an individual.
• Review — Team — same twelve dimensions for multi-contributor repositories.