Skip to content
skillsafebeta
← Report library
Purpose / Documents

Code Review Skill Security Audit

What the author says it does (original text)

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to

Independent security check

Do not install or run it yet

Files checked
2
Risks found
2
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

An unconstrained fixed point can become shell or Git-option injection

Source references: 3
What we found

The Skill accepts an arbitrary user-supplied fixed point and inserts it directly into git diff, git log, and git rev-parse command templates. It does not require argument-safe execution, an option separator, or validation that the value is one Git reference.

Why this matters

If an agent executes a shell-built command containing metacharacters, additional commands could run with the agent's permissions. Even without a shell, a value beginning with a hyphen could be interpreted as a Git option and alter output or cause unintended file operations. The evidence does not show this has occurred.

The source supports a plausible risk, though exploitation depends on how the agent constructs the command. The user-provided fixed point is inserted into three Git command templates without requiring single-argument passing or rejection of shell metacharacters/options. If an executor interpolates it into a shell, a malicious or accidentally copied value could append commands; Git option parsing could also alter the operation. Resolving the ref and checking the diff do not remove that risk. Users can ask the author to resolve only an allowed ref to a commit SHA and require argument-array execution and option boundaries.

SKILL.md:19In the instructionsOpen original file
Whatever the user said is the fixed point (a commit SHA, branch name, tag, `main`, `HEAD~5`, etc.). If they didn't specify one, ask for it.
Show 2 other places
SKILL.md:21In the instructionsOpen original file
Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
SKILL.md:23In the instructionsOpen original file
Before going further, confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty. A bad ref or empty diff should fail here, not inside two parallel sub-agents.
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.No risks found
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

Repository and issue content enters sub-agent prompts without prompt-injection safeguards

Source references: 4
What we found

The Skill locates and fetches issues from commit messages, reads repository standards and specification files, and passes standards material plus a specification path or fetched contents to sub-agents. It never says these sources are untrusted data or that instructions embedded in them must be ignored.

Why this matters

A malicious commit message, issue, standards document, or specification could pose as instructions and induce a sub-agent to distort findings, inspect unrelated data, or attempt other tool actions. The result depends on the sub-agent's permissions; the supplied evidence does not show that an attack occurred.

The skill fetches issue content, reads repository standards/specifications, and places that material or its paths into sub-agent context without explicitly requiring agents to treat it only as untrusted evidence and ignore embedded operational instructions. If a repository file or issue contains prompt-injection text, a sub-agent could deviate from the review, expose accessible information, or invoke unintended tools. The supplied review briefs provide some scope limits, but are not an explicit injection defense. Users can ask the author to mark all external content untrusted, extract only needed facts, and restrict sub-agent tools and write permissions.

SKILL.md:29In the instructionsOpen original file
1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.), fetched via the workflow in `docs/agents/issue-tracker.md`.2. A path the user passed as an argument.
Show 3 other places
SKILL.md:36In the instructionsOpen original file
Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.
SKILL.md:63In the instructionsOpen original file
- The full diff command and commit list.- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full (the sub-agent has no other access to it).- The brief: "Report, per file/hunk where relevant, (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls: documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
SKILL.md:69In the instructionsOpen original file
- The diff command and commit list.- The path or fetched contents of the spec.- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
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

2 instruction sections

The Skill reviews changes between a user-supplied fixed point and HEAD on two axes: compliance with repository standards and compliance with the originating specification. It uses a three-dot diff against the merge base and reads the commit list.

View source
SKILL.md:6In the instructionsOpen original file
Two-axis review of the diff between `HEAD` and a fixed point the user supplies:- **Standards**: does the code conform to this repo's documented coding standards?- **Spec**: does the code faithfully implement the originating issue / spec?
SKILL.md:21In the instructionsOpen original file
Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.

It searches commit messages, user-provided paths, and repository directories for a specification, and repository documents for coding standards, then gives those materials to separate sub-agents. Issue references are fetched through a workflow not included in the supplied material, so its permissions and data handling cannot be assessed from this evidence.

View source
SKILL.md:29In the instructionsOpen original file
1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.), fetched via the workflow in `docs/agents/issue-tracker.md`.2. A path the user passed as an argument.3. A spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".
SKILL.md:36In the instructionsOpen original file
Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.
SKILL.md:58In the instructionsOpen original file
### 4. Spawn both sub-agents in parallel

The final report keeps Standards and Spec results separate without merging or reranking them; if no specification is found, it skips the Spec sub-agent and states that explicitly.

View source
SKILL.md:72In the instructionsOpen original file
If the spec is missing, skip the Spec sub-agent and note this in the final report.
SKILL.md:76In the instructionsOpen original file
Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings, because the two axes are deliberately separate (see _Why two axes_).End with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes: that's the reranking the separation exists to prevent.
Start here · InstructionsSKILL.md
code-review
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
Lines read
92
File checksum (to compare versions)
fcc6974832133fc2d5b767ceb44f4ac095eec9d78272e14a9afa4887715d67ee