Back to skill

Security audit

PR Description

Security checks for vulnerabilities and agentic risk

Overview

This PR-description skill is purpose-aligned and disclosed, with GitHub PR editing gated on explicit user approval.

Before installing, be aware that providing a PR number or URL may cause the agent to use local git or gh to fetch PR details and check whether you can update it. Review generated content carefully before approving any GitHub PR edit.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (5)

Vague Triggers

Medium
Confidence
96% confidence
Finding
The trigger conditions are excessively broad and include mandatory activation for virtually any PR-related request or any provided GitHub PR URL. This can cause the skill to auto-engage in situations where the user may only want a simple read, summary, or unrelated assistance, increasing the chance of unnecessary repository access and tool use on untrusted inputs.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
6. **Propose PR Update:**
   - **Crucial Context:** If you generated the PR description for an existing PR (e.g. the user provided a PR number or URL), you MUST follow these steps to propose an update.
   - **Step 6.1 (Permission Check):** First, run a command to verify if the current authenticated user has permission to edit this PR. You can check this via the `gh` CLI. For example, run `gh pr view <pr-number> --json viewerCanUpdate` to check if `viewerCanUpdate` is true. Or check if the `gh api user` matches the PR author. (Note: If `gh` is not authenticated, treat this as having no permission).
   - **Step 6.2 (Review & Ask User):** ONLY IF the user has permission to edit the PR (e.g. `viewerCanUpdate: true`), you MUST first output the generated PR title and description for the user to review. DO NOT ASK the user any questions yet! If the user does not have permission, you MUST still output the generated PR title and description, and then end your turn.
   - **Step 6.3 (Explicit System Stop):** If you proceeded with Step 6.2 and determined the user HAS permission, stop execution here and explicitly tell the user: "Please review the generated PR description above. If it looks good to you, reply with 'ok' or 'yes', and I will help you update the PR." Wait for the user's response.
   - **Step 6.4 (Execute Update):** In the NEXT turn, after the user has reviewed the content and agreed to proceed, explicitly ask the user: "Would you like me to update the PR title and description with this content using the GitHub CLI?". If the user agrees, write the description to a temporary file. **CRITICAL: The temporary file MUST ONLY contain the description body. You MUST REMOVE the `## Title:` line and its contents from the text you write to the temporary file.** Then, use the GitHub CLI (e.g., `gh pr edit <pr-number> --title "<generated-title>" --body-file <temp-file>`) to update the PR securely.
   - Do NOT execute the update command without the user's explicit approval.
Confidence
81% confidence
Finding
The skill directs the agent to perform permission checks and workflow progression autonomously before clarifying user intent, including mandatory command execution to inspect and potentially prepare PR updates. Even though it later requires explicit approval for the final edit, the 'MUST' sequencing and 'DO NOT ASK the user' language push the agent into action-first behavior that can result in unnecessary access to GitHub metadata and reduced user control over side effects.

Natural-Language Policy Violations

Low
Confidence
92% confidence
Finding
The line says the skill 'will automatically adapt' to the language of the user's prompt. Under the policy, forcing language behavior without an explicit user choice can be a natural-language policy violation, even if the behavior is convenient.

Vague Triggers

Low
Confidence
81% confidence
Finding
This JSON eval file includes user-facing invocation examples such as "帮我根据这个 git diff 生成一个 PR 描述" and "Generate a PR description for this change" without any limiting conditions, exclusions, or explicit trigger boundaries. In a manifest-like/eval context, these broad phrases could overlap with common requests and do not clarify when the skill should or should not activate.

Natural-Language Policy Violations

Low
Confidence
93% confidence
Finding
The expected outputs require Chinese in some cases and English in others, which reflects a language-specific behavior embedded in the skill evaluation data. Because the file does not document this as user-selected behavior or justify a locale restriction, it may conflict with policy guidance against forcing a language without user opt-in.

Static analysis

No suspicious patterns detected.