You join a new team. There are eight repos, four languages, and a wiki page last updated in 2023. You need to understand how everything fits together before you can ship anything useful.

I kept solving this problem the same way: clone repos, read configs, sketch boxes-and-arrows on paper, repeat. So I turned the process into a Claude Code skill called /explore.

What is a Claude Code skill?

A skill is a markdown file (SKILL.md) that lives under ~/.claude/skills/<name>/. When you type /<name> in Claude Code, the tool reads that file and executes the instructions as a structured prompt. Think of it as a reusable recipe that Claude follows step by step.

The skill file has a small YAML frontmatter block and then plain markdown instructions:

---
name: explore
description: Explore an unfamiliar codebase...
context: fork
---

Perform a full architecture exploration of the current project...

The context: fork setting is important — it tells Claude Code to run this skill in a forked context so the exploration doesn’t clutter your main conversation.

What /explore does

The skill runs in four phases.

Phase 1: Setup. It creates an architecture-temp/ directory in your project root and adds it to .gitignore. Everything it produces stays out of your git history.

Phase 2: Discover related repos. It detects the GitHub org from your current repo, then uses gh repo list to enumerate every repo in the org. It reads your project’s dependencies, imports, docker-compose files, and config to figure out which of those repos are directly related. It clones the ones it needs into architecture-temp/repos/.

gh repo view --json owner --jq '.owner.login'   # detect org
gh repo list $ORG --limit 200 --json name,description

Phase 3: Analyze. For each repo (yours plus the cloned ones), it records an inventory: runtime versions, languages, key components, databases, external services, and entry points. When it hits a stack it needs help with, it delegates to a specialist agent — a .NET agent for C# projects, a Node agent for TypeScript, and so on.

Phase 4: Produce deliverables. It writes four markdown files into architecture-temp/:

File Contents
overview.md What the system does, how repos relate, tech stack summary table
architecture.md High-level Mermaid diagram — services, data stores, external deps, protocols
components.md Per-repo Mermaid diagrams showing internal structure
data-flow.md Sequence diagrams for the 2-3 most critical flows

Design decisions worth noting

Gitignored output. The architecture-temp/ folder is disposable. Re-run the skill whenever the system changes and you get a fresh picture. No stale documentation committed to the repo.

Dynamic org detection. The skill doesn’t hardcode an org name. It reads the GitHub owner from whatever repo you’re standing in, so it works across different organizations without editing the skill file.

Agent delegation. Rather than trying to be an expert in every stack, the skill invokes Claude Code’s specialist agents when it encounters unfamiliar frameworks. The explore skill orchestrates; the specialists analyze.

Forked context. The context: fork setting keeps the exploration — which can involve reading hundreds of files across multiple repos — from consuming the token budget in your main conversation. You get the deliverables without the noise.

Running it

From any repo that belongs to a GitHub org:

/explore

That’s it. Wait for the summary, then open architecture-temp/overview.md to start reading.

The full skill

Here’s the complete SKILL.md:

---
name: explore
description: Explore an unfamiliar codebase. Creates a temporary
  architecture-temp/ folder (gitignored), identifies related repos
  in the same GitHub org, clones them locally, then produces
  architecture diagrams, component maps, and an overview doc using
  Mermaid and Markdown.
disable-model-invocation: false
context: fork
---

Perform a full architecture exploration of the current project and
its related repositories within the same GitHub organization.

## Setup

1. Create `architecture-temp/` in the current working directory
   if it doesn't exist.
2. Add `architecture-temp/` to `.gitignore` if not already present
   (append, don't overwrite).
3. Detect the GitHub org by running
   `gh repo view --json owner --jq '.owner.login'` in the current
   project. Store the result as `ORG`.

## Identify related repositories

4. Use `gh repo list $ORG --limit 200 --json name,description`
   to list repos in the org.
5. Read the current project's name, dependencies, and any service
   references (imports, config files, docker-compose, README) to
   infer which other repos in the org are directly related.
6. For each related repo that isn't already cloned locally
   alongside the current project:
   - Clone it into `architecture-temp/repos/<repo-name>` using
     `gh repo clone $ORG/<repo-name>
      architecture-temp/repos/<repo-name>`

## Analyze each repository (current + cloned)

For each repo, identify and record in
`architecture-temp/inventory.md`:

- **Runtime versions**: language version, framework version,
  runtime (Node, .NET, JVM, etc.)
- **Languages used**: primary + any secondary
- **Key components**: services, workers, schedulers, CLI tools
- **Databases**: type, ORM/client used
- **External services**: queues, caches, third-party APIs,
  auth providers
- **Entry points**: main executable, API surface, exposed ports

Invoke the appropriate language/framework specialist agents to
help with unfamiliar stacks. Announce each agent before invoking.

## Produce deliverables in `architecture-temp/`

### `overview.md`
- What the system does
- How the repos relate to each other
- Key data flows
- Tech stack summary table
  (repo | language | runtime | framework | database | external deps)

### `architecture.md`
High-level system architecture diagram in Mermaid
(`graph TD` or `C4Context`), showing:
- Services and their relationships
- Data stores
- External dependencies
- Inter-service communication (sync/async, protocol)

### `components.md`
Per-repo component diagrams in Mermaid (`graph TD`), showing
internal structure:
- Major modules/namespaces
- Key classes or services
- Data flow within the repo

### `data-flow.md`
Sequence diagrams (`sequenceDiagram`) for the 2-3 most important
user-facing or system-critical flows you can identify from the code.

## Finish

Print a summary listing:
- Repos analyzed
- Agents invoked
- Files produced in `architecture-temp/`
- Any repos referenced in code but not found in the org
  (may be external dependencies or private)

Try it yourself

The skill file and the rest of my Claude Code configuration live at github.com/sseely/claude-config. Drop the skills/explore/ folder into your own ~/.claude/skills/ directory and you’re set.