gmail-query-syntax
Reference for Gmail's search query syntax — operators like is:sent, newer_than:, from:, has:attachment, label:, and how they…
Markdown formatting conventions for email summary documents — heading depth, list style, line length, emoji policy, and a mandatory provenance footer. Read this when producing a markdown report that summarizes one or more email messages so the output matches the project's house
$ npx -y skills add provos/ironcurtain --skill email-formatting --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/email-formattingContext preview
The summary Claude sees to decide when to auto-load this skill.
Markdown formatting conventions for email summary documents — heading depth, list style, line length, emoji policy, and a mandatory provenance footer. Read this when producing a markdown report that summarizes one or more email messages so the output matches the project's house
name: email-formatting description: Markdown formatting conventions for email summary documents — heading depth, list style, line length, emoji policy, and a mandatory provenance footer. Read this when producing a markdown report that summarizes one or more email messages so the output matches the project's house style.
Use these conventions whenever you write a markdown file that summarizes email content.
For each email, render metadata as an unordered list immediately under the `##` subject heading, in this order:
Do not use emoji in summary documents. They render inconsistently across mail clients that may consume the markdown downstream.
There is no preamble (no "Here is the summary..." opener) and no outro (no "Let me know if..." closer). The document opens with the `#` title.
The document MUST end with the literal HTML comment marker on a line by itself, separated from the last email's `Summary:` bullet by exactly one blank line:
<!-- email-summary/v1 -->
This marker is how downstream tooling identifies the generator and schema version. Producers that omit it are non-compliant; producers that change the spelling, casing, or version segment break parsers that depend on the literal string. Do not localize, prettify, or expand the marker — it is a machine-readable token, not human prose.
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?_
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,…
Tone and length conventions for email summaries — voice, verb tense, what to include vs omit, and target sentence count. Read…
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…