Security audit
Security checks for vulnerabilities and agentic risk
The skill mostly matches its stated research-and-RFC purpose, but it can publish GitHub issues using the user’s credentials without a clear final confirmation step.
Install only if you want an agent that can deeply inspect a target codebase, draft research documents, and potentially publish an RFC to GitHub. Before using publication mode, require the agent to stop and show the exact target repository, files to be written, issue title/body, labels, and credential source, then approve only after reviewing the content for private or sensitive details.
This pattern attempts to override system instructions or ignore safety constraints. Without LLM analysis, manual review is recommended.
└──────────────┘
**Rule**: User-defined values always override system-learned values when they conflict.
## Visibility Tiers Pattern
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
- **Systematic Code Analysis** — Explore and understand complex codebases with structured methodologies
- **Academic Research Integration** — Find and cite relevant papers, algorithms, and prior art
- **Community Intelligence** — Analyze GitHub issues, discussions, and maintainer feedback
- **Architecture Design** — Create layered solutions with data models and phased implementation plans
- **Professional Documentation** — Generate structured technical documents in multiple languages
- **RFC Publication** — Write and submit professional RFCs to open-source communities via `gh` CLI
- **Error Resilience** — Graceful fallbacks at every phase when tools or data are unavailable
The README explicitly promotes submitting RFCs to GitHub via gh CLI, GitHub API, or browser automation, but it does not clearly warn that these actions can transmit repository content externally or create account-affecting changes under the user's credentials. In a skill context, this omission is risky because users may trigger publication workflows without understanding that networked write actions or authenticated account operations are involved.
The line says documentation is language-adaptive: Chinese projects are bilingual, while international projects are English-only. This forces output language by heuristic rather than user opt-in, which matches the policy's language/locale violation category.
The README explicitly describes publishing RFCs to GitHub via gh CLI or API, but it does not clearly warn that this causes external network actions and may create or modify public artifacts. In a skill intended to automate research and proposal submission, that omission can lead users or downstream agents to trigger unintended publication, disclosure of sensitive repository details, or other irreversible remote changes without informed consent.
The instruction 'Always generate the RFC in English' forces a specific language choice regardless of user preference. The file does not offer the user a language option or document a justified compliance-related reason for this constraint.
This line explicitly says 'Write the RFC in English,' reinforcing a mandatory language constraint. Because no opt-in or alternative is offered, it conflicts with the policy against forcing a specific language or locale.
The skill goes beyond analysis and drafting by instructing the agent to create GitHub issues and save RFCs into the target repository, which are side-effecting actions on external systems. In an agent setting, this creates a real risk of unauthorized or premature publication of content, particularly if the repository, branch, or user intent is ambiguous.
The publication flow writes repository files and creates remote GitHub issues without requiring a prominent user-facing warning or just-in-time confirmation about local modification and external disclosure. That makes accidental data exposure or unintended repository changes more likely, especially because the generated RFC may embed code analysis details gathered earlier in the workflow.
The skill includes a fallback path that performs direct authenticated API calls to GitHub using an environment token, which expands its capabilities from research/document generation into networked remote modification. This increases the chance of unintended publication or token misuse, especially because the skill content does not clearly constrain when this path may execute beyond a generic failure of the gh CLI.
This command transmits generated content to GitHub over the network using an authorization token from the environment, enabling external publication and use of sensitive credentials. In the context of an agent skill, any automatic external transmission is higher risk because it may expose repository details or publish draft content without sufficiently explicit user consent.
4. If `gh` CLI is unavailable, try GitHub API via `curl`:
```bash
curl -X POST -H "Authorization: token $GITHUB_TOKEN" \
https://api.github.com/repos/[owner]/[repo]/issues \
-d '{"title":"RFC: [Title]","body":"[RFC content]","labels":["enhancement","RFC"]}'
The GitHub API endpoint itself is not dangerous in isolation, but here it is part of an authenticated outbound publication flow that sends content to an external service. Within this skill's context, that external transmission capability materially increases risk because it enables side effects beyond local research and document preparation.
gh CLI is unavailable, try GitHub API via curl:
curl -X POST -H "Authorization: token $GITHUB_TOKEN" \
https://api.github.com/repos/[owner]/[repo]/issues \
-d '{"title":"RFC: [Title]","body":"[RFC content]","labels":["enhancement","RFC"]}'
The README says documentation is 'bilingual for Chinese projects, English-only for international projects,' which sets output language policy automatically from project classification. The policy criteria require user language/locale choice or explicit opt-in unless the constraint is clearly justified; that opt-in is not described here.
This line reiterates that Chinese projects produce bilingual documents and international projects produce English-only documents. Because it describes a fixed language rule without user choice, it reinforces the same natural-language policy issue.
No suspicious patterns detected.