Skip to content
skillsafebeta
← Report library
Purpose / Other

Triage Skill Security Audit

What the author says it does (original text)

Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.

Independent security check

Do not install or run it yet

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

Verification checks out and executes contributor-controlled external PR code

Source references: 2
What we found

The Skill explicitly includes external PRs in triage and instructs the agent to check out their diff and run relevant tests or commands. Test scripts, build hooks, and dependency lifecycle scripts can be changed by the PR author, so “running tests” can execute contributor-supplied code.

Why this matters

A malicious PR could read credentials or repository data available to the agent process, alter the workspace, or use the current account's network and service access. The AI disclaimer and later state confirmation do not sandbox that execution.

The risk is supported. External PRs enter discovery, and verification explicitly checks out the PR and runs relevant tests or commands. If the contributor changed tests, build configuration, or lifecycle scripts, this may execute contributor-controlled code in the user's environment. These steps specify no sandbox, lifecycle-script restriction, or command-by-command approval. A user can ask for sandboxing, read-only checkout, and explicit approval of each command.

SKILL.md:64In the instructionsOpen original file
When PRs are in scope, include external PRs in these buckets and tag each line `[PR]` or `[issue]`. Discovery surfaces only *external* PRs (the tracker config defines who counts as external), so a collaborator's in-flight PR is not triage work. This filter is discovery-only; an explicitly named PR is always triaged regardless of author.
Show 1 other places
SKILL.md:70In the instructionsOpen original file
1. **Gather context.** Read the full issue or PR (body, comments, labels, author, dates; for a PR, the diff too). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Run two checks against the codebase: (a) **redundancy**: search for an existing implementation of the requested behavior by domain concept (not just the request's wording), and report where you looked. If found, it's an already-implemented `wontfix` (step 5). (b) **prior rejection**: read `.out-of-scope/*.md` and surface any that resembles this request.2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the request (including whether it's already implemented). Wait for direction.3. **Verify the claim.** Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a PR, confirm the diff does what it claims: check it out, run the relevant tests or commands. Report what happened: confirmed (with code path), failed, or insufficient detail (a strong `needs-info` signal). A confirmed verification makes a much stronger agent brief.
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
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

Triage can persistently modify or delete project decision documents

Source references: 6
What we found

During request refinement, the workflow updates `CONTEXT.md` and ADRs inline as decisions land. Rejected enhancements create or append `.out-of-scope/` files, and reconsideration instructs deletion of such a file. These are lasting repository documents, not temporary triage notes.

Why this matters

A misclassification, prompt injection, or discussion that is not truly final could change project terminology and architecture records or remove prior decision history. Because `.out-of-scope/` is consulted for future requests, one incorrect write can continue influencing later closure decisions.

Legitimate use of this code

These persistent changes are real, but the context presents them as intended triage decision records gated by maintainer decisions: the agent waits for direction after recommending; records are created or appended only after an enhancement is rejected; deletion follows a maintainer's reversal. The candidate therefore describes consequential but purpose-aligned, authorized repository maintenance rather than covert file destruction. Users can still require a displayed diff and separate confirmation before each repository write or deletion.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:76In the instructionsOpen original file
4. **Grill (if needed).** If the request needs fleshing out, call the Skill tool twice, for "grilling" and "domain-modeling", and grill it into shape a round of questions at a time, sharpening domain terms and updating `CONTEXT.md`/ADRs inline as decisions land.
Show 5 other places
SKILL.md:82In the instructionsOpen original file
   - `needs-info`: post triage notes (template below).   - For `wontfix`, close the issue, with the comment depending on *why*:     - **Already implemented**: the change already exists in the codebase. Point to where it lives; do **not** write to `.out-of-scope/` (that KB is for *rejected* requests, not built ones).     - **Rejected (bug)**: give a polite explanation, then close.     - **Rejected (enhancement)**: write to `.out-of-scope/`, link to it from a comment, then close ([OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)).   - `needs-triage`: apply the role. Optional comment if there's partial progress.
OUT-OF-SCOPE.md:90In the instructionsOpen original file
The flow:1. Maintainer decides a feature request is out of scope2. Check if a matching `.out-of-scope/` file already exists3. If yes: append the new issue to the "Prior requests" list4. If no: create a new file with the concept name, decision, reason, and first prior request5. Post a comment on the issue explaining the decision and mentioning the `.out-of-scope/` file6. Close the issue with the `wontfix` label
OUT-OF-SCOPE.md:99In the instructionsOpen original file
## Updating or removing out-of-scope filesIf the maintainer changes their mind about a previously rejected concept:- Delete the `.out-of-scope/` file- The skill does not need to reopen old issues; they're historical records- The new issue that triggered the reconsideration proceeds through normal triage
SKILL.md:72In the instructionsOpen original file
2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the request (including whether it's already implemented). Wait for direction.3. **Verify the claim.** Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a PR, confirm the diff does what it claims: check it out, run the relevant tests or commands. Report what happened: confirmed (with code path), failed, or insufficient detail (a strong `needs-info` signal). A confirmed verification makes a much stronger agent brief.4. **Grill (if needed).** If the request needs fleshing out, call the Skill tool twice, for "grilling" and "domain-modeling", and grill it into shape a round of questions at a time, sharpening domain terms and updating `CONTEXT.md`/ADRs inline as decisions land.
OUT-OF-SCOPE.md:84In the instructionsOpen original file
## When to write to `.out-of-scope/`Only when an **enhancement** (not a bug) is *rejected* as `wontfix`. This applies to enhancement PRs exactly as it does to issues: a rejected PR is recorded here so the same request doesn't return as fresh code.Do **not** write here when something is closed as `wontfix` because it's **already implemented**. That's a built feature, not a rejected one; recording it would poison the dedup checks with false rejections. Instead, the closing comment points to where the feature already lives.
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
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
Medium risk

External issues, comments, and diffs enter a write-capable agent flow without an untrusted-instruction boundary

Source references: 4
What we found

The workflow reads complete bodies, comments, and code diffs, then may post comments, change roles, close issues, and write repository files. The supplied rules never say contributor text, code comments, or command output must be treated only as data or that agent-directed commands inside them must be ignored.

Why this matters

An attacker could place prompt-injection text in an issue, comment, or PR to steer the agent away from maintainer intent, disclose information it has read, or apply incorrect labels, comments, and closure actions. If incorporated into an agent brief, the influence can also reach a later AFK agent.

The workflow loads contributor-controlled bodies, comments, and PR diffs into the agent context, after which the agent may post comments, change roles, write repository files, and close issues. Waiting for maintainer direction at the recommendation stage reduces the chance of unapproved action, but the material does not instruct the agent to treat issue text, code comments, and output solely as untrusted data. Instructions embedded there could therefore influence later actions. Users can restrict write access and require strict separation of external content from operational instructions.

SKILL.md:68In the instructionsOpen original file
## Triage a specific issue or PR1. **Gather context.** Read the full issue or PR (body, comments, labels, author, dates; for a PR, the diff too). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Run two checks against the codebase: (a) **redundancy**: search for an existing implementation of the requested behavior by domain concept (not just the request's wording), and report where you looked. If found, it's an already-implemented `wontfix` (step 5). (b) **prior rejection**: read `.out-of-scope/*.md` and surface any that resembles this request.2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the request (including whether it's already implemented). Wait for direction.3. **Verify the claim.** Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a PR, confirm the diff does what it claims: check it out, run the relevant tests or commands. Report what happened: confirmed (with code path), failed, or insufficient detail (a strong `needs-info` signal). A confirmed verification makes a much stronger agent brief.4. **Grill (if needed).** If the request needs fleshing out, call the Skill tool twice, for "grilling" and "domain-modeling", and grill it into shape a round of questions at a time, sharpening domain terms and updating `CONTEXT.md`/ADRs inline as decisions land.
Show 3 other places
SKILL.md:78In the instructionsOpen original file
5. **Apply the outcome:**   - `ready-for-agent`: post an agent brief comment ([AGENT-BRIEF.md](AGENT-BRIEF.md)).   - `ready-for-human`: same structure as an agent brief, but note why it can't be delegated (judgment calls, external access, design decisions, manual testing).   - `needs-info`: post triage notes (template below).   - For `wontfix`, close the issue, with the comment depending on *why*:     - **Already implemented**: the change already exists in the codebase. Point to where it lives; do **not** write to `.out-of-scope/` (that KB is for *rejected* requests, not built ones).     - **Rejected (bug)**: give a polite explanation, then close.     - **Rejected (enhancement)**: write to `.out-of-scope/`, link to it from a comment, then close ([OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)).   - `needs-triage`: apply the role. Optional comment if there's partial progress.
AGENT-BRIEF.md:1In the instructionsOpen original file
# Writing Agent BriefsAn agent brief is a structured comment posted on a GitHub issue or PR when it moves to `ready-for-agent`. It is the authoritative specification that an AFK agent will work from. The original body and discussion are context: the agent brief is the contract.The brief states **what the agent should do**, which stretches to both surfaces: for an issue, that's building the change from nothing; for a PR, it's what's left to do *to the existing diff*: finish it, close gaps, address review points. Same principles either way; the PR example below shows the difference.
SKILL.md:70In the instructionsOpen original file
1. **Gather context.** Read the full issue or PR (body, comments, labels, author, dates; for a PR, the diff too). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Run two checks against the codebase: (a) **redundancy**: search for an existing implementation of the requested behavior by domain concept (not just the request's wording), and report where you looked. If found, it's an already-implemented `wontfix` (step 5). (b) **prior rejection**: read `.out-of-scope/*.md` and surface any that resembles this request.2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the request (including whether it's already implemented). Wait for direction.3. **Verify the claim.** Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a PR, confirm the diff does what it claims: check it out, run the relevant tests or commands. Report what happened: confirmed (with code path), failed, or insufficient detail (a strong `needs-info` signal). A confirmed verification makes a much stronger agent brief.4. **Grill (if needed).** If the request needs fleshing out, call the Skill tool twice, for "grilling" and "domain-modeling", and grill it into shape a round of questions at a time, sharpening domain terms and updating `CONTEXT.md`/ADRs inline as decisions land.
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

8 instruction sections

The Skill is explicit-invocation only: both model invocation and implicit invocation are disabled, reducing the chance that it modifies tracker items without being deliberately selected.

View source
SKILL.md:2In the instructionsOpen original file
---name: triagedescription: Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.disable-model-invocation: true---
agents/openai.yaml:4In the instructionsOpen original file
  short_description: "Move issues through triage roles"policy:  allow_implicit_invocation: false

The normal flow reads the issue or PR, comments, labels, author, dates, and PR diff, then recommends a category and state and waits for maintainer direction.

View source
SKILL.md:68In the instructionsOpen original file
## Triage a specific issue or PR1. **Gather context.** Read the full issue or PR (body, comments, labels, author, dates; for a PR, the diff too). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Run two checks against the codebase: (a) **redundancy**: search for an existing implementation of the requested behavior by domain concept (not just the request's wording), and report where you looked. If found, it's an already-implemented `wontfix` (step 5). (b) **prior rejection**: read `.out-of-scope/*.md` and surface any that resembles this request.2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the request (including whether it's already implemented). Wait for direction.3. **Verify the claim.** Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a PR, confirm the diff does what it claims: check it out, run the relevant tests or commands. Report what happened: confirmed (with code path), failed, or insufficient detail (a strong `needs-info` signal). A confirmed verification makes a much stronger agent brief.

When applying an outcome, the Skill posts comments and changes state; for some `wontfix` outcomes it also writes to the repository and closes the issue. Every tracker post must carry an AI-generated disclaimer.

View source
SKILL.md:13In the instructionsOpen original file
Every comment or issue posted to the issue tracker during triage **must** start with this disclaimer:```> *This was generated by AI during triage.*```
SKILL.md:78In the instructionsOpen original file
5. **Apply the outcome:**   - `ready-for-agent`: post an agent brief comment ([AGENT-BRIEF.md](AGENT-BRIEF.md)).   - `ready-for-human`: same structure as an agent brief, but note why it can't be delegated (judgment calls, external access, design decisions, manual testing).   - `needs-info`: post triage notes (template below).   - For `wontfix`, close the issue, with the comment depending on *why*:     - **Already implemented**: the change already exists in the codebase. Point to where it lives; do **not** write to `.out-of-scope/` (that KB is for *rejected* requests, not built ones).     - **Rejected (bug)**: give a polite explanation, then close.     - **Rejected (enhancement)**: write to `.out-of-scope/`, link to it from a comment, then close ([OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)).   - `needs-triage`: apply the role. Optional comment if there's partial progress.

A `ready-for-agent` comment is defined as the authoritative specification for a later unattended agent, while the original issue body and discussion are only context.

View source
AGENT-BRIEF.md:1In the instructionsOpen original file
# Writing Agent BriefsAn agent brief is a structured comment posted on a GitHub issue or PR when it moves to `ready-for-agent`. It is the authoritative specification that an AFK agent will work from. The original body and discussion are context: the agent brief is the contract.The brief states **what the agent should do**, which stretches to both surfaces: for an issue, that's building the change from nothing; for a PR, it's what's left to do *to the existing diff*: finish it, close gaps, address review points. Same principles either way; the PR example below shows the difference.
Start here · InstructionsSKILL.md
triage
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.

File reference map

References: 2
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records4 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
  • AGENT-BRIEF.mdFull text included
  • OUT-OF-SCOPE.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.

  • AGENT-BRIEF.mdSupporting file
  • OUT-OF-SCOPE.mdSupporting file
  • SKILL.mdInstructions
  • agents/openai.yamlSupporting file

Operations mentioned in code and instructions

Connect to websites
OUT-OF-SCOPE.md:3In the instructionsOpen original file
The `.out-of-scope/` directory in a repo stores persistent records of rejected feature requests. It serves two purposes:
Read files
OUT-OF-SCOPE.md:72In the instructionsOpen original file
During triage (Step 1: Gather context), read all files in `.out-of-scope/`. When evaluating a new issue:
Lines read
433
File checksum (to compare versions)
40cbae273fb016dd4b000edfd84a0d8965f1cdb7aa53f3ff1ab0455f15ff4444