Morning Brief

This is a Hermes-native morning-brief workflow skill.

Why This Exists

morning-brief exists to connect mail and calendar access for an on-demand brief while keeping the connection strictly read and draft-only and credential entry outside chat, with explicit storage authorization.

Do Not Use When

• The user wants Hermes to check their email or calendar right now rather than set up the connection.
• The connection is already configured and the user only wants today's brief, not a setup walkthrough.
• The request needs a repository code change rather than a local MCP config edit.

Examples

Good example:

• Prompt: connect my email for a morning brief — I want a daily summary of mail and calendar.
• Expected behavior: Check the MCP prerequisite, diagnose the current connection, guide OAuth/token issuance, show the read/draft-only diff, and apply only after approval.
• Why: The request is a mail/calendar integration setup and needs the shared setup contract plus the Send-permission guardrail.

Bad example:

• Prompt: morning-brief: check my email for anything urgent.
• Expected behavior: Route to a mail-reading task instead of starting a connection setup walkthrough.
• Why: A one-off email check is a task request, not an integration setup request.

Completion Checklist

• If a prerequisite is unmet, mark that item "not applicable" and continue with the rest of the guide instead of blocking or guessing.
• Success is applicable-only: verification passes when every applicable item is confirmed complete, not when every possible item exists.
• The connection is confirmed read and draft-only, with Send permission never enabled, before the brief is reported ready.

Recovery Notes

• If the mail or calendar prerequisite is unmet, mark that surface "not applicable" and offer the brief scoped to whichever surface is connected.
• If authentication fails, guide reauthorization or reissuance through secure entry or user-side setup; do not request the failed credential in chat or silently retry it.

Workflow Lane

• Current lane: Automation and status (achievements, workspace-audit, production-audit, live-incident-response, automation-blueprint, github-event-ops, github-issue-intake, buzz, +39 more) - schedules, status, health, and ops review.
• If intent belongs to another lane, hand back to oh-my-hermes or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: omh-routing/references/skill-common-rail.md.

Use When

Use when the user wants Hermes to connect mail and calendar access for an on-demand morning brief, following the shared prerequisite-check, diagnose, guide, diff-approved apply, and verify contract.

Strong routing signals: `morning-brief`, `morning brief`, `connect my email for a morning brief`, `set up morning brief`, `configure morning brief`, `connect mail for morning brief`, `connect calendar for morning brief`, `set up my morning brief`, `모닝 브리핑 설정해줘`, `모닝 브리핑 설정`, `아침 브리핑 설정`, `메일 연동해서 브리핑`

Catalog Metadata

Category: hermes-setup Phase: setup Hermes role: guide Quality tier: hermes-setup-gated Reasoning demand: light

Quality bar:

• Prerequisite check: confirm required access; mark unmet prerequisites "not applicable" and skip them.
• Read-only diagnose: inspect non-secret config metadata, .env key names and presence only, and version; no secret reads or writes.
• Guide: use Hermes-native secure entry or user-side OAuth/token setup, never chat secrets.
• Diff-approved apply: show the config or .env diff with redacted placeholders; apply only after the user explicitly approves.
• Verify: confirm applicable items using non-secret metadata, never secret values.
• Keep the read/draft-only access boundary — never enable Send permission — as a hard constraint on every apply step, not an optional recommendation.

Handoff policy:

Run diagnosis and guidance directly in Hermes for the mail/calendar connection. Diagnosis reads non-secret metadata only; no writes. Show redacted placeholders in the config or .env diff; apply only after the user explicitly approves. Never ask the user to paste secrets into chat. Use Hermes-native secure entry or user-side OAuth/token setup; if unavailable, stop credential application and guide user-side setup. Use only a user-authorized credential store or local configuration; disclose destination and scope first. Keep secrets out of chat, previews, logs and evidence. Do not promise chat or platform non-retention. Delegate to a selected coding executor only if the user needs a change outside chat-driven MCP config edits.

Required inputs:

• mail and calendar MCP connection status
• OAuth/app-password availability; value through secure entry or user-side setup only

Expected outputs:

• read-only diagnosis of the current mail/calendar MCP connection state
• diff-approved MCP config write scoped to read and draft-only access
• an on-demand morning brief once connection is verified

Artifact expectations:

• connection verification note when the wrapper captures it

Safety rules:

• Configure mail and calendar MCP access as read and draft only; never enable Send permission, even if the user asks — drafts stay for the user to send themselves.
• Use Hermes-native secure entry or user-side OAuth/app-password setup, never chat; disclose authorized storage without exposing secrets.
• Do not treat a prepared connection as an observed brief; only report a brief after the connection is verified.

Runtime Evidence

Preferred harness for this skill: hermes-setup.

omh runtime record --skill morning-brief --harness hermes-setup --status started

Record observed delegation results; otherwise return not_available or not_observed. Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.

• Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes. Preserve workflow intent and stop conditions; verify before claiming completion. Reply in the user's own words and the host's own voice: OMH's record terms (surface, lane, wrapper, handoff, evidence boundary, not_observed) stay in records and tool calls, never in the sentence the user reads unless they ask about one; and when a stop condition or a decision the user owns ends the turn, offer the next action as a question rather than declaring what will not be done.

Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.

Shared product, compatibility, topology, memory, harness, and execution rules: omh-routing/references/skill-common-rail.md. Load it when applicable; otherwise name an unavailable capability.