From alemtuzlak-skills
Use when the user wants to create social media posts or launch copy for a feature, product change, PR, or announcement - generates platform-specific copy for Twitter/X, LinkedIn, and other platforms
npx claudepluginhub alemtuzlak/skills --plugin alemtuzlak-skillsThis skill uses the workspace's default tool permissions.
Generate platform-specific social media copy from code changes, marketing briefs, blog posts, or feature descriptions. Each platform gets copy tailored to its rules, audience behavior, and algorithm.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Analyzes competition with Porter's Five Forces, Blue Ocean Strategy, and positioning maps to identify differentiation opportunities and market positioning for startups and pitches.
Share bugs, ideas, or general feedback.
Generate platform-specific social media copy from code changes, marketing briefs, blog posts, or feature descriptions. Each platform gets copy tailored to its rules, audience behavior, and algorithm.
Resolve the argument (if provided) in this order:
.md containing "Executive Summary" or "Key Messages") → marketing brief.md with blog post structure) → blog post#\d+ pattern → PR... or .. → git ref rangeIf no argument is provided, ask: "What should I write social copy for? You can provide a marketing brief, blog post, PR URL/number, git ref range, file/directory path, or just describe the feature."
If multiple interpretations match, confirm with the user.
digraph social_copy {
rankdir=TB;
"Resolve input" [shape=box];
"Phase 1: Discovery" [shape=box];
"Phase 2: Configure" [shape=box];
"Phase 3: Write" [shape=box];
"Phase 4: Review" [shape=box];
"Approved?" [shape=diamond];
"Phase 5: Output" [shape=box];
"Resolve input" -> "Phase 1: Discovery";
"Phase 1: Discovery" -> "Phase 2: Configure";
"Phase 2: Configure" -> "Phase 3: Write";
"Phase 3: Write" -> "Phase 4: Review";
"Phase 4: Review" -> "Approved?" ;
"Approved?" -> "Phase 3: Write" [label="revisions"];
"Approved?" -> "Phase 5: Output" [label="yes"];
}
Do NOT skip phases. Ask questions at a natural pace. Don't overwhelm, but don't artificially slow things down either. If the user answers multiple questions at once, accept bundled answers and skip ahead.
If the user says "just pick defaults", "you choose", or similar, pick reasonable defaults based on context, state what you chose, and ask for a single confirmation before proceeding.
Never assume without confirming.
| Input type | What to read |
|---|---|
| Marketing brief | Extract problem statement, value prop, audience, key messages, competitive positioning. Skip to Step 3. Still do Step 2 if brief lacks product context. |
| Blog post | Extract headline, key points, audience, CTA. Skip to Step 3. Still do Step 2 if blog post lacks product context. |
| PR | Diff, PR description, review comments, commit messages (gh pr view, gh pr diff). For large PRs (20+ files), focus on user-facing changes. |
| Git refs | git diff and git log between refs. For large ranges, prioritize commit messages and user-facing changes. |
| Codebase feature | Read the specified files/directories. |
| Freeform text | Parse the user's description. If it lacks specifics (no feature name, no value prop, no context), ask the user to provide more detail or point to a specific file/PR. Fall back to open-ended questions only if they can't. |
User-facing changes include: new features, UI changes, API changes, performance improvements, bug fixes, and documentation updates. Internal changes include: refactors, test additions, CI changes, and dependency bumps. When uncertain, list what you found and ask the user which are relevant.
Error handling:
gh not available → inform user, suggest gh auth login, offer alternative inputRead if they exist: README, docs/, package.json (or equivalent).
If nothing found, ask: "I couldn't find product context in the repo. Can you briefly describe the product and who it's for?"
"Here's what I'll base the social copy on:"
- Feature A - short description
- Feature B - short description
"Anything to add, remove, or correct?"
Do NOT proceed until the user confirms scope.
Ask these questions:
Q1 - Platforms: "I'll generate copy for Twitter/X and LinkedIn by default. Want to add any other platforms?" (Reddit, Hacker News, Discord, Mastodon, Bluesky, etc.)
If the user adds platforms not covered by existing platform reference files, adapt the copy using your knowledge of that platform's conventions.
Q2 - Tone: Read existing repo content (README, docs, blog posts, social links) to detect the product's voice. Then confirm with presets:
"Based on your existing content, the tone seems [e.g. conversational and developer-focused]. Should I match that, or would you prefer a different direction? Some common options:"
- Professional/thought-leadership
- Casual/conversational
- Witty/playful
- Technical/precise
- Founder-voice/authentic
If no existing content to analyze, present the presets directly.
Q3 - Launch format: "Do you want a single post per platform or a full launch sequence?"
Q4 - CTA: Infer the most appropriate call to action from context:
"I'd suggest the CTA be: [inferred CTA]. Want to go with that or something different?"
Read the platform reference files before writing. Platform rules are in the platforms/ directory relative to this skill file. The skill-loading system should inject these files into context alongside SKILL.md:
platforms/twitter-x.md - Twitter/X rules, format, constraintsplatforms/linkedin.md - LinkedIn rules, format, constraintsIf the platform files are not available in context, use your knowledge of each platform's conventions instead.
For any additional platforms the user requested, use your knowledge of that platform's conventions.
For each platform, generate 2-3 variants of the announcement post with different hook styles. For each variant, note which hook formula it uses (question, bold statement, statistic, narrative, contrarian, etc.).
If user chose single post: generate only the 2-3 announcement variants per platform. Skip teaser and follow-up entirely.
If user chose launch sequence: generate one teaser and one follow-up per platform (no variants needed for those), plus 2-3 variants for the announcement post.
[link] placeholders unless the user provides a specific URL. Twitter counts all URLs as 23 characters regardless of actual length (account for this in character count). For LinkedIn, suggest putting links in comments to avoid algorithm penalty.Use these internally to structure the copy - don't label them in the output:
Follow the format from platforms/twitter-x.md:
[Hook] [emoji]
[What's new - 1-2 sentences] [emoji]
[CTA] [emoji]
No hashtags. 1-2 emojis per section. If content is too rich for a single tweet, generate a thread alternative alongside the single post.
Follow the format from platforms/linkedin.md. Key rules:
For each platform, generate all three phases:
Teaser (pre-launch):
Announcement (launch day):
Follow-up (post-launch):
Always include a timing recommendation.
For single post:
| Platform | Suggested timing |
|---|---|
| Twitter/X | Tuesday-Thursday, 12-6 PM local |
| Tuesday-Thursday, 10 AM-4 PM local |
For launch sequence:
| Phase | Platform | Suggested timing |
|---|---|---|
| Teaser | All | 2-3 days before launch |
| Announcement | Twitter/X | Tuesday-Thursday, 12-6 PM local |
| Announcement | Tuesday-Thursday, 10 AM-4 PM local | |
| Follow-up | All | 2-3 days after launch |
Adapt timing to the user's audience if known. Note: LinkedIn's golden hour (first 90 minutes) determines 70% of reach - post when the audience is most active.
Before presenting copy, scan for potentially sensitive content: internal codenames, security details, unpublished pricing, competitor references from code comments, internal metrics, or unreleased roadmap items. Flag anything questionable to the user before proceeding.
Present all generated copy grouped by platform, with variants labeled.
"Here's the social copy. For each platform I've generated 2-3 variants with different hooks:"
Twitter/X Variant 1 (bold statement hook): ... Variant 2 (question hook): ... Variant 3 (statistic hook): ...
LinkedIn Variant 1: ... Variant 2: ...
"Pick your favorites or tell me what to adjust."
Wait for the user to select variants and/or request revisions. Revise only the requested variants - keep others unchanged. Only proceed to output once approved.
Always print the final approved copy to terminal.
Then ask: "Want me to save this to social/launch-<slug>.md? Or a different path?"
Derive the slug from the feature/product name, kebab-cased, max 50 characters, alphanumeric and hyphens only.
If the user confirms:
gh not available → inform user, offer alternative inputsocial/, create it/blog-post for that)/marketing-brief for that)