Security audit
Security checks for vulnerabilities and agentic risk
This skill is a disclosed Rails CI repair workflow that uses GitHub and local test commands in a purpose-aligned way, with human approval required before commits and merges.
Install this only if you are comfortable letting an agent run Rails tests and RuboCop in repositories you own and trust, and give GH_TOKEN only repo-specific contents:write and actions:read permissions. Review diffs before approving commits, keep branch protection enabled, and do not use it on untrusted third-party code.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
## GH_TOKEN Scoping
Use a **fine-grained personal access token** scoped to the specific repo:
- Grant: `contents: write` (push to feature branches), `actions: read` (view CI logs)
- Do NOT grant org-wide or admin permissions
- Set an expiration date and rotate after use
The trigger phrases include very common developer language such as 'fix CI', 'CI is failing', 'watch the PR', and 'the build is broken', which can cause the skill to activate in routine conversation without a deliberate request. Because this skill pulls CI logs, runs repository code locally, and may push changes to a feature branch after human approval, accidental invocation can expose the agent to untrusted code execution and unintended repository modifications.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- name: Install system dependencies
run: sudo apt-get install -y libvips-dev
The file presents inconsistent safety guarantees: it says the skill pauses for human approval before committing, yet also describes automatic commits/pushes to a feature branch. In a tool that executes repository code and has write access to GitHub, ambiguous approval/commit semantics can mislead operators into granting trust or tokens under false assumptions, increasing the chance of unintended code changes being pushed.
L33 asserts a strict policy around what is and is not committed, but the surrounding documentation elsewhere in the file describes the skill as making commits automatically. Given the manifest's requirement to pause before committing, this creates inconsistent intent documentation about when and under whose approval commits occur. The contradiction is documentation-level rather than a code-level implementation detail.
No suspicious patterns detected.