| name | content-launch-planner |
| description | Plan contribution-first cross-platform launches for eunomia.dev content, GitHub projects, papers, tutorials, demos, and public updates. Use when asked where/when/whether to publish, whether to do all-platform posting, whether others already posted, how to adapt one artifact into a platform matrix, how to prepare Product Hunt or community launches, or how to coordinate Zhihu/Juejin/X/LinkedIn/Xiaohongshu/Reddit/Hacker News/Lobsters/Medium/DEV publisher skills without posting yet. |
Content Launch Planner
Plan the upstream publishing decision before any platform-specific drafting or
browser work. This skill decides whether to publish, which platforms fit, what
each platform should say, what assets are missing, and which publisher skill
should execute each item.
References
Load references according to the task:
- Always load
references/source-and-research.md,
references/platform-matrix.md, references/quality-gates.md, and
references/output-template.md.
- Load
references/launch-assets.md for project, release, demo, paper,
tutorial, or multi-post campaign planning.
- Load
references/producthunt.md only when Product Hunt is proposed, visible
in the browser, or plausibly useful for a tryable product/tool artifact.
- Load
references/external-patterns.md when updating this skill or explaining
which external skill patterns were absorbed.
Workflow
- Build a strategic source brief first: user pain, search/community intent,
current alternatives, unique public evidence, brand pillar, reader outcome,
and only then repository evidence, GitHub links, drafts, papers, screenshots,
and published/not-published ledgers.
- Check for duplicates and current discussion before recommending a community
submission or another post about the same artifact.
- Classify the launch tier and reader intent: contribution-first technical
education, project/tool launch, paper/research discussion, tutorial, release
note, or follow-up.
- For long-form blog/tutorial/paper explainers, default to faithful
syndication: Medium/DEV use the existing English source and Zhihu/Juejin use
the existing Chinese source. Preserve the selected source title exactly and
keep the body substantively unchanged. Do not rewrite, shorten, expand,
reorder, split, localize, or add platform-native openings, examples, or
conclusions. Only mechanical rendering fixes and platform metadata are
allowed. If the source needs a content fix, update the source first and then
syndicate that corrected version. If no suitable source exists in the target
language, stop and get explicit translation or rewrite authorization.
Visible canonical/source links are optional on every platform.
- Select platforms by fit, not by desire to be everywhere. All-platform plans
may recommend "skip" for weak surfaces. For an already published long-form
source, X and LinkedIn default to the source link plus one or two sentences
that state the core problem, tension, or result. Do not plan a separate
interpretation, article summary, thread, carousel, or professional story
arc unless the user explicitly asks for one.
- Prepare a per-platform brief: target reader, surface, angle, hook, proof,
link, media, CTA, risks, and follow-up.
- Before browser/editor work, route platform-specific copy drafts to
draft/media/YYYY-MM-DD/<source-slug>/<platform>.md, using the local date.
For long-form syndication that preserves the article body, the
draft may reference the canonical source file instead of duplicating it, but
it must record the exact source title, links, tags/categories, media, and QA
state. Short posts, comments, and replies should include the full paste-ready
copy.
Do not create standalone figure-inventory, platform-hook, or publish-QA
notes. Put paste-ready copy and required upload metadata in the final
platform artifact; record only real cross-run exceptions in the dated
run-log.md or reusable platform lessons in the matching publisher skill.
- For long-form posts on every platform, finish the platform-specific artifact
locally before touching the platform editor whenever possible. Generate a
temporary or
draft/media/YYYY-MM-DD/<source-slug>/ upload/import artifact
with the exact source title, duplicate body H1 removed, image URLs or
uploaded images, necessary table/code/formula rendering fallbacks,
tags/categories, and links already present in the source.
Use the platform editor for import/upload, settings, and QA, not for writing
or structural repair.
- Hand off execution to the matching publisher skill with the required browser
QA state. Do not paste into a platform or publish from this skill unless the
user explicitly asks to move from planning into execution.
- Include a follow-up plan for comments, private messages, GitHub issues,
corrections, and retrospective notes.
Boundaries
- Keep public content 80% contribution and 20% promotion. Project mentions are
evidence, implementation artifacts, or next steps after useful explanation.
- Do not make substantive changes to syndicated long-form posts. Preserve the
source title, opening, section order, claims, examples, and conclusion. Limit
platform changes to front matter, duplicate H1 removal, heading-level
conversion, image upload/URL repair, code/table/formula rendering, and
platform metadata. Add body text or links only when the user explicitly asks
or after making the same change in the source article.
- Do not force visible canonical links on any platform. If a platform provides a
dedicated canonical field, treat it as a hygiene setting when convenient; do
not edit the article body just to add or repair a canonical/source link.
- Preserve the maintainer posture: consulting, research, and helping solve hard
technical problems, not selling a product.
- Do not include private strategy, customer claims, fundraising, pricing,
partner/customer details, unreleased roadmaps, or unverifiable numbers.
- Social and media platforms are browser-first. Do not use hidden platform APIs,
internal endpoints, background requests, or automatic posting tools. Medium
and DEV publishing must use the normal web editor/import UI and visible submit
buttons, not publish APIs.
- Stop at a plan, draft, editor, or confirmation screen only when the user asks
for planning, drafting, or preview. A request to publish or a queue item marked
排队 authorizes the final action without another confirmation.
Publisher Handoff
Use the platform-specific publisher skill after the plan is accepted:
zhihu-publisher for Zhihu articles, answers, ideas, and AI Works.juejin-publisher for Juejin developer articles and practical notes.x-publisher for default link shares with a one- or two-sentence hook;
threads, replies, quotes, and articles only when explicitly useful.linkedin-publisher for default link shares with a one- or two-sentence
hook; articles, carousels, longer commentary, and comments only when
explicitly useful.xiaohongshu-publisher for Xiaohongshu visual notes, carousel outlines,
title/cover adaptation, and Chinese short-form technical explainers.reddit-publisher for subreddit submissions and comments.hackernews-publisher for HN titles, Show HN, Ask HN, and comments.lobsters-publisher for Lobsters stories, tags, and comments.medium-publisher for Medium long-form syndication or essays.devto-publisher for DEV tutorials, series, and comments.
If no publisher skill exists for a recommended channel, output the plan only and
say what a future publisher skill would need to handle.
