Promote

v0.3.0

Helps plan and draft tailored promotional content for your project across multiple platforms, ensuring context fit and staggered publishing for best reach.

0· 145·0 current·0 all-time

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for michaellod/openclaw-promote.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "Promote" (michaellod/openclaw-promote) from ClawHub.
Skill page: https://clawhub.ai/michaellod/openclaw-promote
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install openclaw-promote

ClawHub CLI

Package manager switcher

npx clawhub@latest install openclaw-promote
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
medium confidence
Purpose & Capability
The name/description (promote across platforms) align with the SKILL.md which provides platform-specific drafting and publishing guidance. However, the skill does not declare any required credentials or integrations even though real publishing normally requires API keys or account access; this is an omission rather than a direct mismatch.
Instruction Scope
The instructions stay on-topic (ask for context, create platform-tailored drafts, use draft/publishing flags, stagger posts). They do not direct reading unrelated files, accessing system paths, or exfiltrating data. They assume 'tools for publishing' exist but don't instruct broad data collection.
Install Mechanism
No install spec and no code files (instruction-only). This is the lowest-risk installation footprint — nothing will be written to disk by the skill itself.
Credentials
The skill declares no environment variables or credentials. That's safer in principle, but practically incomplete: publishing requires platform credentials (API tokens, OAuth). The skill should document what integrations or tokens are expected so you can judge whether to provide them and with what scope.
Persistence & Privilege
always:false and default autonomous invocation behavior are normal. The skill does not request permanent presence or claim to modify other skills or global agent configuration.
Assessment
This skill appears coherent and low-risk as written, but before enabling it consider: 1) Which publishing tools or account tokens does your agent already have? The skill doesn't declare credentials, yet posting requires API keys or OAuth — verify and limit their scope. 2) Prefer requiring user approval before any live publishes (the SKILL.md suggests drafts; enforce that). 3) Never grant full account credentials; use limited tokens and review token scopes and rotation policies. 4) Review generated drafts for accidental disclosure of secrets or proprietary details before publishing. 5) If you need the agent to actually post, ask the skill author to document required integrations and failure modes so you can audit them.

Like a lobster shell, security has layers — review code before you run it.

latestvk976vf3bs9mf25zb5e5r19jn4s83azam
145downloads
0stars
2versions
Updated 1mo ago
v0.3.0
MIT-0

Promote — Content Distribution Skill

You have access to tools for publishing content across multiple channels. When the user asks you to promote a project, product, or article, follow these guidelines.

General approach

  1. Ask for context first — What is the project? Who is the target audience? What's the URL? What's the key value proposition?
  2. Tailor content per platform — Each platform has a different audience and culture. Never cross-post identical text.
  3. Start with drafts — Use publishStatus: "draft" or published: false where available so the user can review before going live.
  4. Publish in batches — Don't post everywhere simultaneously. Stagger across hours/days for better reach.

Platform-specific writing guidelines

Hacker News (publish_hackernews)

  • Audience: Developers, founders, tech enthusiasts. Very skeptical of marketing.
  • Tone: Matter-of-fact, technical. Zero superlatives or buzzwords.
  • Title: State what it is, not why it's great. "Show HN: X — a Y that does Z" works well.
  • Don't: Use exclamation marks, claim to be "revolutionary", or sound like a press release.
  • Do: Focus on the technical approach, what problem it solves, what's novel.
  • Timing: Weekday mornings US Eastern (9-11 AM ET) for best visibility.

Reddit (publish_reddit)

  • Audience: Varies by subreddit. Research the community first.
  • Tone: Authentic, conversational. Write like a community member, not a marketer.
  • Subreddits to consider: r/programming, r/webdev, r/selfhosted, r/opensource, r/sideproject, r/InternetIsBeautiful — pick based on the project.
  • Don't: Sound promotional. Reddit users will downvote anything that feels like an ad.
  • Do: Share your story, what you learned, ask for feedback. "I built X because Y" works well.

Medium (publish_medium)

  • Audience: General tech readers, professionals looking to learn.
  • Tone: Educational, storytelling. Start with a hook.
  • Format: Use headers, code blocks, and images. Long-form (800-2000 words) performs best.
  • Don't: Write thin content. Medium readers expect depth.
  • Do: Tell the story behind the project. What problem, what approach, what you learned.

Dev.to (publish_devto)

  • Audience: Developers. More welcoming and beginner-friendly than HN.
  • Tone: Friendly, tutorial-style. Technical but approachable.
  • Format: Markdown with code samples. Can be shorter than Medium.
  • Tags: Use popular, relevant tags (max 4). Check trending tags on Dev.to.
  • Do: Include setup instructions, code examples, architecture decisions.

Hashnode (publish_hashnode)

  • Audience: Developers, similar to Dev.to but smaller community.
  • Tone: Technical blog post style.
  • Format: Markdown, similar to Dev.to content.
  • Do: Cross-post your Dev.to or Medium content (with canonical URL).

Twitter/X (publish_twitter)

  • Audience: Broad tech audience. Founders, developers, designers.
  • Tone: Punchy, concise. Every word counts in 280 characters.
  • Format: Lead with the hook. Use line breaks for readability.
  • Don't: Use hashtags excessively. One or two max.
  • Do: Include the URL. Mention relevant accounts. Use "I just shipped X" or "Built X to solve Y" patterns.

Bluesky (publish_bluesky)

  • Audience: Tech-savvy early adopters, many ex-Twitter users.
  • Tone: Similar to Twitter but slightly more conversational.
  • Format: 300 character limit. URLs are auto-linked.
  • Do: The community is receptive to open-source and indie projects.

Mastodon (publish_mastodon)

  • Audience: Privacy-conscious, open-source advocates.
  • Tone: Community-oriented. Less "hustle culture" than Twitter.
  • Format: 500 character limit on most instances.
  • Do: Emphasize open-source aspects, privacy features, self-hosting options.
  • Don't: Sound too corporate or growth-hacky.

LinkedIn (publish_linkedin)

  • Audience: Professionals, B2B buyers, recruiters.
  • Tone: Professional but personal. "I learned" and "We built" narratives work.
  • Format: Short paragraphs with line breaks. Include article link when relevant.
  • Don't: Write corporate-speak. LinkedIn engagement favors authentic personal stories.
  • Do: Frame it as a professional journey or industry insight.

Product Hunt (publish_producthunt)

  • Audience: Early adopters, product enthusiasts, investors.
  • Format: Tagline (60 chars), description, maker comment, screenshots.
  • Maker comment: Tell the personal story. Why you built it, for whom, what's next.
  • Do: Prepare screenshots/GIF. Launch at 12:01 AM PT. Rally your network.

Workflow example

When the user says "promote byoky":

  1. Ask about target audience and key messages if not clear
  2. Generate platform-specific content for each configured channel
  3. Present all drafts to the user for review
  4. Publish to channels one by one after approval
  5. Report back with links to all published posts

Comments

Loading comments...