agentleFS
CloudAI-XCloudAI-X/opencode-workflow/skills/analyzing-projects/SKILL.md

analyzing-projects

Skill275 starsChanged 10 months agoMITView on GitHub

Guides systematic project analysis, codebase exploration, and architecture pattern recognition. Use when understanding new codebases, onboarding to projects, or investigating system structure.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. CloudAI-X/claude-workflow★ 1.4ksame name
    2. CloudAI-X/claude-workflow-v2★ 1.4ksame name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository6 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Start by identifying how the application launches:

    line 52
  2. Distinctive:

    Check for related tests

    line 200
  3. Distinctive:

    Create a mental map of key flows

    line 213
  4. Distinctive:

    When exploring a large codebase, parallelize by module:

    line 220
  5. Distinctive:

    Analysis Paralysis: - Don't try to understand everything before starting

    line 274
  6. Distinctive:

    Surface-Only: - Don't stop at directory structure

    line 277
  7. Distinctive:

    Assuming Patterns: - Verify patterns, don't assume from naming

    line 278

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Analyzing Projects

Systematic approaches to understanding codebases, identifying patterns, and mapping system architecture.

When to Use This Skill

  • Onboarding to a new codebase
  • Understanding unfamiliar code before making changes
  • Investigating how features are implemented
  • Mapping dependencies between modules
  • Identifying architectural patterns in use

Core Analysis Framework

The 5-Layer Discovery Process

Layer 1: Surface Scan
  └─ Entry points, config files, directory structure

Layer 2: Dependency Mapping
  └─ Package managers, imports, module relationships

Layer 3: Architecture Recognition
  └─ Patterns (MVC, hexagonal, microservices)

Layer 4: Flow Tracing
  └─ Request paths, data flow, state management

Layer 5: Quality Assessment
  └─ Test coverage, code health, technical debt

Phase 1: Surface Scan

Entry Point Discovery

Start by identifying how the application launches:

  1. Look for standard entry files:
    • main.*, index.*, app.*, server.*
    • cmd/ directory (Go)
    • src/main/ (Java)
    • bin/ scripts
  2. Check configuration files:
    • package.json (scripts.start, main)
    • Makefile, Taskfile
    • Docker/Compose files
    • CI/CD configs (.github/workflows/)
  3. Map directory structure:
    Quick heuristics:
    ├── src/           → Source code
    ├── lib/           → Internal libraries
    ├── pkg/           → Public packages (Go)
    ├── internal/      → Private packages (Go)
    ├── tests/         → Test files
    ├── docs/          → Documentation
    ├── scripts/       → Build/deploy scripts
    └── config/        → Configuration

Initial Questions to Answer

  • What language(s) and framework(s)?
  • What's the build system?
  • How is the app deployed?
  • Where are the main entry points?

Phase 2: Dependency Mapping

Package Manager Analysis

FileEcosystemKey Sections
package.jsonNode.jsdependencies, devDependencies
requirements.txt / pyproject.tomlPythondirect dependencies
go.modGorequire blocks
Cargo.tomlRustdependencies
pom.xml / build.gradleJavadependencies

Internal Module Relationships

  1. Trace imports from entry points
  2. Build a mental model of layers:
    Presentation Layer (routes, controllers, views)
          ↓
    Application Layer (services, use cases)
          ↓
    Domain Layer (entities, business logic)
          ↓
    Infrastructure Layer (database, external APIs)
  3. Identify shared utilities imported across modules

Phase 3: Architecture Recognition

Common Patterns to Identify

PatternIndicatorsTypical Structure
MVCcontrollers/, models/, views/Clear separation of concerns
Hexagonalports/, adapters/, domain/Dependency inversion
Microservicesservices/, docker-composeIndependent deployable units
MonolithSingle large app, shared DBEverything in one deployment
Serverlessfunctions/, handlers/Event-driven, stateless

Architecture Questions

  • How are concerns separated?
  • Where does business logic live?
  • How are external dependencies abstracted?
  • What's the data access pattern?

Phase 4: Flow Tracing

Request Path Analysis

For web applications, trace a request end-to-end:

HTTP Request
    ↓
Router/Routes (maps URL → handler)
    ↓
Middleware (auth, logging, validation)
    ↓
Controller/Handler (orchestrates)
    ↓
Service/Use Case (business logic)
    ↓
Repository/DAO (data access)
    ↓
Database/External API

State Management Analysis

For frontend applications:

  • Where is state stored? (Redux, Zustand, Context)
  • How does data flow? (unidirectional, bidirectional)
  • What triggers re-renders?

Phase 5: Quality Assessment

Code Health Indicators

IndicatorGood SignWarning Sign
Test coverage>70% coverageNo tests, or tests ignored
DependenciesRecent versionsMajor versions behind
DocumentationREADME updatedStale or missing docs
Build timeUnder 2 minutesOver 10 minutes
Error handlingConsistent patternsSwallowed exceptions

Technical Debt Markers

  • TODO/FIXME comments
  • Disabled tests
  • Large functions (>50 lines)
  • Deep nesting (>4 levels)
  • Duplicated code blocks
  • Hardcoded values

Analysis Strategies by Goal

Goal: Make a Bug Fix

  1. Find where the bug manifests
  2. Trace back to the root cause
  3. Understand the affected area only
  4. Check for related tests

Goal: Add a New Feature

  1. Find similar existing features
  2. Understand the patterns they use
  3. Map the modules that need changes
  4. Identify integration points

Goal: Full Codebase Understanding

  1. Complete all 5 phases
  2. Document architecture decisions
  3. Create a mental map of key flows
  4. Identify ownership areas

Parallel Analysis Pattern

When exploring a large codebase, parallelize by module:

Spawn subagents for each major area:
├─ Subagent 1: Analyze src/auth (authentication module)
├─ Subagent 2: Analyze src/api (API layer)
├─ Subagent 3: Analyze src/db (data layer)
├─ Subagent 4: Analyze src/ui (frontend)
└─ Subagent 5: Analyze tests/ (test patterns)

Synthesize findings into unified architecture view.

Output Templates

Quick Architecture Summary

## Project Overview
- **Language**: [Primary language]
- **Framework**: [Main framework]
- **Architecture**: [Pattern identified]
- **Entry Point**: [Main file]

## Key Modules
| Module | Responsibility | Key Files |
|--------|----------------|-----------|
| [Name] | [What it does] | [Files]   |

## Data Flow
[Request lifecycle diagram]

## Notable Patterns
- [Pattern 1]: [Where/how used]
- [Pattern 2]: [Where/how used]

Onboarding Checklist

## Getting Started
- [ ] Clone and install dependencies
- [ ] Run the app locally
- [ ] Run the test suite
- [ ] Trace one request end-to-end
- [ ] Find where [core feature] is implemented

Anti-Patterns to Avoid

  1. Analysis Paralysis - Don't try to understand everything before starting
  2. Ignoring Tests - Tests often document expected behavior
  3. Skipping Config - Configuration reveals deployment context
  4. Surface-Only - Don't stop at directory structure
  5. Assuming Patterns - Verify patterns, don't assume from naming

Quick Reference

SURFACE SCAN:
  entry points → config files → directory structure

DEPENDENCY MAP:
  package manager → import tracing → layer identification

ARCHITECTURE:
  pattern recognition → separation of concerns → abstractions

FLOW TRACING:
  request path → data flow → state management

QUALITY CHECK:
  test coverage → code health → technical debt

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.