菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
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.
Reverse /secops-factory:activate — remove the orchestrator default-agent override and the activation metadata from .claude/settings.local.json. Leaves the plugin enabled; only the default persona is cleared.
| name | verify-metrics-report |
| description | 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. |
| argument-hint | <report description or figures to verify> |
Check someone else's numbers against what Jira actually contains. Executes Phase 6 of the effort-analysis methodology.
NO VERIFICATION VERDICT WITHOUT WINDOW ARCHAEOLOGY FIRST
A count that doesn't match your query may still be correct — under a different window convention. Try trailing windows at several plausible run times before declaring a discrepancy. Verdicts issued without establishing the counter's convention are guesses.
Before any other action, say verbatim:
I am using the verify-metrics-report skill to check the reported figures against Jira ground truth.
| Thought | Reality |
|---|---|
| "My query says 61, the report says 63 — the report is wrong" | Establish the window convention first. Exact matches on short windows calibrate; then judge long windows. |
| "Every row should be verifiable in Jira" | Separate Jira-verifiable rows (ticket counts) from pipeline-only rows (alert-feed counts, TTA/TTT). Verify what Jira can verify; say so about the rest. |
| "A 2-ticket delta is a discrepancy" | Boundary noise on a 30-day window is normal, especially when the trailing edge lands on a storm day. >5% is the flag threshold. |
| "The conversion-rate column confirms the counts" | If a derived column reproduces exactly from other columns, it's derived — not independent confirmation. Check and label it. |
| "The report ran at midnight, obviously" | Try several plausible run times. Report generators use local time, UTC, and cron offsets inconsistently. |
| "Close enough overall — verified" | The verdict is per-row: verified / plausible-within-noise / discrepant / not-Jira-verifiable. No blanket stamps. |
jr CLI installed and authenticatedcreated >= "<start>" AND created < "<end>" at several plausible run times until one matches exactly — that pins the counter's convention.artifacts/metrics/report-verification-<date>.md and present inline.${CLAUDE_PLUGIN_ROOT}/data/effort-analysis-method.md — canonical method (Phase 6)