repository-analyzer

name	repository_analyzer
description	Analyze a code repository inside /workspace/repo and generate a comprehensive markdown architectural report.

Repository Analyzer Skill

Use this skill to structure the final Markdown architectural report for a repository.

Report Structure Requirements

Your report MUST include the following structured sections:

1. Executive Summary

   • High-level purpose of the application, problem solved, target audience, and core tech stack.

2. System Architecture & Component Overview

   • Architectural pattern (Microservices, Monolithic, MVC, Event-Driven, Serverless, etc.).
   • Core sub-systems and how they interact.
   • Mandatory Diagram: Include a clear, descriptive Mermaid architecture diagram (enclosed in a ```mermaid code block, using graph TD or graph LR) to visually represent the components and their relationships.

3. Codebase Structure & Directory Map

   • Detailed walkthrough of top-level folders and what each module/package is responsible for.
   • Formatting Rule: When drawing directory structures, do NOT use Unicode box-drawing characters (such as ├──, └──, │, ─). Instead, use standard ASCII characters (such as |--, +--, |) or standard markdown nested lists.

4. Data Flow & Key Execution Paths

   • Step-by-step trace of key workflows (e.g., request handling, data ingestion, authentication, pipeline execution).
   • Mandatory Flow Diagram: Represent the execution flow of these key workflows visually using a Mermaid sequence diagram (```mermaid sequenceDiagram ...) or flowchart. Do NOT use ASCII-art text sequences.

5. Key Classes, Interfaces, & Data Models

   • Explanation of crucial entities, data structures, and APIs found in the source code.
   • Mandatory Database Schema/Model Diagram: Represent schemas, models, and relationships visually using a Mermaid ER diagram (```mermaid erDiagram ...) or Mermaid Class Diagram (```mermaid classDiagram ...). If displaying raw attributes, you may also use standard Markdown tables.

6. Dependencies, Configuration & Deployment

   • External dependencies, environment variables (.env configurations), database dependencies, and build/deploy instructions (Dockerfile, CI/CD workflows).

7. Security, Performance & Architectural Evaluation

   • Strengths of the architecture, potential bottlenecks, and recommended future enhancements.

Formatting Constraints (CRITICAL)

• NO ASCII-ART DIAGRAMS: Do NOT draw database tables, sequence flows, or block diagrams using raw ASCII-art (such as box-drawing borders +----+, |, or text arrows -->). Always use standard Markdown text, Markdown tables, or Mermaid code blocks so they compile into professional graphical visuals.
• MERMAID QUOTING STYLE: In all Mermaid diagrams (flowcharts, sequence diagrams, class/ER diagrams), you MUST enclose node labels and subgraph titles in double quotes if they contain spaces, slashes (/), parentheses, or special characters (like &), for example: subgraph data_layer ["Data & Business Logic Layer (Model)"] or Router["Flask Router / View Controllers"]. Failing to do so causes compilation failures.
• MERMAID SEQUENCE LIFELINES: When generating sequence diagrams (sequenceDiagram), only use actor or participant to declare lifelines. Do NOT use database or other shapes as participant types, as they are not supported by all Mermaid compilers. If depicting a database, use a standard participant: e.g. participant DB as PostgreSQL Database.