Agent Skills

Skills are predefined task templates that guide the agent through specific compliance workflows.

Available Skills

The Tools column is the size of the skill’s allow-list. The unskilled agent gets all 61 platform function tools, so every skill is a narrowing.

Each skill bundles a system prompt, a tool allow-list, and a max_turns ceiling. How these get applied depends on the runtime:

• Codex runtime (default): the skill’s system prompt is appended to the agent’s prompt as additional guidance. tool_names is not used as a filter — the Codex session has access to every Pretorin MCP tool. max_turns is not enforced — the Codex SDK governs turn count via its own session loop.
• --legacy runtime (OpenAI Agents SDK): the skill’s system prompt replaces the default instructions, the function tools are filtered to tool_names, and max_turns is enforced by the runner.

If you need hard tool/turn restrictions, run with --legacy. Otherwise rely on the skill’s system prompt to keep the Codex agent in scope.

--skill is validated against the registry before either runtime starts: an unknown name exits with code 1 and lists every registered skill, rather than silently falling through to an unskilled run.

The per-skill allow-lists below name the tools the --legacy runtime exposes. They are also the intended working set under the Codex runtime, which enforces them only through the system prompt.

Using Skills

# Gap analysis
pretorin agent run --skill gap-analysis "Analyze my system compliance gaps"

# Narrative generation
pretorin agent run --skill narrative-generation "Generate narratives for all AC controls"

# Evidence collection
pretorin agent run --skill evidence-collection "Collect evidence for AC-02 in this repo"

# Security review
pretorin agent run --skill security-review "Review this codebase for AC-02 coverage"

# STIG scan
pretorin agent run --skill stig-scan "Check STIG applicability for my system"

# CCI assessment
pretorin agent run --skill cci-assessment "Assess CCI compliance for AC-02"

List Skills

pretorin agent skills

Skill Details

Gap Analysis

Read-only platform analysis that identifies controls without complete implementation. The agent:

1. Lists systems and their associated frameworks
2. Checks the compliance status for each system
3. Identifies controls that are not yet implemented or only partially implemented
4. Prioritizes gaps by risk level (controls in higher-impact families first)
5. Provides actionable recommendations for closing each gap

This skill does not write to the platform — it produces a structured report with sections for each framework. To capture findings as evidence or update narratives, follow up with evidence-collection or narrative-generation.

See Gap Analysis Workflow for the broader methodology that combines this skill with codebase search.

Tools: list_systems, get_system, get_compliance_status, list_frameworks, list_controls, get_control, get_control_implementation, get_control_context, get_scope, search_evidence

Narrative Generation

Generates control implementation narratives that meet auditor-readiness requirements:

• No section headers or standalone bold labels — start directly with the implementation overview because the SSP supplies headings
• Target 150–300 words, require at least 800 characters, and never exceed 400 words
• A short implementation overview plus a compact Expectation | Implemented behavior | Evidence table
• Supported operating detail such as ownership, mechanism, cadence, verification, or retention; a few bullets alone are not sufficient
• No markdown images (until platform-side image evidence upload is available)
• No gaps, missing-information placeholders, or remediation backlog in narrative text
• Only documents observable facts (no hallucination)
• Maps supporting evidence to declared expectation keys before narrative composition
• Re-reads and reports covered/uncovered expectations plus unbound evidence
• Saves with AI review disabled unless the user explicitly requests review of the final generation

Under the Codex runtime, that last point is enforced by the MCP update_narrative tool: trigger_review and review_requested_by_user both default to false, and the handler refuses the review — without saving the narrative — if trigger_review=true arrives without review_requested_by_user=true. The --legacy runtime’s in-process update_narrative has no review parameters at all, so review can never be requested from that path.

Evidence descriptions retain their separate, lighter profile: at least one rich markdown element, no section headers or standalone bold labels, and no gap lists, missing-information placeholders, unresolved caveats, or remediation backlog. Control issues (add_control_issue) are the durable home for gaps — don’t inline them in evidence or narratives.

The 800-character floor and 400-word ceiling are quality bounds, not writing targets to pad or fill. Agents should stay near the word-count range and use only supported detail. Built-in generation gets one automatic repair attempt when its draft is too short or lacks the implementation table; a second failure is returned as an explicit quality error instead of a weak narrative.

Narrative citations ground claims but do not satisfy expectation coverage. Every artifact must be linked with an expectation_key or deliberately left unconfirmed with unbound_reason. Recipe/source availability problems remain preflight warnings. Treat ai_analysis as explanatory read-only output: the platform reconciler owns AI finding Issues and exposes them through the issue reads with ai_review_finding_key. Agents create Issues only for gaps independently observed in the workspace or another connected source, so stale or superseded review output cannot create duplicates.

Tools: list_systems, get_system, list_frameworks, get_control, get_control_implementation, get_control_context, get_scope, search_evidence, get_narrative, get_control_issues, link_evidence, update_narrative, add_control_issue, resolve_control_issue

Evidence Collection

Searches the codebase for evidence that maps to specific controls:

• Identifies relevant files and code patterns
• Creates evidence items with auditor-ready descriptions
• Links evidence to controls via the platform
• Binds each artifact to the expectation key it supports (or records an explicit unbound reason)
• Re-reads coverage and reports covered, uncovered, and unbound results
• Records gaps as issues when evidence is missing

Tools: list_systems, get_system, list_frameworks, get_control, get_control_context, get_scope, search_evidence, create_evidence, create_evidence_batch, link_evidence, get_control_issues, add_control_issue, resolve_control_issue

Security Review

Reviews the codebase against specific controls and records findings on the platform:

• Analyzes code for control coverage
• Identifies implementation strengths and weaknesses
• Documents findings with file paths and line numbers
• Pushes monitoring events for critical or high-severity findings
• Reopens control authoring with in_progress and drafts narratives based on findings
• Adds issues for findings that require manual remediation
• Produces remediation recommendations

This is the broadest write-side skill — it can call push_monitoring_event, update_control_status (only in_progress), update_narrative, create_evidence, link_evidence, and add_control_issue/resolve_control_issue in addition to the read-side platform tools. Issue closure is not part of this skill’s surface: it is governed and runs through verify_issue (or void_issue) once treatment completes.

Tools: list_systems, get_system, get_compliance_status, get_control, get_control_implementation, get_control_context, get_scope, push_monitoring_event, update_control_status, update_narrative, create_evidence, link_evidence, search_evidence, get_control_issues, add_control_issue, resolve_control_issue

STIG Scan

Runs STIG compliance scans against a system:

• Checks which STIGs apply to the system (applicability)
• Gets the test manifest (rules to evaluate)
• Reports available scanners and rule coverage
• Summarizes the scan plan and gaps in automated coverage

Tools: list_systems, get_system, get_compliance_status, list_stigs, get_stig, get_stig_applicability, get_test_manifest, get_cci_status

CCI Assessment

Assesses CCI-level compliance for a specific control:

• Gets control context and implementation status
• Lists CCIs for the target control
• Checks CCI-level test results (pass/fail/not tested)
• Identifies CCIs with no test coverage
• Presents results as a traceability chain: Control -> CCIs -> STIG rules -> test results

Tools: get_system, get_control, get_control_context, get_control_implementation, list_ccis, get_cci, get_cci_chain, get_cci_status, search_evidence