executive-brief-skill

name	executive-brief-skill
description	Use this skill when translating technical security findings into executive communication — BLUF briefs, risk summary tables, or audience-adapted posture reports. Triggers on "executive summary of findings", "brief the CISO", "board-level security update", "summarize risks for leadership". Supports board, CISO, and program-level audiences. Do NOT use for technical analysis (use threat-model-skill or attack-domain specialists) or compliance tracking (use compliance-pipeline-skill).
model	{"preferred":"sonnet","acceptable":["sonnet","opus"],"minimum":"sonnet","allow_downgrade":true,"reasoning_demand":"medium"}

Executive Brief Skill for Claude

Scope Constraints

• Read files ONLY within the project working directory
• Do NOT access home directory dotfiles, external services, or execute shell commands
• Do NOT modify any files — this skill performs read-only translation
• Output ONLY the structured ExecutiveBrief format defined below

Input Sanitization

Reject inputs containing path traversal (../), shell metacharacters (; | & $ ` \), or paths outside the project working directory.

Core Principles

1. Translation, Not Simplification

Every technical finding passes through four layers of increasing abstraction, but each layer maintains a traceable link to the one below. An executive reading "Prioritize fix in Q2 silicon respin" can trace that recommendation through business risk, security impact, all the way back to the specific TLP vulnerability in the TDISP state machine.

2. BLUF First, Always

The Bottom Line Up Front must contain: the most critical risk, the recommended action, the timeline and approximate cost, and what happens if action is deferred. Everything else is supporting evidence.

3. Audience Determines Depth, Not Truth

Board, CISO, and program audiences get different depth but never different facts. Never change severity or risk rating based on audience.

4. LLM-Assessed vs. Human-Verified: Always Distinguish

Every finding carries a verification badge:

• [LA] LLM-assessed — Generated by this skill suite; awaiting human review
• [HV] Human-verified — Reviewed and confirmed by a domain expert
• [TV] Tool-verified — Validated by automated tooling (SVA, formal, simulation)

This prevents executives from treating LLM-generated draft findings as confirmed facts.

5. Traceability Is Non-Negotiable

Every finding traces to a source document ID. Every risk rating traces to specific threat findings or compliance results. If you cannot trace a claim, do not include it.

---

Shared References

Load these references when activated:

Reference	Location
Entity Schema	shared-references/soc-security/entity-schema.md
Executive Communication Guide	shared-references/soc-security/cross-cutting/executive-communication.md
Domain Ontology	shared-references/soc-security/domain-ontology/technology-domains.md
SoC Family Profiles	shared-references/soc-security/domain-ontology/soc-families.md
Cross-Cutting References	shared-references/soc-security/cross-cutting/

Load skill-specific references as needed:

Reference	Location
Executive Templates	references/executive-templates.md
Abstraction Methodology — Translation	references/abstraction-methodology-translation.md
Abstraction Methodology — Examples	references/abstraction-methodology-examples.md

---

Input Requirements

Before generating, confirm with the engineer:

1. Audience level: board / ciso / program
2. Source findings: At least one of: ThreatFinding, ComplianceResult, or VerificationItem entities
3. SoC family context: Which family or families this brief covers
4. Output format: brief (default) / risk-entry / status-update

Optional: previous brief (for delta analysis), trend data, cost estimates, timeline constraints, custom audience context.

If inputs are missing, prompt:

"To generate the executive brief, I need: (1) audience level, (2) source findings, (3) SoC family, (4) output format. You can provide these conversationally."

---

The 4-Layer Abstraction Model

Every technical finding passes through four layers. Each adds context and removes implementation detail while maintaining traceability.

Layer 0: Raw Technical Finding
    "DMA bypass via malformed TLP in TDISP handshake"
    |
Layer 1: Security Impact Statement
    "Attacker with physical access can bypass memory isolation"
    |
Layer 2: Business Risk Statement
    "Customer data in confidential AI pipelines may be exposed"
    |
Layer 3: Executive Action Item
    "Prioritize fix in Q2 silicon respin. Cost: ~2-3 engineer-weeks.
     Risk if deferred: potential customer data exposure in production."

Layer 0: Verbatim from upstream entities. Not shown to executives — exists in appendix for traceability. Include entity ID, source, confidence tier, verification status.

Layer 1: Replace hardware-specific terms with security-domain equivalents. Specify attacker profile and access required. State which security property is violated. Keep scope precise.

Layer 2: Translate security impact to business consequence. Name specific business assets at risk. Reference applicable regulations. Quantify exposure scope. Do not catastrophize.

Layer 3: State recommended action in imperative form. Tie timeline to known milestones. Estimate cost in engineer-weeks (mark [ESTIMATED] if not engineer-provided). State deferral consequence in business terms. If cost/timeline unknown, use "TBD" — do not fabricate.

Load references/abstraction-methodology-translation.md for translation rules and vocabulary mapping tables. Load references/abstraction-methodology-examples.md for worked examples across all five technology domains and per-layer quality checks.

---

Audience Calibration

Load references/audience-calibration.md for vocabulary guide, depth calibration, and action framing per audience level.

---

Output Format

Three output formats are supported: brief (full executive brief), risk-entry (single risk register entry), and status-update (remediation progress). Load references/executive-templates.md for all templates.

Full Executive Brief Template (Board-Level)

---
type: exec-brief
id: EB-{YYYY}-{NNN}
title: "{SoC Family} Security Posture Brief — {Date}"
created: {YYYY-MM-DD}
updated: {YYYY-MM-DD}
soc-family: [{families}]
technology-domain: [{domains}]
standards: [{standard versions}]
related-documents: [{TM-IDs, CM-IDs, VC-IDs}]
status: draft
confidence-summary: {grounded: N, inferred: N, speculative: N, absent: N}
caveats: |
  LLM-generated executive brief. All findings require human verification
  before use in executive decision-making. Items marked "LLM-assessed"
  have not been confirmed by a domain expert.
---

# {SoC Family} Security Posture Brief

**Audience:** {board / ciso / program}
**Date:** {YYYY-MM-DD}
**Prepared by:** SoC Security Skills Suite (LLM-assisted draft)
**Status:** Draft — Requires engineer review before distribution

> **Caveat:** This brief is an LLM-generated draft. All findings marked
> "LLM-assessed" require human verification. Risk ratings and cost
> estimates are preliminary. This is NOT a formal security assessment.

## Bottom Line Up Front

{3-8 sentences calibrated to audience. Contains: posture assessment
(Red/Amber/Green), most critical risk, recommended action, timeline,
cost, deferral consequence, verified vs. unverified count.}

## Risk Summary

| # | Finding | Severity | Trend | Verification | Action Required |
|---|---------|----------|-------|--------------|-----------------|
| 1 | {Layer 2 summary} | Critical | {arrow} | {badge} | {Layer 3 action} |

Severity: Critical/High/Medium/Low. Trend: ^ Worsening, v Improving,
= Stable, * New. Badges: [HV] Human-verified, [TV] Tool-verified,
[LA] LLM-assessed.

## Detailed Findings

### Finding 1: {Layer 2 Title}

**Severity:** {level} | **Verification:** {badge} | **Confidence:** {tier} | **Source:** {IDs}

**Security Impact:** {Layer 1}
**Business Risk:** {Layer 2}
**Recommended Action:** {Layer 3}

## Compliance Status Summary

{If ComplianceResult entities available — table of standard coverage and gaps.}

## Confidence Summary

| Tier | Count | Meaning |
|------|-------|---------|
| GROUNDED | {N} | Directly supported by specification or evidence |
| INFERRED | {N} | Logically derived; awaiting verification |
| SPECULATIVE | {N} | Plausible; requires human confirmation |
| ABSENT | {N} | Not analyzed — coverage gap |

## Appendix A: Finding-to-Source Traceability

| Brief # | Layer 0 (Technical) | Threat Model | Compliance Gap | Verification |
|---|---|---|---|---|
| 1 | {TF-ID}: {description} | {TM-ID} | {CR-ID} | {VI-ID} |

## Appendix B: Attack Surface Coverage

| Area | Status | Notes |
|------|--------|-------|
| Side-channel / Fault injection / Debug interface / Key management / Boot chain / Firmware update / Bus access control | ANALYZED or NOT ANALYZED | {note} |

---

Progress Tracking

Copy this checklist and update as you complete each phase:

Progress:
- [ ] Phase 1: Retrieve
- [ ] Phase 2: Reason
- [ ] Phase 3: Render

Recovery note: If context has been compacted and you've lost prior step details, check the progress checklist above. Resume from the last unchecked item. Re-read the relevant reference file for that phase.

Generation Pipeline

1. Retrieve: Load upstream entities (ThreatFinding, ComplianceResult, VerificationItem). Load audience calibration and domain context. Check findings ledger for prior briefs on this SoC family.

2. Reason: For each finding: classify severity using the mapping below, apply 4-layer abstraction, determine trend (NEW if no prior brief), validate traceability, propagate confidence (brief confidence cannot exceed upstream confidence).

   Upstream Signal	Executive Severity
   ThreatFinding.severity: critical	Critical
   ThreatFinding.severity: high	High
   ComplianceResult.coverageStatus: gap + mandatory	High
   ComplianceResult.coverageStatus: partial	Medium
   ThreatFinding.severity: medium	Medium
   ThreatFinding.severity: low or informational	Low

3. Render: Select template by output format. Apply audience calibration for vocabulary and depth. Populate all sections. Add mandatory elements: caveat block, attack surface checklist, coverage boundary, confidence summary, traceability appendix. Wrap in DocumentEnvelope frontmatter.

---

Interaction Patterns

Starting: Confirm audience level, source findings, SoC family, and output format. Briefly explain the 4-layer abstraction approach.

Presenting draft: Prompt engineer to review: severity ratings, cost estimates, action items, verification badges, and SPECULATIVE items. All findings default to [LA] until engineer upgrades them.

Missing cost/timeline: Offer three options: leave as TBD, use order-of-magnitude estimate marked [ESTIMATED], or accept engineer-provided range.

Sparse upstream data: Note which analysis areas are absent (threats, compliance, verification). Proceed with available data; the brief will flag coverage gaps.

Updating a prior brief: Load prior EB-ID as baseline. Produce delta showing resolved, changed-severity, and new findings with overall posture trend.

---

Guardrails

Severity: Never downgrade for audience comfort. Never upgrade without evidence (document rationale if context justifies it). Severity is based on exploitability and impact, not likelihood of fix.

Traceability: Every Risk Summary finding must appear in Appendix A. Never include findings without upstream source — flag new risks to the engineer instead. Mark broken chains [TRACEABILITY GAP — source document needed].

Confidence: SPECULATIVE findings get prominent caveats. LLM-assessed findings use hedging language ("Preliminary assessment indicates..." not "The vulnerability exists"). Confidence summary is mandatory.

Content integrity: Do not fabricate cost estimates (use "TBD" or mark [ESTIMATED]). Do not fabricate competitive comparisons (mark training-derived context [FROM TRAINING — verify independently]). Do not recommend actions beyond the engineering team's control without flagging. Every Layer 3 action must be achievable. Every Layer 2 risk must be plausible — do not catastrophize. Do not invent trend data — if no prior assessment exists, all findings are NEW.

---

Knowledge Base Integration

At invocation start, check knowledge-base/findings-ledger.md for prior briefs matching the target SoC family. Use prior briefs as trend baselines (NEW/RESOLVED/Worsening/Improving/Stable).

At conclusion, append significant findings to the ledger:

## [FINDING-{YYYY}-{NNN}] — {Title}
- Date: {YYYY-MM-DD}
- SoC Family: {family}
- Technology Domain: {domain}
- Finding: {Layer 2 business risk statement}
- Resolution: {Layer 3 recommended action}
- Reusability: {High/Medium/Low}
- Related: [{upstream entity IDs, prior brief IDs}]

---

Mandatory Output Elements

Every executive brief MUST include:

1. Caveat block — LLM-generated draft disclaimer + verification summary
2. Attack surface checklist — Each area marked ANALYZED or NOT ANALYZED
3. Coverage boundary — Explicit scope and out-of-scope areas
4. Confidence summary — GROUNDED/INFERRED/SPECULATIVE/ABSENT counts with reliability percentage
5. Verification status summary — [HV]/[TV]/[LA] counts
6. Traceability appendix — Every finding traced to upstream entity IDs