Skip to content
Report library
Purpose / Other

Ask Matt Skill Security Audit

What the author says it does (original text)

Ask which skill or flow fits your situation. A router over the skills in this repo.

Independent security check

Do not install or run it yet

Files checked
3
Risks found
3
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
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
High risk

Recommended wizard captures credentials and writes them to local files and GitHub Secrets

Source references: 3
What we found

The router directs the agent to reach for `/wizard` when it encounters steps only a human can perform. That wizard generates an interactive Bash script that opens URLs, captures values, and writes them into `.env` and GitHub Secrets. The supplied material does not describe input masking, log suppression, file permissions, or protection against committing `.env`.

Why this matters

If the captured values are API keys, access tokens, or other credentials, they may persist in the working directory, terminal records, or the script's processing path. An accidental commit or weak file permissions could disclose them. Writing GitHub Secrets also changes repository or organization security configuration.

What this evidence establishes

The text says `/wizard` generates a script that captures user-supplied values and writes them to `.env` and GitHub Secrets, so running that separate wizard could place credentials in local and remote settings. However, this source only describes another Skill; it does not include its script, permissions, logging, or input handling, so the alleged missing safeguards cannot be verified. Implicit invocation of this router is also explicitly disabled.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:83In the instructionsOpen original file
- **`/to-questionnaire`** comes in when the thing blocking you isn't in your head or the codebase but in **someone else's**, and it writes them a questionnaire to fill in. It's the inverse of `/grill-me`: instead of interviewing you about the subject, it interviews you about the **send** (who it's going to, what you need back) and aims the questions at the gap. What comes back is material for `/grill-with-docs` or `/to-spec`.- **`/wizard`** is for the steps only a **human** can take: provisioning infrastructure, setting up credentials or CI secrets, clicking through an unfamiliar third-party dashboard, running a one-off migration or cutover. It generates an interactive bash script that opens each URL, captures each value, and writes it into `.env` and GitHub secrets, so the procedure stops being something you re-explain to an agent every time. Model-invoked, so the agent reaches for it the moment it hits a wall only you can pass. If the agent could just do it itself, it should; this is for where a human is genuinely in the loop.- **`/wait-what`** is the corrective for a message that didn't land. Use it mid-conversation, inside any other skill, and the agent re-pitches what it just said with the context you were missing, in plain English, using the `CONTEXT.md` vocabulary. It works after the fact; `/grill-with-docs` is the upfront cure, because a shared language agreed early is what stops the jargon arriving at all.
Show 2 other places
SKILL.md:2In the instructionsOpen original file
---name: ask-mattdescription: Ask which skill or flow fits your situation. A router over the skills in this repo.disable-model-invocation: true---
agents/openai.yaml:4In the instructionsOpen original file
  short_description: "Find the right skill or workflow"policy:  allow_implicit_invocation: false
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

A routing request may be expanded into modifying and committing code

Source references: 3
What we found

The stated purpose is to help choose a Skill or flow, but the main flow tells the agent to invoke `/implement` “right here” for a small task, and that flow commits after implementation and review. Choosing a route is not itself authorization to modify or commit a repository.

Why this matters

If the agent treats routing guidance as execution approval, workspace files could be changed and a Git commit created when the user only wanted advice. The commit makes the changes persistent and may include content the user has not reviewed.

What this evidence establishes

The flow directs a small task to `/implement` in the current session and says that flow commits after review, so treating a routing request as execution authority could modify and commit user files. But this Skill identifies itself as a router for choosing a Skill or flow and disables implicit invocation, while the actual `/implement` instructions are absent. The evidence does not establish whether this is only route advice or would execute without further user agreement.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:2In the instructionsOpen original file
---name: ask-mattdescription: Ask which skill or flow fits your situation. A router over the skills in this repo.disable-model-invocation: true---
Show 2 other places
SKILL.md:22In the instructionsOpen original file
   - **`/handoff`** back what you learned, and reference it from the original idea thread.3. **Branch: is this a multi-session build?**   - **Yes** → **`/to-spec`** (turn the thread into a spec), then **`/to-tickets`** to split it into tracer-bullet tickets, each declaring its **blocking edges**. On a local tracker that's one file per ticket under `.scratch/<feature>/issues/`, worked blockers-first by hand; on a real tracker the edges become native blocking links, so any ticket whose blockers are done can be grabbed: kick off **`/implement`** per ticket, **`/clear`ing context between each one**. Each ticket is self-contained, so the last one's context is disposable.   - **No** → **`/implement`** right here, in the same context window.   Either way, **`/implement`** builds each issue by driving **`/tdd`** internally (one red-green slice at a time), then closes out by running **`/code-review`**, a two-axis review (Standards + Spec) of the diff, before committing. Reach for **`/tdd`** on its own when you just want to build a concrete behaviour test-first without a full spec, and **`/code-review`** on its own whenever you want to review a branch or PR against a fixed point.
agents/openai.yaml:1In the instructionsOpen original file
interface:  display_name: "Ask Matt"  short_description: "Find the right skill or workflow"policy:  allow_implicit_invocation: false
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

Prerequisite flow may alter issue-tracker configuration without a confirmed target

Source references: 3
What we found

The document says to run a setup Skill before the first engineering flow to configure the issue tracker, triage labels, and documentation layout. The routing material does not identify the tracker, repository, labels, or files to be changed, and shows no confirmation step.

Why this matters

If the agent treats this prerequisite as automatic authorization, it could create or modify labels in the wrong project or shared tracker and change repository documentation structure, affecting collaborators and existing automation.

What this evidence establishes

The document presents `/setup-matt-pocock-skills` as a prerequisite before the first engineering flow and says it configures the issue tracker, triage labels, and documentation layout, which could change repository files or an external tracker when run. Its implementation, exact targets, and confirmation behavior are not included, so the source cannot establish that it changes anything without scope confirmation or user authorization.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:88In the instructionsOpen original file
## Precondition**`/setup-matt-pocock-skills`**: run before your first engineering flow to configure the issue tracker, triage labels, and doc layout the other skills assume. Custom issue trackers also work.
Show 2 other places
SKILL.md:2In the instructionsOpen original file
---name: ask-mattdescription: Ask which skill or flow fits your situation. A router over the skills in this repo.disable-model-invocation: true---
agents/openai.yaml:4In the instructionsOpen original file
  short_description: "Find the right skill or workflow"policy:  allow_implicit_invocation: false
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.No risks found
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

This Skill is a workflow-routing document and contains no executable script itself; it primarily recommends other Skills based on the situation. Its metadata also disables automatic model invocation.

View source
SKILL.md:2In the instructionsOpen original file
---name: ask-mattdescription: Ask which skill or flow fits your situation. A router over the skills in this repo.disable-model-invocation: true---
agents/openai.yaml:1In the instructionsOpen original file
interface:  display_name: "Ask Matt"  short_description: "Find the right skill or workflow"policy:  allow_implicit_invocation: false

The recommended main flow can proceed directly from discussion to implementation; the implementation flow performs test-driven development, code review, and then commits the changes.

View source
SKILL.md:22In the instructionsOpen original file
   - **`/handoff`** back what you learned, and reference it from the original idea thread.3. **Branch: is this a multi-session build?**   - **Yes** → **`/to-spec`** (turn the thread into a spec), then **`/to-tickets`** to split it into tracer-bullet tickets, each declaring its **blocking edges**. On a local tracker that's one file per ticket under `.scratch/<feature>/issues/`, worked blockers-first by hand; on a real tracker the edges become native blocking links, so any ticket whose blockers are done can be grabbed: kick off **`/implement`** per ticket, **`/clear`ing context between each one**. Each ticket is self-contained, so the last one's context is disposable.   - **No** → **`/implement`** right here, in the same context window.   Either way, **`/implement`** builds each issue by driving **`/tdd`** internally (one red-green slice at a time), then closes out by running **`/code-review`**, a two-axis review (Standards + Spec) of the diff, before committing. Reach for **`/tdd`** on its own when you just want to build a concrete behaviour test-first without a full spec, and **`/code-review`** on its own whenever you want to review a branch or PR against a fixed point.

The router also describes flows that create persistent files or branches, including CONTEXT.md, ADRs, research Markdown, prototype branches, and local ticket files.

View source
SKILL.md:17In the instructionsOpen original file
1. **`/grill-with-docs`** sharpens the idea by interview. Start here whenever you are **working in a working directory**: it's stateful, retaining what it learns in `CONTEXT.md` and ADRs. (No working directory? Use `/grill-me` instead, covered under Standalone. Both run the same `/grilling` primitive; `grill-with-docs` is the one that leaves a paper trail, which makes it the better of the two whenever a repo is there to leave it in.)2. **Branch: can you settle every question in conversation?** If a question needs a runnable answer (state, business logic, a UI you have to see), detour through a prototype, bridged by **`/handoff`** in both directions (a prototype lives in its own directory, which is exactly what `/handoff` is for; see Phase boundaries):
SKILL.md:80In the instructionsOpen original file
- **`/resolving-merge-conflicts`** works an in-progress merge or rebase conflict hunk by hunk, resolving by **intent** traced to each side's primary source rather than by picking lines, then finishes the operation. It never runs `--abort`. Standalone and off every flow: reach for it when you are already mid-conflict.- **`/prototype`** is a small, throwaway program that answers one design question: does this state model feel right, or what should this UI look like. Throwaway is a constraint on how the code is written, not a promise to destroy it: the answer folds into the real code, and the prototype itself is kept as a **primary source** on a `prototype/<name>` branch out of main, pointed at from the implementation issue. It's the detour in step 2 of the main flow, but reach for it any time a design question is hard to settle on paper.- **`/research`**: delegate reading legwork to a **background agent**: it investigates a question against **primary sources**, then leaves a cited Markdown file in the repo. Keep working while it reads. The file it produces is something to take *into* the main flow at `/grill-with-docs`, since research feeds the thinking rather than replacing it.- **`/to-questionnaire`** comes in when the thing blocking you isn't in your head or the codebase but in **someone else's**, and it writes them a questionnaire to fill in. It's the inverse of `/grill-me`: instead of interviewing you about the subject, it interviews you about the **send** (who it's going to, what you need back) and aims the questions at the gap. What comes back is material for `/grill-with-docs` or `/to-spec`.

A prerequisite for the first engineering flow is described as configuring the issue tracker, triage labels, and documentation layout; the supplied material does not show that setup flow's implementation.

View source
SKILL.md:88In the instructionsOpen original file
## Precondition**`/setup-matt-pocock-skills`**: run before your first engineering flow to configure the issue tracker, triage labels, and doc layout the other skills assume. Custom issue trackers also work.
Start here · InstructionsSKILL.md
ask-matt
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.

File reference map

References: 1
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 records3 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
  • PHASE-BOUNDARIES.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.

  • PHASE-BOUNDARIES.mdSupporting file
  • SKILL.mdInstructions
  • agents/openai.yamlSupporting file

Operations mentioned in code and instructions

Connect to websites
PHASE-BOUNDARIES.md:21In the instructionsOpen original file
**1. Can you continue in this session?** Two things make the answer yes: the next phase needs this phase as a **primary source**, or you have enough [smart zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone) left (~150k tokens) for the next phase to fit. Grilling → implementation is the standard yes: the implementation wants the reasoning verbatim, not a summary of it. Continue costs nothing and loses nothing, so rule it out before anything else.
SKILL.md:32In the instructionsOpen original file
The limit on this is the **[smart zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone)**: the window (~150k tokens on state-of-the-art models) within which the model still reasons sharply. If a session approaches it before `/to-tickets`, don't push on degraded; `/compact` at the nearest phase boundary and carry on (see Phase boundaries).
Read files
SKILL.md:81In the instructionsOpen original file
- **`/prototype`** is a small, throwaway program that answers one design question: does this state model feel right, or what should this UI look like. Throwaway is a constraint on how the code is written, not a promise to destroy it: the an - **`/research`**: delegate reading legwork to a **background agent**: it investigates a question against **primary sources**, then leaves a cited Markdown file in the repo. Keep working while it reads. The file it produces is something to take *into* the main flow at `/grill-with-docs`, since research feeds the thinking rather than replacing it.- **`/to-questionnaire`** comes in when the thing blocking you isn't in your head or the codebase but in **someone else's**, and it writes them a questionnaire to fill in. It's the inverse of `/grill-me`: instead of interviewing you about t 
Run commands
SKILL.md:83In the instructionsOpen original file
- **`/to-questionnaire`** comes in when the thing blocking you isn't in your head or the codebase but in **someone else's**, and it writes them a questionnaire to fill in. It's the inverse of `/grill-me`: instead of interviewing you about t - **`/wizard`** is for the steps only a **human** can take: provisioning infrastructure, setting up credentials or CI secrets, clicking through an unfamiliar third-party dashboard, running a one-off migration or cutover. It generates an interactive bash script that opens each URL, captures each value, and writes it into `.env` and GitHub secrets, so the procedure stops being something you re-explain to an agent every time. Model-invoked, so the agent reaches for it the moment it hits a wall only you can pass. If the agent could just do it itself, it should; this is for where a human is genuinely in the loop.- **`/wait-what`** is the corrective for a message that didn't land. Use it mid-conversation, inside any other skill, and the agent re-pitches what it just said with the context you were missing, in plain English, using the `CONTEXT.md` voc 
Read keys or account settings
SKILL.md:83In the instructionsOpen original file
- **`/to-questionnaire`** comes in when the thing blocking you isn't in your head or the codebase but in **someone else's**, and it writes them a questionnaire to fill in. It's the inverse of `/grill-me`: instead of interviewing you about t - **`/wizard`** is for the steps only a **human** can take: provisioning infrastructure, setting up credentials or CI secrets, clicking through an unfamiliar third-party dashboard, running a one-off migration or cutover. It generates an interactive bash script that opens each URL, captures each value, and writes it into `.env` and GitHub secrets, so the procedure stops being something you re-explain to an agent every time. Model-invoked, so the agent reaches for it the moment it hits a wall only you can pass. If the agent could just do it itself, it should; this is for where a human is genuinely in the loop.- **`/wait-what`** is the corrective for a message that didn't land. Use it mid-conversation, inside any other skill, and the agent re-pitches what it just said with the context you were missing, in plain English, using the `CONTEXT.md` voc 
Lines read
153
File checksum (to compare versions)
43304025343ae0713ed397f4a71d60fb65735f72bd02032d372015eae5452766