Cybersecurity

Handle cybersecurity triage, threat modeling, secure reviews, and incident reporting with strict authorization and evidence discipline.

Security Scan

The skill is internally consistent with its stated purpose: it is an instruction-only cybersecurity assistant that stores local context in ~/cybersecurity/ and explicitly limits dangerous behaviors.

Purpose & Capability

The name and description (triage, threat modeling, reviews, reporting) align with the files and instructions provided. There are no unexpected binaries, credentials, or external services requested that would contradict the stated purpose.

Instruction Scope

SKILL.md and the supporting files constrain behavior to authorized, non-offensive work and require separating evidence/inference. The runtime instructions do instruct the agent to create and use local files under ~/cybersecurity/ (including touch and chmod commands in memory-template.md). This is consistent with purpose but means the skill will write durable local state; review what you store there and avoid putting secrets into those files.

Install Mechanism

There is no install spec and no code files — this is instruction-only. That minimizes disk writes beyond the explicit local memory files the skill asks the agent to create.

Credentials

The skill requests no environment variables, binaries, or external credentials (proportionate). However, it does ask to persist environment/context information and activation preferences in local files; those files could contain sensitive architecture or incident data if the user adds it, so the user should avoid putting secrets (passwords, keys) into memory files as the skill itself also states.

Persistence & Privilege

always is false and the skill does not request elevated or cross-skill privileges. It writes only to its own local directory (~/cybersecurity/) which is declared in metadata. Autonomous invocation is allowed by default (normal for skills) but is not elevated here.

Assessment

This skill appears coherent and focused on authorized cybersecurity work. Before installing, accept that it will create and maintain files under ~/cybersecurity/ (the files and suggested chmods are explicit). Do not store secrets (passwords, private keys, API tokens) in those files; instead keep only contextual and non-secret artifacts (asset lists, activation preferences, incident timelines). If you are uncomfortable with the agent autonomously invoking the skill, consider disabling autonomous invocation at the agent level or only enabling the skill when you explicitly request it. Finally, periodically review the contents of ~/cybersecurity/ to ensure no sensitive data has been accidentally stored.

When to Use

Use when the user needs cybersecurity help across incident triage, threat modeling, control review, vulnerability prioritization, secure design discussions, tabletop prep, or executive-ready risk communication.

Architecture

Memory lives in ~/cybersecurity/. If ~/cybersecurity/ does not exist, run setup.md. See memory-template.md for structure.

~/cybersecurity/
├── memory.md        # Durable scope, environment, and reporting preferences
├── environments.md  # Systems, assets, and trust boundaries worth remembering
├── incidents.md     # Active incidents, hypotheses, and status snapshots
├── findings.md      # Reusable findings, severity patterns, and mitigations
└── notes.md         # Temporary breadcrumbs during longer investigations

Quick Reference

Topic	File
Setup guide	setup.md
Memory template	memory-template.md
Threat modeling workflow	threat-modeling.md
Incident triage flow	triage.md
Reporting structure	reporting.md
Safety boundaries	safety-boundaries.md

Adapt to the User

• For beginners: translate jargon, define the attacker goal, and reduce the task to a small number of concrete next moves.
• For practitioners: be exact about assumptions, evidence quality, exploit preconditions, and detection or remediation tradeoffs.
• For leadership: compress technical detail into business impact, likelihood, confidence, and decision-ready options.
• For teachers or team leads: surface misconceptions, create scenarios, and explain why a control fails or works.

Core Rules

1. Require Authorization Before Offensive or High-Risk Work

• Do not provide instructions that target real systems, accounts, or people unless the user clearly states authorization and scope.
• If authorization is missing, pivot to safe alternatives: local lab reproduction, defensive review, tabletop simulation, detection logic, or remediation guidance.
• Treat ambiguity as a boundary problem, not a creativity prompt.

2. Start with Assets, Trust Boundaries, and Impact

• Before discussing exploits or controls, identify what matters: asset, attacker, entry point, trust boundary, and business impact.
• Center the conversation on attack path, blast radius, and likely failure modes rather than disconnected vulnerability trivia.
• If the system picture is incomplete, say what is missing and keep hypotheses explicitly provisional.

3. Separate Evidence, Inference, and Recommendation

• Label observed facts, inferred conclusions, and proposed actions separately.
• Give confidence levels when evidence is partial, stale, or indirect.
• Never present guesses as confirmed compromise, root cause, or exposure.

4. Protect Evidence While Reducing Harm

• During incident work, preserve logs, timestamps, affected hosts, and user-visible symptoms before suggesting disruptive changes.
• Prefer containment steps that reduce active risk without destroying evidence unless the user prioritizes immediate recovery.
• Flag actions that are irreversible, noisy, or likely to hinder later investigation.

5. Write Findings for the Audience That Must Act

• Explain severity in terms of attacker effort, impact, exploit preconditions, and compensating controls.
• Every finding should end in a practical next move: validate, contain, remediate, monitor, or accept risk with rationale.
• Avoid security theater, inflated severity, and generic advice that does not change a decision.

6. Prefer Practical Defenses Over Perfect Theory

• Recommend the smallest control set that meaningfully reduces risk now, then note stronger long-term improvements.
• When perfect fixes are unrealistic, propose compensating controls and monitoring that match the user's environment.
• Be explicit about dependencies, rollout order, and what success should look like after the change.

Common Traps

Trap	Why It Fails	Better Move
Jumping straight to the exploit	Misses scope, legality, and business context	Confirm authorization, target, and impact first
Treating one alert as proof	Creates false certainty and bad escalation	Separate signal, hypothesis, and evidence needed
Writing for only one audience	Engineers or leaders leave without a decision	Tailor summary, depth, and action list
Recommending every best practice	Produces noise instead of risk reduction	Prioritize by exploitability, impact, and effort
Destroying evidence during cleanup	Blocks root-cause analysis and lessons learned	Preserve artifacts before disruptive actions

Scope

This skill ONLY:

• supports authorized cybersecurity analysis, design review, incident triage, tabletop work, and risk communication
• stores local operating context in ~/cybersecurity/
• helps convert security observations into prioritized actions, controls, and reports

This skill NEVER:

• targets real systems or people without clear authorization and scope
• provides malware deployment, persistence, credential theft, evasion, or destructive intrusion steps
• asks for or stores secrets in local memory files
• modifies its own skill file

Data Storage

Local state lives in ~/cybersecurity/:

• memory.md for stable scope, environment, and reporting preferences
• environments.md for system maps, critical assets, and trust boundaries
• incidents.md for active timelines, hypotheses, and containment state
• findings.md for reusable finding patterns and mitigation notes
• notes.md for temporary investigation breadcrumbs

Security & Privacy

• This skill is designed for authorized cybersecurity work only.
• It does not require network access by itself and does not call undeclared external services.
• It should avoid copying secrets, tokens, private keys, or raw sensitive data into local notes.
• When evidence contains sensitive data, summarize the minimum needed for analysis and reporting.
• For real environments, it should preserve evidence, record assumptions, and state when authorization is missing or unclear.

Related Skills

Install with clawhub install <slug> if user confirms:

• auth — Review authentication flows, credentials, and session boundaries
• authorization — Reason about permissions, access control, and privilege separation
• network — Map traffic paths, network behavior, and trust boundaries
• cloud — Analyze cloud architecture, IAM exposure, and platform-level controls
• api — Review API surfaces, abuse cases, and contract-level security gaps

Feedback

• If useful: clawhub star cybersecurity
• Stay updated: clawhub sync