agentleFS
euCanneuCann/OSCAL-GRC-SKILLS/skills/oscal-parser/SKILL.md

oscal-parser

Skill8 starsChanged 10 months agoMITView on GitHub

Parse OSCAL (Open Security Controls Assessment Language) documents in JSON, YAML, or XML formats and extract structured compliance data. Use this skill when working with security control catalogs, system security plans, component definitions, or other OSCAL document types.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when you need to:

    line 12
  2. Distinctive:

    Read and parse OSCAL documents from files

    line 13
  3. Very specific:

    Look for keys like catalog, profile, system-security-plan, etc.

    line 58
  4. Distinctive:

    When parsing is complete, provide:

    line 84
  5. Distinctive:

    When asked "Parse this OSCAL catalog and tell me what's in it":

    line 93
  6. Distinctive:

    Read the file content

    line 95
  7. Distinctive:

    File not found: Verify the path is correct

    line 108
  8. Distinctive:

    Invalid format: Check file extension matches content

    line 109

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

OSCAL Parser Skill

Parse OSCAL documents in any supported format (JSON, YAML, XML) and extract structured data for compliance analysis.

When to Use This Skill

Use this skill when you need to:

  • Read and parse OSCAL documents from files
  • Detect the format and model type of an OSCAL document
  • Extract metadata, controls, components, or other OSCAL elements
  • Convert OSCAL data into a workable structure for further analysis

✅ Data Source Principle

This skill operates only on documents you provide. It reads and parses — it does not generate compliance data from training knowledge. All output comes directly from your OSCAL document.


Supported Formats

FormatExtensionsNotes
JSON.jsonMost common format, fastest parsing
YAML.yaml, .ymlHuman-readable, good for editing
XML.xmlLegacy format, full schema support

OSCAL Model Types

The parser automatically detects these OSCAL model types:

  • Catalog - Security control catalogs (e.g., NIST 800-53)
  • Profile - Control baselines and overlays
  • System Security Plan (SSP) - System security documentation
  • Component Definition - Reusable component security capabilities
  • Assessment Plan - Assessment procedures
  • Assessment Results - Assessment findings
  • Plan of Action and Milestones (POA&M) - Remediation tracking

How to Parse an OSCAL Document

Step 1: Identify the File

Confirm the file path and check the extension to determine format.

Step 2: Parse the Content

Based on the format:

  • JSON: Parse using standard JSON parsing
  • YAML: Parse using YAML safe loading
  • XML: Parse using XML to dictionary conversion

Step 3: Detect Model Type

Examine the root keys to identify the document type:

  • Look for keys like catalog, profile, system-security-plan, etc.
  • The presence of specific keys indicates the model type

Step 4: Extract Key Information

For each model type, extract:

Catalog:

  • metadata - Title, version, OSCAL version
  • groups - Control families
  • controls - Individual security controls
  • back-matter - Resources and references

System Security Plan:

  • metadata - System identification
  • import-profile - Baseline reference
  • system-characteristics - System description
  • system-implementation - Implementation details
  • control-implementation - How controls are implemented

Component Definition:

  • metadata - Component identification
  • components - Individual components
  • capabilities - Component capabilities

Output Structure

When parsing is complete, provide:

  1. Format detected (JSON/YAML/XML)
  2. Model type (catalog, SSP, etc.)
  3. Metadata summary (title, version, last modified)
  4. Content summary (count of controls, components, etc.)
  5. Any parsing warnings or issues

Example Usage

When asked "Parse this OSCAL catalog and tell me what's in it":

  1. Read the file content
  2. Detect format from extension
  3. Parse the content
  4. Identify it as a catalog
  5. Report:
    • Title and version
    • Number of control families
    • Total number of controls
    • OSCAL version used

Error Handling

Handle these common issues:

  • File not found: Verify the path is correct
  • Invalid format: Check file extension matches content
  • Malformed content: Report specific parsing errors
  • Unknown model type: List root keys for manual identification

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.