Codex Email Skill
Treat email work as a code change. Read the repo, keep edits scoped, preserve existing patterns, and make the result verifiable.
Fit Check
- Primary lens: repo-aware email implementation workflows for codebases, content systems, templates, and tests.
- Common request signals: template implementation, React Email edits, MDX content changes, QA scripts, codebase diffs, and testable email fixes.
- Default posture: Treat email work as a code change. Read the repo, keep edits scoped, preserve existing patterns, and make the result verifiable.
- Useful output family: repo-aware implementation plans, template diffs, QA scripts, render checks, content patches, and concise change reports.
- Production boundary: separate recommendation from execution.
- Evidence boundary: say which source material supports the recommendation.
Use This For
repo-aware email implementation workflows for codebases, content systems, templates, and tests.
Avoid Using It For
Generic email advice with no audience, platform, lifecycle, evidence, or approval context.
Procedure
- Locate the email surface in the repository: components, templates, content files, campaign config, preview routes, tests, or ESP export scripts.
- Read adjacent files before editing so naming, styling, localization, and data-loading patterns match the codebase.
- Define the intended behavior as a diffable change: copy update, layout fix, template module, data field, tracking parameter, or QA assertion.
- Implement the smallest coherent change and avoid unrelated refactors, dependency churn, or broad style rewrites.
- Run the narrowest useful verification: type check, template render, snapshot, unit test, lint, preview build, or visual smoke check.
- Report changed files, verification result, remaining risk, and any production steps that still need approval.
Acceptance Checks
- The edit follows local patterns instead of inventing a parallel email system.
- Dynamic fields have fallbacks and do not leak undefined values into copy.
- Rendering constraints are considered before using modern CSS.
- Tests or previews cover the user-visible behavior when risk justifies it.
- No live send, import, DNS, or suppression action is performed as part of a code edit.
Output Pattern
Return repo-aware implementation plans, template diffs, QA scripts, render checks, content patches, and concise change reports. Keep recommendations concrete. Separate analysis from live-system actions, and require explicit approval before sending email, importing contacts, changing DNS, altering suppression rules, or editing production automations.
1---2name: codexemailskill3description: Use when Codex, Hermes, OpenClaw, Claude Code, Cowork, or another AI agent needs to plan, review, implement, audit, or improve email work focused on repo-aware email implementation workflows for codebases, content systems, templates, and tests. Triggers include requests about template implementation, React Email edits, MDX content changes, QA scripts, codebase diffs, and testable email fixes.4---5
6# Codex Email Skill
7
8Treat email work as a code change. Read the repo, keep edits scoped, preserve existing patterns, and make the result verifiable.
9
10## Fit Check
11
121. Primary lens: repo-aware email implementation workflows for codebases, content systems, templates, and tests.
132. Common request signals: template implementation, React Email edits, MDX content changes, QA scripts, codebase diffs, and testable email fixes.
143. Default posture: Treat email work as a code change. Read the repo, keep edits scoped, preserve existing patterns, and make the result verifiable.
154. Useful output family: repo-aware implementation plans, template diffs, QA scripts, render checks, content patches, and concise change reports.
165. Production boundary: separate recommendation from execution.
176. Evidence boundary: say which source material supports the recommendation.
18
19### Use This For
20
21repo-aware email implementation workflows for codebases, content systems, templates, and tests.
22
23### Avoid Using It For
24
25Generic email advice with no audience, platform, lifecycle, evidence, or approval context.
26
27## Procedure
28
291. Locate the email surface in the repository: components, templates, content files, campaign config, preview routes, tests, or ESP export scripts.
302. Read adjacent files before editing so naming, styling, localization, and data-loading patterns match the codebase.
313. Define the intended behavior as a diffable change: copy update, layout fix, template module, data field, tracking parameter, or QA assertion.
324. Implement the smallest coherent change and avoid unrelated refactors, dependency churn, or broad style rewrites.
335. Run the narrowest useful verification: type check, template render, snapshot, unit test, lint, preview build, or visual smoke check.
346. Report changed files, verification result, remaining risk, and any production steps that still need approval.
35
36## Acceptance Checks
37
381. The edit follows local patterns instead of inventing a parallel email system.
392. Dynamic fields have fallbacks and do not leak undefined values into copy.
403. Rendering constraints are considered before using modern CSS.
414. Tests or previews cover the user-visible behavior when risk justifies it.
425. No live send, import, DNS, or suppression action is performed as part of a code edit.
43
44## Output Pattern
45
46Return repo-aware implementation plans, template diffs, QA scripts, render checks, content patches, and concise change reports. Keep recommendations concrete. Separate analysis from live-system actions, and require explicit approval before sending email, importing contacts, changing DNS, altering suppression rules, or editing production automations.
aiskillstore