agentsclimarketplace

Explore

Skill jvalin17/agent-toolkit/skills/explore

Production-ready skills for AI coding agents. 13 skills, 9 agents, harness hooks & quality gates (signed optional for long sessions). Plan, build, test, debug, ship. Any repo, any language. Claude Code native, universal LLM compatible.

Install
npx -y skills add jvalin17/agent-toolkit --skill explore

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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

SKILL.md

6.1 KB, as published. Nobody here has run it

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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.