Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Security technical decision explainer

Translates a single security architecture decision into three audience-tuned explanations — engineer, PM, and executive — plus a one-line summary, a decision record, and an anticipated-objections table, without…

download .md

Purpose

Take one complex security architecture decision and produce parallel explanations calibrated for engineers, product managers, and executives — each accurate, each in that audience's language and decision frame — so the security engineer can communicate the same choice across the org without repeating the analysis or losing rigor for any group.

When to Use

Invoke this skill when the user asks to:

  • Explain a security architecture decision to engineers, PMs, and executives at once
  • Justify a security tradeoff (e.g., cost, latency, UX friction) to non-technical stakeholders
  • Write an architecture decision record (ADR) or security decision brief for a control or design
  • Prepare for a review where they'll defend a chosen approach against alternatives
  • Communicate a risk-acceptance or risk-mitigation choice to leadership
  • Translate a technical finding or remediation plan into business terms without softening the facts

Inputs Required

Before starting, collect:

  • The decision: What was chosen or is being proposed (e.g., "adopt mTLS for service-to-service auth," "accept the risk of the unpatched legacy dependency for Q3")
  • The alternatives considered: The other options on the table and why they were passed over
  • The driving problem/risk: The threat, gap, or requirement forcing the decision
  • Key tradeoffs: Cost, latency, complexity, developer friction, timeline, or UX impact accepted
  • Target audiences: Which of engineer / PM / executive to produce (default: all three)
  • Stakes & context: Compliance driver, incident history, or deadline shaping the decision
  • Known objections: Any pushback already heard or expected from specific stakeholders

If alternatives or objections aren't provided, infer the most plausible ones from the decision and flag them as assumptions.

Instructions

Step 1: Extract the Decision Core

Before writing for any audience, state internally the invariant facts that must survive every translation:

  • The choice: One sentence, no jargon-free rewording yet
  • The problem it solves: The specific risk or requirement
  • The primary tradeoff: The single most important thing being accepted
  • The reversibility: Is this a one-way door or easily changed later? These facts must be consistent across all three explanations — only framing changes, never substance.

Step 2: Engineer Explanation

Audience frame: How does this work, and will it make my life harder?

  • Lead with the mechanism — the actual control, protocol, or pattern
  • Name the alternatives and give the concrete technical reason each was rejected (performance, blast radius, maintainability, standard-of-practice)
  • State the operational impact: what changes in their workflow, deploys, debugging, or on-call
  • Include the threat model in precise terms — what attacker capability this defends against and what it explicitly does not
  • Be specific about numbers where they exist (latency added, key rotation cadence, coverage gaps)
  • Length: 120–180 words

Step 3: PM Explanation

Audience frame: What does this cost my roadmap, and what do I tell my stakeholders?

  • Lead with the impact on delivery: timeline, dependencies, and any feature or UX friction introduced
  • Translate the risk into user/product terms — what a failure would mean for customers or the product
  • State the tradeoff as a scoped decision, not an open-ended cost ("adds one sprint now, avoids a likely emergency later")
  • Give them a defensible one-liner they can repeat to their own stakeholders
  • Avoid protocol names unless you immediately define the consequence; keep the threat model at the "what could go wrong for the product" level
  • Length: 100–150 words

Step 4: Executive Explanation

Audience frame: What's the business risk, what's it cost, and do I need to act?

  • Lead with the risk-and-decision in one line: what's at stake and what was decided
  • Frame in terms of exposure, cost, compliance, and reputational/financial consequence — not mechanism
  • State the tradeoff as a business judgment with a clear recommendation and confidence level
  • Make the ask explicit: informational, or does it need a decision/budget/sign-off?
  • Zero jargon — if a security term is unavoidable, replace it with its business meaning
  • Length: 60–100 words

Step 5: Decision Record & Objections

Produce two supporting artifacts:

  • One-line summary: A single sentence usable as a Slack message or email subject
  • Decision record (ADR-lite): Context → Decision → Alternatives rejected → Consequences → Status
  • Anticipated objections table: 3–5 likely pushbacks, the audience each comes from, and a direct, honest response for each (do not dismiss valid objections — concede where warranted)

Output Format

  • Structure: Decision core → three audience explanations (clearly labeled) → one-line summary → ADR-lite → objections table
  • Length: 700–1,000 words total
  • Format: Labeled prose sections for the explanations; structured fields for the ADR; a table for objections
  • Sections: Decision Core → For Engineers → For PMs → For Executives → One-Line Summary → Decision Record → Anticipated Objections
  • Tone: Precise and non-condescending — each audience gets full respect; no group is talked down to, none is buried in jargon

Quality Checklist

Before delivering output, verify:

  • [ ] All three audience explanations describe the same decision with no contradictory facts
  • [ ] The engineer version names alternatives with concrete technical rejection reasons
  • [ ] The executive version contains zero undefined security jargon and states an explicit ask
  • [ ] Each explanation stays within its word-count band and leads with that audience's core question
  • [ ] The objections table has 3–5 rows, each tagged to an audience with an honest (not dismissive) response
  • [ ] The ADR-lite includes all five fields (Context, Decision, Alternatives, Consequences, Status)

Notes

  • The failure mode to avoid is a "dumbed-down" executive version that hides the real tradeoff — executives make worse decisions when consequences are softened. Simplify the language, never the stakes.
  • When a decision is a one-way door (hard to reverse), flag reversibility explicitly in all three versions — it changes how urgently each audience should engage.
  • If objections reveal the decision is actually contested rather than settled, say so; this skill explains decisions, it doesn't manufacture false consensus.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills