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.
In this repository15 other files it gives its agents.
- advanced-oscal-validatorSkill
- compliance-report-generatorSkill
- component-definition-builderSkill
- control-implementation-generatorSkill
- control-mapperSkill
- controls-extractorSkill
- evidence-collectorSkill
- oscal-catalog-providerSkill
- oscal-control-mapperSkill
- oscal-ssp-validatorSkill
- oscal-text-converterSkill
- oscal-validatorSkill
- oscal-visualizerSkill
- risk-assessorSkill
- workflow-orchestratorSkill
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
- Distinctive: line 12
Use this skill when you need to:
- Distinctive: line 13
Read and parse OSCAL documents from files
- Very specific: line 58
Look for keys like catalog, profile, system-security-plan, etc.
- Distinctive: line 84
When parsing is complete, provide:
- Distinctive: line 93
When asked "Parse this OSCAL catalog and tell me what's in it":
- Distinctive: line 95
Read the file content
- Distinctive: line 108
File not found: Verify the path is correct
- Distinctive: line 109
Invalid format: Check file extension matches content
≈ “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.
Files
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
| Format | Extensions | Notes |
| JSON | .json | Most common format, fastest parsing |
| YAML | .yaml, .yml | Human-readable, good for editing |
| XML | .xml | Legacy 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 versiongroups- Control familiescontrols- Individual security controlsback-matter- Resources and references
System Security Plan:
metadata- System identificationimport-profile- Baseline referencesystem-characteristics- System descriptionsystem-implementation- Implementation detailscontrol-implementation- How controls are implemented
Component Definition:
metadata- Component identificationcomponents- Individual componentscapabilities- Component capabilities
Output Structure
When parsing is complete, provide:
- Format detected (JSON/YAML/XML)
- Model type (catalog, SSP, etc.)
- Metadata summary (title, version, last modified)
- Content summary (count of controls, components, etc.)
- Any parsing warnings or issues
Example Usage
When asked "Parse this OSCAL catalog and tell me what's in it":
- Read the file content
- Detect format from extension
- Parse the content
- Identify it as a catalog
- 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
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
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.

