agentleFS
rikilamadridrikilamadrid/pathfinder/skills/whereami/SKILL.md

whereami

Skill1 starsChanged 43 days agoMITView on GitHub

Report a compact read-only snapshot of the current Pathfinder work session.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 6 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    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:

    Use it when a session resumes, after a long gap, or before deciding the next action.

    line 10
  2. Very specific:

    Read context/current-ticket.md if it exists.

    line 24
  3. Very specific:

    If the file is missing or still holds template placeholders, report none.

    line 27
  4. Distinctive:

    Add at most one line after it, and only when step 5 found drift:

    line 49
  5. Distinctive:

    Read only. No writes, no commits, no git command that mutates anything.

    line 59
  6. Very specific:

    Read at most two files: context/execution-mode.md and context/current-ticket.md.

    line 60
  7. Distinctive:

    Do not open the ticket, the feature spec, history, roadmap, or source.

    line 62
  8. Distinctive:

    Do not offer to fix drift, update state, or start the next action.

    line 65
  9. Distinctive:

    Do not do this:

    line 84

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Where Am I

Answer one question: what is this session working on right now?

Use it when a session resumes, after a long gap, or before deciding the next action. It reports state. It never changes it.

Process

  1. Role: report an explicit /role override when one is active; otherwise report none. Lifecycle role assumptions apply only to their own invocation, so a previous ticket or planning action does not persist a role for whereami. Roles are never written to disk. Do not infer one from the current ticket or search roles/.
  2. Mode: read context/execution-mode.md if it exists and take the value from its marker line, as skills/ticket/SKILL.md §Execution mode defines it. Report human-in-the-loop when the file is missing, and invalid when the file exists without a valid marker. Do not infer a mode from anything else.
  3. Read context/current-ticket.md if it exists. Take Ticket, Feature, and Next from it verbatim. The ticket key and the Feature number are the ones recorded there, from their filenames. If the file is missing or still holds template placeholders, report none.
  4. Run git status --short --branch once. Report the branch/ref, and clean or the count of changed paths.
  5. Compare the Git section of context/current-ticket.md with step 4. Report a drift line only if the recorded branch differs from the real one.
  6. Context telemetry: report it only if this harness exposes it. Otherwise unavailable. Do not estimate.

Output

Exactly this shape, one line each:

Role:    <role | none>
Mode:    <human-in-the-loop | orchestrator | invalid>
Feature: <## — name | none>
Ticket:  <key and name | none>
Git:     <branch/ref> — <clean | N changed>
Context: <telemetry | unavailable>
Next:    <single next action | none>

Add at most one line after it, and only when step 5 found drift:

Drift:   current-ticket.md records <branch>, working tree is on <branch>

Then stop.

Rules

  • Read only. No writes, no commits, no git command that mutates anything.
  • Read at most two files: context/execution-mode.md and context/current-ticket.md.
  • Do not open the ticket, the feature spec, history, roadmap, or source.
  • Report none, unavailable, or invalid instead of inferring a missing value.
  • Do not offer to fix drift, update state, or start the next action. The human decides what happens after the snapshot.

Example

/whereami after resuming mid-feature:

Role:    developer
Mode:    human-in-the-loop
Feature: 12 — export saved searches
Ticket:  12.2 — CSV writer
Git:     feature/12-export-saved-searches — 3 changed
Context: unavailable
Next:    Verify the CSV writer against the acceptance criteria

Anti-example

Do not do this:

Role:    developer (inferred from recent commits)
Mode:    orchestrator (the project has several branches)
Feature: 12 — export saved searches
Ticket:  12.3 — probably the download endpoint
Git:     feature/12-export-saved-searches — 3 changed
Context: ~60% used
Next:    I can update current-ticket.md and start ticket 12.3 — want me to?

It guesses the role from history, guesses the mode from the branch list, invents a ticket that was never written, estimates telemetry it cannot see, and turns a status report into a proposal to write state.

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.