Reports
A scan report provides a comprehensive analysis of a GitHub repository, generated after completing a scan. The report is available in the dashboard at /dashboard/scans and can also be downloaded as a PDF.
Overview
Each report is structured into several sections that provide different insights about the repository. The content varies based on the scan level selected:
- Basic - Repository Metadata, Commit Density, Package Bloat
- Standard - Everything in Basic, plus Static Analysis, Security Issue Detection, and Files Analyzed
- Deep - Everything in Standard, plus Code Analysis and Vibe Analysis
Each section includes a score (where applicable) and detailed breakdown of the findings. Scores range from 0 to 100, with higher scores indicating better results.
Scan Summary
The Scan Summary provides a high-level overview of the repository analysis. It appears at the top of every report and includes:
- Scan Level - The level of analysis performed (Basic, Standard, or Deep)
- Scanned At - Timestamp of when the scan was completed
- Overall Scores - Visual score cards for each analysis section:
- Commit Density Score
- Package Bloat Score
- Static Analysis Score (Standard/Deep)
- Code Analysis Score (Deep)
- Vibe Analysis Score (Deep)
The summary helps you quickly assess the overall health and quality of the repository without diving into each section.
TL;DR
An AI-generated summary of the entire scan, produced by sending the full scan result to an LLM. The LLM assigns a score (0-100) and lists key findings based on its own qualitative assessment. This is an LLM-opinionated conclusion — the score is purely model-driven, not algorithmic.
Available in all scan levels. The LLM prompt adapts based on the scan level to acknowledge which data sections are available.
Repository Metadata
This section provides general information about the GitHub repository being analyzed. It includes the following metadata:
How it's generated: Data is fetched directly from the GitHub API (repo info, stars, forks, language, topics, commits, package.json). No scoring — factual display only.
| Field | Description |
|---|---|
| name | Repository name (e.g., facebook/react) |
| description | Repository description from GitHub |
| stars | Number of GitHub stars |
| forks | Number of forks |
| watchers | Number of watchers |
| language | Primary programming language |
| license | Detected license (e.g., MIT, Apache-2.0) |
| size | Repository size in KB |
| openIssues | Number of open issues |
| contributorsCount | Number of contributors |
| topics | Repository topics/tags |
| createdAt | Repository creation date |
| pushedAt | Last push date |
| lastCommitDate | Date of the last commit |
| commitSha | SHA of the latest commit |
This metadata is available in all scan levels (Basic, Standard, and Deep).
Commit Density
The Commit Density section analyzes the repository's commit activity to assess development velocity and maintenance health.
How it's generated: Commits are fetched from the GitHub API (up to 365) and bucketed into weekly or daily periods. The score is calculated via a threshold-based formula on the average commits-per-month — no LLM involvement.
Score
A score from 0 to 100 based on the repository's commit activity patterns. Higher scores indicate active, consistent development.
| Commits / Month | Score | Assessment |
|---|---|---|
| >= 50 | 90 | Very active development |
| >= 20 | 75 | Active development |
| >= 5 | 60 | Moderate activity |
| >= 1 | 40 | Low activity |
| < 1 | 20 | Minimal / abandoned |
Commits per Month
The average number of commits per month, calculated over the repository's activity history.
Description
A textual assessment of the commit density, describing whether the repository is actively maintained, sporadically updated, or dormant.
Activity History
A visual chart showing commit activity over time, broken down by time buckets (weeks or months). This helps identify:
- Periods of high and low activity
- Recent changes in development pace
- Overall project momentum
Activity Period
The time range covered by the activity analysis, from the first recorded commit to the most recent.
This section is available in all scan levels (Basic, Standard, and Deep).
Package Bloat
The Package Bloat section analyzes the repository's dependencies to identify potential bloat and maintenance concerns.
How it's generated: package.json is fetched from the GitHub API. Dependencies are counted and categorized by pattern matching against known categories (UI, testing, build tools, etc.). The score is calculated via a threshold-based formula on total dependency count — no LLM involvement.
Score
A score from 0 to 100 based on the dependency profile. Higher scores indicate leaner, well-maintained dependency trees.
| Total Dependencies | Score | Assessment |
|---|---|---|
| 0 (no package.json) | 50 | Not a Node.js project |
| <= 10 | 90 | Minimal dependencies |
| <= 30 | 70 | Reasonable count |
| <= 60 | 50 | Moderate count |
| <= 100 | 30 | High count — potential bloat |
| > 100 | 15 | Very high — significant bloat |
Dependency Count
Total number of dependencies found in the repository's package manifests (package.json, etc.).
Dev Dependency Ratio
The ratio of development dependencies to production dependencies. A high ratio may indicate a build-heavy project, while a low ratio suggests a simpler setup.
Description
A textual assessment of the dependency health, describing whether the project has a reasonable dependency footprint or potential bloat issues.
Key Packages
A list of notable dependencies that are central to the project's functionality, helping you understand the technology stack at a glance.
Categorized Dependencies
Dependencies grouped by category (e.g., UI frameworks, testing libraries, build tools). This helps identify:
- What the project is built with
- Potential redundant or conflicting packages
- Outdated dependency categories
Monorepo Packages
If the repository is a monorepo, this shows the internal packages detected within the workspace.
This section is available in all scan levels (Basic, Standard, and Deep).
Files Analyzed
A table listing every file that was analyzed during the scan, showing the type of analysis applied and whether the file was truncated. Available in Standard and Deep scan levels.
How it's generated: Compiled from all per-file analysis tasks (static analysis, code analysis, vibe analysis) run during the scan. Each analyzed file is recorded with its analysis types, original size, and truncation status.
| Column | Description |
|---|---|
| File Path | Path to the file within the repository |
| Type | Analysis type applied (Static, Code, Vibe, or a combination) |
| Size | Original file size in human-readable format |
| Truncated | Whether the file exceeded the max length threshold (30,000 chars) and was truncated before LLM analysis |
Files that exceed the configured max length threshold are truncated before being sent to the LLM to manage context window size. Static analysis via Tree-sitter is not affected by truncation as it operates on the full file.
Static Analysis
The Static Analysis section provides code quality metrics by analyzing the repository's source code without executing it. This section is available in Standard and Deep scan levels.
How it's generated: Each file is parsed with Tree-sitter AST (WASM) for supported languages (JS, TS, Python, Go, Java, Ruby, Rust, C, C++). Regex-based analysis runs as a fallback for unsupported languages. TypeScript syntax errors are cross-validated against the TypeScript compiler to suppress false positives. No LLM involvement.
Score
A score from 0 to 100 composed of three weighted sub-scores, averaged across all analyzed files:
| Component | Weight | Method |
|---|---|---|
| Structure | 25% | Cyclomatic complexity (control flow count) and file size analysis |
| Security | 50% | Starts at 100, deducts for eval(), innerHTML, SQL injection, hardcoded secrets, exec(), etc. |
| Best Practices | 25% | Starts at 100, deducts for console.log, debugger, TODO/FIXME, @ts-ignore, excessive comments |
Final score = Structure × 25% + Security × 50% + Best Practices × 25%.
Code Quality Metrics
Detailed metrics about the codebase, which may include:
- Lines of code and file count
- Code complexity scores
- Duplication percentage
- Style and formatting compliance
Issues Found
A breakdown of issues detected, categorized by severity (error, warning, info), helping prioritize what needs attention.
Code Analysis
The Code Analysis section uses AI-powered analysis to provide deep insights into the repository's code quality, architecture, and patterns. This section is only available in Deep scan level.
How it's generated: Each file is sent to an LLM for qualitative analysis. The LLM evaluates the code based on the same three sub-categories as Static Analysis, but the scores come from AI judgment rather than deterministic AST parsing. No heuristics or Tree-sitter involvement.
Score
An AI-generated score from 0 to 100 assessing the overall code quality, architecture, and maintainability. Composed of three weighted sub-scores from the LLM:
| Component | Weight | LLM Evaluates |
|---|---|---|
| Structure | 25% | Organization, modularity, complexity |
| Security | 50% | Validation, authentication, vulnerabilities |
| Best Practices | 25% | Error handling, type safety, documentation |
Final score = Structure × 25% + Security × 50% + Best Practices × 25%.
Architecture Assessment
Analysis of the project's architecture patterns, including:
- Code organization and structure
- Design pattern usage
- Separation of concerns
- Scalability indicators
Code Patterns
Identification of common and notable coding patterns, including both positive patterns (best practices) and anti-patterns that may need attention.
Recommendations
AI-generated suggestions for improving code quality, reducing technical debt, and enhancing maintainability.
Vibe Analysis
The Vibe Analysis section detects "vibe coding" patterns - indicators that the code may have been generated primarily by AI without proper human review or understanding. This section is only available in Deep scan level.
How it's generated: An adaptive 50/50 blend of heuristic signals and LLM assessment. Heuristics analyze commit patterns, comment-to-code ratios, per-file git stats (up to 200 commits), and AI hallucination patterns. The LLM evaluates each file independently. The blend weight adapts based on confidence signals (stars, contributors, commit spread) — the heuristic share ranges from 10% to 75%. Scores are inverted so 100 = most human-like.
Score
A score from 0 to 100 where higher scores indicate more human-crafted code. Lower scores suggest significant AI-generated content without proper oversight. Composed of three LLM-assessed sub-categories:
| Component | Weight | LLM Evaluates |
|---|---|---|
| Uniformity | 35% | Is the code monotonously template-like vs. organically evolved? |
| Boilerplate | 35% | Unnecessary ceremony vs. pragmatic abstraction? |
| Domain Fit | 30% | Generic surface-level solution vs. deep domain understanding? |
LLM sub-scores are combined, then blended with heuristic signals using adaptive weights. Final scores are inverted so 100 = most human-like code.
Vibe Indicators
Specific patterns detected that suggest AI-generated code, such as:
- Repetitive or templated code structures
- Lack of domain-specific optimizations
- Generic naming and comments
- Over-engineered or under-engineered solutions
- Known AI hallucination patterns (misspelled APIs, nonexistent libraries)
Assessment
A qualitative assessment of the code's "vibe", describing the balance between human craftsmanship and AI assistance in the repository.
Context
Important context about the findings, noting that AI-assisted coding is not inherently negative - the analysis focuses on whether the code demonstrates proper understanding and Intentional design.