Skip to content

Phase 5: Star Optimization Strategy

Date: 2026-03-03 Scope: SmartMur GitHub organization and claude-superpowers flagship repo Goal: Grow from 0 stars to 1,000+ stars within 6 months of public launch

Table of Contents

  1. Why People Currently Wouldn't Star This
  2. Psychology of GitHub Stars
  3. Missing Visual Elements
  4. README Optimization
  5. 6-Month Star Growth Roadmap
  6. Documentation Strategy
  7. Demo Strategy
  8. Community Strategy
  9. Social Proof Strategy
  10. Naming Impact

1. Why People Currently Wouldn't Star This

Honest Assessment

An anonymous developer landing on the current claude-superpowers repo would bounce within 10 seconds. Here is why, ranked by severity.

1.1 "Private project. All rights reserved."

This is the single biggest killer. The README literally says "Private project. All rights reserved." at the bottom. Nobody stars a repo they cannot use, fork, or contribute to. Open-source projects without a recognized license (MIT, Apache 2.0, GPL) are treated as proprietary by default. GitHub's own Explore, Trending, and Topic pages all deprioritize or exclude unlicensed repositories.

Fix: Choose a license before doing anything else. For maximum star potential in the automation/devtools space, MIT or Apache 2.0 is the standard. n8n uses a "fair-code" Sustainable Use License. Dify uses Apache 2.0. Pick one.

1.2 No Hero Image, No Screenshot, No GIF

The first thing a visitor sees is a plain # Claude Superpowers heading followed by a paragraph of text. Compare this to any repo with 1k+ stars: they all have a banner image, a screenshot of the product in action, or an animated GIF within the first viewport scroll. The ASCII architecture diagram is nice for developers who already understand the project, but it communicates nothing to a first-time visitor scanning at speed.

Research from Daytona's analysis of 4,000-star READMEs confirms: "An impactful header should include a logo, badges, one-liner, visuals, and quick start guide." The current README has none of those in its header.

1.3 No Badges

Zero shields.io badges. No CI status, no test count, no Python version, no license badge, no Docker pulls, no code coverage. Badges serve as a TL;DR trust signal. A visitor glancing at a row of green badges instantly registers "this project is maintained, tested, and professional." Their absence communicates the opposite.

1.4 Name Doesn't Travel

"Claude Superpowers" is descriptive but has problems: - It contains a trademark ("Claude") that belongs to Anthropic. - It doesn't work as a standalone brand. Nobody says "I use Superpowers" or "Check out Claude Superpowers." - It isn't searchable. Googling "claude superpowers" returns Anthropic marketing pages. - It sounds like a wrapper or extension, not a platform.

1.5 No Social Proof Anywhere

Zero stars, zero forks, zero contributors, zero issues, zero discussions. No "Used by" section, no testimonials, no blog posts, no tweets, no conference talks. A repo with zero social signals triggers the bystander effect: if nobody else starred it, why should I?

1.6 No Clear Value Proposition in 5 Seconds

The opening paragraph reads: "A local-first automation platform that gives Claude Code autonomous capabilities: encrypted credential management, pluggable skills, scheduled jobs, multi-channel messaging, browser automation, SSH fabric, workflow orchestration, persistent memory, and file watchers."

This is a feature list, not a value proposition. It tells you what it does but not why you'd want it or what problem it solves. Compare to khuedoan/homelab (9k stars): "Fully automated homelab from empty disk to running services with a single command." That is a value proposition. One sentence. One promise. One outcome.

1.7 Perceived Complexity Without Payoff

The README lists 14 skills, 4 workflows, 43 MCP tools, 70 REST endpoints, 982 tests. To the uninitiated, this reads as overwhelming complexity rather than mature capability. There is no progressive disclosure -- no "start here, add more later" path. The quickstart has 8 steps including installing system dependencies and initializing an encrypted vault. Compare to n8n: npx n8n or docker run -it --rm n8n.

1.8 No Demo You Can Try

There is no hosted demo, no playground, no sandbox, no "try it in 30 seconds" path. The browser automation and dashboard are impressive features, but nobody will know that unless they clone the repo and run Docker Compose. The conversion funnel from "visitor" to "user" has too many steps.

1.9 Documentation Exists But Is Invisible

There are 20+ documentation pages, but they are buried in tables at the bottom of the README. Most visitors never scroll past the architecture diagram. The docs that exist are reference-oriented (how things work) rather than outcome-oriented (how to accomplish X).

1.10 Org Context Is Absent

The SmartMur organization has 10 repos but no org-level README, no pinned repos strategy, no consistent branding, no cross-linking between repos. A visitor to github.com/smartmur sees a scattered collection of personal projects with no narrative thread.

2. Psychology of GitHub Stars

What the Research Says

A 2018 study published in the Journal of Systems and Software ("What's in a GitHub Star?") analyzed the top 5,000 most-starred repositories and surveyed developers about their starring behavior. Combined with more recent data from Infracost, Star History, and Indie Hackers, a clear picture emerges.

2.1 The Three Motivations

Developers star repositories for three distinct reasons:

Motivation Percentage Implication
Bookmarking ~45% "I might need this later." Triggered by clear utility and easy-to-scan README.
Appreciation ~35% "This is impressive work." Triggered by visual polish, test counts, architecture quality.
Active use ~20% "I'm using this right now." Triggered by solving an immediate problem the developer has.

The largest segment (bookmarking) means most stars come from people who will never run your code. They star because the README convinced them the project might be useful someday. This is critical: your README is more important than your code for star acquisition.

2.2 The 10-Second Window

Developers make the star/bounce decision in roughly 10 seconds. In that window they process:

  1. Logo/banner -- "Is this a real project or a homework assignment?"
  2. One-liner -- "What does it do?"
  3. Badges -- "Is it maintained? Is it tested?"
  4. Screenshot/GIF -- "What does it look like in action?"
  5. Star count -- "Have other people validated this?"

If any of those signals are missing or negative, the visitor moves on. This is not a rational evaluation; it is pattern matching against thousands of previously seen repos.

2.3 Social Proof Cascade

Three out of four developers (75%) consider star count before using or contributing to a project. This creates a chicken-and-egg problem: you need stars to get stars. Breaking out of zero requires external momentum -- a Hacker News post, a tweet from an influencer, inclusion in an awesome-list.

Research shows 78.5% of developers who experienced a star spike linked it to social media posts, predominantly Hacker News. The average HN front-page repo gains 121 stars in 24 hours, 189 in 48 hours, and 289 in a week. But these are averages pulled up by outliers; the median is closer to 50-80 stars from a single HN post.

GitHub's trending algorithm measures star velocity relative to a repository's baseline, not absolute numbers. A repo that normally gets 2 stars/day jumping to 20 has a higher "trending score" than a repo going from 50 to 60. This means a coordinated launch that concentrates stars into a 24-48 hour window is dramatically more effective than the same number of stars spread over a month.

Reaching GitHub Trending creates a positive feedback loop: trending visibility drives more stars, which keeps you trending longer. The Liam ERD project reached the #2 daily spot on GitHub Trending, which triggered "spontaneous sharing without [their] involvement" and became the single largest growth driver.

2.5 The Emotional Triggers

Beyond rational evaluation, specific emotional triggers drive starring behavior:

  • "I wish I'd built this" -- Technical admiration. Triggered by elegant architecture, high test counts, clean code.
  • "This solves my exact problem" -- Immediate relevance. Triggered by specific use cases in the README that match the visitor's current pain.
  • "I want to be associated with this" -- Identity signaling. Triggered by projects that align with values the developer holds (privacy, local-first, open-source, AI).
  • "Everyone else is starring this" -- Herd behavior. Triggered by high star count, trending status, social media buzz.

The current repo triggers none of these at the README level.

3. Missing Visual Elements

3.1 Required Visual Assets (Priority Order)

Asset Purpose Tool to Create Impact
Project logo Brand recognition, README header, social cards Figma, Canva, or commissioned Critical
Hero banner First-viewport visual hook with logo + tagline Figma/Canva with screenshot composite Critical
Dashboard screenshot Prove the UI exists and looks professional Actual screenshot of running dashboard Critical
Terminal GIF Show claw CLI in action (30 seconds, core workflow) asciinema + svg-term, or VHS (Charm) Critical
Architecture diagram (graphical) Replace ASCII art with a polished Mermaid/D2/Excalidraw diagram Mermaid in Markdown, or D2/Excalidraw PNG High
Workflow diagram Show a real workflow (deploy pipeline) as a visual flowchart Mermaid or Excalidraw High
Telegram bot screenshot Show multi-channel messaging working in a real chat Screenshot of actual Telegram interaction Medium
Before/after comparison "Without claude-superpowers" vs "With claude-superpowers" Side-by-side image or table Medium
Social preview image (og:image) Controls how the repo looks when shared on Twitter/Slack/Discord 1280x640 PNG uploaded via GitHub settings High

3.2 Required Badges

Add these shields.io badges in this order, immediately below the hero banner:

[![CI](https://github.com/smartmur/claude-superpowers/actions/workflows/ci.yml/badge.svg)](...)
[![Python 3.12+](https://img.shields.io/badge/python-3.12+-blue.svg)](...)
[![Tests](https://img.shields.io/badge/tests-982%20passing-brightgreen.svg)](...)
[![License](https://img.shields.io/badge/license-MIT-green.svg)](...)
[![Docker](https://img.shields.io/badge/docker-compose-blue.svg)](...)
[![MCP Tools](https://img.shields.io/badge/MCP%20tools-43-purple.svg)](...)

3.3 Asset Creation Workflow

Phase the visual work over two weeks:

Week 1 (minimum viable visuals): - Logo: Text-based logo using a monospace font + accent color. Does not need to be a custom illustration. Think deno or bun -- simple, recognizable, quick to create. - Hero banner: Logo + tagline + one screenshot composited in Canva/Figma. - Terminal GIF: Record a 30-second claw session using VHS (https://github.com/charmbracelet/vhs) or asciinema. - Badges: Copy-paste shields.io URLs into README. - Social preview: Resize hero banner to 1280x640.

Week 2 (polish): - Dashboard screenshot: Run the dashboard, take a real screenshot, crop and annotate. - Architecture diagram: Convert ASCII to Mermaid (renders natively on GitHub). - Telegram screenshot: Show a real notification arriving in Telegram. - Before/after comparison: Create a two-column image or use a GitHub details/summary block.

4. README Optimization

4.1 The Proven Structure

Analysis of repos that grew from 0 to 1k+ stars reveals a consistent README structure. Here is the template, mapped to claude-superpowers content:

1. Hero banner (logo + tagline + badges)
2. One-line value proposition
3. Animated GIF or screenshot (first viewport)
4. "Why?" section (3 bullet points, outcome-focused)
5. Quick start (3 steps maximum, copy-paste ready)
6. Feature highlights (with screenshots/GIFs per feature)
7. Architecture (graphical, not ASCII)
8. Comparison table (vs. alternatives)
9. Documentation links
10. Contributing guide
11. Community links (Discord, Twitter, etc.)
12. License

4.2 Rewritten Opening (Draft)

The current opening is feature-focused. Here is an outcome-focused rewrite:

<p align="center">
  <img src="assets/banner.png" alt="Claude Superpowers" width="800">
</p>

<p align="center">
  <strong>Turn your home server into an AI-powered command center.</strong><br>
  Automate infrastructure, schedule tasks, control devices, and monitor everything --
  all from your terminal, Telegram, or a web dashboard. Local-first. No cloud required.
</p>

<p align="center">
  <a href="..."><img src="https://img.shields.io/badge/tests-982%20passing-brightgreen" /></a>
  <a href="..."><img src="https://img.shields.io/badge/python-3.12+-blue" /></a>
  <a href="..."><img src="https://img.shields.io/badge/license-MIT-green" /></a>
  <a href="..."><img src="https://img.shields.io/badge/MCP%20tools-43-purple" /></a>
  <a href="..."><img src="https://img.shields.io/badge/docker-compose-blue" /></a>
</p>

<p align="center">
  <img src="assets/demo.gif" alt="Demo" width="700">
</p>

4.3 "Why?" Section (New)

Replace the implicit "this exists" with an explicit "here's why you'd want this":

## Why?

- **One CLI for everything**: Instead of 12 different tools for SSH, cron, secrets, messaging,
  browser automation, and monitoring, `claw` unifies them behind a single interface with 43 MCP
  tools that Claude Code can call directly.

- **Local-first, no SaaS dependency**: Everything runs on your hardware. Your credentials stay
  in an age-encrypted vault on your disk. Your data stays in local SQLite. No cloud account
  required.

- **AI-native automation**: Built for Claude Code from the ground up. Skills, workflows, and
  the intake pipeline let Claude orchestrate multi-step infrastructure tasks autonomously --
  with human approval gates when you want them.

4.4 Quick Start (Simplified)

Reduce the current 8-step quickstart to 3 steps:

## Quick Start

```bash
# 1. Install
git clone https://github.com/smartmur/claude-superpowers && cd claude-superpowers
pip install -e .

# 2. Run
claw status

# 3. (Optional) Start full stack
docker compose up -d
claw dashboard

See the full setup guide for Telegram, vault, and browser configuration. 

The key insight from n8n and Dify: the quickstart should get someone to a *working state* in under 60 seconds. Advanced configuration (vault init, Telegram tokens, Playwright) belongs in a separate guide, not the README quickstart.

### 4.5 Feature Showcase (With Visuals)

Each major feature should have its own collapsible section with a screenshot or GIF:

```markdown
<details>
<summary><strong>Dashboard</strong> -- Web UI for all subsystems</summary>
<br>
<img src="assets/dashboard.png" width="700" />

70 REST endpoints across 16 routers. Real-time status for cron jobs, skills, messaging,
SSH hosts, and browser sessions. Protected by HTTP Basic auth.

```bash
claw dashboard          # Start locally on port 8200
docker compose up dashboard  # Via Docker

### 4.6 Comparison Table (New)

Position against known alternatives to help visitors understand the niche:

```markdown
## How It Compares

| Feature | claude-superpowers | n8n | Rundeck | Ansible AWX |
|---|---|---|---|---|
| AI-native (MCP/Claude) | Yes | Partial | No | No |
| Local-first (no cloud) | Yes | Yes | Yes | Yes |
| Encrypted vault | age | N/A | Vault | Vault |
| Multi-channel messaging | 5 channels | Webhooks | Email | Email |
| Browser automation | Playwright | N/A | N/A | N/A |
| SSH fabric | Built-in | Via nodes | Built-in | Built-in |
| Skill system | Yes | Templates | N/A | Roles |
| Setup time | 3 minutes | 1 minute | 30 minutes | 60 minutes |

4.7 Things to Remove from the README

  • The full ~/.claude-superpowers/ directory tree (move to reference docs)
  • The complete project structure listing (move to reference docs)
  • The tech stack table (move to reference docs or collapse it)
  • The documentation table with 20+ links (replace with 4-5 top-level links)
  • "Private project. All rights reserved." (replace with actual license)

The README should be under 300 lines. The current one is 380 lines, and most of it is reference material that belongs in docs.

5. 6-Month Star Growth Roadmap

Overview

Month Target Stars Cumulative Primary Channel Key Action
Month 1 50 50 Personal network + Reddit Pre-launch prep
Month 2 150 200 Hacker News + Reddit Public launch
Month 3 200 400 Content marketing + awesome-lists Sustain momentum
Month 4 200 600 Conference talks + YouTube Authority building
Month 5 200 800 Cross-pollination + integrations Ecosystem growth
Month 6 300 1,100 Second HN push + Product Hunt Milestone push

Month 1: Pre-Launch Preparation (Stars Target: 50)

Week 1-2: Visual and README overhaul - [ ] Choose and apply an open-source license (MIT recommended) - [ ] Create project logo (text-based, monospace font + accent color) - [ ] Create hero banner image (1280x640, logo + tagline + screenshot) - [ ] Record terminal demo GIF (30 seconds, claw status -> claw skill run heartbeat -> Telegram notification) - [ ] Take dashboard screenshot (real running instance, annotated) - [ ] Convert ASCII architecture diagram to Mermaid - [ ] Add shields.io badges (CI, tests, Python version, license, Docker) - [ ] Set GitHub social preview image (repository settings -> Social preview)

Week 2-3: README rewrite - [ ] Rewrite README following the structure in Section 4.1 - [ ] Cut README to under 250 lines with progressive disclosure - [ ] Add "Why?" section with 3 outcome-focused bullets - [ ] Simplify quickstart to 3 steps - [ ] Add comparison table (vs. n8n, Rundeck, Ansible AWX) - [ ] Add feature showcase with collapsible sections and screenshots - [ ] Add "Contributing" section with link to CONTRIBUTING.md - [ ] Add "Community" section with Discord invite link

Week 3-4: Repository hygiene - [ ] Create CONTRIBUTING.md with setup instructions and code style - [ ] Create CODE_OF_CONDUCT.md (Contributor Covenant) - [ ] Create issue templates (bug report, feature request, skill request) - [ ] Create discussion categories (General, Show & Tell, Ideas, Q&A) - [ ] Label 10+ issues as "good first issue" and "help wanted" - [ ] Pin top 3 repos on SmartMur org profile - [ ] Create org-level README for github.com/smartmur - [ ] Write CHANGELOG.md with version history - [ ] Tag a v1.0.0 release with release notes

Week 4: Soft launch - [ ] Share with personal network (friends, colleagues, homelab communities you're already part of) - [ ] Post in 2-3 small Discord servers you're a member of - [ ] Ask 5-10 people to star, try the quickstart, and file issues for anything confusing - [ ] Fix all issues from soft launch feedback

Expected outcome: 50 stars from personal network + soft launch. More importantly, the repo is now "launch-ready" with visuals, docs, and community infrastructure.

Month 2: Public Launch (Stars Target: 150)

Week 5: Content preparation - [ ] Write a launch blog post: "I Built an AI-Powered Home Server Automation Platform with 982 Tests" (host on dev.to, cross-post to Medium and Hashnode with canonical URL) - [ ] Write a "Show HN" post draft (under 80 words, focus on the problem solved, not features) - [ ] Prepare r/homelab post (focus on the homelab use case, include dashboard screenshot) - [ ] Prepare r/selfhosted post (focus on local-first, no cloud dependency) - [ ] Record a 3-minute YouTube demo video (terminal + dashboard + Telegram)

Week 6: Launch week (coordinate for maximum star velocity)

Monday: - [ ] Publish blog post on dev.to - [ ] Tweet thread (5-7 tweets) from personal account showing key features

Tuesday: - [ ] Submit to Hacker News as "Show HN" between 8-10am ET (peak HN traffic) - [ ] Cross-post blog to Hashnode and Medium

Wednesday: - [ ] Post to r/homelab (not a link post -- write a genuine "here's what I built" narrative) - [ ] Post to r/selfhosted

Thursday: - [ ] Post to r/Python (focus on the Python architecture, test suite, Click CLI) - [ ] Post to r/docker (focus on the Docker Compose stack)

Friday: - [ ] Submit to relevant awesome-lists: - awesome-selfhosted (PR) - awesome-docker (PR) - awesome-python (PR) - awesome-homelab (PR) - awesome-claude (if exists)

Week 7-8: Respond and iterate - [ ] Reply to every HN comment, Reddit comment, and GitHub issue within 4 hours - [ ] Write a follow-up blog post addressing common questions/criticisms - [ ] Fix any issues raised during launch - [ ] Thank every new contributor publicly

Key insight from Infisical: They grew from 90 to 3,000 stars by driving all traffic to GitHub (not to a website). Every blog post, tweet, and Reddit comment should link to the GitHub repo, not a landing page.

Key insight from Liam ERD: Getting featured by @GithubProjects on X was their biggest single growth driver. Engage with GitHub's official accounts and trending pages.

Month 3: Sustain Momentum (Stars Target: 200)

  • [ ] Publish 2 technical blog posts per week on dev.to:
  • "How I Built a 43-Tool MCP Server for Claude Code"
  • "Automating Home Server Monitoring with Python and Telegram"
  • "Building an Encrypted Vault with age in Python"
  • "Why I Replaced 5 SaaS Tools with One CLI"
  • "How APScheduler Powers My Homelab Cron"
  • "Browser Automation with Playwright for Infrastructure Monitoring"
  • "SSH Fabric: Managing 10 Servers from One Terminal"
  • "Building a Multi-Channel Notification System in Python"
  • [ ] Submit PRs to 5 more awesome-lists
  • [ ] Create a "skill marketplace" concept (community-contributed skills)
  • [ ] Release v1.1.0 with community-requested features
  • [ ] Start a Discord server with channels: general, support, showcase, development
  • [ ] Cross-post all articles to dev.to, Hashnode, Medium (always with canonical URL)

Month 4: Authority Building (Stars Target: 200)

  • [ ] Submit a talk proposal to PyCon, PyConf, or a local Python meetup: "Building AI-Native CLI Tools with Claude MCP"
  • [ ] Record and publish 3 YouTube tutorials:
  • "Getting Started with Claude Superpowers in 5 Minutes"
  • "Automating Your Homelab with Skills and Workflows"
  • "Building Custom Skills for Claude Code"
  • [ ] Guest post on a homelab blog or newsletter
  • [ ] Create a comprehensive "Awesome Claude Code" list and include claude-superpowers
  • [ ] Engage with Claude Code community (Anthropic Discord, forums, X)
  • [ ] Create integration guides for popular homelab tools (Proxmox, TrueNAS, Portainer)

Month 5: Ecosystem Growth (Stars Target: 200)

  • [ ] Release 5 community-ready skill templates
  • [ ] Create a "skill-factory" repo (contributed skills, published via SkillHub)
  • [ ] Build integrations with trending projects (Ollama, n8n, Home Assistant)
  • [ ] Cross-promote with related repos (link to them, ask for reciprocal links)
  • [ ] Release a VS Code extension or Claude Code plugin
  • [ ] Publish a case study: "How I Manage My Homelab with AI Automation"
  • [ ] Engage in "State of Homelab" discussions on Reddit

Month 6: Milestone Push (Stars Target: 300)

  • [ ] Publish a major feature release (v2.0) with a compelling narrative
  • [ ] Second Hacker News push: "Show HN: 6 Months Building an AI-Powered Homelab -- What I Learned"
  • [ ] Submit to Product Hunt
  • [ ] Create a comparison landing page (GitHub Pages)
  • [ ] Publish a "Year in Review" or "1000 Stars Retrospective" blog post
  • [ ] Pitch to tech newsletters (TLDR, Morning Brew, Python Weekly, DevOps Weekly)
  • [ ] Run a "Hacktoberfest-style" contribution event if timing aligns

6. Documentation Strategy

6.1 Documentation Tiers

Structure docs into three tiers that serve different audiences at different stages:

Tier Audience Format Location
Tier 1: README First-time visitors (10 seconds) Scannable, visual, outcome-focused README.md
Tier 2: Guides New users (30 minutes) Tutorial-style, step-by-step docs/guides/
Tier 3: Reference Active users/contributors Complete API/config reference docs/reference/

6.2 Missing Documentation (Create in This Order)

Priority 1 (pre-launch): 1. CONTRIBUTING.md -- How to set up a dev environment, run tests, submit PRs, code style, commit conventions. This is mandatory for community growth. 2. Quick Start Guide (docs/guides/getting-started.md) -- Already exists but needs to be rewritten as a 10-minute tutorial that ends with a visible result (e.g., "You just automated a health check that sends to Telegram"). 3. Skill Development Guide (docs/guides/creating-skills.md) -- The skill system is the primary contribution vector. Make it dead simple to create and share skills.

Priority 2 (launch week): 4. Use Case Gallery (docs/guides/use-cases.md) -- 10 concrete scenarios with code: "Monitor Docker containers and alert via Telegram," "Backup verification with Slack notification," "Automated SSL cert renewal check." 5. Integration Guides -- One page each for: Proxmox, TrueNAS, Home Assistant, Portainer, Pi-hole, AdGuard.

Priority 3 (month 2-3): 6. Architecture Deep Dive (docs/reference/architecture.md) -- Already exists but should include Mermaid diagrams and design decision rationale. 7. FAQ -- Address common objections: "Why not just use n8n?", "Is this tied to Claude?", "Can I use this without an Anthropic API key?" 8. Troubleshooting Guide -- Common errors and fixes.

6.3 Documentation Style Rules

  • Every guide starts with a one-sentence summary of what the reader will accomplish.
  • Every guide ends with a "Next Steps" section linking to related guides.
  • Code examples must be copy-paste ready (no placeholder values that will error).
  • Screenshots must be current (update them with every major release).
  • Every page has a "Last updated" date.
  • Use admonitions (Note, Warning, Tip) sparingly but consistently.
  • Keep paragraphs under 4 sentences.

6.4 Documentation Site

For the first 6 months, GitHub-rendered Markdown is sufficient. Do not invest in a docs site (MkDocs, Docusaurus, etc.) until you have 500+ stars and active users requesting better navigation. The effort-to-impact ratio of a docs site at 0 stars is terrible.

When you do build a docs site, use MkDocs Material (the standard for Python projects) or Starlight (Astro-based, newer, faster).

7. Demo Strategy

7.1 Demo Assets (Priority Order)

Asset Format Duration Purpose Tool
Terminal GIF GIF/SVG in README 30 seconds README hero visual VHS or asciinema
Dashboard screenshot PNG in README N/A Prove the UI exists Browser screenshot
YouTube quickstart Video 3-5 min "Does this actually work?" OBS or terminal recording
YouTube deep dive Video 15-20 min Convert interested visitors to users OBS
Live demo instance Web URL Always-on Zero-friction evaluation GitHub Codespaces or hosted dashboard

7.2 Terminal GIF Script

The terminal GIF is the single highest-impact demo asset. Here is the exact script to record:

# Show version and status
$ claw --version
claude-superpowers 1.0.0

$ claw status
[Rich-formatted table showing: skills (14), cron jobs (3), vault (initialized), messaging (Telegram: connected)]

# Run a skill
$ claw skill run heartbeat
[Output showing hosts pinged, services checked, all-green status table]

# Send a message
$ claw msg send telegram "Health check complete -- all systems green"
Message sent to Telegram (chat: homelab-alerts)

# Show dashboard URL
$ claw dashboard &
Dashboard running at http://localhost:8200

Record this with VHS (https://github.com/charmbracelet/vhs) which produces crisp, small GIF files from a declarative tape file. Alternatively, use asciinema + svg-term for an SVG that renders perfectly at any resolution.

7.3 YouTube Content Plan

Video 1: "5-Minute Quickstart" (launch week) - Clone, install, run claw status - Run a skill, show Telegram notification arriving - Open dashboard, show the web UI - End with: "Star the repo if this is useful"

Video 2: "Building a Custom Skill" (month 2) - claw skill create --name disk-check --type bash - Edit the script to check disk usage - Schedule it as a cron job - Show the Telegram alert when disk is above 90%

Video 3: "Full Homelab Automation Tour" (month 3) - Walk through a real homelab setup - Show SSH fabric managing multiple hosts - Show workflows (deploy pipeline with rollback) - Show browser automation (screenshot a Proxmox dashboard) - Show the morning brief workflow

7.4 Live Demo Strategy

Option A: GitHub Codespaces (recommended for first 6 months) Add a .devcontainer/devcontainer.json that pre-installs all dependencies. Visitors click "Open in Codespace" and get a working environment in 30 seconds. Add a badge to the README: 

[![Open in GitHub Codespaces](https://github.com/codespaces/badge.svg)](...)

Option B: Hosted dashboard (month 3+) Run a read-only demo instance of the dashboard behind a Cloudflare tunnel. Populate it with sample data. Link to it from the README as "Try the live demo." This is low-risk since the dashboard is read-only when auth credentials are not provided.

Option C: Gitpod/Replit (alternative to Codespaces) Same concept, different platform. Gitpod has better open-source support.

8. Community Strategy

8.1 Platform Prioritization

Not all platforms are equal for developer tools. Prioritize based on expected ROI:

Platform Priority Audience Fit Effort Expected Stars/Post
Hacker News P0 High (technical, opinionated) Medium 50-300
r/homelab P0 High (exact target audience) Low 20-50
r/selfhosted P0 High (self-hosting enthusiasts) Low 20-50
X (Twitter) P1 Medium (broad tech audience) Medium 10-30
dev.to P1 Medium (developer blogging) Medium 5-20
r/Python P1 Medium (Python developers) Low 10-30
Discord P2 Medium (community retention) High (ongoing) Indirect
Product Hunt P2 Low (more SaaS-focused) Medium 20-50
YouTube P2 Medium (tutorial seekers) High 10-30 per video
LinkedIn P3 Low (wrong audience) Low 2-5

8.2 Reddit Strategy

Reddit is the highest-ROI channel for homelab tools. But Reddit also has "an almost supernatural ability to detect marketing." The rules:

  1. Be a genuine community member first. Post helpful comments in r/homelab and r/selfhosted for 2-4 weeks before sharing your project. Answer questions. Help people debug Docker issues. Build credibility.
  2. When you share, write a narrative, not a pitch. "I spent 6 months building an automation platform for my homelab. Here's what I learned and what it can do" performs 10x better than "Check out my new tool."
  3. Include real screenshots of your actual homelab. r/homelab loves hardware photos and dashboard screenshots. Show your physical setup.
  4. Acknowledge limitations honestly. "It doesn't support X yet, and Y is still rough" earns more trust than a polished pitch.
  5. Respond to every comment. Engagement signals to Reddit's algorithm that the post is worth promoting.
  6. Never post the same content to multiple subreddits on the same day. Space them out by 2-3 days.

8.3 Hacker News Strategy

HN is a high-risk, high-reward channel. A front-page post can deliver 100-300 stars in 48 hours. A post that doesn't reach the front page delivers zero.

Timing: Post between 8-10am ET on Tuesday or Wednesday (highest front-page probability based on historical data).

Format: Use "Show HN:" prefix. Keep the title under 80 characters. Focus on the unique angle: - Good: "Show HN: AI-powered homelab automation with 43 MCP tools and 982 tests" - Bad: "Show HN: Claude Superpowers -- a local-first automation platform"

First comment: Immediately post a detailed comment explaining: what it is, why you built it, what's unique, known limitations, and your technical stack. This comment often gets more upvotes than the post itself and is critical for HN front-page survival.

Do not ask for upvotes. HN detects and penalizes vote rings. Let the content speak.

8.4 X (Twitter) Strategy

Build a developer audience through a consistent posting cadence:

  • Daily: Share one interesting technical detail, code snippet, or "TIL" from building the project.
  • Weekly: Post a thread (5-7 tweets) showcasing a feature with screenshots/GIFs.
  • On launch: Thread with numbered tweets, each covering one feature with a visual.
  • Hashtags: #homelab, #selfhosted, #python, #docker, #devops, #AI, #ClaudeCode
  • Engage with: @AnthropicAI, @ClaudeAI, homelab influencers, Python community leaders.

8.5 Discord Server

Create a Discord server when you reach 100 stars (not before -- an empty Discord is worse than no Discord).

Channels: - #announcements (releases, blog posts) - #general (discussion) - #support (help and troubleshooting) - #showcase (people sharing their setups) - #skills (skill development and sharing) - #development (contributor discussion) - #off-topic

Bot: Add a GitHub webhook that posts new stars, releases, and issues to #announcements.

8.6 Newsletter Outreach (Month 3+)

Submit the project to these newsletters:

Newsletter Audience How to Submit
Python Weekly Python developers pythonweekly.com submission form
TLDR General tech tldr.tech submission form
DevOps Weekly DevOps engineers devopsweekly.com submission form
Console.dev Developer tools console.dev GitHub integration
Changelog Open source changelog.com podcast + newsletter
Awesome Selfhosted Newsletter Self-hosters Via awesome-selfhosted PR

9. Social Proof Strategy

9.1 The Cold Start Problem

Zero social proof is the hardest state to escape. Here is the sequence to build credibility from nothing:

Phase 1: Manufactured Legitimacy (Month 1)

These are not fake signals -- they are real signals that you can control: - 982 tests passing -- This is genuine social proof. Make it visible with a badge and mention it in every post. - v1.0.0 release -- Tag a release. Repos with releases look more professional than repos without them. - 14 skills, 43 MCP tools, 70 endpoints -- Quantify everything. Numbers communicate maturity. - CI/CD pipeline -- A green CI badge is a trust signal. - CONTRIBUTING.md + issue templates -- Signals that you expect and welcome contributors. - Code of Conduct -- Signals professionalism and inclusivity. - Professional README -- The single biggest controllable trust factor.

Phase 2: Earned Legitimacy (Month 2-3)

  • First external contributors -- Even one PR from someone outside the project changes the perception from "personal project" to "community project." Actively recruit contributors by labeling issues "good first issue" and promoting them on X and Reddit.
  • First blog post about the project (by someone else) -- Reach out to homelab bloggers and offer early access or a guided demo.
  • awesome-list inclusion -- Being listed on awesome-selfhosted or awesome-docker is a permanent trust signal.
  • GitHub Discussions activity -- Even 10 discussions with genuine answers creates a sense of active community.

Phase 3: Organic Legitimacy (Month 4-6)

  • GitHub Trending badge -- If you hit trending (even for a day), screenshot it and add it to the README.
  • Star count milestones -- Celebrate 100, 250, 500, 1000 stars publicly. Each milestone post generates more stars.
  • "Used by" section -- Once 3+ people are using it, add a "Used by" section to the README (with permission).
  • Conference talk -- A recorded talk at any meetup or conference is permanent social proof.
  • YouTube reviews by others -- Once the project has enough traction, homelab YouTubers will find it.

9.2 Social Proof Assets to Create

Asset When Purpose
Star History chart After 100 stars Shows growth trajectory (star-history.com embed)
"Used by" logos After 3 users Shows real adoption
Testimonial quotes After 5 users "This replaced 4 tools for my homelab"
Blog post links After 2 external posts "Featured in..." section
Conference talk video After month 4 Permanent authority signal
Contributor graph After 5 contributors Shows community activity

9.3 Star History Embed

Once you cross 100 stars, add a Star History chart to the README:

## Star History

[![Star History Chart](https://api.star-history.com/svg?repos=smartmur/claude-superpowers&type=Date)](https://star-history.com/#smartmur/claude-superpowers&Date)

This creates a self-reinforcing signal: people see a growing chart and want to be part of the trend.

10. Naming Impact

10.1 Why Naming Matters More Than You Think

The name is the first thing people see, the thing they type when telling a colleague about the project, and the thing they search for on Google. A bad name creates friction at every stage of the adoption funnel.

Case study: OpenClaw. Originally named "Clawdbot," the project was forced to rename five times due to Anthropic trademark issues. But the chaos itself became a growth driver -- each rename generated discussion on HN and Reddit. The final name "OpenClaw" stuck because it was: short, memorable, searchable, and didn't contain anyone else's trademark.

Case study: n8n. The name comes from "nodemation" (node + automation). It is: 3 characters, pronounceable ("n-eight-n"), unique on Google, and has no trademark conflicts. It took time to catch on but is now instantly recognizable.

10.2 Problems with "Claude Superpowers"

Problem Severity Detail
Trademark risk Critical "Claude" is Anthropic's registered trademark. Using it in a project name without permission risks a cease-and-desist. OpenClaw's experience with Anthropic C&D letters is instructive.
Not searchable High Searching "claude superpowers" returns Anthropic marketing. The project cannot own its own search term.
Implies dependency High The name suggests this only works with Claude. In reality, the platform's automation, messaging, SSH, and browser features work independently of any LLM.
Too long Medium 2 words, 18 characters. Hard to use as a CLI name, package name, or hashtag. The CLI is claw which is good, but disconnected from the full name.
Not brandable Medium There's no clear way to build a visual brand around "Claude Superpowers." No obvious logo concept, no mascot potential.

10.3 Naming Recommendations

The CLI is already called claw. Build the brand around that.

Option A: Claw (simplest) - Short, memorable, one syllable - Already the CLI name - Implies grabbing/controlling things - Logo: a stylized claw or crab claw - Risk: generic, might collide with other projects

Option B: ClawStack - Communicates that it's a platform/stack, not a single tool - Searchable and unique - Logo: stacked claw marks - Risk: "Stack" is overused in tech naming

Option C: Autonomous name (break from Claude association entirely) - Something like "Foreman," "Quartermaster," "Bulwark," "Sentinel," "Bastion" - These position the project as a standalone platform - Risk: loses the Claude Code connection which is a current differentiator

Recommended: Use "Claw" as the project name with the tagline "AI-powered homelab automation." This keeps the existing CLI name, is short and memorable, does not use Anthropic's trademark, and can be branded visually. The repo becomes smartmur/claw and the package becomes claw.

If "claw" has PyPI/GitHub namespace conflicts, consider "clawctl" (following kubectl/sysctl naming convention) or "clawops."

10.4 Org-Level Naming

The SmartMur organization name is fine -- it's unique, short, and doesn't conflict with anything. Use it as the org brand and let individual repos have their own identities.

Consider creating a cohesive narrative across repos: - smartmur/claw -- AI-powered homelab automation (flagship) - smartmur/homelab -- Infrastructure as Code (Docker Compose stacks) - smartmur/k3s-cluster -- Kubernetes homelab - smartmur/dotfiles -- Personal config (less relevant to star strategy)

The first three repos form a natural "SmartMur homelab ecosystem" narrative that can be cross-promoted.

Appendix A: Reference Examples

Repos That Grew from 0 to 1k+ Stars

Repo Stars Time to 1k Key Growth Driver
khuedoan/homelab 9k ~6 months HN post + "one command" value prop + architecture diagram
Infisical 25k 2 months to 3k HN + influencer tweet (Guillermo Rauch) + multiple platform push
Liam ERD 3k 3 months GitHub Trending + awesome-list PRs + international content strategy
n8n 177k 2 years to 10k Community forum + visual workflow builder + fair-code license
Dify 130k 1 year to 50k AI wave timing + visual drag-and-drop + 100+ LLM providers

What They All Have in Common

  1. Clear, visual README with logo/banner/GIF in the first viewport
  2. One-sentence value proposition that communicates outcome, not features
  3. 3-step quickstart that gets to a working state in under 60 seconds
  4. Open-source license (MIT, Apache 2.0, or custom fair-code)
  5. Active community engagement (every issue/comment answered quickly)
  6. Multi-platform launch (HN + Reddit + Twitter + blog, coordinated in one week)
  7. Consistent content cadence (1-2 blog posts per week for the first 3 months)

Appendix B: Immediate Action Checklist (Next 7 Days)

This is the minimum viable set of changes to make the repo "starrable":

  • [ ] Choose and add a LICENSE file (MIT recommended)
  • [ ] Create a text-based project logo
  • [ ] Record a 30-second terminal demo GIF with VHS
  • [ ] Take a real dashboard screenshot
  • [ ] Add shields.io badges to README
  • [ ] Rewrite README opening (value prop + why + simplified quickstart)
  • [ ] Remove "Private project. All rights reserved."
  • [ ] Set GitHub social preview image
  • [ ] Create CONTRIBUTING.md
  • [ ] Tag v1.0.0 release
  • [ ] Enable GitHub Discussions
  • [ ] Create 3 "good first issue" labels on open issues

Appendix C: Sources and References