Comms ops

---

Email Channel

Email Ops

Use this when the real task is mailbox work: triage, drafting, replying, sending, or proving a message landed in Sent.

This is not a generic writing skill. It is an operator workflow around the actual mail surface.

Skill Stack

Pull these SKC-native skills into the workflow when relevant:

• brand-voice before drafting anything user-facing
• investor-outreach for investor, partner, or sponsor-facing mail
• customer-billing-ops when the thread is a billing/support incident rather than generic correspondence
• knowledge-ops when the message or thread should be captured into durable context afterward
• research-ops when a reply depends on fresh external facts

When to Use

• user asks to triage inbox or archive low-signal mail
• user wants a draft, reply, or new outbound email
• user wants to know whether a mail was already sent
• the user wants proof of which account, thread, or Sent entry was used

Guardrails

• draft first unless the user clearly asked for a live send
• never claim a message was sent without a real Sent-folder or client-side confirmation
• do not switch sender accounts casually; choose the account that matches the project and recipient
• do not delete uncertain business mail during cleanup
• if the task is really DM or iMessage work, hand off to messages-ops

Workflow

1. Resolve the exact surface

Before acting, settle:

• which mailbox account
• which thread or recipient
• whether the task is triage, draft, reply, or send
• whether the user wants draft-only or live send

2. Read the thread before composing

If replying:

• read the existing thread
• identify the last outbound touch
• identify any commitments, deadlines, or unanswered questions

If creating a new outbound:

• identify warmth level
• select the correct channel and sender account
• pull brand-voice before drafting

3. Draft, then verify

For draft-only work:

• produce the final copy
• state sender, recipient, subject, and purpose

For live-send work:

• verify the exact final body first
• send through the chosen mail surface
• confirm the message landed in Sent or the equivalent sent-copy store

4. Report exact state

Use exact status words:

• drafted
• approval-pending
• sent
• blocked
• awaiting verification

If the send surface is blocked, preserve the draft and report the exact blocker instead of improvising a second transport without saying so.

Output Format

MAIL SURFACE
- account
- thread / recipient
- requested action

DRAFT
- subject
- body

STATUS
- drafted / sent / blocked
- proof of Sent when applicable

NEXT STEP
- send
- follow up
- archive / move

Pitfalls

• do not claim send success without a sent-copy check
• do not ignore the thread history and write a contextless reply
• do not mix mailbox work with DM or text-message workflows
• do not expose secrets, auth details, or unnecessary message metadata

Verification

• the response names the account and thread or recipient
• any send claim includes Sent proof or an explicit client-side confirmation
• the final state is one of drafted / sent / blocked / awaiting verification

---

Messages Channel

Messages Ops

Use this when the task is live-message retrieval: iMessage, DMs, recent one-time codes, or thread inspection before a follow-up.

This is not email work. If the dominant surface is a mailbox, use email-ops.

Skill Stack

Pull these SKC-native skills into the workflow when relevant:

• email-ops when the message task is really mailbox work
• connections-optimizer when the DM thread belongs to outbound network work
• lead-intelligence when the live thread should inform targeting or warm-path outreach
• knowledge-ops when the thread contents need to be captured into durable context

When to Use

• user says "read my messages", "check texts", "look in DMs", or "find the code"
• the task depends on a live thread or a recent code delivered to a local messaging surface
• the user wants proof of which source or thread was inspected

Guardrails

• resolve the source first:
  • local messages
  • X / social DM
  • another browser-gated message surface
• do not claim a thread was checked without naming the source
• do not improvise raw database access if a checked helper or standard path exists
• if auth or MFA blocks the surface, report the exact blocker

Workflow

1. Resolve the exact thread

Before doing anything else, settle:

• message surface
• sender / recipient / service
• time window
• whether the task is retrieval, inspection, or prep for a reply

2. Read before drafting

If the task may turn into an outbound follow-up:

• read the latest inbound
• identify the open loop
• then hand off to the correct outbound skill if needed

3. Handle codes as a focused retrieval task

For one-time codes:

• search the recent local message window first
• narrow by service or sender when possible
• stop once the code is found or the focused search is exhausted

4. Report exact evidence

Return:

• source used
• thread or sender when possible
• time window
• exact status:
  • read
  • code-found
  • blocked
  • awaiting reply draft

Output Format

SOURCE
- message surface
- sender / thread / service

RESULT
- message summary or code
- time window

STATUS
- read / code-found / blocked / awaiting reply draft

Pitfalls

• do not blur mailbox work and DM/text work
• do not claim retrieval without naming the source
• do not burn time on broad searches when the ask is a recent-code lookup
• do not keep retrying a blocked auth path without surfacing the blocker

Verification

• the response names the message source
• the response includes a sender, service, thread, or clear blocker
• the final state is explicit and bounded

---

Unified Notifications Channel

Unified Notifications Ops

Use this skill when the real problem is not a missing ping. The real problem is a fragmented notification system.

The job is to turn scattered events into one operator surface with:

• clear severity
• clear ownership
• clear routing
• clear follow-up action

When to Use

• the user wants a unified notification lane across GitHub, Linear, local hooks, desktop alerts, chat, or email
• CI failures, review requests, issue updates, and operator events are arriving in disconnected places
• the current setup creates noise instead of action
• the user wants to consolidate overlapping notification branches or backlog proposals into one SKC-native lane
• the workspace already has hooks, MCPs, or connected tools, but no coherent notification policy

Preferred Surface

Start from what already exists:

• GitHub issues, PRs, reviews, comments, and CI
• Linear issue/project movement
• local hook events and session lifecycle signals
• desktop notification primitives
• connected email/chat surfaces when they actually exist

Prefer SKC-native orchestration over telling the user to adopt a separate notification product.

Non-Negotiable Rules

• never expose tokens, secrets, webhook secrets, or internal identifiers
• separate:
  • event source
  • severity
  • routing channel
  • operator action
• default to digest-first when interruption cost is unclear
• do not fan out every event to every channel
• if the real fix is better issue triage, hook policy, or project flow, say so explicitly

Event Pipeline

Treat the lane as:

1. Capture the event
2. Classify urgency and owner
3. Route to the correct channel
4. Collapse duplicates and low-signal churn
5. Attach the next operator action

The goal is fewer, better notifications.

Default Severity Model

Class	Examples	Default handling
Critical	broken default-branch CI, security issue, blocked release, failed deploy	interrupt now
High	review requested, failing PR, owner-blocking handoff	same-day alert
Medium	issue state changes, notable comments, backlog movement	digest or queue
Low	repeat successes, routine churn, redundant lifecycle markers	suppress or fold

If the workspace has no severity model, build one before proposing automation.

Workflow

1. Inventory the current surface

List:

• event sources
• current channels
• existing hooks/scripts that emit alerts
• duplicate paths for the same event
• silent failure cases where important things are not being surfaced

Call out what SKC already owns.

2. Decide what deserves interruption

For each event family, answer:

• who needs to know?
• how fast do they need to know?
• should this interrupt, batch, or just log?

Use these defaults:

• interrupt for release, CI, security, and owner-blocking events
• digest for medium-signal updates
• log-only for telemetry and low-signal lifecycle markers

3. Collapse duplicates before adding channels

Look for:

• the same PR event appearing in GitHub, Linear, and local logs
• repeated hook notifications for the same failure
• comments or status churn that should be summarized instead of forwarded raw
• channels that duplicate each other without adding a better action path

Prefer:

• one canonical summary
• one owner
• one primary channel
• one fallback path

4. Design the SKC-native workflow

For each real notification need, define:

• source
• gate
• shape: immediate alert, digest, queue, or dashboard-only
• channel
• action

If SKC already has the primitive, prefer:

• a skill for operator triage
• a hook for automatic emission/enforcement
• an agent for delegated classification
• an MCP/connector only when a real bridge is missing

5. Return an action-biased design

End with:

• what to keep
• what to suppress
• what to merge
• what SKC should wrap next

Output Format

CURRENT SURFACE
- sources
- channels
- duplicates
- gaps

EVENT MODEL
- critical
- high
- medium
- low

ROUTING PLAN
- source -> channel
- why
- operator owner

CONSOLIDATION
- suppress
- merge
- canonical summaries

NEXT SKC MOVE
- skill / hook / agent / MCP
- exact workflow to build next

Recommendation Rules

• prefer one strong lane over many weak ones
• prefer digests for medium and low-signal updates
• prefer hooks when the signal should emit automatically
• prefer operator skills when the work is triage, routing, and review-first decision-making
• prefer project-flow-ops when the root cause is backlog / PR coordination rather than alerts
• prefer workspace-surface-audit when the user first needs a source inventory
• if desktop notifications are enough, do not invent an unnecessary external bridge

Good Use Cases

• "We have GitHub, Linear, and local hook alerts, but no single operator flow"
• "Our CI failures are noisy and people ignore them"
• "I want one notification policy across Claude, OpenCode, and Codex surfaces"
• "Figure out what should interrupt versus land in a digest"
• "Collapse overlapping notification PR ideas into one canonical SKC lane"

Related Skills

• workspace-surface-audit
• project-flow-ops
• github-ops
• knowledge-ops
• customer-billing-ops when the notification pain is billing/customer operations rather than engineering