GitHub PR Manager

• Outcome: Review
• Latest audit: Sep 12, 2026 · 1:09 AM UTC
• Version: 1.0.0

Overview

This PR automation skill is coherent, but it asks for persistent GitHub automation with broad credentials and repository-changing actions that are not tightly controlled.

Review before installing. Use only with explicit manual approval for commits, pushes, force-pushes, public replies, workflow changes, and scheduled jobs. Prefer an existing gh login or a short-lived fine-grained token limited to the target repository, never paste a real token into an echoed shell command, and remove or avoid cron-based tracking unless you have a clear cleanup plan.

A.I.G

Vulnerability Patterns

• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (4)

T06 · System Persistence

Error

• Location: SKILL.md:17
• Finding: Unbounded Cross-Session Persistence Through Scheduled PR Monitoring## Vulnerability Details **File Location**: `SKILL.md:17-24` **Additional Locations**: `SKILL.md:108-124`, `references/workflow.md:17` **Vulnerability Type**: Scheduled task persistence **Risk Level**: High The following is an English rendering of the complete affected instruction block: ```text Steps: 1. Confirm the repository name and PR number. 2. Use the gh CLI or browser to obtain the current PR status. 3. Create memory/pr-tracking.md to record the initial status. 4. Configure cron to check periodically, every two hours by default. 5. Inform the user of the current status and blockers. ``` Related instructions require the agent to continue checking the pull request every two hours and automatically handle problems within its capabilities. ### Technical Analysis The Skill directs the agent to install a recurring cron task that survives the current execution session. It does not define: - The exact scheduler command or execution target. - The identity and privileges under which the job runs. - An expiration time or maximum number of executions. - A unique task identifier for later removal. - Automatic cleanup when the pull request is merged, closed, or abandoned. - A requirement for explicit informed user approval before installation. - Restrictions on what repository mutations a scheduled invocation may perform. This creates a persistent execution mechanism with an undefined lifecycle. Because the scheduled workflow may inspect reviews, modify code, push commits, and post GitHub comments, the persistence is not limited to passive status monitoring. ### Attack Path 1. A user asks the Skill to track a pull request. 2. The agent follows the instruction to create a recurring cron task. 3. The initiating session ends, but the task remains installed. 4. The scheduled process continues authenticating to GitHub every two hours. 5. A later review, CI event, or attacker-controlled comment triggers ...[truncated 830 chars]
• Remediation: ## Remediation Suggestions 1. Remove automatic cron installation and prefer session-scoped polling. 2. Require explicit, separate user confirmation before creating any persistent task. 3. Display the exact scheduler command, execution identity, frequency, permissions, and cleanup behavior before installation. 4. Assign every task a unique identifier tied to one repository and pull request. 5. Set a mandatory expiration time and execution limit. 6. Automatically remove the task when the pull request is merged, closed, or no longer accessible. 7. Restrict scheduled runs to read-only status collection. Require interactive approval for code changes, pushes, force-pushes, review replies, issue closure, or branch deletion. 8. Provide a command that lists and removes all tasks created by the Skill. 9. Log scheduled activity without storing credentials or sensitive repository content.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:72
• Finding: GitHub Token May Be Exposed Through Shell Command Text## Vulnerability Details **File Location**: `SKILL.md:72-75` **Vulnerability Type**: Insecure plaintext credential handling **Risk Level**: High ```bash # Log in using the user's token echo "<token>" | gh auth login --with-token ``` ### Technical Analysis The documented authentication procedure encourages substituting a real GitHub token directly into shell command text. Although the token is passed to `gh` through standard input, it still appears as an argument to the shell's `echo` command. Depending on the execution environment, the command can be retained or exposed through: - Interactive shell history. - Terminal or agent transcript capture. - Debug or command-execution logs. - Process auditing and endpoint monitoring. - Accidental copying or command reuse. - CI logs when shell tracing is enabled. The requested token scopes include repository and workflow access. Disclosure would therefore expose a credential with meaningful mutation capabilities rather than a low-impact, read-only secret. ### Attack Path 1. A user follows the Skill documentation and replaces the placeholder with a real token. 2. The shell, terminal, agent framework, or monitoring system records the complete command. 3. Another local user, log reader, support operator, or compromised process obtains the recorded command. 4. The attacker extracts the GitHub token. 5. The attacker authenticates to GitHub and performs operations permitted by the token until it expires or is revoked. ### Impact Assessment A disclosed token may allow access to private source code, pull-request mutation, commit pushes, workflow interaction, and organizational metadata access, depending on the token type and granted scopes. The scope is all repositories and organizations authorized for that token. If workflow permissions permit workflow changes or dispatches, compromise may also affect CI/CD resources and secrets exposed to authorized workflow ex ...[truncated 9 chars]
• Remediation: ## Remediation Suggestions 1. Do not place a real token directly in shell command text. 2. Prefer `gh auth login` with an interactive, non-echoing credential prompt. 3. Where non-interactive authentication is necessary, read the token from a protected secret provider or file descriptor rather than an inline command. 4. Ensure shell tracing and command echoing are disabled while credentials are handled. 5. Use short-lived, fine-grained GitHub tokens restricted to the specific repository. 6. Request only permissions needed for the immediate operation; do not request broad `repo`, `workflow`, or organization access by default. 7. Never store tokens in tracking files, learning files, agent messages, transcripts, or repository configuration. 8. Document token revocation and rotation procedures. 9. Validate that any temporary credential file has restrictive permissions and is securely deleted immediately after use.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:38
• Finding: Untrusted Review Content Can Trigger Autonomous Repository Mutations## Vulnerability Details **File Location**: `SKILL.md:38-47` **Additional Locations**: `SKILL.md:108-114`, `references/workflow.md:48-69` **Vulnerability Type**: Unsafe processing of externally controlled instructions **Risk Level**: High The following is an English rendering of the complete affected instruction block: ```text Steps: 1. Use the gh API to retrieve all review comments. 2. Classify them as required fixes, suggested changes, or discussion. 3. For each required fix: - For a code issue, locate and fix it. - For a process issue, perform the operation, such as replying to an issue or assigning it. - For a discussion question, prepare a response. 4. Commit the fix and reply to the reviewer. ``` The detailed workflow additionally instructs the agent to modify code, run local tests, commit changes, and push updates after analyzing review comments. ### Technical Analysis GitHub reviews and comments are externally controlled input. The Skill treats that content as a source of actionable tasks but does not establish a trust boundary between review data and agent instructions. No controls are specified for: - Detecting prompt injection or instructions unrelated to the reviewed code. - Confirming the review author's identity and authority. - Restricting changes to files and lines associated with the review. - Preventing execution of commands suggested in comments. - Requiring user approval before commits or pushes. - Showing the user a proposed patch and impact summary. - Limiting GitHub operations to an explicit allowlist. - Preventing changes to workflows, security controls, credentials, or repository ownership files. A malicious reviewer, compromised GitHub account, or unauthorized commenter could attempt to shape agent behavior by presenting harmful instructions as required review feedback. ### Attack Path 1. An attacker obtains the ability to submit a review or comment on a tr ...[truncated 1134 chars]
• Remediation: ## Remediation Suggestions 1. Treat every review, issue, and comment as untrusted data rather than an instruction. 2. Never execute commands copied from GitHub comments. 3. Verify that the author has an authorized repository role before considering requested changes. 4. Convert feedback into a proposed change plan and require explicit user approval before editing files. 5. Present the complete diff, affected files, tests, and security impact before each commit or push. 6. Require separate approval for force-pushes, workflow-file changes, branch deletion, issue closure, assignment changes, and public replies. 7. Restrict automated edits to an explicit file and operation allowlist. 8. Block autonomous changes to CI workflows, authentication files, ownership rules, dependency sources, release configuration, and secret-handling code. 9. Add prompt-injection detection and reject comments that attempt to alter agent policy, request secrets, access unrelated files, or invoke tools. 10. Use read-only scheduled monitoring and reserve all mutations for an interactive, user-approved session.

T02 · Agent Memory Poisoning

Warning

• Location: LEARNING.md:3
• Finding: Untrusted Operational Content Can Persist in Tracking and Learning State## Vulnerability Details **File Location**: `LEARNING.md:3-9` **Additional Locations**: `SKILL.md:17-24`, `SKILL.md:139-143` **Vulnerability Type**: Persistent state poisoning **Risk Level**: Medium The following is an English rendering of the complete affected instruction block: ```text For each PR management task, record: 1. Problems encountered and their solutions. 2. User feedback and suggestions. 3. Areas that can be improved. 4. New ways to handle scenarios. Periodically, monthly or quarterly, review and update SKILL.md. ``` The Skill also directs the agent to create `memory/pr-tracking.md` and record all operations there. ### Technical Analysis The learning mechanism allows operational material derived from users, reviewers, issues, and other external GitHub content to be persisted and later used to update the Skill's governing instructions. No schema, sanitization rule, provenance marker, retention limit, or approval process is defined. This creates a path by which untrusted external content can be transformed into persistent guidance. The risk is elevated because the instructions explicitly contemplate updating `SKILL.md`, which controls future agent behavior. The Skill does not separate: - Trusted user decisions from untrusted reviewer text. - Objective status fields from free-form instructions. - Historical observations from executable guidance. - Repository-specific lessons from global behavior. - Temporary tracking data from long-term learning state. ### Attack Path 1. An attacker submits crafted review or issue content to a pull request managed by the Skill. 2. The agent processes that content as part of a PR-management task. 3. The agent records a derived “solution,” feedback item, or new handling method in persistent tracking or learning state. 4. During a later review cycle, the persisted material is used to update `SKILL.md` or guide another session. 5. The attacker-influenc ...[truncated 629 chars]
• Remediation: ## Remediation Suggestions 1. Do not automatically update `SKILL.md` from task-derived learning records. 2. Require human review and explicit approval for every persistent instruction change. 3. Store tracking state in a strict schema containing only necessary identifiers, timestamps, and enumerated status values. 4. Do not persist free-form review comments, external instructions, secrets, or proposed commands. 5. Label every stored item with its source and trust level. 6. Keep repository-specific state isolated from global Skill behavior. 7. Treat stored content as data and never execute or follow instructions found in memory files. 8. Define a retention period and delete tracking state when the pull request is merged, closed, or abandoned. 9. Maintain an auditable diff and rollback mechanism for approved changes to Skill instructions. 10. Sanitize persisted text against prompt injection and references to credentials, unrelated files, system configuration, or persistent task creation.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (11)

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

```bash
cd <repo-path>
git commit --amend --signoff --no-edit
git push --force-with-lease origin <branch>
```

### 3. Review 意见处理

• Confidence: 96% confidence
• Finding: The embedded command includes `git push --force-with-lease`, a high-risk parameter that can rewrite remote branch history. In an automation-oriented skill, dangerous tool parameters are more severe because they may be executed repeatedly or with insufficient human review, causing code loss, reviewer confusion, or unintended repository state changes.

Credential Access

High

• Category: Privilege Escalation

Content

### Token 权限

需要以下权限的 GitHub Personal Access Token：
- `repo` - 访问仓库代码
- `workflow` - 访问 Actions
- `read:org` - 读取组织信息

• Confidence: 89% confidence
• Finding: The skill explicitly instructs use of a GitHub Personal Access Token with broad permissions including `repo` and `workflow`, which enables code modification, workflow interaction, and broad repository access. In combination with automated PR handling, this expands blast radius significantly if the token is mishandled, over-scoped, or used in an unintended repository context.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**DCO 失败**：
```bash
git commit --amend --signoff --no-edit
git push --force-with-lease origin <branch>
```

**Format 失败**（如有配置）：

• Confidence: 86% confidence
• Finding: The workflow instructs the agent to run `git push --force-with-lease` as part of an automated remediation path. Even though `--force-with-lease` is safer than plain `--force`, it still rewrites branch history and can overwrite expected remote state if used automatically, especially in a PR-management skill that performs unattended GitHub operations. In this context, the skill is more dangerous because it is explicitly designed to manage PRs end-to-end and may apply repository-changing actions without a clear user confirmation checkpoint.

Natural-Language Policy Violations

Medium

• Confidence: 93% confidence
• Finding: SQP-3 applies to all file types and covers language or locale policy violations in natural language. The entire document is written in Chinese, including the title and operating instructions, with no indication that the user can choose another language or that the skill is intentionally region-specific.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The learning log records configuring GitHub CLI token login as part of normal operation without any mention of secure credential handling, least-privilege scopes, storage behavior, or user consent. In a PR automation skill, normalizing token setup without safeguards can lead to unsafe reuse of personal access tokens, accidental exposure in shells/logs, or overbroad repository access.

Natural-Language Policy Violations

Medium

• Confidence: 88% confidence
• Finding: The skill name, description, workflow, and interaction guidance are entirely written in Chinese, and the examples assume Chinese interaction, but there is no statement offering the user a language choice. Under the policy, forcing a specific language without opt-in is a natural-language policy concern unless the locale restriction is explicitly justified.

Vague Triggers

Medium

• Confidence: 91% confidence
• Finding: The skill description is broad enough to auto-activate on many ordinary PR-related requests, including ones involving code changes, reviews, and GitHub operations. Over-broad activation increases the chance the agent performs repository actions or enters a long-running automation flow without sufficiently explicit user intent or confirmation boundaries.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill prescribes `git push --force-with-lease` as an automatic DCO fix without an explicit warning that this rewrites commit history and may disrupt collaborators, invalidate review context, or overwrite expected branch state. In a PR automation skill, presenting force-push as a routine auto-fix is especially dangerous because the agent may apply it in unattended or loosely supervised workflows.

Natural-Language Policy Violations

Medium

• Confidence: 93% confidence
• Finding: The entire workflow is written in Chinese and presents the process as the default operating language, with no indication that users may choose another language or that the skill is intentionally limited to a Chinese-speaking context. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation.

Missing User Warnings

Low

• Confidence: 86% confidence
• Finding: The log describes creating a cron task to check PR status every two hours, but does not mention obtaining user approval, disclosing persistent background behavior, or providing cleanup instructions. For an agent skill, silently normalizing scheduled tasks can cause unauthorized persistence, unexpected API usage, and privacy or resource concerns on the user's machine.

Natural-Language Policy Violations

Low

• Confidence: 88% confidence
• Finding: This markdown file presents PR reply templates under Chinese section headings, but all suggested reply content is fixed in English. That creates a language-policy concern because the skill effectively steers users toward a specific language without any opt-in or alternative localized templates.

Static analysis

No suspicious patterns detected.