Security audit
Security checks for vulnerabilities and agentic risk
This skill is a bounded spec-writing workflow with disclosed local document creation and a git commit step, but no hidden code, network behavior, credential use, or destructive actions.
Before installing, be aware that this skill may read repository context, write a spec file under docs/specs, and create a git commit for that document. Review the generated spec and repository diff before allowing the write or commit if your environment treats commits as triggers for automation.
The skill advertises itself as producing a system-agnostic spec through collaborative dialogue, but its workflow includes repository-specific writes and version-control operations. This hidden side-effect expands the trust boundary from conversation-only assistance to persistent local and source-control modification, which can surprise users and automation.
The skill explicitly frames itself as ending at a written spec and not transitioning into other activities, yet later instructs the agent to write files and commit to git. That mismatch can cause users and downstream systems to grant broader permissions than expected or perform repository mutations under a misleading, low-risk label.
The skill directs the agent to write a file and commit it without an explicit warning or fresh consent at the point of mutation. In practice, this can lead to silent filesystem and repository changes that users did not realize would occur, especially because the skill is presented as a brainstorming/specification aid rather than a modifying tool.
Automatic git commits are not necessary to brainstorm or draft a spec, so embedding them in the skill creates unnecessary capability and risk. A commit can permanently record unwanted content, trigger CI/CD or policy hooks, and make accidental changes harder to notice or undo in agentic workflows.
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.
**Only fix issues that would cause real problems downstream.**
A downstream planning system acting on this spec should be able to:
- Understand what to build without asking the user again
- Decompose requirements into tasks
- Know what's in scope and what's not
- Understand the constraints they're working within
No suspicious patterns detected.