mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-18 14:53:05 +08:00
ec9ace9c54
Translate everything-claude-code repository to Japanese including: - 17 root documentation files - 60 agent documentation files - 80 command documentation files - 99 rule files across 18 language directories (common, angular, arkts, cpp, csharp, dart, fsharp, golang, java, kotlin, perl, php, python, ruby, rust, swift, typescript, web) - 199 skill documentation files Total: 455 files translated to Japanese with: - Consistent terminology glossary applied throughout - YAML field names preserved in English (name, description, etc.) - Code blocks and examples untouched (comments translated) - Markdown structure and relative links preserved - Professional translation maintaining technical accuracy This translation expands ECC accessibility to Japanese-speaking developers and teams. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
122 lines
3.5 KiB
Markdown
122 lines
3.5 KiB
Markdown
---
|
|
name: email-ops
|
|
description: ECC用の証拠ベースのメールボックストリアージ、ドラフト作成、送信検証、および送信済みメールセーフフォローアップワークフロー。ユーザーがメールを整理したり、実際のメールサーフェスを通じてドラフトまたは送信したい、または送信済みメールに何が到着したかを証明したい場合に使用します。
|
|
origin: ECC
|
|
---
|
|
|
|
# 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 ECC-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
|
|
|
|
```text
|
|
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
|