Security audit
Security checks for vulnerabilities and agentic risk
This skill is a transparent spec-writing helper that reads relevant project context and saves a reviewed Markdown spec, with no executable code or hidden persistence.
Install if you want an agent to draft project specs from repository context. Be aware it may read relevant project files and referenced GitHub issues or docs, and it will write a Markdown spec after review; review the generated boundaries before using the spec to guide implementation.
The manifest description lists several specific triggers but then expands scope to "any request to formalize requirements into a structured document," which is open-ended. That breadth, combined with phrases like "plan this out" elsewhere, makes activation boundaries unclear and increases the chance of unintended invocation.
"Plan this out" is a common phrase that can refer to many kinds of help, not specifically generating a structured implementation spec. Without additional limiting conditions or negative examples, the trigger is too broad for reliable skill selection.
Instructing the skill to gather context from available sources and not ask the user for information it can find itself encourages autonomous inspection of project files and linked resources without an explicit minimization boundary. In environments with broad workspace or network access, this can lead to over-collection of sensitive data or retrieval from external references that the user did not intend to authorize for spec generation.
### Step 1: Gather Context
Collect information from available sources. Do not ask the user for things you can find yourself.
**From the user's input:**
- What to build and why
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.
3. **Six core areas** — Commands, Testing, Project Structure, Code Style, Git Workflow, Boundaries. Use as a completeness checklist.
4. **Three-tier boundaries** — ✅ Always do (proceed without asking) / ⚠️ Ask first (need human approval) / 🚫 Never do (hard stop). More effective than flat rule lists.
5. **Modularity** — Each section should be independently useful. A coding agent working on the backend doesn't need the frontend spec section in its context.
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.
- [e.g., Commit secrets or API keys]
- [e.g., Modify CI/CD configuration]
- [e.g., Delete existing tests without approval]
- [e.g., Git commit (user handles commits)]
## 8. Out of Scope
No suspicious patterns detected.