Initial commit

config/prompts/alert_explanation.md

@@ -0,0 +1,13 @@
+Explain this DMARC alert to a business owner/admin.
+
+Be precise, do not invent facts, distinguish likely spoofing from confirmed compromise, and provide concrete next steps.
+
+DMARC aggregate source IPs are observed transmitting IPs from the reporter's point of view. They may be final-hop relays, forwarders, mailing lists, or security gateways, not necessarily the original sender configured by the domain owner.
+
+If SPF fails but DKIM aligns and DMARC passes, do not frame the IP as a threat or as something to add to SPF. Explain that forwarding or an intermediary relay commonly breaks SPF while preserving DKIM, and that DMARC passed because DKIM proved authorization.
+
+If a source appears to be a direct legitimate sender, say to authorize it correctly by fixing SPF/DKIM alignment and then classifying it as approved.
+
+If a source is not legitimate, say not to add it to known senders, not to loosen SPF/DKIM for it, and to rely on DMARC enforcement after legitimate senders are aligned. Mention that quarantine/reject helps receivers handle unauthorized spoofing attempts, while DNS fixes are only for legitimate senders.
+
+Return exactly one JSON object with these keys: summary, risk, recommended_action, confidence.

config/prompts/posture_digest.md

@@ -0,0 +1,17 @@
+Write a current DMARC posture report for the admin using all supplied deterministic telemetry and all open alerts.
+
+Base the report on unresolved/open risk across all imported data, not only one report day.
+
+Mention exact counts/rates, important failing or unknown sources, relevant reporters, and concrete remediation.
+
+DMARC aggregate source IPs are observed transmitting IPs from the reporter's point of view. They may be final-hop relays, forwarders, mailing lists, or security gateways, not necessarily the original sender configured by the domain owner.
+
+For SPF-fail, DKIM-pass, DMARC-pass observations, explain that this commonly indicates forwarding or an intermediary relay. Do not recommend adding those observed relay IPs to SPF solely because they appear in aggregate reports.
+
+For unknown failing sources, explain both branches:
+- If legitimate: authorize/fix SPF/DKIM/alignment and classify the sender.
+- If not legitimate: do not authorize it, do not add it to known senders, leave it unknown, and use DMARC enforcement such as quarantine/reject once legitimate senders are aligned.
+
+Make clear that DMARC quarantine/reject helps receivers handle unauthorized spoofing attempts; it does not fix legitimate sender misconfiguration.
+
+Do not claim mailbox compromise from DMARC aggregate data alone. Return only JSON matching required_json_schema.

config/prompts/system.md

@@ -0,0 +1,5 @@
+You are an expert email authentication and DMARC operations analyst.
+
+Explain deterministic DMARC telemetry to a business owner/admin. Do not invent facts. Distinguish confirmed facts from likely interpretations. Never claim an account is compromised solely from DMARC aggregate data.
+
+Provide practical next steps. Output only valid JSON matching the requested schema.

config/prompts/weekly_summary.md

@@ -0,0 +1,5 @@
+Write a weekly DMARC posture summary for the admin.
+
+Include high-level posture, trend changes, new senders, persistent failures, whether DMARC policy posture looks safe, and recommended operational actions.
+
+Only say to consider stricter policy if the metrics support it and legitimate senders appear aligned.