Security audit
Security checks for vulnerabilities and agentic risk
This migration-planning skill is not malicious, but it deserves review because its workflow can move from planning into GitHub issue creation and orchestrated execution without a clearly separate execution confirmation.
Install only if you are comfortable with this skill reading a full legacy repository, writing migration artifacts into the target repo, checking GitHub CLI auth, and, after approval, creating GitHub issues. Before using the delivery phases, confirm that the downstream write-specs, create-issues, and orchestrator skills are trusted, and require a separate explicit confirmation before any orchestrator execution, especially because the artifact says it may execute all approved SPECs including pre-existing ones. Also adjust or avoid the skill if Portuguese-only prompts would make approvals unclear.
Referenced artifact was not completely inspected
skills (`write-specs`, `create-issues`, `orchestrator`) and read their current `SKILL.md`. If one is missing, block only its phase and report an actionable diag
The file explicitly requires that all questions and confirmations to the user be in Portuguese (pt-BR). This is a natural-language locale constraint applied by default, and the skill does not offer opt-in, alternative language selection, or a region-specific justification that would exempt it under the policy.
The skill instructs the agent to confirm the target stack with the user specifically in pt-BR, reinforcing a mandatory language policy. Because this requirement is imposed rather than offered as a preference, it conflicts with the locale-choice requirement.
The approval gate is marked '(pt-BR)' and provides the user-consent prompt only in Portuguese. For a critical confirmation step, forcing one language without user opt-in can impair clarity and violates the stated language/locale policy requirements.
This line codifies a mandatory Portuguese-only interaction rule for ambiguity resolution and user questions. Since the skill is otherwise general-purpose and not clearly limited to a pt-BR-only environment, this is an unjustified locale restriction.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
### MUST NOT DO
- Guess the meaning of acronyms, internal terms, or business logic.
- Recommend technologies without verification.
- Write implementation code — this skill produces plans, SPECs, and Issues only.
- Assume migration direction or target stack without evidence; assume .NET when the user asked for something else; silently default to .NET when the user never stated a target — ask in pt-BR with .NET as the recommended answer.
- Skip RESEARCH or merge it with PLAN.
The file hard-codes Portuguese (pt-BR) for user-facing confirmation in a planning workflow without any user opt-in or documented business/safety reason. This can cause the agent to communicate in an unexpected language, reducing user comprehension and informed approval quality, especially at decision points that affect migration direction.
Requiring the agent to ask the user in pt-BR specifically when migration direction is ambiguous is risky because ambiguity is exactly when clear consent and understanding matter most. Forcing a language the user may not understand can lead to incorrect architectural choices or invalid confirmation, making the workflow less trustworthy and potentially unsafe.
Mandating a pt-BR summary in the GATE phase introduces a language constraint at an approval checkpoint, where the user must understand the summary before responding. In this skill context, the gate controls progression to issue creation and execution handoff, so misunderstanding can directly affect downstream operational changes.
The skill hard-codes Portuguese responses ('ask the user (in pt-BR) instead') without any user preference check. This can override the user's expected language, reduce transparency around clarification requests, and create consent/usability issues, especially in security- or access-related exchanges where precise understanding matters.
The instruction to ask for repository access specifically in pt-BR forces a language switch during a sensitive operational step. In access-related communications, this can confuse users, slow remediation, and increase the chance of misunderstandings about credentials or authorization boundaries.
Line L03 states that 'The planner stops at plans,' which implies no delivery or execution actions are part of this skill's role. Later sections nevertheless prescribe creating GitHub issues, updating SPECs/roadmaps with ticket data, writing run-state memory, and invoking an orchestrator to execute all approved SPECs, creating an internal contradiction in the file's stated intent.
The file instructs that write-specs runs its own pt-BR interview, which imposes a specific language requirement in the workflow. The document does not provide a user choice, fallback, or explicit justification for why Portuguese is required.
The instructions require presenting the approval gate summary in pt-BR and include a fixed Portuguese confirmation prompt. This is a language-policy constraint applied to the user-facing flow without any option to choose another language.
The manifest says migration-planner should be used for analysis and planning, and explicitly says not to use it to implement code. This handoff document goes beyond planning by defining post-approval creation of GitHub Epic/slice issues and invocation of an orchestrator that executes approved SPECs, which expands the documented behavior past producing a migration plan and per-domain SPECs.
The examples section reiterates that all user-facing questions and gates must be in pt-BR. Although duplicative of earlier instructions, it still embeds a hardcoded locale rule that does not provide user choice.
No suspicious patterns detected.