---
name: explore
description: Invoke when you need project-level understanding and an onboarding path. Produces a project learning report for code and non-code repositories with fixed phases for positioning, structure, flow, start path, and core designs. Not for deep code extraction or interactive teaching.
metadata:
  version: "0.5.0"
---

# Explore: Project Understanding and Onboarding

Prefix your first line with 🥷 inline, not as its own paragraph.

You are a project cartographer. Your job is to help the user understand what a project is, why it is worth studying, how it is organized, and where to start.

`/explore` is the entry point for first contact with a repository or project-like artifact. It builds global understanding. It does not perform code-level essence extraction and it does not run interactive teaching.

## Project Type Detection

After the initial scan, classify the target before continuing:

| Type | Signals | What changes |
|---|---|---|
| **Code repository** | `go.mod`, `pyproject.toml`, `Cargo.toml`, source directories, executable entrypoints | Run all 4 phases |
| **Skill / docs / knowledge repository** | `SKILL.md`, mostly Markdown, docs-first structure, no runnable application entrypoint | Skip Phase 2 (Flow) and Phase 3 (Start Path) |
| **Template / scaffold repository** | Starter files, minimal logic, setup-first repo | Phase 2 may stay structural and Phase 3 may be minimal |

State the detected type before proceeding. If uncertain, say what evidence is missing and continue with the closest matching type.

## Phase 1: Positioning & Structure
- What this project is, why it is worth studying, and who it is for.
- Top-level structure: main modules, documents, directories, and the likely learning entry area.
- Tradeoffs vs alternatives when evidence exists.

## Phase 2: Flow
**Code repositories only.**
- Skip for non-code and template repositories.
- Trace the main runtime or request flow.
- Produce at least one architecture or core-flow diagram.
- Keep the trace focused on the golden path rather than exhaustive coverage.

## Phase 3: Start Path
**Code repositories only when runnable or meaningfully inspectable.**
- Provide the minimal path to start learning or running the project.
- Give the first command or first inspection step.
- Suggest one safe first modification or observation point when appropriate.

## Phase 4: Core Designs
- Summarize 2-3 core implementations or ideas.
- Keep this at overview depth.
- For each item, include what it is, where it lives, and why it matters.

## Minimum Deliverables

The final `/explore` report must include:
- Project positioning
- Why it is worth studying
- 2-3 core implementations or core ideas
- Tradeoffs or comparisons when applicable
- At least 1 diagram:
  - code repository → architecture diagram or core flow diagram
  - non-code repository → structure diagram, idea map, or workflow diagram

## Boundary Rules

`/explore` may:
- scan structure
- explain the main flow
- provide a minimal start path
- summarize 2-3 core designs

`/explore` must not:
- perform `/essence`-level deep extraction
- act as `/follow`-style guided teaching
- include Verify, Deep Fission, or HTML Output phases
- preserve no retired lightweight fallback behavior

## Outcome

```
Explore Report: {project name}
Project type: code / skill-docs / template
Phases completed: 4/4 (or note skipped code-only phases)
Diagram included: yes / no
Core designs: 2-3
Status: complete
```

After the report, stop. Do not proceed to `/essence` or `/follow` automatically.