← Back to Whitepapers Core Innovation

WP05 — Skill-Based Platform: A Never-Changing Core with a Shared Skill Library

> Thesis: The platform's core binary never ships a new release. Every module — every scanner, every fuzzer, every reporter, every agent — is assembled at runtime from skills pulled out of a shared, versioned Skill Library. Adding support for a new technology is no longer an engineering project that touches the core; it is a documentation project that drops a new skill package into the library. The result is a security platform whose capability surface grows continuously while its attack surface for regression stays frozen at zero.

This whitepaper specifies the architecture, schema, loader, runtime composition, versioning, marketplace, and safety model of a Skill-Based Platform. It is written to be implementable: every section contains enough concrete detail (YAML schemas, sequence diagrams rendered as ASCII, code-shaped pseudocode, threat models) that a small team could begin construction within a sprint. It also situates the design against two prior art systems — Legion's plugin framework and CAI's modular agents — and explains where the Skill-Based Platform deliberately diverges.

Table of Contents

  • Motivation: Why the Core Must Never Change
  • What Is a Skill?
  • Skill Schema (YAML)
  • Skill Categories
  • Skill Loader Architecture
  • Runtime Composition
  • Versioning and Compatibility
  • The Skill Marketplace
  • Safety Rules and Sandboxing
  • Comparison: Legion Plugins vs. CAI Modular Agents vs. Skill-Based Platform
  • Operational Scenarios
  • Failure Modes and Mitigations
  • Roadmap
  • Appendix: Glossary

    • 1. Motivation: Why the Core Must Never Change

    Every security platform of meaningful age carries a scar pattern: the core was once small and correct, then feature requests arrived, then the core grew, then the core became the thing everyone is afraid to touch. A refactor that should have taken a day now takes a quarter because the core is simultaneously the scheduler, the transport, the plugin host, the policy engine, the report renderer, and the catalog of every technology the platform has ever been asked to look at. Releases become coordination problems. A regression in the HTTP/2 parser delays the release that also fixes a memory leak in the MQTT fuzzer, because both live in the same binary and ship on the same train.

    The Skill-Based Platform inverts this. The core is a deliberately tiny, deliberately boring program. It does exactly four things:

  • Load skills from the Skill Library.
  • Compose those skills into runnable modules at request time.
  • Enforce safety policy around every skill invocation.
  • Stream results to the operator and to durable storage.

    • It does not know what HTTP is. It does not know what MQTT is. It does not know what a Kubernetes API server is. It knows how to read a skill manifest, validate it, materialize the components the manifest describes, wire those components into a directed graph, run that graph under a resource envelope, and emit results. The knowledge of what to do lives entirely in skills. The knowledge of how to do it safely lives in the core. This separation is the single most important property of the system, and every other design decision in this document exists to defend it.

    The payoff is mechanical. When a customer asks, "Can you scan our new IoT protocol stack?", the answer is never "we'll put it on the roadmap for Q3." The answer is "we'll have a skill for it by Friday." Adding a technology is no longer a core change; it is a skill package, and a skill package is 1–2 hours of focused work for a domain expert. Zero downtime, zero regression risk to the core, zero coordination with a release train. The skill is written, validated against the schema, pushed to the marketplace, and available to every deployed platform instance within the library's propagation window (seconds for a cloud-hosted library, minutes for an on-prem mirror).

    2. What Is a Skill?

    A skill is the smallest unit of capability the platform understands. It is a self-contained, declaratively-described package that teaches the platform how to engage with one specific technology, technique, or reporting format. Critically, a skill is not code that runs inside the core. A skill is a manifest (the skill.yaml) plus a set of assets (knowledge documents, command definitions, pattern libraries, parser scripts, report templates). The core reads the manifest, loads the assets, and uses them to compose a module at runtime. The skill itself is inert until the core activates it.

    Every skill contains exactly five component slots, each of which is optional but at least one must be present:

    Slot Purpose Format Example ------------ Knowledge Domain context, CVE references, config defaults, threat models Markdown + structured YAML frontmatter "Apache 2.4.49 has CVE-2021-41773; path traversal in mod_alias; check /cgi-bin/." Commands Executable actions the platform can run Declarative command specs (argv templates, container images, HTTP requests) "Run nuclei -t cves/2021/CVE-2021-41773.yaml -u {target}" Patterns Regex / AST / semantic matchers for identifying findings in command output or raw traffic YAML pattern definitions with severity and confidence "Match 403 followed by path containing ../ → Path Traversal, High." Parser Transforms raw command output into normalized findings Python script (sandboxed) or declarative JSONata/jq expression "Parse nuclei JSON output → Finding objects." Report Template Human-facing rendering for findings produced by this skill Jinja2 / Markdown / HTML template "Render CVE-2021-41773 findings as an executive summary section."

    A skill that only has knowledge is a reference skill — the platform can surface it to operators or feed it to an LLM agent as context, but it won't run commands. A skill that has commands and patterns but no parser will rely on the core's default parser. A skill that has only a report template is a presentation skill that formats findings from other skills. This composability is intentional: skills are Lego bricks, not monoliths.

    2.1 Skill Identity

    Every skill has a globally unique identity composed of three parts:

    Appendix: Glossary

    Term Definition ------ Skill The smallest unit of platform capability. A declarative package with knowledge, commands, patterns, parser, and report template. Skill Library The collection of all available skills, organized by category and version. Skill Registry The in-process, in-memory index of loaded skills. The core's source of truth for what is available. Core The never-changing platform binary. Loads skills, composes modules, enforces safety, streams results. Module A running instance of a composition DAG. The unit of execution. Composition The process of selecting skills and wiring them into a DAG for a given target and engagement. Finding The normalized output unit of any skill. Has severity, confidence, target, evidence, class, and CWE. Engagement Mode A safety tier (safe, standard, aggressive) that gates which impact levels are allowed. Impact A skill's declared potential to affect the target: passive, non-destructive, active, destructive. Marketplace The signed, versioned, channel-tiered registry where skills are published, discovered, and subscribed to. Channel A maturity/trust tier in the marketplace: dev, beta, stable, verified. Library Manifest Hash A cryptographic hash of the library's complete skill inventory at a point in time. Used for reproducibility. DAG Directed Acyclic Graph. The structure of a composed module. Nodes are skills; edges are dependencies and data flows. Executor The runtime that executes a skill's command: container, process, http, or inline.

    This document specifies the Skill-Based Platform architecture as of schema version skill.platform/v1. The design is stable; the skill library is not. That is the point.

    ← ALL WHITEPAPERS