// 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.
Reference vocabulary for designing instrumented harnesses that drive vulnerability discovery — design classes (trigger-driven vs coverage-driven), tiered scope (T1 isolated function / T2 multi-component / T3 full build), systematic input exploration, the two-coverage distinction (fuzzer-feedback vs audit), existing-fuzzer selection (libFuzzer / AFL++ / Jazzer / atheris / `go test -fuzz`), seed-corpus discipline, diagnostic checkpoints, common pitfalls, and design-document scope. Read when designing or reviewing a harness specification. Stays neutral on language and stack — pulls in the relevant surface skill (e.g. `memory-safety-c-cpp`) for bug-class taxonomy.
Reference vocabulary for interpreting vulnerability findings — detector-vs-impact distinction, severity anchoring on demonstrated evidence, the eleven-item interpretation rubric, delegation transparency, primitive-extent scaling, the disqualifier taxonomy (D-0..D-4), CVSS Achievable / Environmental framing, hedging-phrase elimination, and falsification asymmetry. Read when interpreting a finding to decide whether the demonstrated evidence supports the severity it would warrant. Surface-neutral; pulls in the relevant surface skill (e.g. `memory-safety-c-cpp`) for bug-class-specific exploitability factors.
Reference vocabulary for memory-safety vulnerabilities in native C/C++ code — bug-class taxonomy, common arithmetic patterns that lead to corruption, dispatch-family discipline, type-confusion idioms, use-after-free patterns, and exploitability factors. Read when analyzing, hypothesizing, designing harnesses for, or triaging findings against C/C++ code with sanitizer support (ASAN/UBSAN/TSAN/MSan). Not applicable to managed runtimes (JVM, .NET) or scripting languages — those have their own skills.
Reference for Gmail's search query syntax — operators like is:sent, newer_than:, from:, has:attachment, label:, and how they compose. Read this when constructing a Gmail search query string for the google_workspace.gmail_search_messages Code Mode call, especially when filtering by sent vs received, recency, sender, or labels.
Canonical shape of the .workflow/emails/emails.json file passed between the fetch and summarize states — required fields (sender, recipient, subject, date, body), types, and field semantics. Read this whenever you write or read emails.json so producer and consumer agree on the shape.
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 | 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.
# heading at the top: the report title.## heading whose text is the email subject.### or deeper for per-email metadata; use a bullet list instead.For each email, render metadata as an unordered list immediately under the
## subject heading, in this order:
From: <sender>To: <recipient(s), comma-separated>Date: <as it appears in the source, no reformatting>Summary: <1-2 sentences in prose>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.