Menu
Use when updating JIRA security ticket custom fields with enrichment data. Validates data, maps to configured field IDs, and updates via jr CLI.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when generating security operations metrics and KPIs — from local enrichment/review artifacts AND from Jira ground truth via the jr CLI (SLA compliance, cycle time, backlog health, alert storms, workload, disposition mix).
Use when measuring how much analyst time is spent populating/maintaining Jira tickets, or baselining ticket volume per client/type/month. Reconstructs work sessions from ticket event timestamps (creation, field edits, comments) — works with empty worklogs.
Use when alert severity/criticality exist only as text in analyst worksheet comments (no native Jira field) — extracts them with whitelisted regex over ADF comment bodies and reports coverage.
Use when modeling annual ticket-administration cost for an existing client or a prospect — OSINT T-shirt sizing, analog selection, and Low/Base/High cost scenarios from measured effort priors.
Use when checking an external or automated metrics report (dashboards, colleague spreadsheets, tool-generated counts) against Jira ground truth — window archaeology, boundary-noise tolerance, and derived-column detection.
Opt in to the SecOps Factory companion for this project. Writes .claude/settings.local.json to set the orchestrator (Morgan, the SOC Operations Coordinator) as the default main-thread agent. Reversible via /secops-factory:deactivate.
| name | update-jira |
| description | Use when updating JIRA security ticket custom fields with enrichment data. Validates data, maps to configured field IDs, and updates via jr CLI. |
| argument-hint | <ticket-id> |
Update JIRA security alert custom fields with enrichment data via jr CLI.
NO JIRA UPDATE WITHOUT REVIEW APPROVAL FIRST
JIRA updates represent the official record. Updating before review approval means posting unvalidated analysis as authoritative. Check for the review-approval marker before proceeding.
Before any other action, say verbatim:
I am using the update-jira skill to update ticket with enrichment data.
| Thought | Reality |
|---|---|
| "The enrichment looks complete, I'll skip review check" | Iron Law. Check for review-approval marker. |
| "I'll update priority first and finish the rest later" | Partial updates create inconsistent state. Update all fields together. |
| "Field update failed, I'll skip it" | Log the failure, continue with other fields, report partial success. |
| "CVSS is 11.0, that seems right" | Validate ranges: CVSS 0.0-10.0, EPSS 0.0-1.0. Reject invalid data. |
| "I don't know the field IDs, I'll guess" | Load field mappings from config. Never guess custom field IDs. |
| "The cloud_id is in the error message, that's fine" | Never expose cloud_id in user-facing output. Security consideration. |
Look for review-approval marker in conversation context or JIRA comments. If not found, HALT:
Review approval required before JIRA update. Run /review-enrichment first.
Validate each field:
CVE-\d{4}-\d{4,7}Skip invalid fields with warning. Continue with valid fields.
jr CLI:
jr issue edit <ticket-id> --priority <priority-name>
jr issue comment <ticket-id> "Enrichment complete. CVSS: X.X, EPSS: X.XX, KEV: Y/N, Priority: PX" --markdown
jr issue move <ticket-id> "Enriched"
jr issue view <ticket-id>
Report: fields updated, fields skipped, any errors.