dtsong 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:
- Audience level:
board/ciso/program - Source findings: At least one of: ThreatFinding, ComplianceResult, or VerificationItem entities
- SoC family context: Which family or families this brief covers
- 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
Retrieve: Load upstream entities (ThreatFinding, ComplianceResult, VerificationItem). Load audience calibration and domain context. Check findings ledger for prior briefs on this SoC family.
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 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:
- Caveat block — LLM-generated draft disclaimer + verification summary
- Attack surface checklist — Each area marked ANALYZED or NOT ANALYZED
- Coverage boundary — Explicit scope and out-of-scope areas
- Confidence summary — GROUNDED/INFERRED/SPECULATIVE/ABSENT counts with reliability percentage
- Verification status summary — [HV]/[TV]/[LA] counts
- Traceability appendix — Every finding traced to upstream entity IDs