@skill-graph/cli 0.5.6

package/marketplace/skills/ontology-modeling/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: ontology-modeling
+description: "Use when formalizing domain meaning with classes, properties, constraints, RDF/OWL-style semantics, SHACL-like validation shapes, or reasoning-ready axioms. Do NOT use for simple category trees (use `taxonomy-design`), pre-implementation business entity sketches (use `conceptual-modeling`), database schemas (use `data-modeling`), or broad representation choice (use `knowledge-modeling`)."
+license: MIT
+compatibility: "Portable ontology modeling guidance; implementation can be Markdown, RDF, JSON-LD, OWL, SHACL, or an internal schema language."
+allowed-tools: Read Grep
+metadata:
+  metadata: "{\"schema_version\":6,\"version\":\"1.1.0\",\"type\":\"capability\",\"category\":\"foundations\",\"domain\":\"foundations/ontology\",\"scope\":\"portable\",\"owner\":\"skill-graph-maintainer\",\"freshness\":\"2026-05-16\",\"drift_check\":\"{\\\\\\\"last_verified\\\\\\\":\\\\\\\"2026-05-16\\\\\\\"}\",\"eval_artifacts\":\"planned\",\"eval_state\":\"unverified\",\"routing_eval\":\"absent\",\"comprehension_state\":\"present\",\"stability\":\"experimental\",\"keywords\":\"[\\\\\\\"ontology modeling\\\\\\\",\\\\\\\"formal semantics\\\\\\\",\\\\\\\"RDF\\\\\\\",\\\\\\\"OWL\\\\\\\",\\\\\\\"JSON-LD\\\\\\\",\\\\\\\"SHACL\\\\\\\",\\\\\\\"class axioms\\\\\\\",\\\\\\\"property domains\\\\\\\",\\\\\\\"property ranges\\\\\\\",\\\\\\\"disjoint classes\\\\\\\",\\\\\\\"reasoning constraints\\\\\\\",\\\\\\\"semantic interoperability\\\\\\\"]\",\"examples\":\"[\\\\\\\"we need class and property definitions that another system can reason over, not just a human-readable diagram\\\\\\\",\\\\\\\"should Customer and Organization be disjoint classes in this ontology?\\\\\\\",\\\\\\\"define property domains and ranges for our skill graph export\\\\\\\",\\\\\\\"turn this conceptual model into a machine-checkable ontology without inventing database tables\\\\\\\"]\",\"anti_examples\":\"[\\\\\\\"make a simple browse category tree for skills\\\\\\\",\\\\\\\"identify the business entities and relationships before implementation\\\\\\\",\\\\\\\"design the SQL tables, keys, and indexes\\\\\\\",\\\\\\\"choose whether this knowledge belongs in rules, frames, a graph, or a hybrid\\\\\\\"]\",\"relations\":\"{\\\\\\\"boundary\\\\\\\":[{\\\\\\\"skill\\\\\\\":\\\\\\\"taxonomy-design\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"taxonomy-design owns informal classification and facets; ontology-modeling owns formal semantics\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"conceptual-modeling\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"conceptual-modeling is stakeholder-readable domain analysis; ontology-modeling is machine-checkable semantic formalization\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"data-modeling\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"data-modeling owns persistence structure and constraints; ontology-modeling owns meaning constraints\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"knowledge-modeling\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"knowledge-modeling chooses the representation paradigm; ontology-modeling applies one formal paradigm\\\\\\\"}],\\\\\\\"related\\\\\\\":[\\\\\\\"semantic-relations\\\\\\\",\\\\\\\"taxonomy-design\\\\\\\",\\\\\\\"knowledge-modeling\\\\\\\"],\\\\\\\"depends_on\\\\\\\":[\\\\\\\"semantic-relations\\\\\\\"],\\\\\\\"verify_with\\\\\\\":[\\\\\\\"semantic-relations\\\\\\\",\\\\\\\"conceptual-modeling\\\\\\\"]}\",\"portability\":\"{\\\\\\\"readiness\\\\\\\":\\\\\\\"scripted\\\\\\\",\\\\\\\"targets\\\\\\\":[\\\\\\\"skill-md\\\\\\\"]}\",\"lifecycle\":\"{\\\\\\\"stale_after_days\\\\\\\":365,\\\\\\\"review_cadence\\\\\\\":\\\\\\\"quarterly\\\\\\\"}\",\"mental_model\":\"|\",\"purpose\":\"|\",\"boundary\":\"|\",\"analogy\":\"An ontology is to a domain model what an engineering tolerance specification is to a manufactured part — the part might fit at +/-0.5mm informally (taxonomy, conceptual model), but if another factory must mass-produce a counterpart that mates with it, both factories need a tolerance spec that says *exactly* what 'fits' means in microns. The spec is more expensive to write than the napkin sketch, but it is the artefact that lets two shops produce interlocking parts without ever talking to each other.\",\"misconception\":\"|\",\"concept\":\"{\\\\\\\"definition\\\\\\\":\\\\\\\"Ontology modeling is the discipline of formalizing the meaning of a domain into classes, properties, and axioms whose semantics is precise enough for automated reasoning, validation, or cross-system interoperability. Drawing from Aristotle's categories, Gruber's information-systems definition of ontology, and Guarino's formal ontology tradition, it treats meaning as something that can be specified — a *commitment to a conceptualization* — and the specification as a contract that downstream consumers can compute over.\\\\\\\",\\\\\\\"mental_model\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"purpose\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"boundary\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"taxonomy\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"analogy\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"misconception\\\\\\\":\\\\\\\"|\\\\\\\"}\",\"skill_graph_source_repo\":\"https://github.com/jacob-balslev/skill-graph\",\"skill_graph_protocol\":\"Skill Metadata Protocol v5\",\"skill_graph_project\":\"Skill Graph\",\"skill_graph_canonical_skill\":\"skills/ontology-modeling/SKILL.md\"}"
+  skill_graph_source_repo: "https://github.com/jacob-balslev/skill-graph"
+  skill_graph_protocol: Skill Metadata Protocol v4
+  skill_graph_project: Skill Graph
+  skill_graph_canonical_skill: skills/ontology-modeling/SKILL.md
+---
+
+# Ontology Modeling
+
+## Coverage
+
+Formalize domain meaning into classes, properties, constraints, and axioms. Covers class hierarchy, object/data properties, domain/range, cardinality constraints, equivalence, disjointness, identity, controlled vocabularies, validation shapes, and interop-oriented JSON-LD/RDF projection. The output may be an actual ontology file or a precise ontology sketch before implementation.
+
+## Philosophy
+
+Ontology modeling is only worth its cost when ambiguity, interoperability, validation, or reasoning matter. Most teams do not need OWL. They need clear conceptual models and controlled vocabularies. Escalate to ontology when another consumer must compute over the semantics, validate instances against constraints, or align meaning across systems.
+
+The ontology must preserve business meaning while stating which inferences are allowed. A vague ontology is worse than no ontology because it gives false confidence to downstream tools.
+
+## Method
+
+1. Identify competency questions: what must the ontology answer or validate?
+2. Separate classes, instances, and literals.
+3. Define properties with domain, range, direction, and cardinality where needed.
+4. Add equivalence and disjointness only when the claim is durable.
+5. Reuse existing vocabularies where they fit; do not rename standards for style.
+6. Validate against positive and negative instance examples.
+7. Document open-world vs closed-world assumptions.
+
+## Verification
+
+- [ ] Every class exists to answer a competency question
+- [ ] Property domain and range are explicit where consumers depend on them
+- [ ] Disjointness claims are intentional and tested with counterexamples
+- [ ] Synonyms are aliases, not duplicate classes
+- [ ] The model distinguishes class, instance, and literal values
+- [ ] Validation examples include invalid cases
+- [ ] Reasoning assumptions are stated
+
+## Do NOT Use When
+
+| Use instead | When |
+|---|---|
+| `taxonomy-design` | You need a human-governed category tree or facets, not formal axioms. |
+| `conceptual-modeling` | You are still discovering business entities and relationships with stakeholders. |
+| `data-modeling` | You need persistence schema, keys, indexes, or denormalization decisions. |
+| `semantic-relations` | You only need to choose the relation type between concepts. |
+
+## Key Sources
+
+- Gruber, T. R. (1993). "A Translation Approach to Portable Ontology Specifications." *Knowledge Acquisition*, 5(2), 199-220. The canonical definition of ontology as "a specification of a conceptualization"; the modern grounding of formal ontology in information systems.
+- Guarino, N. (1998). "Formal Ontology and Information Systems." In *Proceedings of FOIS '98*. IOS Press. The methodological foundation for evaluating ontologies; the discipline of distinguishing ontology from taxonomy by the presence of formal axioms.
+- Guarino, N., & Welty, C. (2002). "Evaluating ontological decisions with OntoClean." *Communications of the ACM*, 45(2), 61-65. The OntoClean methodology: meta-properties (rigidity, unity, identity, dependence) for evaluating subclass-relation correctness.
+- Baader, F., Calvanese, D., McGuinness, D. L., Nardi, D., & Patel-Schneider, P. F. (Eds.). (2003). *The Description Logic Handbook*. Cambridge University Press. The canonical reference for the formal foundations of OWL: syntax, semantics, complexity, and reasoning algorithms.
+- W3C. [OWL 2 Web Ontology Language: Document Overview (Second Edition)](https://www.w3.org/TR/owl2-overview/). The normative specification of OWL 2 and its profiles (EL, QL, RL).
+- W3C. [RDF Schema 1.1](https://www.w3.org/TR/rdf-schema/). The minimal RDFS vocabulary used as the lightweight precursor to OWL.
+- W3C. [Shapes Constraint Language (SHACL)](https://www.w3.org/TR/shacl/). The validation companion to OWL: closed-world validation shapes for RDF data.
+- Sowa, J. F. (2000). *Knowledge Representation: Logical, Philosophical, and Computational Foundations*. Brooks/Cole. Comprehensive synthesis covering description logics, conceptual graphs, and the historical lineage from Aristotle to modern formal ontology.
+- Smith, B. (2004). "Beyond Concepts: Ontology as Reality Representation." In *Proceedings of FOIS 2004*. The realist position on ontology: ontologies represent what exists in the world, not just what is in someone's head. Foundation for upper ontologies like BFO.
+- Noy, N. F., & McGuinness, D. L. (2001). ["Ontology Development 101: A Guide to Creating Your First Ontology."](https://protege.stanford.edu/publications/ontology_development/ontology101.pdf) Stanford KSL Technical Report. The widely-cited practitioner methodology for ontology authoring.

package/marketplace/skills/owasp-security/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: owasp-security
+description: "Use when reviewing code for security vulnerabilities, threat-modelling a new feature, implementing authentication or authorization, handling user input, or auditing a codebase against the OWASP Top 10 (2021). Covers injection (SQL, NoSQL, command, LDAP, XSS), broken access control, cryptographic failures, insecure design, security misconfiguration, vulnerable dependencies, identification and authentication failures, software and data integrity failures, logging and monitoring failures, and server-side request forgery. Do NOT use for general code review (use `code-review` for the holistic per-PR pass), for chasing a known production bug (use `debugging`), or for writing a security policy doc (use `documentation`)."
+license: MIT
+compatibility: Language-agnostic; OWASP Top 10 2021 reference
+allowed-tools: Read Grep Bash
+metadata:
+  metadata: "{\"schema_version\":6,\"version\":\"1.0.0\",\"type\":\"capability\",\"category\":\"quality\",\"domain\":\"quality/security\",\"scope\":\"portable\",\"owner\":\"skill-graph-maintainer\",\"freshness\":\"2026-05-04\",\"drift_check\":\"{\\\\\\\"last_verified\\\\\\\":\\\\\\\"2026-05-04\\\\\\\"}\",\"eval_artifacts\":\"planned\",\"eval_state\":\"unverified\",\"routing_eval\":\"absent\",\"stability\":\"experimental\",\"keywords\":\"[\\\\\\\"security\\\\\\\",\\\\\\\"owasp\\\\\\\",\\\\\\\"owasp top 10\\\\\\\",\\\\\\\"vulnerability\\\\\\\",\\\\\\\"sql injection\\\\\\\",\\\\\\\"xss\\\\\\\",\\\\\\\"cross site scripting\\\\\\\",\\\\\\\"csrf\\\\\\\",\\\\\\\"authentication\\\\\\\",\\\\\\\"authorization\\\\\\\",\\\\\\\"access control\\\\\\\",\\\\\\\"broken access control\\\\\\\",\\\\\\\"secret in code\\\\\\\",\\\\\\\"insecure design\\\\\\\",\\\\\\\"cryptographic failure\\\\\\\",\\\\\\\"ssrf\\\\\\\",\\\\\\\"threat model\\\\\\\",\\\\\\\"security review\\\\\\\",\\\\\\\"dependency vulnerability\\\\\\\",\\\\\\\"audit code for security\\\\\\\",\\\\\\\"is this code safe\\\\\\\",\\\\\\\"detect security vulnerabilities\\\\\\\"]\",\"examples\":\"[\\\\\\\"audit this endpoint for SQL injection and XSS specifically\\\\\\\",\\\\\\\"this PR adds user input — what security checks should I run?\\\\\\\",\\\\\\\"threat-model this new file-upload feature\\\\\\\",\\\\\\\"review this auth flow against OWASP — is there a bypass?\\\\\\\",\\\\\\\"I'm building a search box — how do I prevent injection?\\\\\\\",\\\\\\\"the dependency scanner flagged 12 vulnerabilities — which ones matter?\\\\\\\",\\\\\\\"is this code path vulnerable to SSRF?\\\\\\\",\\\\\\\"review this access-control logic — can a non-admin escalate?\\\\\\\"]\",\"anti_examples\":\"[\\\\\\\"review this PR holistically\\\\\\\",\\\\\\\"production users are reporting an error — debug it\\\\\\\",\\\\\\\"write our company security policy doc\\\\\\\",\\\\\\\"scaffold a new skill teaching security review\\\\\\\",\\\\\\\"rename this auth function for clarity\\\\\\\"]\",\"relations\":\"{\\\\\\\"boundary\\\\\\\":[{\\\\\\\"skill\\\\\\\":\\\\\\\"code-review\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"code-review is the holistic per-PR pass that includes security as one of many concerns; owasp-security is the security-specific deep audit\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"debugging\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"debugging chases a known failure (security or otherwise); owasp-security finds vulnerabilities BEFORE they are exploited in production\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"testing-strategy\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"testing-strategy decides what to test broadly; owasp-security defines security-specific test cases (auth bypass tests, injection tests, etc.) as a sub-concern\\\\\\\"}],\\\\\\\"related\\\\\\\":[\\\\\\\"code-review\\\\\\\",\\\\\\\"testing-strategy\\\\\\\"],\\\\\\\"verify_with\\\\\\\":[\\\\\\\"testing-strategy\\\\\\\",\\\\\\\"code-review\\\\\\\"]}\",\"portability\":\"{\\\\\\\"readiness\\\\\\\":\\\\\\\"scripted\\\\\\\",\\\\\\\"targets\\\\\\\":[\\\\\\\"skill-md\\\\\\\"]}\",\"lifecycle\":\"{\\\\\\\"stale_after_days\\\\\\\":180,\\\\\\\"review_cadence\\\\\\\":\\\\\\\"quarterly\\\\\\\"}\",\"skill_graph_source_repo\":\"https://github.com/jacob-balslev/skill-graph\",\"skill_graph_protocol\":\"Skill Metadata Protocol v5\",\"skill_graph_project\":\"Skill Graph\",\"skill_graph_canonical_skill\":\"skills/owasp-security/SKILL.md\"}"
+  skill_graph_source_repo: "https://github.com/jacob-balslev/skill-graph"
+  skill_graph_protocol: Skill Metadata Protocol v4
+  skill_graph_project: Skill Graph
+  skill_graph_canonical_skill: skills/owasp-security/SKILL.md
+---
+
+# OWASP Security
+
+## Coverage
+
+- The OWASP Top 10 (2021) categories: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, A10 Server-Side Request Forgery
+- Detection patterns per category: the code shapes that signal vulnerability and the grep / static-analysis queries that surface them
+- Mitigation patterns per category: parameterised queries, output encoding, principle-of-least-privilege access checks, secure defaults, dependency pinning, input allowlisting, structured logging
+- Threat modelling: the four-question STRIDE-lite (what are we building, what could go wrong, what are we doing about it, did we do a good job) for new features
+- The AI-generated code premium: vulnerabilities specifically common in LLM-authored code (1.7-2.74× rate per published research) and what to look for
+- Severity grading and disclosure: when a finding is critical, high, medium, or informational, and how to communicate fixes without leaking exploitable detail
+- Defence in depth: why a single mitigation is insufficient, and how to layer controls
+- The auth invariants that recur: authentication separated from authorisation, every privileged action checked, sessions invalidated on logout, secrets never in code or logs
+
+## Philosophy
+
+Security is not a feature; it is a *property* of the system that erodes silently unless actively maintained. The OWASP Top 10 is not a checklist to memorise — it is a vocabulary for naming the most-common ways software fails. A reviewer who can name "this is A03 Injection" and "this is A07 Identification Failure" can communicate findings to teammates, prioritise against industry data, and reach mitigations that are already documented and known to work.
+
+The most expensive security bug is the one you didn't *notice was a security bug*. Most live vulnerabilities started life as a perfectly reasonable-looking line of code that the author did not recognise as a security-relevant decision. The point of this skill is to enrich your default reading of code with a security lens — not as a separate review pass, but as a way of seeing every input, every boundary, and every privileged action.
+
+## The OWASP Top 10 — Detection and Mitigation
+
+### A01 — Broken Access Control
+
+**Detection.** Look for: missing authorisation checks on routes, IDOR-shaped URLs (`/users/{id}/...` with no ownership check), client-side-only role checks, force-browsing exposed endpoints, missing CSRF tokens on state-changing requests.
+
+```
+grep -rn "router\.\(get\|post\|put\|delete\)" --include="*.ts" \
+  | grep -v "requireAuth\|requireAdmin\|allowAnonymous"
+```
+
+**Mitigation.** Centralise authorisation in middleware or a request-scoped helper (`requireAuth`, `requireOrgAccess`, `requireResourceOwnership`). Default to deny; require an explicit positive decision to allow. Test access denial as carefully as access success.
+
+### A02 — Cryptographic Failures
+
+**Detection.** Plaintext storage of credentials/PII, weak hashing (`md5`, `sha1`) for passwords (use Argon2 or bcrypt), reused IVs, hardcoded keys, missing TLS on sensitive endpoints, weak random sources (non-cryptographic random functions) for security tokens.
+
+**Mitigation.** Use library primitives, not hand-rolled crypto. `crypto.randomBytes` for tokens; Argon2id/bcrypt for password hashing; AES-256-GCM with unique nonces for symmetric encryption; TLS 1.3 in transit; environment-variable secrets that the deployment system injects.
+
+### A03 — Injection (SQL, NoSQL, command, LDAP, XSS)
+
+**Detection.** String concatenation building queries, unparameterised user input interpolated into SQL/NoSQL/shell, dynamic-code-evaluation primitives invoked on any user input, direct DOM injection from user-controlled strings, missing output encoding in templates.
+
+```
+grep -rn "exec\|innerHTML\s*=" --include="*.ts" --include="*.js"
+grep -rn "query.*\${" --include="*.ts" --include="*.sql"
+```
+
+The dynamic-code-evaluation family of primitives — those that take a string and execute it as code — is the highest-severity injection surface and should be banned in production code on user-controlled paths.
+
+**Mitigation.** Parameterised queries always (`db.query("WHERE id = $1", [id])`, not template-literal interpolation of user input). Output encoding by default in the templating layer. Allowlist user input where the input space is narrow (enums, IDs). Content-Security-Policy headers to limit XSS blast radius. Forbid the dynamic-code-evaluation primitives entirely on production paths via a project-wide lint rule.
+
+### A04 — Insecure Design
+
+**Detection.** No threat model exists for the feature. Trust boundaries are not documented. Rate limiting absent on expensive operations. Business logic that can be subverted (price-tampering, quantity-tampering, redirect-tampering).
+
+**Mitigation.** Threat-model new features at design time, not at review time. Document trust boundaries (what data is trusted, what is not). Rate-limit expensive operations and authentication endpoints. Server-side validate every business-rule the client could subvert.
+
+### A05 — Security Misconfiguration
+
+**Detection.** Default credentials in production. Verbose error messages (stack traces) returned to users. Unnecessary services enabled. Permissive CORS (`Access-Control-Allow-Origin: *` on credentialed endpoints). Missing security headers (CSP, X-Frame-Options, X-Content-Type-Options).
+
+**Mitigation.** Secure defaults. Generic error messages to users; verbose logs to internal-only systems. Minimal services. Specific allowlisted origins for CORS on credentialed endpoints. Helmet (Node) or equivalent for header defaults.
+
+### A06 — Vulnerable Components
+
+**Detection.** Dependency lockfile not committed. No automated dependency-vulnerability scanning (Dependabot, Snyk, npm audit). Outdated framework versions with known CVEs.
+
+**Mitigation.** Lockfiles committed. Automated vulnerability scanning on every PR. Pin direct dependencies; let the lockfile pin transitive ones. Patch high/critical CVEs within the disclosure SLA (typically 7-30 days).
+
+### A07 — Identification and Authentication Failures
+
+**Detection.** Weak password policies, no rate limiting on login, predictable session tokens, sessions not invalidated on logout, missing MFA option on sensitive accounts, password reset flow with predictable tokens.
+
+**Mitigation.** Use a battle-tested auth library (NextAuth, Auth0, Clerk, Devise) — do not hand-roll. Rate-limit authentication. Invalidate sessions on logout, password change, and privilege escalation. Offer MFA. Password reset tokens must be cryptographically random and single-use with a short expiry.
+
+### A08 — Software and Data Integrity Failures
+
+**Detection.** Insecure deserialisation — using language-native binary deserialisers (e.g., Python's object-deserialisation module, Java native serialisation) on untrusted input is a remote code execution surface. JSON-parse with prototype-pollution risk on untrusted input. Unsigned packages or scripts loaded at runtime. CI/CD pipelines that pull and execute from mutable sources (pipe-to-shell of remote scripts).
+
+**Mitigation.** Treat deserialised data as untrusted; validate against a schema before consuming. Prefer JSON or schema-validated formats over native binary deserialisers for any cross-trust-boundary data. Sign artifacts; verify signatures. Pin script sources by hash for any pipe-to-shell.
+
+### A09 — Security Logging and Monitoring Failures
+
+**Detection.** Authentication failures not logged. Sensitive operations (privilege change, data export) not logged. Logs that contain PII or secrets. No alerting on auth-anomaly patterns.
+
+**Mitigation.** Log every authentication attempt (success and failure). Log every privileged operation with actor and target. Strip PII and secrets from logs. Alert on burst-authentication-failure patterns and unusual privileged actions.
+
+### A10 — Server-Side Request Forgery (SSRF)
+
+**Detection.** User input flowing into outbound HTTP requests (`fetch(userInput)`, `axios.get(userInput)`). Webhook URL validation that allows internal IPs. Image-proxying or URL-preview endpoints.
+
+**Mitigation.** Allowlist outbound destinations. Reject URLs that resolve to RFC 1918 private addresses, link-local, or loopback. Use a separate egress-restricted network namespace for user-driven outbound calls.
+
+## The AI-Generated Code Premium
+
+Empirical studies (Stanford/Microsoft 2023, GitClear 2024) report AI-generated code has 1.7-2.74× the security-issue rate of human-authored equivalents. The recurring failure modes:
+
+- **CWE-89 SQL Injection** — string-concatenated queries, the most common AI failure.
+- **CWE-79 XSS** — direct DOM injection patterns from user-controlled strings, the second most common.
+- **CWE-306 Missing Authentication** — endpoints generated without a thought to who can hit them.
+- **CWE-918 SSRF** — user-input URLs passed to fetch with no validation.
+- **CWE-22 Path Traversal** — file operations with unsanitised paths.
+
+When reviewing AI-generated diffs, give these five categories deliberate attention. The code "looks fine" because it pattern-matches reasonable code; the security flaw is invisible at the line level and visible only when you ask the security questions explicitly.
+
+## Threat-Modelling a New Feature
+
+Four questions, asked at design time:
+
+1. **What are we building?** A one-paragraph summary of the feature, including who the users are.
+2. **What could go wrong?** Walk through STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. For each, name a concrete attacker-story.
+3. **What are we doing about it?** For each "could go wrong", name the mitigation. Defence in depth — at least two independent controls per category.
+4. **Did we do a good job?** What evidence will convince us the mitigations work? Tests, code review, penetration testing, monitoring alerts.
+
+The four questions are due *before* implementation, not during review. A feature without a threat model is shipping its security as a guess.
+
+## Verification
+
+- [ ] Every input boundary (HTTP, CLI, file upload, environment) is identified and the trust posture is explicit
+- [ ] Every privileged action has an authorisation check that defaults to deny
+- [ ] All database queries are parameterised; no string-concatenated SQL/NoSQL
+- [ ] All HTML output is encoded by default; direct DOM injection from user-controlled strings is absent
+- [ ] Dynamic-code-evaluation primitives are forbidden on production paths
+- [ ] Secrets are loaded from environment, not committed in code or logs
+- [ ] Dependencies are scanned on every PR; high/critical CVEs are patched within SLA
+- [ ] Authentication is rate-limited; sessions invalidate on logout, password change, privilege escalation
+- [ ] Outbound HTTP from user input is allowlisted (no SSRF surface)
+- [ ] AI-generated diffs have been audited specifically for the five most-common AI failure modes
+- [ ] A threat model exists for the feature being shipped
+
+## Do NOT Use When
+
+| Use instead | When |
+|---|---|
+| `code-review` | Conducting a holistic per-PR review (security is one concern of many) |
+| `debugging` | Investigating a known production failure (security or otherwise) |
+| `documentation` | Writing security policy or contributor security guide |
+| `testing-strategy` | Deciding broadly what to test (security tests are one slice of strategy) |
+| `skill-scaffold` | Authoring a new SKILL.md, including a security-themed skill |