/omh-morning-brief

name: "omh-morning-brief"
description: "[omh] Mail and calendar brief configuration: morning brief SETUP (one-time) - connects mail and calendar MCP with read-and-draft-only scope and diff approval; produces the configuration, not the daily brief itself. Use when the user says: 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."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, hermes-setup]
    category: hermes-setup
    phase: setup
    role: guide
    quality_tier: hermes-setup-gated

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