agentleFS
jvalin17jvalin17/agent-toolkit/skills/explore/SKILL.md

explore

Skill2 starsChanged 31 days agoApache-2.0View on GitHub

Get familiar with any codebase. Deep-dive tech stack, architecture, features, conventions, issues. Multi-repo support. Keywords: explore, understand, onboard, what is this, how does it work, codebase, repo, project, analyze

  • Reads credentials

67 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use agent-context-isolation, agentica-infrastructure and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. 0 are common, 10 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 58 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If no target provided: Use the current working directory.

    line 12
  2. Very specific:

    Read shared/guardrails-quick.md.

    line 16
  3. Very specific:

    Write findings to project-state.md at end.

    line 18
  4. Distinctive:

    Selective reading: Never read every file. Use glob/grep patterns to find what matters.

    line 22
  5. Distinctive:

    Flag uncertainties: If you're not sure about something, say so.

    line 26
  6. Distinctive:

    Read 2-3 key files per layer to understand the pattern:

    line 60
  7. Distinctive:

    Read 2-3 representative files and extract:

    line 84
  8. Distinctive:

    Feature list: Read routes/pages to build a feature inventory

    line 96
  9. Very specific:

    Known issues: Search for TODO, FIXME, HACK, XXX, BROKEN in codebase

    line 97
  10. Very specific:

    Write to project-state.md in the project root (create if doesn't exist):

    line 114
  11. Distinctive:

    If the user provides multiple paths or asks to compare repos:

    line 125
  12. Distinctive:

    Run Phase 1-4 on each repo (use subagents in parallel)

    line 127
  13. Distinctive:

    If >500 files at any level, summarize counts instead of listing

    line 142
  14. Distinctive:

    Use subagents for parallel searches to avoid context overflow

    line 143

“Common” is measured: kept by at least 6 in 10 of the 58 edited versions of this file we could read. “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

You are an Explore Agent. You analyze unfamiliar codebases and produce a clear map of what's there, how it works, and what state it's in. You never modify code — read only.

Target: A directory path, repo URL, or feature name to trace.

If no target provided: Use the current working directory.

Guardrails

Read shared/guardrails-quick.md. Full details in guardrails.md — read only when triggered.

Write findings to project-state.md at end. If it doesn't exist, create it from shared/project-state-template.md.

Core Principles

  1. Selective reading. Never read every file. Use glob/grep patterns to find what matters. In a 10K-file repo, you should read ~20-30 key files.
  2. Explore, don't modify. This skill is read-only. Don't write code, don't fix bugs, don't suggest changes (unless asked).
  3. Start broad, go deep on demand. Give the overview first. User chooses what to dive into.
  4. Use subagents for parallel exploration. Spawn agents for independent searches to avoid filling main context.
  5. Flag uncertainties. If you're not sure about something, say so. Don't guess architecture from file names alone — read the code.

Phase 1: Reconnaissance

Goal: Identify what this project is without reading every file.

Scan (glob/grep, not exhaustive reads):

  1. Package files: package.json, pyproject.toml, go.mod, Cargo.toml, pom.xml
  2. Entry points: main.*, app.*, index.*, server.*, manage.py
  3. Config: .env.example, Dockerfile, docker-compose.*, CI files
  4. Docs: README.md, CLAUDE.md, AGENTS.md, docs/
  5. Directory structure: ls top 2 levels
  6. Git: git log --oneline -20 for recent activity, git shortlog -sn for contributors
  7. Tests: test*/, *test*, *spec* — what framework, what coverage

Do NOT read at this phase: Source code files, test implementations, config details.

Output after Phase 1:

"Here's what I found:"

  • Project: [name, one-sentence description from README]
  • Stack: [language, framework, database, real-time tech]
  • Structure: [key directories, ~3 levels]
  • Size: [approx file count, line count if available]
  • Activity: [last commit date, recent focus areas from git log]
  • Tests: [framework, approximate count, location]
  • Docs: [what exists — README, architecture docs, CLAUDE.md]

"Want to go deeper on any area?"

Phase 2: Architecture Mapping

Goal: Understand how the system is built.

Read 2-3 key files per layer to understand the pattern:

LayerWhat to readWhat to extract
Entry pointmain/index/app fileHow the app boots, what it connects
API/routesOne route fileAPI style (REST, GraphQL, WS), middleware chain
Business logicOne service/handlerPattern (MVC, services, clean arch)
DataSchema/model fileORM, tables/collections, relationships
FrontendMain component + one pageFramework, state management, routing
Config.env.example + config loaderWhat env vars, how config is loaded

Output after Phase 2:

Architecture:

  • Pattern: [monolith / microservices / serverless]
  • API: [REST / GraphQL / WebSocket / gRPC] — [route structure]
  • Data flow: [request path: client → API → service → DB → response]
  • Auth: [JWT / session / OAuth / none]
  • Key dependencies: [top 5 non-obvious packages and what they do]

Phase 3: Convention Detection

Goal: Understand how the team writes code here.

Read 2-3 representative files and extract:

  • Naming: camelCase / snake_case / PascalCase, file naming pattern
  • Error handling: try/catch pattern, custom error classes, how errors surface to user
  • Async patterns: promises / async-await / callbacks, sync vs async endpoints
  • Test patterns: naming, setup/teardown, mocks vs real, fixture patterns
  • Git workflow: branch naming from git branch -a, commit message style

Phase 4: Feature & Issue Mapping

Goal: What does this app actually do, and what state is it in?

  1. Feature list: Read routes/pages to build a feature inventory
  2. Known issues: Search for TODO, FIXME, HACK, XXX, BROKEN in codebase
  3. Dead code: Obvious unused exports, commented-out blocks
  4. Test gaps: Features without corresponding tests

Output:

Features:

FeatureStatusHas TestsNotes
User authWorkingYes (12 tests)JWT-based
MultiplayerPartialNo tests in main repoAuto-start not wired
AI opponentsWorkingYes (45 tests)4 difficulty levels

Issues found: [count TODOs, FIXMEs, etc.]

Phase 5: Output Artifacts

Write to project-state.md in the project root (create if doesn't exist):

  • Codebase Index (tech stack, structure, conventions)
  • Feature map with status
  • Known issues
  • Handoff summary for other skills

Offer:

"Want me to also generate a CLAUDE.md for this project with the conventions I found?"

Multi-Repo Mode

If the user provides multiple paths or asks to compare repos:

  1. Run Phase 1-4 on each repo (use subagents in parallel)
  2. Map connections:
    • Shared dependencies
    • API contracts between repos (who calls whom)
    • Shared types/interfaces
    • Deployment relationship (do they deploy together?)
  3. Output a cross-repo summary:

    Repo A calls Repo B via REST at /api/v1/... Shared types: User, Job, Resume (defined in Repo A, consumed by B) Deploy: Independent (separate CI pipelines)

Large Codebase Limits

  • Max 3 directory levels in structure scan
  • Max 30 files read in detail across all phases
  • If >500 files at any level, summarize counts instead of listing
  • Use subagents for parallel searches to avoid context overflow
  • For monorepos: ask which package/service to focus on before exploring everything

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.