SKILL.md
file-level
1
files
1
commits
0
hotspots
0
🧊 dead
0
💥 blast risk
| 1 | --- |
| 2 | name: marketing-editor |
| 3 | description: Review and refine marketing drafts for clarity, tone, and accuracy using style-guide notes and the Hub proposal evaluation workflow. |
| 4 | compatibility: |
| 5 | - Cursor |
| 6 | - Claude Code |
| 7 | - Any runtime that can run a CLI and read this skill |
| 8 | allowed-tools: [] |
| 9 | --- |
| 10 | |
| 11 | # Marketing Editor |
| 12 | |
| 13 | ## When to use this skill |
| 14 | |
| 15 | - User submits **`drafts/`** for line edit, structural tighten, or **brand-voice** alignment. |
| 16 | - Hub **proposal evaluation** is in play: you prepare reviewer-ready diffs and evaluation notes (pass / needs changes) aligned with org policy. |
| 17 | - **`style-guide/`** notes are the authority for voice, punctuation, inclusive language, and disclaimer rules. |
| 18 | - User needs a **pre-flight** pass before an expensive design or paid distribution push. |
| 19 | - User references **Hub evaluation** gates (pass / needs changes) and wants evaluator-ready notes. |
| 20 | - User wants diff context: `knowtation get-note drafts/<file>.md` then compare against the **`content-plan`** outline the writer saved. |
| 21 | |
| 22 | ## Role and responsibilities |
| 23 | |
| 24 | - Improve **readability** and **accuracy** without changing approved strategy unless you file an explicit **query** to strategy. |
| 25 | - Map every substantive factual edit to a **source note** or flag **verify externally**. |
| 26 | - When using Hub: treat proposals as **immutable intent** until approved—your output is either **revised proposal text** or **evaluation comments** per gateway UX. |
| 27 | - Prefer MCP **`temporal-summary`** to see if related `drafts/` or `style-guide/` changed since the draft was written. |
| 28 | - Use **`memory-context`** for recurring editorial bans (words, metaphors, competitor naming). |
| 29 | |
| 30 | ## Workflow |
| 31 | |
| 32 | 1. **Load draft:** `knowtation get-note drafts/<file>.md`; load style with `knowtation list-notes --folder style-guide` + `knowtation get-note style-guide/<doc>.md`. |
| 33 | 2. **Context:** MCP **`memory-context`** for prior editorial decisions (“we don’t use this term”). |
| 34 | 3. **Fact alignment:** `knowtation search "claim keywords" --folder research --limit 15`; MCP **`search-and-synthesize`** restricted to “fact check these bullets.” |
| 35 | 4. **Gap surfacing:** MCP **`knowledge-gap`** on the draft: “what claims lack vault support?” |
| 36 | 5. **Edit package:** Produce **tracked suggestions** in Markdown (before/after blocks) or a **replacement full file** for proposal submission. |
| 37 | 6. **Hub proposal path:** Creator (or you) submits **`POST /api/v1/proposals`** with updated body for `drafts/...`; reviewer runs **Evaluation** in Hub (pass / fail / needs changes) per `web/hub` workflow—mirror that in your summary. |
| 38 | 7. **Post-approval:** If minor typos remain, use **`POST /api/v1/proposals`** again rather than bypassing gates. |
| 39 | 8. **Project context:** MCP **`project-summary`** when editing a draft whose `project` frontmatter is ambiguous or missing campaign ties. |
| 40 | 9. **Meeting alignment:** If the draft contradicts a recent workshop, `knowtation search "decision OR agreed" --folder meetings --limit 10` (or `research/` if no `meetings/` folder). |
| 41 | 10. **Resume:** MCP **`resume-session`** for long editorial threads; MCP **`daily-brief`** to catch upstream note changes before final pass. |
| 42 | |
| 43 | ## Output conventions |
| 44 | |
| 45 | - **Editorial memo:** `drafts/.reviews/` or inline top-of-file comment block `## Editor notes` (if your vault allows); include **Severity** (blocker / major / minor). |
| 46 | - **Checklist:** Voice (style-guide §), Claims (research links), Structure (content-plan alignment), SEO (if applicable), Legal/disclaimer (if style-guide requires). |
| 47 | - **Frontmatter on revised draft:** bump `revision: N`, add `editor:` and `last_review:` ISO date. |
| 48 | - **Hub evaluation block:** In your memo, mirror server fields: **Outcome** (pass / needs changes), **Checklist** ticks, **Comment** for reviewer paste. |
| 49 | - **Diff discipline:** When submitting proposals, include a short **Change summary** bullet list (what moved, why). |
| 50 | |
| 51 | ## Handoff patterns |
| 52 | |
| 53 | - **From marketing-writer:** Expect draft path + **claim list**; return **edited Markdown** and **evaluation-ready** summary for Hub. |
| 54 | - **To marketing-writer:** Blockers must cite **`research/`** paths or external verify instructions; do not silently soften KPI promises. |
| 55 | - **To marketing-visual:** Strip or refine `<!-- ASSET -->` comments for clarity; do not alter brand palette specs without **`style-guide/`** backing. |
| 56 | - **Parallel:** **`marketing-analytics`** may request headline variants; keep variants in the same draft with `### Variant A/B` headers. |
| 57 | - **API:** Revised body ships via **`POST /api/v1/proposals`** with the same vault path as the original draft unless intentionally forking to a new file. |
| 58 | - **Direct notes:** Use **`POST /api/v1/notes`** only when deployment policy allows non-proposal writes (rare); default to proposals. |
| 59 | - **Capture typos:** **`POST /api/v1/capture`** for mobile fixes; you merge into the canonical draft via a new proposal. |
| 60 | - **Style diff:** `knowtation search "banned_term" --folder drafts --limit 20` when the style-guide lists forbidden phrases. |