# Vibe Code Intake > Analyse a codebase and produce a Vibe-Code Confidence Score (0–100) plus a classification of authorship style. Use as a pre-step before any code review, intake, or audit when the origin of the code is unknown or suspected to be AI-generated without engineering oversight. The score and classification determine the review posture for subsequent analysis. Trigger whenever someone shares a codebase, repo, or set of source files and asks about code quality, authorship, or whether it was AI-generated. Also triggers on "run vibe-code-intake", "score this codebase", or "is this vibe-coded". - Skill: `miguelpecegueiro/vibe-code-intake` (Agent Skill) - Install (CLI): `npx skillmds@latest add miguelpecegueiro/vibe-code-intake` - Raw SKILL.md: https://api.skillmd.com/api/skills/miguelpecegueiro/vibe-code-intake/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: MiguelPecegueiro (https://skillmd.com/u/miguelpecegueiro) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/miguelpecegueiro/vibe-code-intake --- # Vibe-Code Intake Produce an authorship classification report for an unknown codebase. The goal is not to judge the developer but to calibrate the reviewer's posture: vibe-coded projects require a fundamentally different review approach than human-authored or AI-assisted ones. --- ## Definitions **Vibe-coded** — code produced by prompting an AI iteratively with no engineering oversight. The developer accepts output, runs it, prompts again. No deliberate architecture, no security thinking, no reproducibility discipline. **AI-assisted** — a human developer uses AI as a tool within a structured engineering workflow. Commits are intentional, structure is deliberate, security is considered. AI accelerates the human; the human is still in control. **Human-authored** — written by a developer without significant AI assistance. --- ## Investigation workflow Complete all three steps before scoring. Do not score after reading only the manifest or README. ### Step 1 — Orient (read, do not score yet) Read in this order: 1. Repository root: README, manifest files (package.json, .csproj, requirements.txt, etc.), `.gitignore`, CI config 2. Entry points: main file, startup/program file, route definitions, controller index 3. One representative module end-to-end (see Step 2) 4. Test directory (or confirm absence) 5. Config files and any `.env` / secrets handling Note what you see. Do not assign scores yet. ### Step 2 — Trace one request end-to-end (mandatory) Pick one meaningful operation — a form submission, an API call, a data processing job. Trace it from entry point to data store and back: - Where does input arrive? - How is it validated? - How does it reach the database or external service? - What is returned? - Where could it fail, and what happens when it does? This step is mandatory. Structural incoherence — the most diagnostic signal — is invisible without tracing actual execution flow. A codebase can look clean from the top level and be completely incoherent in its execution paths. ### Step 3 — Sample broadly Read 5–10 more files from different parts of the codebase. Prioritise: - A service or helper class that is referenced from multiple places - Error handling code - Any authentication or authorization logic - Database interaction layer --- ## Scoring Score across five categories. Total maximum: 100. ### 1. Structural coherence (25 points) Does the architecture hold together when you trace through it? | Score | Signal | |---|---| | 20–25 | Consistent layering, responsibilities are separated, entry points lead somewhere coherent | | 13–19 | Mostly coherent with localised inconsistencies | | 6–12 | Mixed — some modules are structured, others are not; tracing a request reveals gaps | | 0–5 | No discernible architecture; logic scattered, responsibilities mixed, execution flow unclear | ### 2. Security and error handling (25 points) Does the code handle failure and protect itself? | Score | Signal | |---|---| | 20–25 | Input validated, exceptions handled specifically, no credentials in code, auth present where needed | | 13–19 | Mostly safe with some gaps | | 6–12 | Significant gaps — missing validation, broad catches, credentials in config files | | 0–5 | No meaningful security posture — SQL injection surface, hardcoded secrets, missing auth, swallowed exceptions | ### 3. Consistency and naming discipline (20 points) Does the codebase read like one person wrote it? | Score | Signal | |---|---| | 16–20 | Consistent naming, patterns reused, conventions held throughout | | 10–15 | Mostly consistent with some drift | | 5–9 | Naming inflation (classes and methods with grand names that do trivial things), mixed conventions | | 0–4 | No consistency — different conventions per file, names do not reflect behaviour, dead feature graveyards | ### 4. Test and reproducibility discipline (15 points) Can someone else run this reliably? | Score | Signal | |---|---| | 12–15 | Tests present and meaningful, dependencies pinned, build is reproducible | | 8–11 | Partial tests or reproducibility | | 4–7 | Tests absent or trivial; dependencies unpinned | | 0–3 | No tests, no reproducibility discipline, environment-specific assumptions scattered through code | ### 5. Cross-cutting concerns (15 points) Are logging, config, and shared infrastructure handled uniformly? | Score | Signal | |---|---| | 12–15 | Logging consistent, config centralised, no magic numbers scattered, shared concerns handled once | | 8–11 | Mostly uniform with gaps | | 4–7 | Inconsistent — some places log, some do not; config values scattered; concerns duplicated | | 0–3 | No consistent approach to any cross-cutting concern | --- ## Classification bands ### 0–20 — Human-authored (disciplined) The author has strong engineering instincts and uses AI, if at all, as an accelerator within a controlled workflow. Code is intentional. Trust the structure; standard review posture applies. *Diagnostic test for this band vs. the next:* Does every class and method have a clear single responsibility that is reflected in its name and contents? If yes, this band. ### 21–40 — AI-assisted (disciplined) AI was clearly used but the human stayed in control. Some AI-isms present (slightly inflated naming, occasional over-abstraction) but the author reviewed and shaped output. Architectural decisions are coherent. Review posture: normal, with attention to AI-generated boilerplate that may have been accepted without full review. *Diagnostic test vs. undisciplined:* Are cross-cutting concerns (logging, error handling, auth) consistent across the entire codebase, or only in the parts that were demo-ed? Consistent = disciplined. ### 41–60 — AI-assisted (undisciplined) AI was used extensively and the human accepted output without sufficient review. The happy path works. Error handling, edge cases, and security are inconsistent. Structure looks plausible from the top but breaks down when traced through. Review posture: verify every security boundary, do not trust naming to reflect implementation, check all external integrations manually. *Diagnostic test vs. partial vibe:* Does the codebase have any modules that are clearly well-engineered, or is the inconsistency uniform throughout? Pockets of quality = undisciplined AI-assisted. Uniform mediocrity = partial vibe. ### 61–80 — Partial vibe-coded Most of the codebase was produced by accepting AI output without review. The developer may have understood what they were asking for but not what they received. Dead code, duplicate logic, and inconsistent security posture throughout. Review posture: audit every security boundary, every external integration, every data flow. Do not trust documentation or comments to reflect actual behaviour. *Diagnostic test vs. full vibe:* Is there any evidence of deliberate architectural decisions — a README that reflects the actual structure, a migration history, a consistent DB schema design? Evidence of intent = partial. None = full vibe. ### 81–100 — Vibe-coded (full) The developer accepted AI output with no meaningful review at any layer. Security is not a consideration. Structure is accidental. The app may work in the happy path and fail unpredictably elsewhere. Review posture: treat as untrusted input. Every claim in documentation or comments must be verified against actual code. Full intake review (`codebase-intake-review`) is required before any production use or before assigning remediation tasks. --- ## Report structure ### 1. Classification summary - Score: X/100 - Classification: [band label] - One paragraph plain-language summary of what the evidence shows ### 2. Evidence by category For each of the five scoring categories: - Score awarded: X/max - Key evidence (file names, function names, patterns observed) - Any positive signals ### 3. Review posture recommendation - What to trust in subsequent review - What to verify regardless - What to treat as suspect until proven otherwise - Whether a full `codebase-intake-review` is recommended ### 4. Mixed-origin notes If different modules score significantly differently, call this out explicitly. A well-engineered core with a vibe-coded feature layer is common and changes the remediation approach. --- ## Critical constraints - **Evidence before scores.** Never assign a score without citing specific evidence from files you read. A score without evidence is an opinion. - **Complete the workflow.** Step 2 (tracing a request) is mandatory — do not score after reading only the README and manifest. - **Stack-agnostic signals.** The absence of discipline looks the same in every stack. Calibrate signals to the ecosystem — a .NET codebase without tests is the same signal as a Python codebase without tests. - **Do not modify source files.** Read only.