The Skill Stack Launch Checklist: 12 Sections, 90+ Checkpoints
GitHub is a graveyard of awesome-lists with 40 stars and a last commit from two years ago.
Every one of them started the same way: someone had real expertise, got excited, ran git init, and scaffolded a repo. Strategy was going to come later. Later never came. The repo shipped as a pile of entries with no buyer, no positioning, no license, and no launch plan, and it died quietly in the feed.
The failure isn’t effort. It’s sequence.
Publishing a skill stack, a framework library, a prompt pack, a template collection, is the highest-return credibility move available to an operator right now. Done right, it’s a citable asset that outranks every blog post you’ll ever write. Done in the wrong order, it’s a dead repo with your name on it.
So we run a pre-launch diagnostic first. Twelve sections. Ninety-plus checkpoints. One hard rule:
The repository is not scaffolded until sections one through five are complete.
This is the full checklist, ungated, CC BY 4.0. It’s the same template we run on client and internal launches. Work top-to-bottom. For a bounded AI workflow, the AI Skill Assurance and Deployment Readiness instrument turns launch evidence, ownership, tests, and change controls into a review record. It does not certify or approve deployment.
Section 1: Strategy
→ Problem statement, one sentence. What this stack solves that no existing curated list covers. If you can’t write it, stop here. → ICP. Role plus company stage. Not “everyone.” A stack for everyone is a stack for no one. → Outcome promise. The concrete deliverable the user walks away with after running one entry. → The “why this exists” sentence. Must survive a 10-second skim. If a stranger can’t repeat it back, rewrite it.
Section 2: Packaging Vector
→ Monetization model: free as a reputation play / free core + paid pro layer (rubrics, templates, slides) / paid per entry / front end for a productized service / hybrid. → If hybrid: where exactly is the free/paid gate? Name the line. → Funnel for an existing service? If yes, write the upsell path in one sentence: user runs the free asset, the output surfaces a problem, the service solves it.
Section 3: Branding
→ Brand stance: forward (name and logo dominant) / subtle (footer credit) / stealth (no brand). → Name candidates, 3 to 5. Then pick. → Naming style: descriptive (searchable, generic) / abstract (ownable, needs explanation) / metaphor (memorable, brand-native). → Tone: aspirational or problem-framed. Pick one. → Tagline. One sentence. Must survive an elevator pitch. → Availability checks: GitHub org free, npm/PyPI free, domain (optional), trademark conflict (USPTO TESS, EUIPO).
Section 4: License
→ Commercial use allowed? → Attribution mandatory? → Mixed code + content? If yes, dual license: code MIT or Apache-2.0, content CC BY 4.0. → License selected: MIT / Apache 2.0 / CC BY 4.0 / CC BY-SA 4.0 / CC BY-NC 4.0. → Trademark filing, or explicitly skipping. → LICENSE file written and linked from the README. A license in your head is not a license.
Section 5: Contributions
→ Model: open (anyone PRs) / curated (maintainer-only) / hybrid (open submissions, maintainer veto). → Rejection bar documented in CONTRIBUTING.md: required frontmatter fields, required sections, min/max length, required output type, required stance. If the bar isn’t written down, every rejection becomes an argument. → Sign-off mechanism: CLA / DCO / implicit (PR = agreement). → Review SLA in days. Write a number. → Out-of-scope contributions listed explicitly. What you won’t accept matters more than what you will.
side note: this is the section everyone skips, and it’s the one that decides whether year two of your repo is an asset or a chore.
Sections one through five done? Now you may scaffold.
Section 6: Hosting + Security
→ Source-of-truth host: GitHub / GitLab / Codeberg / other. → Distribution channels: releases and clone, npm, PyPI, Homebrew tap, marketplace mirror, curl one-liner. → Hosted runner? Local-only means zero key risk. Hosted means you flag and manage API key exposure. → Runtime credentials needed? If yes, document every env var. → Security hygiene: .gitignore blocks .env and keys, secret scanning on, no secrets anywhere in commit history, dependencies pinned, packages signed with provenance.
Section 7: Scope + Robustness
→ Launch entry count. Honest number. → Positioning matches count: “curated” holds at 10 to 25 entries. “Awesome” needs 50 to 100+. “Comprehensive” needs 200+. Calling 12 entries comprehensive is a credibility leak on day one. → v1.5 expansion roadmap. What ships 90 days post-launch. → v1 scope locked. What ships now versus what’s deferred, in writing, so launch week doesn’t renegotiate it.
Section 8: Tech / Format
→ Entry format: Markdown / JSON / YAML / TypeScript / Python / mixed. → Required frontmatter fields, listed. → Required sections per entry, listed. → Installer pattern: git clone / npx / curl one-liner / package manager / marketplace-only. → Validation tooling: CI validates PRs, lint rules documented, test runner.
Section 9: Repo Scaffold
Files committed before launch:
→ README.md: branded intro, install, index, license → LICENSE, full text → CONTRIBUTING.md: spec template, rejection bar, PR process → CODE_OF_CONDUCT.md and CONTRIBUTORS.md → .gitignore blocking secrets and build artifacts → PR template and validation workflows → Installer script or CLI entry point → Package manifest → docs/ with methodology, roadmap, FAQ → Entries organized into folders by track or category
Section 10: Launch
→ Top 3 channels: Hacker News, X, LinkedIn, Reddit, Product Hunt, newsletter, direct outreach, communities. → Launch order and 24-hour plan. Which channel fires first, and why. → Pre-launch ask list. Friendlies tagged for amplification before day zero, not after. → Launch copy drafted in advance: Show HN title and body, X thread, LinkedIn long-form, newsletter blast. → Success metric for 30 days. Stars, installs, signups, or inbound. A number, written down. → Failure threshold and pivot plan. Decide now what result means “reframe or archive,” so a quiet launch doesn’t turn into a zombie repo. → Discoverability: repo description filled, 5 to 10 topic tags, social preview image, pinned to profile, badges in README.
Section 11: Governance + Long-Term
→ Maintainer count, named humans. → Bus factor mitigation: co-maintainer or backup curator named. → Versioning: semver / calendar / main-is-stable. → Breaking-change policy: who signs off, how much notice. → Sunset or transfer plan. Every public asset needs a dignified ending written before it launches.
Section 12: The Quick-Fill 10
The rapid version. Ten prompts, one line each. If you can fill these in under 20 minutes, the full checklist will hold. If you can’t, the stack isn’t ready and no amount of scaffolding will fix that.
- Buyer
- Outcome
- Monetization
- Brand stance
- Name + tagline
- License
- Contributions model
- Host + runner
- Launch count + v1.5 plan
- Launch channel order
Clarity precedes momentum
That’s the line printed on the cover of the internal version, and it’s the whole argument. The graveyard repos didn’t fail at building. They failed at deciding. Every section above is a decision forced before the work starts, which is exactly when deciding is cheap.
This checklist is CC BY 4.0. Take it, run it, adapt it. Carry a bounded AI workflow into the AI Assurance instrument, or read the companion piece on how we design the diagnostics themselves: our skill-building checklist.
Scaffold last.
Frequently Asked Questions
Do I have to run all twelve sections before publishing?
No. Sections one through five are the hard gate: strategy, packaging vector, branding, license, contributions. Those five are expensive to change once people start using the thing. Six through twelve can be tightened after launch. The checklist is sequenced by cost of reversal, not by importance.
What if I only have three skills?
Publish three. A small stack with one clear thesis outranks a large one with none. What kills small stacks is not the count, it is the missing reason they belong together. If you cannot write the sentence explaining why these three sit in one repo, the problem is the thesis, not the volume.
Should it live in its own repo or inside an existing one?
Its own, almost always. A skill stack buried in a monorepo inherits that repo’s name, its README, and its search results. You are publishing a citable asset. It needs its own address, its own history, and a name someone can say out loud.
How do I know if it worked?
Someone uses your language without crediting you. Stars are vanity and forks are mild interest, but a stranger describing their own problem using your section names is the system working. That is the same signal that matters for any framework you put into the world.