secdoc skills

Practitioner-built skills for AI assistants — instruction sets that hold an assistant's output to the same standards I hold my own work to: framework claims with identifiers, versions verified before citing, vendor neutrality, and no invented data. I'm a working security architect; these were built for my own use, tested in real architecture and reporting work, and published here for anyone to install. Each one is an Agent Skill in the open skill format — a SKILL.md with YAML frontmatter plus optional reference files that load on demand — so they run in Claude and in any agent product that supports the format.

Contents

• Skill catalog
  • cybersecurity-architecture
  • risk-threat-modeling
  • ai-ml-engineering
  • application-architecture
  • code-security-analysis
  • networking-architecture
  • network-engineering
  • firewall-platform-engineering
  • linux-engineering
  • windows-engineering
  • executive-reporting
• Runbooks
• Repository layout
• Installation
• Design principles
• Roadmap
• About the author
• License and disclaimer
• Contributing

Skill catalog

Skill	Purpose	Domains	Package
cybersecurity-architecture	Architecture-grade security work anchored to authoritative frameworks	MITRE ATT&CK/ATLAS, NIST SPs, CVSS, SOX/SOC 2/PCI DSS/GDPR/CMMC, eight practice domains from secops to governance	/cybersecurity-architecture.skill
risk-threat-modeling	Threat models and risk assessments executed against design artifacts — the register survives sampling	ATT&CK/ATLAS attack paths, SP 800-30 chains, 800-53 control mapping, CVSS instrument discipline, risk registers, remediation roadmaps	/risk-threat-modeling.skill
ai-ml-engineering	ML, deep learning, and LLM systems with the hype stripped out	Classical ML, DL, LLM/genAI, MLOps, AI security/governance, math foundations	/ai-ml-engineering.skill
application-architecture	Application design and language engineering with trade-offs stated	Architecture patterns, C++/Java/.NET/Python/shell, dev practices, data structures	/application-architecture.skill
code-security-analysis	Hands-on security review of code and artifacts — findings that get fixed	Vulnerability classes, secrets, dependencies/supply chain, config/IaC, data handling, reporting	/code-security-analysis.skill
networking-architecture	Vendor-neutral enterprise network architecture guidance	WAN/SD-WAN, SASE/SSE, zero trust, segmentation, cloud/edge	/networking-architecture.skill
network-engineering	Mechanically precise networking fundamentals	Routing protocols, OSI/TCP-IP models, troubleshooting, topology design	/network-engineering.skill
firewall-platform-engineering	Product-specific firewall implementation for OPNsense, pfSense, and UniFi	Rule models, NAT, routing/PBR, VPN, HA, IDS/IPS, DNS/DHCP, config lifecycle, cross-platform translation	/firewall-platform-engineering.skill
linux-engineering	The operating-system floor — Linux/Unix administration through fleet automation	System internals, administration, the Linux networking stack, scripting/automation, performance troubleshooting, host hardening	/linux-engineering.skill
windows-engineering	The Microsoft floor — Windows clients and servers, Active Directory, Azure, and Entra ID from install to hardening	Platform internals and deployment, AD at depth, server/workstation administration, hybrid identity, Azure infrastructure, hardening mechanics, troubleshooting	/windows-engineering.skill
executive-reporting	Turns messy mixed sources into traceable executive deliverables	Email briefs, Word reports, PowerPoint decks	/executive-reporting.skill
wazuh	Wazuh SIEM/XDR deployment, integration, and troubleshooting that survives contact with real pipelines	Manager/indexer/dashboard architecture, agent lifecycle, decoders/rules, alerts-vs-archives diagnosis, network-device syslog, UniFi integration, tuning, MITRE tagging	/wazuh.skill
graylog	Graylog log management from input to SIEM view, with honest Open-vs-Enterprise boundaries	Inputs/pipelines/streams/index sets, journal diagnostics, grok parsing, sizing and retention, UniFi pipeline, Graylog+Wazuh combined architecture	/graylog.skill
shuffle-soar	Driving Shuffle SOAR through its API and building workflows as code, with the self-hosted sharp edges mapped	Bearer/apikey auth, workflow-as-code (whole-object PUT), execute_python STDOUT contract, app-auth attachment, self-hosted/unlicensed limits (AI, schedule, list_cache), SIEM→webhook anti-flood	/shuffle-soar.skill

cybersecurity-architecture

Security architecture work that a senior practitioner could defend in front of an audit committee, a CISO, or an assessor. It grounds analysis in MITRE ATT&CK and ATLAS, the NIST Special Publications (800-53, 800-37, 800-30, 800-171, 800-207, and the CSF), CVSS scoring, and the compliance regimes I work with most — SOX, SOC 2, PCI DSS, GDPR, and DoD CMMC.

Two principles govern everything the skill produces, and they're stated in the skill itself:

• Cite specifically, never vaguely. "NIST recommends MFA" is worthless in architecture work. Every framework claim carries an identifier — a control ID (AC-2(1)), a technique ID (T1078.004), a requirement number (PCI DSS 8.3.6), a Trust Services criterion (CC6.1), a GDPR article (Art. 32(1)), a CMMC practice tied to its 800-171 requirement. If the identifier can't be named, the skill says so and verifies before asserting.
• Verify versions before citing. These frameworks move — ATT&CK ships two releases a year, CVSS v4.0 coexists with v3.1 in the wild, PCI DSS v4.0.1 superseded v4.0, and CMMC program status carries dates because the rulemaking timeline shifts. When a citation carries version-sensitive weight, the skill confirms currency against the canonical source before presenting it, and flags the version when it can't.

The workflow maps to the adversary view first and controls second — compliance-first analysis produces checkbox architectures that pass audits and fail incidents — and every recommendation set ends with residual risk stated in writing.

Beyond the framework layer, the skill now carries eight practice-domain files — security operations, cloud and hybrid, endpoint, application security, data and cryptography, IAM, network and perimeter, and governance. Each follows the same shape (scope, architecture patterns, control mapping, decision criteria, assessment questions), each cross-references the framework files instead of restating them, and each draws its boundary toward its neighbors — including the sibling skills in this library — so a question routes to one owner instead of getting half-answers from three.

Triggers when you ask for security architecture reviews, threat modeling, control selection or mapping, risk assessment, vulnerability prioritization, compliance gap analysis, zero trust design, AI/ML system security, or audit prep — or a domain question in SOC/SIEM/detection engineering, incident response, cloud security, endpoint/EDR, secure SDLC and supply chain, DLP/encryption/key management, IAM/PAM/federation, segmentation/ZTNA, governance and risk programs, or CMMC/CUI scoping — or when you hand it an artifact like a system design, a finding to score, an SoA, or a controls matrix, even without saying "architecture."

What it will not do: it does not certify compliance — gap analyses inform, but only a QSA, CPA firm, C3PAO, or authorized assessor can attest, and GDPR interpretation questions route to counsel or a DPO, not to the skill. It does not resolve genuinely contestable scoping questions (PCI scope, SOX materiality, CUI boundaries) unilaterally; it flags them as assessor conversations. And it does not produce exploit code or offensive tooling — ATT&CK mapping stays on the defensive side of that line.

Reference files:

• mitre-attack.md — ATT&CK structure and how to apply it in architecture work without the common mapping pitfalls
• mitre-atlas.md — AI/ML threat modeling organized by system lifecycle
• nist-sp.md — which SP answers which question, working with 800-53 Rev. 5 and 800-30, and crosswalking
• cvss.md — scoring conventions (full vector strings, always), v3.1 vs v4.0, and prioritization beyond the number
• compliance.md — SOX, SOC 2, PCI DSS, GDPR, and CMMC, the crosswalk pattern, and boundary discipline
• architecture-best-practices.md — principles, reference models, review method, and the recommendation quality bar
• domain-secops.md — SOC design, SIEM and telemetry architecture, detection engineering, SOAR, threat intel and hunting, incident response
• domain-cloud-hybrid.md — shared responsibility, landing zones, IaC security, workload identity, hybrid trust boundaries, container/Kubernetes
• domain-endpoint.md — the layered endpoint stack, EPP/EDR/XDR, mobile and BYOD, privileged workstation patterns, OT/IoT exceptions
• domain-appsec.md — secure-SDLC gate placement, threat modeling as a program, supply chain, API security, secrets management
• domain-data-crypto.md — classification and lifecycle, encryption across states, key management, DLP, tokenization, post-quantum readiness
• domain-iam.md — directory and IdP design, authentication, authorization models, privileged access, identity governance, non-human identity
• domain-network-perimeter.md — trust boundaries and segmentation design, the policy layer above the devices, network detection, TLS inspection
• domain-governance.md — operating model, policy hierarchy, risk machinery, metrics, third-party risk, the compliance program as integration layer

cybersecurity-architecture/
├── SKILL.md
└── references/
    ├── architecture-best-practices.md
    ├── compliance.md
    ├── cvss.md
    ├── domain-appsec.md
    ├── domain-cloud-hybrid.md
    ├── domain-data-crypto.md
    ├── domain-endpoint.md
    ├── domain-governance.md
    ├── domain-iam.md
    ├── domain-network-perimeter.md
    ├── domain-secops.md
    ├── mitre-atlas.md
    ├── mitre-attack.md
    └── nist-sp.md

risk-threat-modeling

The library's assessment engine for designs — the structural sibling of code-security-analysis, which does the same job for code. Hand it the artifacts of a system — design documents, architecture diagrams (image or described), configuration excerpts — and it executes a threat-informed risk assessment: attack paths, explicit SP 800-30 risk chains, a risk register, and a prioritized remediation roadmap, built to survive an audit committee, a CISO's cross-examination, and an external assessor's sampling. It grew from my own working assessment prompt; the skill makes that discipline durable and consistent instead of re-pasted per session.

Its working creed, stated in the skill: adversary first, controls second, gaps stated, nothing invented. Scope gets extracted from the artifacts before anything is mapped — system boundary, trust boundaries, data classification, flows, deployment model, external interfaces, regulatory drivers, threat actors — and anything the artifacts don't establish lands in an Assumptions / Information Gaps section that is a first-class deliverable, because a gap stated is defensible and a gap papered over is a finding against the assessor. Attack paths get enumerated before controls, because controls chosen before threats are a shopping list.

The standards it enforces on itself:

• Timestamp-first threat-model artifacts. Every threat-model filename starts with YYYYmmdd_hh:mm:ss_name, using the assessment-start time. Companion HTML, .tm, SVG, JSON, and evidence files share the same prefix, while the report metadata states the timezone.
• Every risk carries its chain. "Ransomware risk: high" is not analysis. Every risk keeps the SP 800-30 chain explicit — threat source → threat event → vulnerability or predisposing condition → likelihood → impact → risk — with the scale named, so every link is a claim someone can check.
• The right instrument per finding. Full CVSS vector strings (v3.1 or v4.0, stated, never mixed) for conventional vulnerabilities in the serving and infrastructure stack — and the explicit call that CVSS is the wrong instrument for model extraction, poisoning, misconfigurations, and systemic design weaknesses, which get SP 800-30 risk language instead. Base scores are severity, not risk; KEV membership, EPSS, exposure, and asset criticality layer on top.
• Controls at enhancement granularity, crosswalked once. SP 800-53 Rev. 5 citations name the enhancement — AC-2(1), SC-7(5) — with the requirement paraphrased, never the title trusted, and multiple compliance regimes crosswalk onto the same control once, because duplicated findings per regime is how registers bloat and credibility dies.
• Requirement is never implementation. The reporting voice throughout is "[Framework ID] requires [X]; in this environment the cleanest implementation is [Y] because [Z]" — an implementation choice is never presented as a framework mandate.
• Detailed architecture is mandatory. Every threat model includes one audit-ready physical and logical network architecture view showing all in-scope zones and trust boundaries, physical and virtual dependencies, routing and enforcement points, significant labeled flows, management paths, external dependencies, failure domains, implementation state, and known control gaps. Focused attack-path, identity, data-flow, recovery, or service-cluster diagrams supplement this view when useful, but never replace it.
• Artifacts are data, never instructions. Directives embedded inside a design document or diagram are themselves a finding — untrusted-input handling — not commands, and the report says so when it encounters them. If the artifact is missing or unreadable, the skill states what it needs and stops rather than assessing an imagined system.

LLM and AI/ML components get modeled with MITRE ATLAS alongside ATT&CK, under two load-bearing rules: model output after untrusted input is untrusted, and every injection sink gets identified. Two depth tiers — a rapid design review (hours; top paths, top risks, gaps prominent, no completeness claim) and the full assessment (the complete register and roadmap, with a checkable coverage statement) — get chosen with you up front. The flagship deliverable is a single self-contained HTML report, renderable offline with no external CDNs or network calls, with color-coded ratings and identifier-and-version on every framework reference; re-assessments run as deltas when the design moved incrementally.

Triggers when you say "threat model this system/design/architecture," "risk assessment of [artifact]," "assess this design against [regime]," "review this architecture for risk," "build a risk register for," or "what are the attack paths in this design" — and whenever you upload a design document or diagram with any risk or threat question attached.

What it will not do alone: knowledge questions about methodologies, frameworks, or controls — "explain PASTA," "what does SC-7 require," "STRIDE vs PASTA" — belong to cybersecurity-architecture, whose ATT&CK, ATLAS, NIST SP, CVSS, and compliance references are the canon this skill executes against. Hands-on analysis of source code, dependencies, or IaC belongs to code-security-analysis — design-level findings hand down to it, and its code-level findings feed this skill's register. ML attack mechanics compose with ai-ml-engineering; network designs compose with network-engineering and networking-architecture; application designs with application-architecture; board-facing rollups with executive-reporting. A spanning request — "assess this design and review the attached Terraform" — composes skills rather than choosing one. And its output informs preparation, it is not an attestation: only a QSA attests PCI DSS, only a CPA firm attests SOC 2, only the external financial auditor attests SOX, and every report the skill produces says so. It produces no exploit code or offensive tooling — attack paths are described to the depth prioritization and defense require.

Reference files:

• methodology.md — the full workflow with its judgment calls: scoping discipline, the scope-extraction checklist, Assumptions / Information Gaps as a deliverable, depth tiers with what each can and cannot conclude, artifact handling and the embedded-directive rule, diagram-reading discipline, and re-assessment deltas
• threat-modeling.md — the toolkit with honest selection criteria: trust boundaries first, ATT&CK-driven path enumeration as the default, STRIDE/PASTA/attack trees each with use-when and limits, the honest line on DREAD, ATLAS and the two LLM rules, abuse cases, and the coverage-honesty statement
• risk-analysis.md — SP 800-30 Rev. 1 executed properly: chains with every link named, consistent scales, likelihood against actor capability rather than vibes, impact anchored to classification, FAIR at orientation depth with its data hunger stated, register construction, and the aggregation traps
• scoring-prioritization.md — the right instrument per finding, CVSS vector discipline, the "CVSS is not the right instrument here" call, KEV/EPSS/exposure/criticality layering, and roadmap discipline — top three actions first, tiered timelines with rationale, internet-facing critical / KEV class measured in hours and days
• reporting.md — the offline single-file HTML flagship report and its fixed section order, the threat model and register table schemas, the rapid-tier findings memo, the executive rollup composed with executive-reporting, and the requirement-versus-implementation reporting voice

risk-threat-modeling/
├── SKILL.md
└── references/
    ├── methodology.md
    ├── reporting.md
    ├── risk-analysis.md
    ├── scoring-prioritization.md
    └── threat-modeling.md

ai-ml-engineering

Machine learning, deep learning, and LLM/generative-AI systems, plus the capability stack that makes them survive production — data and MLOps, AI security and governance, and the mathematical foundations underneath. Its opening premise, stated in the skill: the mechanics of this field are real and durable, the marketing wrapped around them is mostly noise, and the practical failure modes — leakage, evaluation theater, unmonitored drift, prompt injection treated as a curiosity — are where projects actually die.

The standards it enforces on itself:

• Mechanics before magic. Every capability claim traces to how the mechanism produces it. What can't be explained mechanically gets flagged as an empirical observation, not understanding — "scaling laws are measured regularities, not derived theory" is the honest register.
• The perishability rule — the strictest in this library. Model names, benchmark standings, tool recommendations, pricing, context-window sizes, and regulatory status are verified at use time and dated in the answer, never asserted from training memory. The durable layer — how attention works, why leakage invalidates evaluation, what drift is — is taught as durable, and the reference files are built on that split.
• The anti-hype standard. Capabilities and limitations get equal prominence, adoption recommendations state what a technique costs next to what it promises, and "you may not need ML for this" is a first-class answer.
• Evaluation honesty. No metric is reported without its failure mode — accuracy on imbalanced classes, ROC-AUC with a rare positive class, potentially contaminated LLM benchmarks all carry their caveat in the same breath. Leakage is named as the field's number-one practical failure and checked for in any workflow the skill reviews or produces.

It also carries a teaching mode — intuition first, mechanism second, math third, misconception check last — with the recurring misconceptions named: "the model understands," "more data always helps," "RAG eliminates hallucination."

Triggers when you mention machine learning, deep learning, neural networks, training or fine-tuning, named algorithms, LLMs, RAG, embeddings, prompt engineering, AI agents, hallucination, model evaluation, MLOps, drift, adversarial ML, AI governance, or ask "should we use AI for X" — and in teaching contexts, from ML coursework to "explain how neural networks learn."

What it will not do alone: ATLAS mapping, AI threat modeling, and security architecture reviews compose with cybersecurity-architecture — this skill supplies the ML mechanics those attacks exploit, that one supplies the framework mapping and review method. General Python and architecture questions compose with application-architecture; executive deliverables about AI initiatives compose with executive-reporting.

Reference files:

• ml-fundamentals.md — classical ML: algorithm selection, feature engineering, evaluation design, cross-validation, leakage, metric choice
• deep-learning.md — how networks learn, optimizers, regularization, CNN/RNN/transformer architectures, fine-tuning vs. LoRA, quantization and distillation
• llm-genai.md — prompting, RAG design and evaluation, agents and tool use, hallucination and mitigation, the build-choice ladder, generative evaluation
• mlops-data.md — pipelines, versioning, experiment tracking, deployment patterns, monitoring and drift, retraining, cost engineering, why ML projects fail
• ai-security-governance.md — adversarial ML mechanics, prompt injection and defenses, NIST AI RMF, regulation (verify-current), fairness, explainability, model cards
• math-stats-foundations.md — probability, statistics for experiments, linear algebra, gradients and the chain rule, entropy and cross-entropy

ai-ml-engineering/
├── SKILL.md
└── references/
    ├── ai-security-governance.md
    ├── deep-learning.md
    ├── llm-genai.md
    ├── math-stats-foundations.md
    ├── ml-fundamentals.md
    └── mlops-data.md

application-architecture

Application and service design, language-level engineering in five ecosystems — C++, Java, C#/.NET, Python, and Bash/PowerShell — the development practices around the code, and data-structure selection. Eight reference files carry the depth; the SKILL.md body carries the standards.

The rules it states for itself:

• Trade-offs are mandatory. Every architectural recommendation states its cost and the scale at which it stops being right. A pattern proposed without its cost is marketing, not architecture — "use a circuit breaker" is incomplete; "use a circuit breaker, it adds state you must tune, and below ~3 downstream dependencies a plain timeout is simpler and sufficient" is an answer.
• Code is idiomatic to its language. Never Java-shaped Python or C-shaped C++. When a practice doesn't translate across ecosystems — checked exceptions, header hygiene, LINQ habits — it says so rather than porting silently.
• Version-sensitive facts get verified at use time. Current language standards, LTS lines, runtime support windows: searched and dated, because training memory is not a source for anything with an end-of-life date.
• Complexity claims are honest. Big-O first, then the constant-factor and cache-behavior caveats that make the textbook answer wrong at real sizes.
• Code compiles and runs as written for a named language version, with comments that explain why, never narrate what.

Like its AI/ML sibling, it carries a teaching mode — concept before syntax, one worked example before the general rule, misconception check after, with the classics named: "microservices are more scalable" as a reflex, mutable default arguments in Python, == versus .equals() in Java, unquoted variables in Bash.

Triggers when you ask how to structure an application, service, or API; name a design pattern; weigh microservices vs monolith; ask a language-specific question in any of the five ecosystems; request a code review; ask "which data structure"; or raise refactoring, technical debt, testing strategy, or CI/CD. REST design, CQRS, async/await, the GIL, RAII, ShellCheck, or hash tables all qualify — the word "architecture" isn't required. Teaching contexts, from coursework to certification study, trigger it too.

What it will not do alone: security architecture, threat modeling, and compliance mapping compose with cybersecurity-architecture — this skill supplies secure-coding practice, that one supplies the framework layer. Hands-on vulnerability review of a specific file, PR, or repo composes with code-security-analysis — this skill owns quality and design, that one owns the security finding. Network behavior questions compose with network-engineering; reporting deliverables about development work compose with executive-reporting.

Reference files:

• architecture-patterns.md — system/service/API structure, microservices vs monolith, resilience, caching, observability
• cpp.md — RAII, ownership, move semantics, undefined behavior, sanitizers, build reality
• java.md — collections, streams, concurrency, records, GC, build tooling, LTS lines
• dotnet.md — async/await, LINQ, nullable references, DI, EF Core, release cadence
• python.md — idioms, typing, packaging, GIL and concurrency, performance, traps
• shell-scripting.md — Bash and PowerShell safety discipline, pipeline models, and the promotion rule
• development-practices.md — version control, testing strategy, code review, CI/CD, dependencies, secure coding, debugging, performance
• data-structures.md — selection, complexity honesty, and per-language stdlib mapping

application-architecture/
├── SKILL.md
└── references/
    ├── architecture-patterns.md
    ├── cpp.md
    ├── data-structures.md
    ├── development-practices.md
    ├── dotnet.md
    ├── java.md
    ├── python.md
    └── shell-scripting.md

code-security-analysis

Hands-on security review of real code and application artifacts — source files, repositories, diffs, dependency manifests, configuration, and IaC — producing classified, prioritized, remediation-ready findings. It runs a review the way a review actually finds bugs: not by grepping for dangerous function names, which finds the shallow 40% and misses every authorization flaw, but by tracing untrusted input to where it does damage. Two failure modes govern its standards — noise that trains developers to ignore findings, and confidence that misses the auth bug sitting in plain sight — and the skill is built to avoid both.

The standards it enforces on itself:

• Every finding carries its fix. A finding without a fix is homework, not help — remediation is working code in the codebase's own language and style, and it explains why the fix closes the flow, so the finding doubles as a teaching artifact rather than a lint hit to paste and forget.
• False-positive discipline. Uncertainty is stated as uncertainty — "injectable if user_id reaches this untrusted, trace shown" is a different finding from "injectable, here's the request" — and missing context (framework version, whether an input is trusted, deployment model) gets asked for, not silently assumed worst. A report padded with guesses loses the credibility that gets the real findings fixed.
• Severity honesty. No inflating an internal-tool XSS to critical because XSS sounds bad, no deflating an auth bypass to medium because the fix is expensive. Best-practice items are labeled hardening and kept in their own section, cleanly apart from exploitable findings, so the severity gradient — the report's most valuable signal — stays credible.
• Coverage honesty. The review states what it analyzed and what it couldn't — runtime behavior, environment config it can't see, code outside the provided scope — because a review that implies a completeness it doesn't have is worse than one that names its blind spots.
• Defensive purpose, stated in the skill. It explains the attack path in prose to the depth a fix needs, but does not produce weaponized exploit code, bypass tooling, or working payloads beyond the minimal illustrative case a fix must defend against. Found secrets are treated as live and reported for immediate rotation, never tested for validity — using the credential is the breach, not the check for it. Reviewing unfamiliar or third-party code for backdoors, obfuscated exfiltration, and malicious install scripts is in scope as defensive work.

The methodology is ordered on purpose — scope first, then entry points, then trust boundaries, then source-to-sink reasoning — because authorization flaws are invisible to pattern matching (the vulnerability is a missing check, which looks like nothing) and only surface when you read the logic and ask "where is the check that this caller may touch this object?" AI-generated code gets checked harder, not softer: plausible-looking security code is read as wrong until proven right, and every imported package is verified to exist, because hallucinated and slopsquatted dependencies are a live entry vector.

Triggers when you say "review this code for vulnerabilities," "is this secure" or "is this exploitable," "scan this repo for secrets," ask for a "security review" of a file, PR, or repo, ask "is this query injection-safe," want to "audit this Dockerfile/pipeline/Terraform/Kubernetes manifest," "check these dependencies" for known CVEs, or "harden this code" — and whenever you paste code with any security question attached, even a one-liner. It also fires on inspecting third-party code for backdoors, exfiltration, or malicious install scripts.

What it will not do alone: code quality, idioms, and design review with no security question compose with application-architecture — that skill owns quality and design, this one owns the security finding. AppSec program architecture, security-tool-category strategy, framework and compliance mapping, and formal CVSS scoring compose with cybersecurity-architecture (including its cvss.md reference for vector strings and its appsec/data-crypto domains for vaulting and encryption architecture). Design-level threat models and risk registers compose with risk-threat-modeling — that skill assesses the design, this one assesses the code, and findings flow both ways. ML-model-specific analysis — poisoning, adversarial input, model supply chain — composes with ai-ml-engineering, while this skill still reviews the code around the model. Leadership-facing report deliverables compose with executive-reporting. And it does not run code or confirm exploitability at runtime, does not certify a codebase as secure (absence of found bugs in scope is not proof of security, and the coverage section says so), and does not produce offensive tooling or working exploits beyond the minimal proof a fix must defend against.

Reference files:

• methodology.md — how a review runs: depth tiers (triage, deep, diff-focused PR, each with what it can't conclude), entry-point enumeration, trust-boundary mapping before pattern matching, taint reasoning and the sanitizer-that-doesn't rule, the manual/tool split, validation before reporting, and reviewing AI-generated code as its own discipline
• vulnerability-classes.md — the CWE-anchored, OWASP-mapped taxonomy with per-language notes across C++, Java, .NET, Python, shell, and JS/TS: the injection family, authn/session flaws, authorization logic as a first-class section (IDOR, missing function-level checks, confused deputy), deserialization, SSRF, path traversal, XXE, races/TOCTOU, memory safety, cryptographic misuse, and unsafe reflection
• secrets-detection.md — secret classes and their shapes, the pattern/entropy/context detection layers, where secrets actually hide (git history included), assume-live triage, and the rotate-then-purge-then-prevent order
• dependencies-supplychain.md — known-CVE matching against per-ecosystem manifests and lockfiles, transitive reality, reachability honesty, patch/pin/replace guidance, typosquat and hallucinated-package checks, install-script risk, and lockfile hygiene
• config-iac-analysis.md — Dockerfiles, Kubernetes manifests, Terraform and cloud IaC, CI/CD pipeline definitions, and application config, each with the misconfiguration, why it's exploitable, and the corrected stanza
• data-handling.md — sensitive data into logs, errors, and traces; PII in URLs; analytics and crash reporters; client-side storage; over-broad serialization; and the retention patterns worth flagging for the compliance conversation
• reporting.md — the finding format (impact-first title, evidence and flow, CWE, severity with reasoning, exploitability, remediation code, verification step), risk-ordered report assembly, the false-positive log as a deliverable, re-review discipline, and the executive rollup

code-security-analysis/
├── SKILL.md
└── references/
    ├── config-iac-analysis.md
    ├── data-handling.md
    ├── dependencies-supplychain.md
    ├── methodology.md
    ├── reporting.md
    ├── secrets-detection.md
    └── vulnerability-classes.md

networking-architecture

Vendor-neutral guidance on enterprise network architecture: WAN and SD-WAN, SASE and SSE, zero trust networking, segmentation and microsegmentation, cloud transit, and edge connectivity. It cites the governing standards where they exist — NIST SP 800-207 for zero trust, MEF 70/70.1 for SD-WAN service attributes, Gartner's definitions for SASE/SSE composition.

Its stance, stated in the skill: the architectural principles are durable, the vendor market is not. Gartner redraws categories and vendors consolidate roughly every 18–24 months, so the skill verifies current market details — vendor positioning, product names, pricing — with a search at use time rather than baking them in. Vendor names appear only as illustrations of a category, never endorsements, and the skill never presents a single vendor as "the answer."

For design work, it follows a fixed answer shape — context restated, qualifying gaps, recommendation with the principle behind it, trade-offs, migration sequence, standards mapping — because in real brownfield environments the migration path matters more than the end state.

Triggers when you ask about branch or site connectivity, MPLS vs SD-WAN vs DIA decisions, SASE or SSE adoption, ZTNA rollout or VPN replacement, segmentation, cloud transit and hybrid/multi-cloud connectivity, remote access architecture, or want a network design reviewed or recommended. Mentioning SD-WAN, SASE, SSE, SWG, CASB, ZTNA, FWaaS, MPLS, DMVPN, transit gateway, or "modernizing our network" qualifies — the word "architecture" isn't required.

What it will not hold: vendor endorsements, static market claims, or absolute pricing — cost figures date fast, so it gives relative economics with caveats and searches before answering anything that depends on current market state.

Reference files:

• wan-fundamentals.md — transport options, legacy WAN patterns, SD-WAN mechanics, and the migration path off legacy
• sase-sse.md — definitions, the SSE component stack, delivery architecture, single- vs multi-vendor, and the VPN-to-ZTNA migration
• adjacent-architectures.md — zero trust networking on SP 800-207, segmentation, cloud networking, edge, and how they interlock
• decision-frameworks.md — the qualifying questions, selection heuristics, trade-off ledger, migration sequencing, and design red flags

networking-architecture/
├── SKILL.md
└── references/
    ├── adjacent-architectures.md
    ├── decision-frameworks.md
    ├── sase-sse.md
    └── wan-fundamentals.md

network-engineering

Networking fundamentals at the level of mechanism, not summary: routing protocol internals for OSPF, EIGRP, BGP, RIP, and IS-IS; the OSI and TCP/IP models with their associated protocols — ARP through TLS — including a layer-by-layer troubleshooting methodology; and topology and design engineering from the three-tier campus model to spine-leaf fabrics.

Its stance is the counterpart to its market-facing sibling: fundamentals age slowly. OSPF's SPF calculation and BGP's path selection don't shift with vendor announcements, so this material is durable in a way the SASE and SD-WAN market is not — with one exception the skill names itself. Standards-revision items — RFC updates, protocol deprecations, IEEE amendment status — get flagged for verification rather than asserted from memory.

The boundary with networking-architecture is stated in the frontmatter and holds cleanly: strategy and market questions — SD-WAN vs MPLS adoption, SASE/SSE, ZTNA rollout, cloud transit — belong to networking-architecture. Questions that span both, like routing design for an SD-WAN migration, compose the two skills rather than duplicating either.

Triggers when you ask how a routing protocol actually works, need a layer-by-layer walk through the OSI or TCP/IP models and their protocols, are troubleshooting by layer, are designing or reviewing a topology from campus three-tier to spine-leaf — and in teaching contexts: Network+ and CCNA study questions trigger it too.

What it will not do: it does not answer strategy and market questions — those are networking-architecture's trigger space, and this skill defers to it rather than overlapping. Product-specific firewall implementation — building the actual rules, NAT, and routing on OPNsense, pfSense, or UniFi — belongs to firewall-platform-engineering, which builds on the protocol mechanics this skill owns.

Reference files:

• routing-protocols.md — protocol internals for OSPF, EIGRP, BGP, RIP, and IS-IS
• osi-model-protocols.md — the OSI and TCP/IP models, their associated protocols, and the layer-by-layer troubleshooting method
• topology-design.md — topology and design engineering, three-tier campus through spine-leaf

network-engineering/
├── SKILL.md
└── references/
    ├── osi-model-protocols.md
    ├── routing-protocols.md
    └── topology-design.md

firewall-platform-engineering

The product-specific implementation layer for three firewall products: OPNsense, Netgate pfSense (Community Edition and Plus), and Ubiquiti UniFi (the Network application and the Cloud Gateway line). Where the networking skills stay vendor-neutral, this one names menu paths, packages, services, and CLI on real shipping versions, because the question "how do I actually build this on this box" needs an answer for that box, not a category.

It is product-specific by design, and the SKILL.md says so in one sentence. That makes it the third declared exception to the library's vendor-neutral rule, alongside the two OS-floor skills. The discipline that keeps it honest is a durable-versus-perishable split written into the file structure: mechanics that rarely change (how pf evaluates a ruleset first-match with quick, how NAT translates before it filters, what a state is, how policy routing picks a gateway, how CARP elects a master) are stated as fact and carried across all three products, while specifics that shift often (versions, GUI menu paths, package names, default backends) are marked and dated to a version check, verified at use rather than recalled. These products move fast, so the split is load-bearing: OPNsense ships twice a year, pfSense Plus is mid-transition from the legacy PHP GUI to the Go-based Netgate Nexus controller, and UniFi renames menu paths between minor releases. The shipping baseline it was built and dated against, all flagged verify-at-use: OPNsense 26.7, pfSense CE 2.8.1 and pfSense Plus 26.07 with Nexus, and UniFi Network 9.x with the zone-based firewall.

The standards it enforces on itself:

• Name the exact construct. "Firewall > NAT > Outbound, Hybrid mode" or "Settings > Zones > Create Policy," never "the NAT settings," with the package, service, and CLI tool (pfctl, configctl, nft, vtysh) named where it matters. An unattributed menu path is a bug in the answer.
• Attribute every path and version to a product and mark it perishable. A path that is right on pfSense CE is wrong on OPNsense and wrong again on the pfSense Plus Nexus GUI, so nothing is presented as shared layout.
• Translate mechanic to mechanic, never implying parity that does not exist. UniFi has no CARP; OPNsense has no ThreatGate. The cross-platform reference names the gaps rather than papering over them.

Triggers when a question names one of these products or their constructs: OPNsense/pfSense floating rules and aliases, Firewall > NAT outbound/port-forward/1:1/NPt, CARP and pfsync, Unbound and Kea, Suricata/Snort/pfBlockerNG/Zenarmor, the os-frr or FRR package, the pfSense Plus Nexus GUI on port 8443; or UniFi zones and the zone matrix, the External/Internal/Gateway/VPN/DMZ/Hotspot zones, ZBF migration, Teleport, threat management and CyberSecure, and the UDM/UXG/UCG/Cloud Gateway hardware. It also fires on "how do I do X on OPNsense/pfSense/UniFi," on translating a rule or route across the three, and on teaching or writing about these products.

What it will not do alone: vendor-neutral protocol mechanics belong to network-engineering (how OSPF floods LSAs, what a state table is in the abstract), and this skill implements them on the specific box. Network strategy and product-tier choice belong to networking-architecture (SASE, MPLS versus SD-WAN, which tier fits a site), and this skill takes over once the product is chosen. Firewall policy, zone architecture, and control-language framing belong to cybersecurity-architecture (what the policy should allow, how zones map to a trust model, how a rulebase maps to NIST or PCI), and this skill expresses that policy as OPNsense floating rules or a UniFi zone matrix. It composes upward to all three and does not restate them.

Reference files:

• firewall-rules.md — the rule model on each platform: pf first-match and the role of quick, states, aliases as tables, interface versus floating rules on OPNsense and pfSense; UniFi zones, the zone matrix, source-to-destination evaluation, and the one-way legacy-to-ZBF migration
• nat.md — outbound, port forward, 1:1, and IPv6 NPt; the order of translation before filtering and why the permitting rule targets the internal address; and the UniFi rule that a port forward needs a matching zone allow policy
• routing-pbr.md — static routes, gateways, gateway groups and multi-WAN, policy routing by setting a gateway on a rule, and dynamic routing through FRR (OSPF and BGP) including where UniFi does and does not expose it
• vpn.md — IPsec site-to-site and mobile, OpenVPN, and WireGuard on OPNsense and pfSense; UniFi site-to-site, VPN server and client, and Teleport; with AllowedIPs explained as routing and ACL at once
• high-availability.md — CARP, pfsync, and XMLRPC config sync as three separate mechanisms on the pf platforms, and the honest limit that UniFi has no equivalent
• ids-ips-filtering.md — Suricata and Snort, pfBlockerNG, and Zenarmor; UniFi threat management, CyberSecure, and DPI traffic identification; with the IDS-versus-inline-IPS trade stated
• dns-dhcp-services.md — Unbound and Dnsmasq, the ISC-to-Kea DHCP move, and the pfSense Plus CoreDNS/rexdns and ThreatGate additions; UniFi's dnsmasq-based equivalents
• management-config-lifecycle.md — web GUI, console and SSH, the single-file config.xml model and backup/restore, the pfSense Plus Nexus transition on port 8443, and UniFi controller topology with where an engineer drops beneath it to nftables and FRR
• cross-platform-translation.md — the concept map across all three products, and the four gaps to UniFi named plainly: no CARP/pfsync, partial dynamic routing, no exposed recursive resolver, no single config file

firewall-platform-engineering/
├── SKILL.md
└── references/
    ├── cross-platform-translation.md
    ├── dns-dhcp-services.md
    ├── firewall-rules.md
    ├── high-availability.md
    ├── ids-ips-filtering.md
    ├── management-config-lifecycle.md
    ├── nat.md
    ├── routing-pbr.md
    └── vpn.md

linux-engineering

The operating-system floor of the library — expert answers and work products across Linux and Unix-based systems, from first-boot administration to fleet-grade automation, in the voice of an engineer who has actually recovered the box. When the machine under a networking, security, or application question is Linux, this is the skill the others stand on.

The standards it enforces on itself:

• Show the output. Commands appear with representative output, because the output is where understanding lives and where the next question comes from. A command with no output shown is half an answer.
• Family marking is mandatory. Any command, path, or default that varies by distribution family carries a bracketed family tag — [Debian-family], [RHEL-family], [SUSE-family] — with the major equivalents named, matching the convention my teaching materials already run. Genuinely universal commands carry no tag; an untagged family-specific claim is an error.
• Unix honesty. Where BSD or commercial Unix diverges in ways that matter — flag dialects, init systems, ZFS-native platforms, packaging — the divergence is named rather than papered over, and "on Linux" is said when only Linux is meant.
• Modern and honest tooling. systemd, journalctl, ip, ss, and nftables taught in the present tense with their predecessors named as history the installed base still contains — read fluency, not endorsement. Version-sensitive facts (current releases, default filesystems, tool availability) are verified at use time, never asserted stale; the durable layer — inodes, signals, permissions — is taught as durable.
• Every recommendation with a trade-off states it. ext4 versus XFS versus ZFS versus Btrfs is a decision table, not a favorite.
• The safety discipline. Destructive operations — rm with globs, dd, mkfs, partition writes, LVM removals, recursive chmod/chown, anything piped to a shell from the network — always ship with their blast radius stated, a verification step before the trigger is pulled (list what will be affected; confirm the device node twice; on fleets, one host before all hosts), and a recovery note: the backup, the snapshot, the second terminal already logged in. curl | sh gets its risk named every time it appears.

It carries a teaching mode built on the same conventions as my course materials: the terminal as a conversation — prompt, command, output, next command — concept before flag soup, one worked example before the general rule, and the classic misconceptions checked (chmod 777 as a "fix," editing sudoers without visudo, killing processes to "free" the page cache, trusting a load average without asking what Linux actually counts in it).

Triggers when you ask to set up, configure, or manage users, storage, services, mounts, or packages; ask systemd or init questions or "why won't it boot"; raise kernel, sysctl, or module questions; weigh LVM, RAID, or filesystem choices; say "harden this server"; ask about SSH configuration, permissions and ACLs, cron and timers, or journalctl and /var/log; say "load average is high," "out of memory," "disk is full," or "what is eating my CPU"; ask bash or shell questions in an operations context; or paste terminal output, a config file, or a shell script with a fix-this or what-does-this-mean question. BSD, AIX, Solaris, and macOS-as-Unix phrasings trigger it too.

What it will not do alone: language engineering — idioms, when a script should become a Python program, cross-platform development practice — composes with application-architecture, whose shell-scripting discipline is the craft canon this skill builds automation on. Routing protocols, switch/router/firewall devices, and network design compose with network-engineering and networking-architecture — this skill configures Linux's own stack and hands off at the wire. Security architecture, framework mapping, and compliance language compose with cybersecurity-architecture — this skill executes the hardening mechanics; that skill names the controls. Config and script security review composes with code-security-analysis, and the log pipelines it builds feed the SOC/SIEM territory and the leadership rollups executive-reporting covers downstream. A spanning question composes skills rather than choosing one.

Reference files:

• system-internals.md — the boot chain with where each failure mode announces itself, systemd at depth (units, targets, ordering, the journal, generators), the kernel interface (modules, sysctl, /proc and /sys), processes and signals done precisely (what SIGKILL cannot do, zombies without folklore), memory (the page cache and why "free" isn't, the OOM killer's logic), and filesystems from the inside — VFS, inodes, journaling, and the ext4/XFS/ZFS/Btrfs decision table with the ZFS licensing note
• administration.md — users, groups, and PAM at the depth an admin debugs; package management across families with repository trust and update-cadence-as-security-hygiene; the storage lifecycle (GPT, LVM with snapshot discipline, software RAID with rebuild-time honesty, fstab and the systemd mount-unit reality, quotas); unit files written properly with drop-ins over edits; cron and timers as a pair; backup engineering (3-2-1, restore-testing as the actual backup); journal persistence and the rsyslog/SIEM forwarding pipeline; KVM/libvirt and containers as an admin concern; and configuration management as a category, with the threshold a fleet has to cross to earn it
• networking-stack.md — who owns this interface (networkd/NetworkManager/ifupdown/netplan, family-tagged), addressing and policy routing with ip, name resolution (nsswitch, systemd-resolved, the stub and the symlink), nftables as the present tense with iptables translation, bridges/bonds/VLANs and the veth-and-namespace container substrate, SSH engineering at depth (the hardening order that doesn't lock you out, certificates at fleet scale, why ProxyJump replaces agent forwarding), and the outward diagnostic ladder — link, address, route, resolution, port, path
• scripting-automation.md — bash beyond the basics (arrays, parameter expansion as the tool that replaces sed half the time, traps, process substitution, getopts), the text toolchain with awk given its due as the language it is, robust-script patterns (set -euo pipefail with its caveats stated, flock, idempotence, dry-run flags as a design habit), ShellCheck as non-negotiable and bats at orientation, the timer-unit-over-cron worked pair, Python-for-operations at orientation with the promotion rule deferred by pointer, and the fleet loop over SSH with its limits stated — the honest on-ramp to configuration management
• performance-troubleshooting.md — method before tools (USE, hypothesis-driven debugging, reproduce before fixing), load average told honestly (uninterruptible I/O wait counts, and 4.0 means nothing without core count), the observation toolkit by resource, the deleted-but-open full-disk classic, the eBPF era at orientation with its kernel-dependency flag, sar and atop for the after-the-fact question, the full-disk / out-of-memory / high-load ladders written as ladders, and reading the kernel's own reports — dmesg, oops messages, and pressure stall information as the modern signal
• hardening-security.md — the minimal-install discipline, SSH hardening as the first act with the lockout warning stated explicitly, sudo granularity and NOPASSWD honesty, SELinux taught as contexts-booleans-and-the-audit-log rather than "just disable it" alongside AppArmor as profiles, auditd and file-integrity monitoring at working depth, the default-deny host firewall stance with family-tagged frontends, update automation, secure boot and LUKS at orientation, and CIS-benchmark execution mechanics with scoring honesty and the compose-upward pointer for control language

linux-engineering/
├── SKILL.md
└── references/
    ├── administration.md
    ├── hardening-security.md
    ├── networking-stack.md
    ├── performance-troubleshooting.md
    ├── scripting-automation.md
    └── system-internals.md

windows-engineering

The Microsoft floor of the library, beside linux-engineering's Unix floor — expert answers and work products across Windows workstations and servers, Active Directory, Azure infrastructure, and Entra ID, in the voice of the engineer who has actually restored the domain. When the estate under a networking, security, or identity question runs Windows, this is the skill the others stand on — and when the estate is mixed, the two floors compose.

The standards it enforces on itself:

• GUI-and-shell parity. Every administrative task shows the console path — named precisely: which MMC snap-in, which Windows Admin Center or Entra admin center blade — and the PowerShell equivalent, under the standing rule that anything done twice gets done in PowerShell. Generated commands are runnable as written for a named PowerShell edition and module, because half the Microsoft cmdlet surface depends on which one is loaded.
• Rename-and-licensing honesty. This is the fastest-renaming vendor in the library, and the skill's credibility dies on a stale product name. Current names are used with the former name noted once where readers will know it by the old one — Entra ID (formerly Azure AD). Licensing-tier placements are verified and dated at answer time, never recalled, and servicing channels, support lifecycles, and deprecation statuses — NTLM's staged retirement, WSUS's deprecation path, legacy authentication cutoffs — are treated as verify-at-use-time items, dated in the answer.
• Evidence over guess. Diagnostic answers name the event log, the event ID, and the tool that proves the hypothesis before proposing the fix. The event log outranks the guess.
• Edition and scale honesty. Answers distinguish what applies to a workgroup, a single-domain shop, and a multi-forest enterprise — "just use PIM" is not an answer for a ten-seat office.
• Trade-offs are mandatory. On-prem AD versus Entra-only versus hybrid is a decision table, not a default, and every architectural recommendation states its cost.
• The safety discipline. Operations touching identity authority and data get ceremony: FSMO transfers distinguished from seizures with the never-bring-the-old-holder-back rule, authoritative versus non-authoritative AD restore stakes stated before steps, schema changes flagged as forest-wide and irreversible, registry edits shown with export-first, Group Policy changes tested against a pilot OU before broad linking — the Windows analog of one-host-before-all-hosts — Conditional Access built with a break-glass account named and report-only mode first, and anything destructive shipped with blast radius stated, a verification step, and the recovery prerequisite named: Recycle Bin enabled, backup current, second Global Admin.

It carries a teaching mode built for the misconceptions I meet in my own classroom — name what the student got right, then fix the model: Group Policy configures Windows components including the host firewall, but network firewalls live on network devices, not in GPO; a domain admin account is not needed for daily work; Kerberos clock skew is a time problem wearing an authentication costume; "the GPO isn't applying" is a precedence, scope, or replication question with a gpresult answer; and Entra ID is not "AD in the cloud" — the protocols, objects, and management model differ, and the differences are the syllabus.

Triggers when you install, deploy, or image Windows; join a domain, promote a DC, fix a GPO that "isn't applying," or set up Group Policy; mention forests, OUs, FSMO, replication, trusts, or Kerberos; work on server roles — file services, DNS/DHCP, Hyper-V, clustering — or workstation management, profiles, Intune, and Autopilot; say conditional access, hybrid join, Entra Connect, app registration, or PIM; ask Azure questions in a Windows context (VMs, VNets, Azure Files, Arc); say "harden this server/domain," LAPS, BitLocker, or baselines; troubleshoot blue screens, slow logons, event IDs, authentication or replication errors; or paste PowerShell output, event-log excerpts, gpresult output, or error codes with a fix-or-explain question. Legacy Server versions still in production trigger it too, answered with the migration honesty they deserve.

What it will not do alone: PowerShell as a language — idioms, module authorship, cross-platform script craft — composes with application-architecture, whose shell-scripting discipline is the canon this skill's administration patterns build on. Protocol mechanics and network devices compose with network-engineering and networking-architecture — this skill configures Windows' DNS, DHCP, and NPS roles and hands off at the wire. Security architecture, framework mapping, and control language compose with cybersecurity-architecture — this skill executes the hardening, that skill names the controls, and the AD attack-surface content maps techniques upward. Config and script review composes with code-security-analysis. linux-engineering is the sibling floor, and cross-platform estates compose the two. Its audit-policy output feeds the SOC pipeline and the leadership rollups executive-reporting covers downstream. A spanning question composes skills rather than choosing one.

Reference files:

• platform-install-internals.md — the platform under the administration: the registry as the configuration store with its hive layout and edit ceremony, services and their accounts, WMI/CIM as the query surface, the event log architecture beyond the big three; editions and servicing with Server Core versus Desktop Experience argued honestly; unattended installs, imaging and sysprep, Autopilot at working depth, server deployment patterns; the boot chain, BCD, WinRE, and last-known-good's modern reality; and update servicing as a discipline — the WU stack, WSUS's deprecation status verified, and patch-ring design
• active-directory.md — the domain at expert depth: forest and domain design with OU structure for delegation and GPO rather than org-chart vanity; the FSMO roles with what actually breaks when each is down and the transfer-versus-seizure ceremony; replication with sites, the KCC, and repadmin/dcdiag as the health verbs; DNS as AD's load-bearing wall and the standing rule that half of "AD is broken" is DNS; Group Policy processing order with enforcement, blocking, filtering, and loopback explained the way the tenth confused engineer needs it, plus GPO hygiene and gpresult as proof; Kerberos and NTLM at working depth with delegation's flavors risk-ordered and clock skew's five-minute rule; identity lifecycle with gMSAs as the answer to password-never-changes; and AD care — backup, both restore flavors with stakes stated, the Recycle Bin, tombstone lifetime, and clean DC decommissioning
• server-workstation-admin.md — the daily craft: file services with NTFS-versus-share permissions and the effective-access answer, DFS honesty; the DNS and DHCP roles configured properly with protocol depth composed from the networking skills; print services and their honest pain; IIS at orientation; Hyper-V at working depth with checkpoints and their production caveat; clustering and Storage Spaces at orientation with decision honesty; NTFS versus ReFS as a decision table; PowerShell-for-administration — remoting as the fleet tool, bulk operations, reporting one-liners, JEA, and DSC's successors at orientation; workstation profiles and their failure modes; scheduled tasks on service accounts, not domain admins; and the management-tooling map from MMC to Windows Admin Center
• entra-hybrid-identity.md — the cloud identity plane and the bridge to it: Entra's object model versus AD's, with app registrations versus enterprise applications untangled; hybrid identity as the load-bearing decision — Entra Connect versus Cloud Sync, and PHS versus PTA versus federation compared honestly with the operational bill of each; device identity states and what each unlocks; Conditional Access as policy architecture with report-only-first discipline, the break-glass rule, and phishing-resistant MFA as the design bar tied to SP 800-63; PIM and access reviews with the edition-honesty note; licensing-tier placement as a verify-current pattern; and Intune at the boundary — compliance policies feeding Conditional Access, configuration profiles as GPO's cloud-era counterpart
• azure-infrastructure.md — Azure for the Windows engineer, scoped deliberately: tenants versus subscriptions versus management groups, and RBAC versus Entra roles as the confusion worth one clear page; Windows VMs done properly, including domain controllers in Azure with their placement and DNS rules; virtual networking at working depth composing with the networking skills; Azure Files and identity-based access for the file-server-migration conversation; DCs in VMs versus Entra Domain Services versus Entra-only as the decision table it is; Arc at orientation; backup and site recovery with restore-testing as the actual backup; and cost honesty — the meter runs on compute, storage, and egress, and the always-on DC VM is a budget line someone must own
• hardening-security.md — Windows hardening mechanics, composing upward for control language: Microsoft and CIS baselines with the compare-before-apply discipline and pilot-OU staging; credential protection as the Windows-specific heart — LAPS, Credential Guard and LSA protection, the admin-tiering model and PAWs, and the kerberoasting surface described defensively with gMSAs, AES-only, and long random passwords as the mitigations; protocol hardening — SMB signing and the SMBv1 corpse, NTLM restriction as an audit-first project, LDAP signing and channel binding; audit policy engineered toward detection with the event IDs that matter — these are the lines the SIEM is fed; BitLocker with recovery-key escrow as the non-negotiable; RDP hardening with no direct internet exposure; and the Defender stack as categories with the EDR boundary marked
• troubleshooting-performance.md — the discipline of finding out, Windows edition: event-log fluency with Get-WinEvent at scale; the Sysinternals fluency every Windows engineer owes themselves — Process Explorer, ProcMon with its filter discipline, Autoruns, TCPView — plus PerfMon with data collector sets for the after-the-fact question; the diagnostic ladders written as ladders — slow logon (profile, GPO count, DNS, mapped drives, in that order), cannot authenticate (time skew, DNS, secure channel, lockout source), GPO not applying, replication failing, and blue screen at orientation with WinDbg and the driver as the usual answer; performance truth-telling — what Task Manager hides that PerfMon shows, memory working sets without folklore; and the Windows classics named as classics — DNS wearing an AD-outage costume, time skew wearing an authentication costume, and the disabled-computer-account secure-channel failure

windows-engineering/
├── SKILL.md
└── references/
    ├── active-directory.md
    ├── azure-infrastructure.md
    ├── entra-hybrid-identity.md
    ├── hardening-security.md
    ├── platform-install-internals.md
    ├── server-workstation-admin.md
    └── troubleshooting-performance.md

executive-reporting

Synthesizes messy mixed sources — email threads, documents, spreadsheets, web data, meeting notes, metrics exports — into executive deliverables in three output types: an email brief, a Word report, or a PowerPoint deck. Document production itself is delegated to the platform's document skills; this skill's job is the synthesis discipline in front of it.

Two disciplines govern it, as the skill states them:

• Ingestion inventory. Every source gets logged before synthesis begins, so every claim in the deliverable traces back to a specific input. Nothing appears in the output that can't be pointed to in a source.
• Answer-first synthesis. The deliverable leads with the answer, and every number carries a "so what" — a figure without its implication is filler, not reporting.

Behind both sits the hard rule: no invented data. If a number, date, or fact isn't in the sources, it doesn't appear in the deliverable — it appears as a named gap.

Triggers when you hand it mixed source material and ask for an executive deliverable — a status brief, a leadership report, a board-ready deck.

What it will not do: it will not fabricate figures to fill gaps, and it will not produce a deliverable whose claims can't be traced to the ingested sources.

Reference files:

• email-brief.md — structure and conventions for the email deliverable
• word-report.md — structure and conventions for the report deliverable
• pptx-deck.md — structure and conventions for the deck deliverable

executive-reporting/
├── SKILL.md
└── references/
    ├── email-brief.md
    ├── pptx-deck.md
    └── word-report.md

wazuh

Product-specific skill for the Wazuh SIEM/XDR platform: manager, indexer, dashboard, and agent fleet. Durable pipeline mechanics (pre-decode, decode, rule match, alert threshold) are stated as fact; version-bound paths, ports, and defaults are marked (v) with a checked date, following the same durable-versus-perishable convention as firewall-platform-engineering.

The core of the skill is diagnostic discipline. Most "Wazuh is not working" reports are the alerts-versus-archives distinction: events that decode but match no rule above the alert threshold are invisible in the default dashboard, and the fix is rule coverage, not ingestion surgery. The skill enforces a strict four-stage diagnosis (wire, read, decode, alert) with wazuh-logtest at its center, and refuses to let troubleshooting skip stages.

Reference files carry a full UniFi-to-Wazuh integration (sender config, decoder skeletons for zone-block lines, storm and management-plane rules, validation loop), a symptom-indexed troubleshooting runbook (agent disconnects, indexer red, disk watermarks, silent ingestion death), and a tuning guide (alert-level strategy, noise-reduction workflow, CDB lists, MITRE tagging discipline, active-response cautions).

What it will not do: it does not pretend Wazuh is a general log-exploration platform; heavy raw-log search and long retention route to the graylog skill, and vendor-neutral SOC strategy routes to cybersecurity-architecture.

graylog

Product-specific skill for Graylog log management: inputs, pipeline rules, streams, index sets, events, and the operational failure modes between them. Same durable-versus-perishable convention; Open-versus-Enterprise feature boundaries are flagged explicitly so the skill never recommends a paid feature as if it were free.

The skill centers on the message flow (input, pipeline, stream, index set) and the two gauges that explain most incidents: the disk journal (climbing utilization means the store cannot keep up) and the message-processor order setting that silently breaks pipeline rules. Parsing guidance prefers pipelines over legacy extractors, pushes noise-dropping before indexing as the primary cost lever, and treats shard budget as the hidden constraint it is.

Reference files carry the UniFi-to-Graylog pipeline end to end (input, ZBF grok rules, stream routing, block-storm event definitions, and fan-out forwarding of security streams to Wazuh for single-syslog-target devices), a symptom-indexed troubleshooting runbook, and a sizing/retention design guide (index-set classes, rotation strategy, heap and shard anchors, compliance retention mapping).

What it will not do: it does not present Graylog Open as a detection-content platform; endpoint telemetry, FIM/SCA, compliance dashboards, and MITRE views belong to Wazuh, and the two skills compose deliberately in a combined architecture where each platform does what it is good at.

shuffle-soar

Product-specific skill for driving Shuffle SOAR programmatically rather than through the drag-and-drop UI. It exists because Shuffle's API is excellent at triggering and reading workflows but sharp-edged at authoring them, and because a self-hosted, unlicensed instance silently disables several cloud features that tutorials assume are present.

The skill states the durable mechanics as fact and flags per-deployment variance (host, ports, licensing, credential names) so nothing is assumed against the wrong instance. It documents the authentication trap (the Bearer apikey is the profile UUID, not the account password), the workflow-as-code contract (whole-object PUT, adapt shapes from a known-good workflow, read-back-verify each save), and the field-level gotchas that cost real debugging: execute_python returns STDOUT and its result is wrapped as $Node.message.<field>, app auth attaches via authentication_id rather than action parameters, and an app-auth url must be the base only to avoid path doubling.

It maps the self-hosted/unlicensed limitations to verify through getinfo (cloud-only AI, non-functional schedule trigger, empty list_cache, UI-only webhook activation) so you design host-side around them instead of fighting the API, and it carries the SIEM-to-webhook integration pattern with the anti-flood rule: scope the forward by category/rule, never by severity alone.

What it will not do: it is not UI click-through guidance and not a SIEM detection-content skill; alerting logic composes with the SIEM skills (wazuh, graylog), and Shuffle here is the response/automation layer.

Runbooks

Standalone reference procedures (not skills). Anonymized so they are safe to hand to someone with no prior exposure to the system, and written to be followed literally. All IP addresses use RFC 5737 documentation ranges; substitute your own values.

Runbook

What it covers

UniFi Firewall Assessment and Change Workflow

End-to-end workflow for a UniFi Cloud Gateway (UniFi OS / Network 9.x, Zone-Based Firewall): API key setup and connectivity check, read-only full config snapshot, assessment of the pulled config, a disciplined one-change-at-a-time change-control loop via the API, and verification plus rollback. Includes the v2-vs-classic endpoint reference and the write gotchas (server-assigned policy index, BLOCK respond-policy flag, provisioning lag, VLAN-zone-move hazard) that cause real incidents.

Repository layout

One folder per skill, each self-contained: a SKILL.md with YAML frontmatter, plus a references/ directory of files the skill loads on demand. The packages/ directory holds each skill packaged as an archive for direct install — same content as the folder, in two forms. Future skills land as new top-level folders following the same convention, with a catalog subsection added above by the same rules.

.
├── cybersecurity-architecture/
│   ├── SKILL.md
│   └── references/
├── risk-threat-modeling/
│   ├── SKILL.md
│   └── references/
├── ai-ml-engineering/
│   ├── SKILL.md
│   └── references/
├── application-architecture/
│   ├── SKILL.md
│   └── references/
├── code-security-analysis/
│   ├── SKILL.md
│   └── references/
├── networking-architecture/
│   ├── SKILL.md
│   └── references/
├── network-engineering/
│   ├── SKILL.md
│   └── references/
├── firewall-platform-engineering/
│   ├── SKILL.md
│   └── references/
├── linux-engineering/
│   ├── SKILL.md
│   └── references/
├── windows-engineering/
│   ├── SKILL.md
│   └── references/
├── executive-reporting/
│   ├── SKILL.md
│   └── references/
├── packages/
│   ├── cybersecurity-architecture.skill
│   ├── risk-threat-modeling.skill
│   ├── ai-ml-engineering.skill
│   ├── application-architecture.skill
│   ├── code-security-analysis.skill
│   ├── networking-architecture.skill
│   ├── network-engineering.skill
│   ├── firewall-platform-engineering.skill
│   ├── linux-engineering.skill
│   ├── windows-engineering.skill
│   └── executive-reporting.skill
├── runbooks/
│   └── unifi-firewall-assessment-workflow.md
├── LICENSE
└── README.md

Installation

Skills install differently per surface. These paths are verified against Anthropic's documentation as of this writing — if one fails, check the current docs linked in each section, because install mechanics change.

Claude (claude.ai and desktop)

Requires Code execution and file creation enabled in Settings, and a ZIP with the skill folder as its root — the .skill packages here satisfy that (rename to .zip if the picker insists).

1. Go to Customize → Skills
2. Click +, then Create skill
3. Upload the skill's ZIP (skill folder at the archive root, SKILL.md inside it)
4. Toggle the skill on

On Team and Enterprise plans an owner must enable Skills in Organization settings first, and can provision skills org-wide. Details: Use skills in Claude.

Claude Code

Filesystem-based — no upload. Clone or copy the skill folder into the skills directory and start a new session; Claude discovers it automatically and loads it when relevant.

# personal — available in all projects
git clone https://github.com/<owner>/<repo>.git
cp -r <repo>/cybersecurity-architecture ~/.claude/skills/

# project — committed with the repo, shared with the team
cp -r <repo>/cybersecurity-architecture .claude/skills/

Details: Extend Claude with skills.

Claude API

Upload the skill to your workspace via the Skills API, then reference it in requests. A ZIP upload must contain the skill directory as its single top-level entry:

zip -r cybersecurity-architecture.zip cybersecurity-architecture/

curl https://api.anthropic.com/v1/skills \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -F "files[]=@cybersecurity-architecture.zip"

The Python SDK also offers a files_from_dir helper that takes the folder path directly. Details and current endpoint specifics: Using Agent Skills with the API.

Other agent products

These skills use only the open Agent Skills format — a SKILL.md with standard frontmatter plus reference files, no platform-specific extensions. Per Anthropic's documentation, the standard works across multiple AI tools; the format specification lives at agentskills.io. Any product that reads the format should load these unchanged.

Design principles

These are the rules the skills enforce on themselves, and they're the same rules a new skill has to meet before it lands here:

Framework claims carry identifiers. A control ID, a technique ID, a requirement number, a CWE ID, a CVSS vector string. A claim that can't be pinned to an identifier gets verified or gets flagged — it doesn't get asserted.

Version-sensitive facts get verified at use time. ATT&CK releases, CVSS versions, PCI DSS revisions, CMMC program status, OWASP Top 10 and ASVS editions, language LTS lines, model names and benchmarks, vendor market positions, distro releases and default filesystems, firewall-platform release versions and their shifting GUI menu paths, Microsoft product names, licensing-tier placements, and deprecation schedules — anything that moves is checked against the canonical source when cited, not baked into the skill to go stale.

Vendor-neutral throughout, with three declared exceptions. Categories, representative players, and selection criteria — never a single vendor as the answer. Three skills are product-specific by design: the two OS-floor skills and firewall-platform-engineering, which owns the implementation layer for OPNsense, pfSense, and UniFi. Within them the same rule holds: current product names and versions verified rather than recalled, GUI paths and licensing claims dated, never asserted.

Sibling skills partition, they don't overlap. Related skills draw their trigger boundary explicitly — network-engineering owns protocol mechanics and networking-architecture owns strategy and market, while firewall-platform-engineering owns the product-specific implementation layer for OPNsense, pfSense, and UniFi and composes upward to both, and to cybersecurity-architecture for firewall policy and zone architecture as control language; ai-ml-engineering owns ML attack mechanics, cybersecurity-architecture owns the ATLAS mapping and review method; code-security-analysis owns the hands-on vulnerability finding in a specific file or repo, application-architecture owns code quality and design, and cybersecurity-architecture owns the AppSec program and framework layer above both; risk-threat-modeling owns assessment execution against design artifacts while cybersecurity-architecture keeps the framework knowledge it executes against and code-security-analysis keeps the code-level finding; linux-engineering owns the operating system itself — administration, internals, the host's own network stack, and hardening mechanics — handing off at the wire to the networking skills, composing upward to cybersecurity-architecture for control language, and building its automation on application-architecture's shell-scripting canon; windows-engineering is its Microsoft sibling floor — Windows administration, Active Directory, hybrid identity, and Azure-for-Windows — owning PowerShell-for-administration while application-architecture keeps the language craft, handing off at the wire like its sibling, executing hardening whose control language composes upward, and splitting mixed estates with linux-engineering by platform — and a question spanning boundaries composes the skills rather than getting a half-answer from either. The cybersecurity-architecture domain files carry these boundary sentences internally too: its network-perimeter file owns security policy and zone architecture while device engineering stays with network-engineering, platform-specific firewall implementation stays with firewall-platform-engineering, and SASE strategy stays with networking-architecture, and its appsec file owns gate placement while coding practice stays with application-architecture and per-artifact review stays with code-security-analysis.

Reference files load on demand. The core SKILL.md stays lean; deep material sits in references/ and loads only when the task calls for it. That's what the format is for.

Document production delegates. When a deliverable is a Word file, a deck, or a PDF, the skill hands formatting to the platform's document skills and keeps its own scope to the analysis and synthesis discipline.

No AI-pattern language in output. Every deliverable these skills generate is held to a language standard that strips the filler patterns AI text is known for. The output should read like a practitioner wrote it, because the instructions did.

Roadmap

More skills will land here as I build and test them against the same bar — I don't publish what I haven't used.

About the author

I'm a senior cybersecurity architect with 25+ years in the field, author of the Cybersecurity Architect's Handbook, and a long-time adjunct instructor in cybersecurity, networking, and digital forensics. I write at secdoc.tech.

License and disclaimer

This repository is dual-licensed, attribution required: code and skill definitions under the Apache License 2.0; documentation, guides, and diagrams under CC BY 4.0. See LICENSING.md and NOTICE. Credit: Lester E. Nichols III, secdoc.tech.

These skills reference security frameworks, standards, and compliance regimes, but their output is not legal, audit, or compliance advice, and it is not an attestation of anything. Gap analyses, threat models, risk registers, and mappings produced with these skills inform your work; only a qualified assessor can certify it, and GDPR questions with legal weight belong with counsel or a DPO. The linux-engineering and windows-engineering skills describe system-administration and hardening operations, including destructive and identity-authority ones — disk operations, FSMO seizures, directory restores, schema changes; you run commands against your own systems and directories at your own judgment, with the backups, staging, and verification steps the skills themselves insist on. The firewall-platform-engineering skill describes changes to live firewalls, including ones that can cut off your own access or cannot be undone, such as rule and NAT edits, HA failover, the pfSense Plus Nexus transition, and the irreversible UniFi zone-based-firewall migration; you apply them against your own devices at your own judgment, with console access and a saved configuration in hand, as the skill itself insists.

MITRE ATT&CK® and MITRE ATLAS are the work of The MITRE Corporation, with ATT&CK's registered mark acknowledged. NIST publications are the work of the National Institute of Standards and Technology. CVSS is maintained by FIRST. The CWE list is maintained by The MITRE Corporation; the OWASP Top 10 and ASVS by the OWASP Foundation. PCI DSS belongs to the PCI Security Standards Council; SOC 2 to the AICPA; CMMC to the U.S. Department of Defense; the GDPR to the European Union. CIS Benchmarks belong to the Center for Internet Security. Microsoft, Windows, Windows Server, Active Directory, Azure, Microsoft Entra, Hyper-V, BitLocker, Intune, and Defender are trademarks of the Microsoft group of companies. OPNsense is a registered trademark of Deciso B.V. pfSense and Netgate are registered trademarks of Rubicon Communications, LLC. Ubiquiti and UniFi are trademarks of Ubiquiti Inc. All cited frameworks, standards, and products belong to their respective owners; this repository maps to them, it doesn't reproduce or replace them.

Contributing

This is a personal library published in the open, so treat it that way: issues and suggestions are welcome, and PRs get considered. The contribution bar is the design principles above — identifiers on framework claims, versions verified not assumed, vendor neutrality, lean core with on-demand references. If a change meets that bar, I want to see it.

GitLab CI baseline

GitLab CI validates tracked JSON, Python, and shell syntax, then runs a network-independent high-confidence secret scan across full Git history. The public pipeline contains no private registry, runner, credential, CA, or internal-domain reference.