Map a codebase into feature-grouped flowcharts, identify duplicated concerns across features, and propose a unified architecture. Use when asked to "find the ideal path," unify duplicated systems, or audit architecture before a refactor. Emits a proposed unified flowchart plus
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/pathfinder
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Map a codebase into feature-grouped flowcharts, identify duplicated concerns across features, and propose a unified architecture. Use when asked to "find the ideal path," unify duplicated systems, or audit architecture before a refactor. Emits a proposed unified flowchart plus
📊 Stats
Stars88,332
Forks7,667
LanguageJavaScript
LicenseApache-2.0
📦 Ships with claude-mem
</> SKILL.md
pathfinder.SKILL.md
---name: pathfinder
description: Map a codebase into feature-grouped flowcharts, identify duplicated concerns across features, and propose a unified architecture. Use when asked to "find the ideal path," unify duplicated systems, or audit architecture before a refactor. Emits a proposed unified flowchart plus per-system /make-plan prompts.
---# Pathfinder
You are an ORCHESTRATOR. Map the codebase into feature-grouped flowcharts, identify duplicated concerns, propose the simplest unified architecture, and hand off per-system plans to `/make-plan`.
You do not write implementation code. You produce diagrams, a duplication report, a proposed unified flowchart, and handoff prompts.
## Delegation Model
Use subagents for *discovery and extraction* (file reading, flow tracing, grep, diagramming). Keep *synthesis* (deciding feature boundaries, picking unification strategies, final flowchart) with the orchestrator. Reject subagent reports that lack source citations and redeploy.
### Subagent Reporting Contract (MANDATORY)
Each subagent response must include:
1. Sources consulted — exact file paths and line ranges read
2. Concrete findings — exact function names, call sites, data flow
3. Mermaid diagram(s) with nodes labeled by `file:line`
4. Confidence note + known gaps
## Output Artifacts
All artifacts go in `PATHFINDER-<YYYY-MM-DD>/` at repo root:
- `00-features.md` — feature inventory with boundaries
- `04-handoff-prompts.md` — copy-pasteable `/make-plan` prompts per unified system
## Phases
### Phase 0: Feature Discovery (ALWAYS FIRST)
Deploy ONE "Feature Discovery" subagent to:
1. Walk the source tree (not built artifacts) and read top-level README / CLAUDE.md
2. Propose feature boundaries based on directory structure, import graph, and naming
3. Return a flat list of features with: name, entry points (file:line), core files, brief purpose
Orchestrator reviews the proposal, adjusts boundaries if needed, writes `00-features.md`. Do NOT fan out until feature boundaries are approved.
### Phase 1: Per-Feature Flowcharts (FAN OUT)
Deploy ONE "Flowchart" subagent per feature in parallel. Each receives only its feature's scope. Each must:
1. Trace the feature's primary happy path from entry point to terminal state
2. Identify side effects (DB writes, HTTP calls, file I/O, process spawns)
3. Note error and fallback branches but do not let them dominate the diagram
4. Produce a Mermaid `flowchart TD` with every node labeled `Name<br/>file:line`
5. List external dependencies (other features it calls into) at the bottom
Orchestrator writes each flowchart to `01-flowcharts/<feature>.md`. Reject any diagram missing `file:line` labels.
### Phase 2: Duplication Hunt
Deploy TWO subagents in parallel:
**"Within-Feature Duplication"** subagent:
- For each feature, find repeated code/logic patterns inside the feature only
- Report only duplications worth consolidating (ignore trivial repetition)
**"Cross-Feature Duplication"** subagent:
- Compare flowcharts across features for concerns that appear in multiple places
- Examples of what to look for: multiple capture paths, parallel queue implementations, duplicated storage/migration code, repeated agent scaffolding, parallel parsing layers
- For each duplication, report: (a) the concern, (b) every location with `file:line`, (c) why they diverged, (d) whether the divergence is legitimate specialization or accidental
Orchestrator synthesizes both into `02-duplication-report.md`. Every duplication claim must cite ≥2 `file:line` locations.
### Phase 3: Unified Proposal (ORCHESTRATOR)
The orchestrator writes `03-unified-proposal.md` itself — do not delegate synthesis.
For each duplicated concern from Phase 2 that is NOT legitimate specialization:
1. Propose the simplest unified design (one path, one store, one handler — whatever applies)
2. Name the consolidated component and its single entry point
3. Show what each old call site becomes
4. Call out any loss of capability and whether it's acceptable
End the document with ONE combined Mermaid flowchart showing the proposed unified system. Nodes still labeled with target `file:line` (new or existing) where knowable.
**Anti-patterns to reject in your own proposal:**
- Adding a new abstraction layer "for flexibility"
- Keeping both old paths behind a feature flag
- Introducing a registry/factory when a switch statement suffices
- Preserving divergent behavior "just in case"
### Phase 4: Per-System Handoff Prompts
For each unified system in the proposal, write a ready-to-run `/make-plan` prompt to `04-handoff-prompts.md`. Each prompt must:
1. State the target unified component and its single entry point
2. List the exact call sites to rewrite (from Phase 2 evidence)
3. Cite the relevant flowchart file from `01-flowcharts/`
4. Include anti-pattern guards specific to this system
Format each as a fenced code block the user can copy directly into `/make-plan`.
## Key Principles
- **Evidence over intuition** — every diagram node and duplication claim cites `file:line`
- **Current state before ideal state** — Phases 0–2 describe what IS; Phase 3 describes what SHOULD BE
- **Simplest unification wins** — prefer deletion over abstraction; prefer one path over configurable paths
- **Specialization is not duplication** — two components serving different trust models or data sources are legitimate even if their code looks similar
- **Handoff, don't implement** — Pathfinder ends at plan prompts; `/make-plan` and `/do` take it from there
## Failure Modes to Prevent
- Drawing flowcharts from memory instead of source — redeploy subagent with grep evidence requirement
