Skip to content
skillsafebeta
← Report library
Purpose / Other

Wayfinder Skill Security Audit

What the author says it does (original text)

Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.

Independent security check

Do not install or run it yet

Files checked
2
Risks found
5
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 1
Medium risk

An automatically selected Task ticket may change accounts, access, or data

Source references: 2
What we found

Task tickets explicitly permit service registration, access provisioning, and data movement, and tell the agent to perform such work alone when possible. Because the Skill selects the first frontier ticket when none is named, a user asking only to advance the map may not have separately approved the particular external action.

Why this matters

It could create unwanted accounts, alter access controls, incur charges, or move data to a new location.

Task tickets explicitly include service signup, access provisioning, and moving data, and direct the agent to act alone where possible. Combined with automatic ticket selection, a general request to advance the map could cause account, permission, or data-state changes without operation-specific confirmation. Users can require all Tasks to be HITL and separately approve external-account, access, and data-movement actions.

SKILL.md:80In the instructionsOpen original file
- **Grilling** (HITL): Conversation. The default case. Always call the Skill tool twice, for "grilling" and "domain-modeling".- **Task** (HITL or AFK): Manual work that must happen before a _decision_ can be made: nothing to decide, prototype, or research, but the discussion is blocked until it's done. Signing up for a service so its API can be judged, provisioning access, moving data so its shape can be seen. This is the one type that _does_ rather than decides, and it earns its place by unblocking a decision, not by delivering the destination. The agent drives it alone where it can (AFK); otherwise it hands the human a precise checklist (HITL). Resolved when the work is done; the answer records what was done and any resulting facts (credentials location, new URLs, row counts) later tickets depend on.
Show 1 other places
SKILL.md:120In the instructionsOpen original file
User invokes with a map (URL or number). A ticket is **optional**: without one, you pick the next decision, not the user.1. Load the **map**: the low-res view, not every ticket body.2. Choose the ticket. If the user named one, use it. Otherwise take the first frontier ticket in order. **Claim it**: assign it to yourself before any work.3. Resolve it. **Zoom as needed**: fetch the full body of any related or closed ticket on demand; call the Skill tool for whichever skills the `## Notes` block names. If in doubt, call the Skill tool twice, for "grilling" and "domain-modeling".4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far.
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Medium risk

Credential locations may be published in issue comments

Source references: 2
What we found

Task answers are told to record the “credentials location,” and the general resolution flow posts the answer as a resolution comment. Tracker readers could therefore learn where secret files, vault entries, or environment configuration are kept.

Why this matters

Even without exposing a secret value, its location can help unauthorized readers find sensitive material and reveal internal paths, account naming, or key-management structure.

A Task result may include the location of credentials, while every resolution is posted as an issue comment. The text does not direct publication of credential values, but a path, vault-entry name, or configuration location can still help unintended readers locate sensitive material; exposure depends on tracker visibility. Users can require non-sensitive references only and restrict issue access.

SKILL.md:80In the instructionsOpen original file
- **Grilling** (HITL): Conversation. The default case. Always call the Skill tool twice, for "grilling" and "domain-modeling".- **Task** (HITL or AFK): Manual work that must happen before a _decision_ can be made: nothing to decide, prototype, or research, but the discussion is blocked until it's done. Signing up for a service so its API can be judged, provisioning access, moving data so its shape can be seen. This is the one type that _does_ rather than decides, and it earns its place by unblocking a decision, not by delivering the destination. The agent drives it alone where it can (AFK); otherwise it hands the human a precise checklist (HITL). Resolved when the work is done; the answer records what was done and any resulting facts (credentials location, new URLs, row counts) later tickets depend on.
Show 1 other places
SKILL.md:125In the instructionsOpen original file
3. Resolve it. **Zoom as needed**: fetch the full body of any related or closed ticket on demand; call the Skill tool for whichever skills the `## Notes` block names. If in doubt, call the Skill tool twice, for "grilling" and "domain-modeling".4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far.5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals that a ticket (this one or another) sits beyond the destination, **rule it out of scope** rather than resolving it on the route. If the decision invalidates other parts of the map, update or delete those tickets.
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 1
Medium risk

Charting alone creates research branches and lets subagents write findings

Source references: 2
What we found

Although the Skill says it is planning-only by default, charting starts a subagent for every research ticket and captures findings on a `research/<name>` branch. It does not state that branches must remain local, must not be pushed, or must be cleaned up.

Why this matters

The repository may gain unexpected branches and research files. If pushed, the shared repository can retain this material, potentially including information copied from documentation or knowledge bases.

The planning default is not read-only: charting launches a subagent for every research ticket and records findings on a `research/<name>` branch, changing the repository even when the request is only to chart. It calls the branch throwaway but does not say whether it is pushed or when it is removed, so remote publication cannot be inferred. Users can require local-only branches, no push, and an explicit cleanup policy.

SKILL.md:11In the instructionsOpen original file
## Plan, don't doWayfinder is **planning** by default: each ticket resolves a decision, and the map is done when the way is clear, with nothing left to decide before someone goes and does the thing. The pull to just do the work is usually the signal you've reached the edge of the map and it's time to hand off. An effort can override this in its **Notes**, carrying execution into the map itself, but absent that, produce decisions, not deliverables.
Show 1 other places
SKILL.md:113In the instructionsOpen original file
2. **Map the frontier.** Grill again, **breadth-first** this time: fan out across the whole space rather than deep on any one thread, surfacing the open decisions and the first steps takeable now. **If this surfaces no fog** (the way to the destination is already clear, the whole journey small enough for one session), you don't need a map. Stop and ask the user how they'd like to proceed.3. **Create the map** (label `wayfinder:map`): Destination and Notes filled in, Decisions-so-far empty, the fog sketched into **Not yet specified**.4. **Create the tickets you can specify now** as child issues of the map, then wire blocking edges in a **second pass** (issues need ids before they can reference each other). Wiring sorts them into the frontier and the blocked; everything you can't yet specify stays in the fog: the **Not yet specified** section.5. **Fire the research subagents.** For each `research` ticket you just created, spin up a subagent that calls the Skill tool with "research" to resolve it in parallel, capturing its findings on a throwaway `research/<name>` branch with a context pointer from the ticket.6. Stop: charting is one session's work; it hand-resolves nothing.
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 1
Medium risk

Collaborative issues may be closed, changed, or deleted without per-item confirmation

Source references: 2
What we found

If the user supplies a map without naming a ticket, the Skill chooses the first eligible ticket itself, assigns it, and closes it. It may then update or delete other tickets it judges invalid, while acknowledging that other sessions may edit the tracker concurrently.

Why this matters

This could change ownership and project decision records or remove tickets still in use by collaborators. With concurrent edits, it may act on stale state and overwrite others' work.

When the user supplies only a map, the workflow autonomously selects and claims the first frontier ticket, then closes it after resolution. It may also update or delete other tickets. Because concurrent sessions may edit the tracker, these mutations could conflict with collaborators. Users can require per-item confirmation and concurrency/version checks before closing, deleting, or changing non-current tickets.

SKILL.md:120In the instructionsOpen original file
User invokes with a map (URL or number). A ticket is **optional**: without one, you pick the next decision, not the user.1. Load the **map**: the low-res view, not every ticket body.2. Choose the ticket. If the user named one, use it. Otherwise take the first frontier ticket in order. **Claim it**: assign it to yourself before any work.3. Resolve it. **Zoom as needed**: fetch the full body of any related or closed ticket on demand; call the Skill tool for whichever skills the `## Notes` block names. If in doubt, call the Skill tool twice, for "grilling" and "domain-modeling".4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far.5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals that a ticket (this one or another) sits beyond the destination, **rule it out of scope** rather than resolving it on the route. If the decision invalidates other parts of the map, update or delete those tickets.
Show 1 other places
SKILL.md:128In the instructionsOpen original file
The user may run unblocked tickets in parallel, so expect other sessions to be editing the tracker concurrently.
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.Risks found: 1
High risk

Editable map Notes and ticket text can indirectly drive other Skills

Source references: 3
What we found

The workflow fetches full related-ticket bodies and invokes whichever Skills the Notes name. Maps are issues that may be edited concurrently, but the instructions do not require author verification, a trusted pinned revision, or treating issue text as untrusted data. Anyone able to edit the map or a ticket could add Skill names or manipulative content that influences later agent work.

Why this matters

Malicious or compromised tracker content could redirect a planning session into another workflow with file, network, account, or permission capabilities. The exact harm depends on the invoked Skill and available privileges.

The map is an editable issue, and the workflow explicitly invokes Skills named in its Notes while also fetching related ticket bodies. It expects concurrent tracker edits. If an untrusted collaborator can modify that content, they could alter later Skill invocations or influence decisions. No author verification or version pinning is required. Users can restrict map write access and require review of changed Notes before invoking newly named Skills.

SKILL.md:21In the instructionsOpen original file
The map is a single issue on this repo's issue tracker, labelled `wayfinder:map`, the canonical artifact. Its tickets are child issues of the map.The map is an **index**, not a store. It lists the decisions made and points at the tickets that hold their detail; a decision lives in exactly one place, its ticket, so the map never restates it, only gists it and links.**Where the map, its child tickets, blocking, and frontier queries physically live is tracker-specific.** The issue tracker should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`. Consult the tracker doc's "Wayfinding operations" section for how _this_ repo expresses them. If no tracker has been provided, default to the local-markdown tracker.
Show 2 other places
SKILL.md:122In the instructionsOpen original file
1. Load the **map**: the low-res view, not every ticket body.2. Choose the ticket. If the user named one, use it. Otherwise take the first frontier ticket in order. **Claim it**: assign it to yourself before any work.3. Resolve it. **Zoom as needed**: fetch the full body of any related or closed ticket on demand; call the Skill tool for whichever skills the `## Notes` block names. If in doubt, call the Skill tool twice, for "grilling" and "domain-modeling".4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far.5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals that a ticket (this one or another) sits beyond the destination, **rule it out of scope** rather than resolving it on the route. If the decision invalidates other parts of the map, update or delete those tickets.
SKILL.md:128In the instructionsOpen original file
The user may run unblocked tickets in parallel, so expect other sessions to be editing the tracker concurrently.
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

7 instruction sections

The Skill is planning-only by default, but the effort's Notes can override that boundary and carry execution into the map.

View source
SKILL.md:11In the instructionsOpen original file
## Plan, don't doWayfinder is **planning** by default: each ticket resolves a decision, and the map is done when the way is clear, with nothing left to decide before someone goes and does the thing. The pull to just do the work is usually the signal you've reached the edge of the map and it's time to hand off. An effort can override this in its **Notes**, carrying execution into the map itself, but absent that, produce decisions, not deliverables.

It creates a map issue, child issues, labels, and dependencies in the repository's tracker; while processing a map it also assigns, comments on, closes, updates, or deletes issues.

View source
SKILL.md:21In the instructionsOpen original file
The map is a single issue on this repo's issue tracker, labelled `wayfinder:map`, the canonical artifact. Its tickets are child issues of the map.The map is an **index**, not a store. It lists the decisions made and points at the tickets that hold their detail; a decision lives in exactly one place, its ticket, so the map never restates it, only gists it and links.**Where the map, its child tickets, blocking, and frontier queries physically live is tracker-specific.** The issue tracker should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`. Consult the tracker doc's "Wayfinding operations" section for how _this_ repo expresses them. If no tracker has been provided, default to the local-markdown tracker.
SKILL.md:123In the instructionsOpen original file
1. Load the **map**: the low-res view, not every ticket body.2. Choose the ticket. If the user named one, use it. Otherwise take the first frontier ticket in order. **Claim it**: assign it to yourself before any work.3. Resolve it. **Zoom as needed**: fetch the full body of any related or closed ticket on demand; call the Skill tool for whichever skills the `## Notes` block names. If in doubt, call the Skill tool twice, for "grilling" and "domain-modeling".4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far.5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals that a ticket (this one or another) sits beyond the destination, **rule it out of scope** rather than resolving it on the route. If the decision invalidates other parts of the map, update or delete those tickets.

Task tickets go beyond decision-making and may register for services, provision access, or move data; the agent performs them alone when it can.

View source
SKILL.md:80In the instructionsOpen original file
- **Grilling** (HITL): Conversation. The default case. Always call the Skill tool twice, for "grilling" and "domain-modeling".- **Task** (HITL or AFK): Manual work that must happen before a _decision_ can be made: nothing to decide, prototype, or research, but the discussion is blocked until it's done. Signing up for a service so its API can be judged, provisioning access, moving data so its shape can be seen. This is the one type that _does_ rather than decides, and it earns its place by unblocking a decision, not by delivering the destination. The agent drives it alone where it can (AFK); otherwise it hands the human a precise checklist (HITL). Resolved when the work is done; the answer records what was done and any resulting facts (credentials location, new URLs, row counts) later tickets depend on.

When charting a map, it starts a parallel subagent for every research ticket and tells it to capture results on a throwaway research branch.

View source
SKILL.md:113In the instructionsOpen original file
2. **Map the frontier.** Grill again, **breadth-first** this time: fan out across the whole space rather than deep on any one thread, surfacing the open decisions and the first steps takeable now. **If this surfaces no fog** (the way to the destination is already clear, the whole journey small enough for one session), you don't need a map. Stop and ask the user how they'd like to proceed.3. **Create the map** (label `wayfinder:map`): Destination and Notes filled in, Decisions-so-far empty, the fog sketched into **Not yet specified**.4. **Create the tickets you can specify now** as child issues of the map, then wire blocking edges in a **second pass** (issues need ids before they can reference each other). Wiring sorts them into the frontier and the blocked; everything you can't yet specify stays in the fog: the **Not yet specified** section.5. **Fire the research subagents.** For each `research` ticket you just created, spin up a subagent that calls the Skill tool with "research" to resolve it in parallel, capturing its findings on a throwaway `research/<name>` branch with a context pointer from the ticket.6. Stop: charting is one session's work; it hand-resolves nothing.
Start here · InstructionsSKILL.md
wayfinder
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.
Files and check records2 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • agents/openai.yamlFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • agents/openai.yamlSupporting file

Operations mentioned in code and instructions

Read keys or account settings
SKILL.md:80In the instructionsOpen original file
- **Grilling** (HITL): Conversation. The default case. Always call the Skill tool twice, for "grilling" and "domain-modeling".- **Task** (HITL or AFK): Manual work that must happen before a _decision_ can be made: nothing to decide, prototype, or research, but the discussion is blocked until it's done. Signing up for a service so its API can be judged, provisioning access, moving data so its shape can be seen. This is the one type that _does_ rather than decides, and it earns its place by unblocking a decision, not by delivering the destination. The agent drives it alone where it can (AFK); otherwise it hands the human a precise checklist (HITL). Resolved when the work is done; the answer records what was done and any resulting facts (credentials location, new URLs, row counts) later tickets depend on.
Lines read
135
File checksum (to compare versions)
1e067306ffb20753c836500ad47df3179d932d0c78afc44cccce8eee11d9a99b