threat-surface-mapper
Skill1 starsChanged 8 months agoMITView on GitHub
In this repository25 other files it gives its agents.
- abuse-case-writerSkill
- authn-authz-separatorSkill
- dependency-vuln-exposure-reviewerSkill
- input-validation-auditorSkill
- least-privilege-reviewerSkill
- secrets-handling-checkerSkill
- secure-by-design-reviewerSkill
- secure-defaults-checkerSkill
- security-misconfiguration-checkerSkill
- security-requirements-writerSkill
- session-security-reviewerSkill
- trust-boundary-identifierSkill
- abuse-case-writerSkill
- authn-authz-separatorSkill
- dependency-vuln-exposure-reviewerSkill
- input-validation-auditorSkill
- least-privilege-reviewerSkill
- secrets-handling-checkerSkill
- secure-by-design-reviewerSkill
- secure-defaults-checkerSkill
- security-misconfiguration-checkerSkill
- security-requirements-writerSkill
- session-security-reviewerSkill
- threat-surface-mapperSkill
- trust-boundary-identifierSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 34
Read the artifact from a security perspective and identify the concrete trust and exposure model.
- Distinctive: line 38
Prefer explicit attack paths, assets, boundaries, and failure conditions over generic advice.
- Distinctive: line 54
Prefer concrete attack paths and control implications over generic slogans.
- Distinctive: line 59
Do not confuse compliance language with real security risk reduction.
- Distinctive: line 60
Do not bury critical exposure behind long, unprioritized issue lists.
- Distinctive: line 61
Do not recommend controls without explaining the attack or failure they address.
- Distinctive: line 62
Do not hide uncertainty when architecture or deployment details are missing.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
threat-surface-mapper
Purpose
Map the system threat surface by enumerating assets, entry points, trust zones, attackers, and abuse opportunities.
Trigger this skill when
- The current artifact has security implications that need structured review or hardening.
- You need to turn vague security concerns into concrete findings, controls, or requirements.
- You want the next security-focused action to be explicit rather than ad hoc.
Expected inputs
- system overview
- architecture diagrams
- entry points
- data flows
- external integrations
Deliverables
- threat surface map
- asset list
- entry-point inventory
- attack hypotheses
- priority exposure notes
Operating procedure
- Read the artifact from a security perspective and identify the concrete trust and exposure model.
- Separate facts from assumptions and call out missing information that affects confidence.
- Map the highest-risk paths first rather than trying to describe every possible issue equally.
- Translate findings into concrete control or requirement language that a builder can act on.
- Prefer explicit attack paths, assets, boundaries, and failure conditions over generic advice.
- Finish with the most sensible handoff skill based on the dominant risk area you found.
Quality gates
- Findings are specific to the artifact and threat context, not generic security boilerplate.
- Output separates facts, assumptions, risks, controls, and recommended next action.
- Prioritization reflects impact and exposure, not just the number of issues found.
- Recommendations are implementable and framed in a way that can be tested or reviewed later.
Handoff targets
- trust-boundary-identifier
- abuse-case-writer
- security-requirements-writer
Output style
- Be explicit about uncertainty.
- Prefer concrete attack paths and control implications over generic slogans.
- Separate facts, risks, recommendations, and next steps.
- Make the output usable by engineers, reviewers, and test designers.
Failure modes to avoid
- Do not confuse compliance language with real security risk reduction.
- Do not bury critical exposure behind long, unprioritized issue lists.
- Do not recommend controls without explaining the attack or failure they address.
- Do not hide uncertainty when architecture or deployment details are missing.
Minimum output skeleton
## Summary
## Findings
## Structured outputs
## Risks
## Recommendations
## Recommended next skillDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

