Security Start — Pick the Right Skill

Some security asks arrive with no shape: "make this secure", "where do I start?". This skill turns one into a plan of one to three skills from this catalog, in order, and then gets out of the way. It doesn't audit anything itself.

Cross-references: every skill in the table below. The README's "Where to start" section is the long-form version of this table.

When to use

• The ask is vague: "is my app secure?", "help me with security", "what should we check first?"
• The user doesn't know which of the skills applies, or asks which one to use
• A quick look at the repo is enough to decide (package.json, Dockerfile, .github/workflows/, Terraform, an .apk)

Not for: any ask that already names its subject. Route those straight to the owning skill without this one: a pasted finding → finding-triage; a CVE → vuln-research; "OWASP audit" → owasp-audit; a workflow file → cicd-security; "SOC 2" → control-audit; "we've been hacked" → incident-triage.

Authorization

• Read-only. This skill reads file names and manifests in the current repo to decide; it doesn't run tools or touch any system.
• The skills it hands off to carry their own authorization checks. Offensive skills (recon, osint-recon, web-pentest, red-team-engagement, business-logic-testing) need written authorization for the target. Say so when routing to them.

Workflow

Step 1 — Look before asking

If there's a repo, spend a minute on it before asking anything:

ls; ls .github/workflows 2>/dev/null
ls package.json requirements.txt pyproject.toml go.mod Cargo.toml Gemfile pom.xml 2>/dev/null
ls Dockerfile docker-compose.yml *.tf k8s helm 2>/dev/null

Note the language, frameworks, whether there's an API, CI, containers, IaC, an AI feature, a mobile app.

Step 2 — Ask at most three questions

Only ask what Step 1 didn't answer:

1. What do you have? Source code, a deployed app you're allowed to test, cloud accounts, logs, a single finding, a suspicious file, a regulation or an auditor.
2. What's happening? Building something new, about to ship, an incident right now, a CVE wave, an audit date, general worry.
3. Who's it for? Just you, your engineers, or a board, a customer or an auditor.

An active incident skips the questions: go straight to incident-triage.

Step 3 — Route

Pick from the table. Most asks need one skill, some two or three in sequence. Prefer the cheapest first step that gives real evidence.

If two rows fit, pick the one closest to real evidence: code over policy, the deployed thing over the diagram.

Step 4 — Hand off

Say which skill comes first and why in one line, then the next steps. Start the first skill straight away if the user agrees. Don't summarize what the skills will find.

Output Format

## Security start
**What you have:** [source / live app / cloud / logs / file / audit]   **What's happening:** [situation]

1. `skill-name` — [why this first, one line]
2. `skill-name` — [what it adds after step 1]
3. `skill-name` — [optional]

[One line on authorization, if any step is offensive.]

Boundaries

• Routing only. No findings, no severities, no tool runs.
• Never route an offensive skill without saying it needs written authorization for the target.
• If nothing in the catalog fits, say so plainly rather than stretching a skill.

References

• README "Where to start" and the skill map (this table is a condensed version)
• Router skills elsewhere informed the shape: obra/superpowers using-superpowers (MIT), addyosmani/agent-skills using-agent-skills (MIT), and the foundation skill in coreyhaines31/marketingskills (MIT). Paraphrased, nothing copied.