agentleFS
emaraschioemaraschio/cursor-commands/.cursor/skill-contracts/pathfinder/SKILL.md

pathfinder

Skill9 starsChanged 3 months agoMITView on GitHub

Map the fog of war before building. Given a project goal and known context, separate decisions already fixed from open decision frontiers and fog-of-war unknowns, tag each unknown with a next move (research, prototype, ask an expert, user test, or delegate), and lay out parallel work tracks plus the next three actions. Plan-only, no execution in the same turn. Use for pathfinder, decision mapping, fog of war, or planning a greenfield or messy project before the next step feels obvious but undercooked.

10 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use oh-my-issues, what-the and 8 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.
  • tuliosalustiano27Skill

    oh-my-issues

    Cluster a GitHub issue backlog by root cause into a small set of plan-master issues, redirect children with a standardized comment, and bundle architectural-fix PRs that close clusters atomically. Use when an issue tracker has accumulated dozens of reports that share underlying defects, when asked to triage / consolidate / cluster / dedupe issues, when asked to build a plan series or roadmap from open issues, or when routing a new incoming bug into an existing plan.

    Also in 3 projects that use this

  • tuliosalustiano27Skill

    what-the

    What the? Use when the user wants a plain-English breakdown of something technical — the who, what, where, why, and when.

    Also in 3 projects that use this

  • tunnckoCoreSkill

    how-it-works

    Use for 'how does X work', code walkthroughs before changing something, and placement / ownership / layering questions ('where should this live', 'which package owns this', 'is this the right layer'). Explains subsystem architecture, runtime flow, onboarding mental models. Can critique architecture. Use why for motivation.

    Also in 4 projects that use this

  • magnusrodsethSkill

    learn-codebase

    Understand a codebase by reading its actual source, on GitHub or on disk: how a pattern is really implemented, an org's conventions, how two things are wired. Use for \"how does <repo> do X\". For published API docs prefer find-docs.

    Also in 5 projects that use this

  • dqtx760Skill

    timeline-report

    Generate a "Journey Into [Project]" narrative report analyzing a project's entire development history from claude-mem's timeline. Use when asked for a timeline report, project history analysis, development journey, or full project report.

    Also in 3 projects that use this

  • barrelcSkill

    mem-search

    Search kimi-mneme's persistent cross-session memory database. Use when user asks "did we already solve this?", "how did we do X last time?", "what did we do yesterday?", or needs work from previous sessions.

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 8 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run phases in order. Do not deliver the map until Phase 3.

    line 25
  2. Distinctive:

    If the goal is missing, ask one focused question before proceeding.

    line 30
  3. Very specific:

    Ask structured clarifying questions (use AskQuestion when available) to separate what is fixed from what is unknown.

    line 35
  4. Distinctive:

    Put a decision under "already fixed" only when the context states it.

    line 48
  5. Very specific:

    If the host workspace has a docs/ directory, offer to save it as docs/decision-maps/<kebab-slug>.md.

    line 56
  6. Distinctive:

    Use this structure for the final deliverable:

    line 61
  7. Distinctive:

    Do not execute the project, scaffold code, or run destructive commands in the same turn as delivering the map unless the user explicitly …

    line 89
  8. Distinctive:

    Do not invent facts to fill a section.

    line 91
  9. Distinctive:

    Never imply a native Cursor product feature.

    line 92
  10. Very specific:

    scoped-audit: read-heavy cataloging of an existing surface with verify-before-report.

    line 98
  11. Distinctive:

    Deliver the map without building it: Stop at the map (plan-only) unless the user explicitly says to skip planning and build now.

    line 104

“Common” is measured: kept by at least 6 in 10 of the 10 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

Pathfinder

Role

You act as a senior project planner. The user gives a project goal and whatever context they have; you return a fog map that separates what is already settled from what is still unknown, and turns each unknown into a concrete next move. This skill is plan-only: it maps the terrain, it does not build the project in the same turn.

When to use

Use before a greenfield project, a messy or under-specified request, or any workflow where the next step feels obvious but is undercooked. The point is to map the fog of war first (the decisions, research gaps, and unknowns that could derail the work later) so building starts on solid ground. For a six-part agent delegation contract, use define-agent-goal. For a runnable prompt, use structure-prompt.

Workflow

Run phases in order. Do not deliver the map until Phase 3. Do not execute the project, scaffold code, or run destructive commands when delivering the map unless the user explicitly says to skip planning and build now.

Phase 0: Intake

  1. Extract the project goal (the outcome the user wants) and the known context (requirements, constraints, stakeholders, links, notes) from the message.
  2. If the goal is missing, ask one focused question before proceeding.
  3. Produce a one-sentence restatement of what the project is trying to achieve.

Phase 1: Discovery

Ask structured clarifying questions (use AskQuestion when available) to separate what is fixed from what is unknown. Cover only gaps the context leaves open:

  • What is genuinely non-negotiable versus assumed?
  • Which choices are still open and materially shape the project?
  • What unknowns could change the whole plan if the answer surprises you?
  • Who owns the decisions, and what is the deadline or budget pressure?

Aim for 4 to 6 high-signal questions. Skip anything the user already answered.

Phase 2: Draft the map

Fill the map template below. Keep it to about one page: prefer tables and bullets over prose. While drafting:

  • Put a decision under "already fixed" only when the context states it. An assumption is not a fixed decision; it belongs in frontiers or fog.
  • Give every fog-of-war unknown exactly one next move label: research, prototype, ask an expert, user test, or delegate.
  • Make the parallel work plan genuinely parallel: 3 to 5 tracks that different people or agents could run at the same time.
  • End with exactly three concrete actions the user can take today.

Phase 3: Deliver

  1. Post the fog map in chat using the template headings (sections 1 to 6).
  2. If the host workspace has a docs/ directory, offer to save it as docs/decision-maps/<kebab-slug>.md. Write the file only after the user confirms.
  3. Suggest the follow-up: pick a track and run it, or turn a track into a define-agent-goal for autonomous work.

Map template

Use this structure for the final deliverable:

# Fog map: <short title>

## 1. Decisions already fixed
Non-negotiables stated in the context. One line each.

## 2. Decision frontiers
Open choices that still shape the project, with the options in play.

## 3. Fog-of-war questions
Unknowns that could change the plan if the answer surprises you.

## 4. Next move per unknown
Each unknown from section 3, tagged: research | prototype | ask an expert | user test | delegate.

## 5. Parallel work plan
3 to 5 tracks that can run at the same time, with the owner or agent for each.

## 6. Next three actions
Three concrete things to do today.

Populate every section with concrete content. Leave a section explicitly empty only when the context genuinely has nothing for it, and say so.

Safety

  • Do not execute the project, scaffold code, or run destructive commands in the same turn as delivering the map unless the user explicitly says to skip planning and build now.
  • Redact secrets, tokens, credentials, PII, and PHI in both the context you echo and the map you produce.
  • Do not invent facts to fill a section. An unknown stays in the fog with a next move; it does not get promoted to a fixed decision.
  • Never imply a native Cursor product feature; this is a portable planning document for Cursor agents.

Distinction from other commands

  • define-agent-goal: a six-part delegation contract (outcome, verification, constraints, boundaries, iteration, stopping) for one task an agent will run. Pathfinder maps project-level uncertainty before any single task is scoped.
  • structure-prompt: produces a runnable prompt. Pathfinder produces a planning artifact, not a prompt.
  • scoped-audit: read-heavy cataloging of an existing surface with verify-before-report. Pathfinder is forward-looking uncertainty mapping, not an inventory of what already exists.

Guardrails

  • Separate fixed from unknown. Mark a decision fixed only when the context states it; An assumption is not a fixed decision, so keep assumptions in frontiers or fog.
  • Tag every unknown with a next move. Label each unknown with exactly one next move (research, prototype, ask an expert, user test, or delegate).
  • Deliver the map without building it. Stop at the map (plan-only) unless the user explicitly says to skip planning and build now.
  • Parallel tracks and three actions. Deliver 3 to 5 parallel tracks plus exactly three concrete actions today.
  • Docs save only after confirm. Offer the path and write only after the user confirms.
  • Do not claim a native product feature. Present this as a portable planning document for Cursor agents.

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.