email-formatting
Markdown formatting conventions for email summary documents — heading depth, list style, line length, emoji policy, and a…
Tone and length conventions for email summaries — voice, verb tense, what to include vs omit, and target sentence count. Read this when writing the prose Summary line for each email so the voice is consistent across the report.
$ npx -y skills add provos/ironcurtain --skill summary-style-guide --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/summary-style-guideContext preview
The summary Claude sees to decide when to auto-load this skill.
Tone and length conventions for email summaries — voice, verb tense, what to include vs omit, and target sentence count. Read this when writing the prose Summary line for each email so the voice is consistent across the report.
name: summary-style-guide description: Tone and length conventions for email summaries — voice, verb tense, what to include vs omit, and target sentence count. Read this when writing the prose Summary line for each email so the voice is consistent across the report.
Each email in the report gets a one- or two-sentence prose summary. This document covers the _voice_ of those sentences. For the surrounding markdown structure, the heading depth, and where the summary sits in the document, see the email-formatting conventions.
rather than "I am asking..." or "Alice is asking...".
summary is what the email _did_, not how it was framed.
by Bob".
The summary should answer: _what is the actionable substance of this email?_ Concretely:
distinct items (e.g., a status update _and_ an unrelated ask).
email contains multiple threads of substance and the summary should pick the most actionable one and drop the rest.
If the email is ambiguous or the body is truncated, write a confident summary of what's visible rather than hedging. Do not insert "appears to" or "seems to be" — the consumer of the summary already knows it was machine-derived.
A secure\* runtime for autonomous AI agents, where security policy is derived from a human-readable constitution. _\*When someone writes "secure," you should immediately be skeptical. What do we mean by secure?_
Markdown formatting conventions for email summary documents — heading depth, list style, line length, emoji policy, and a…
Reference for Gmail's search query syntax — operators like is:sent, newer_than:, from:, has:attachment, label:, and how they…
Canonical shape of the .workflow/emails/emails.json file passed between the fetch and summarize states — required fields (sender,…
Reference vocabulary for designing instrumented harnesses that drive vulnerability discovery — design classes (trigger-driven vs…
Reference vocabulary for memory-safety vulnerabilities in native C/C++ code — bug-class taxonomy, common arithmetic patterns that…
Reference vocabulary for interpreting vulnerability findings — detector-vs-impact distinction, severity anchoring on demonstrated…