the-homepage
Skill334 starsChanged 3 months agoMITView on GitHub
Structure a dev-tool homepage that converts developers into champions. Use when the landing page is written for the buyer instead of the developer, reads as salesy, buries what the product does, or makes it hard to start. Pairs with the ShipReady homepage audit.
In this repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- start-hereSkill
- strategy-and-roadmapSkill
- who-is-this-forSkill
- talk-to-usersSkill
- positioning-and-storySkill
- beyond-the-wrapperSkill
- value-prop-that-convertsSkill
- time-to-first-valueSkill
- first-50-usersSkill
- launch-itSkill
- market-to-devs-sell-to-buyersSkill
- pricingSkill
- founder-led-salesSkill
- founder-led-contentSkill
- know-if-its-workingSkill
- market-scanSkill
- review-the-workSkill
- growth-loopsSkill
- research-the-marketSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 38
Don't build everything. Start with: homepage · docs · pricing · navbar (login, signup, contact, GitHub) · About (an About page builds trust …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
The homepage
Write your homepage for the person who actually reads it: the end-user developer, not the CTO who signs the check. The developer becomes your champion and sells it internally for you.
Use this when: your homepage speaks to buyers/ROI, it's clever but vague about what the thing does, or a developer can't tell in 5 seconds whether to care, and can't start in 5 minutes if they do.
The core rule (Czakon)
Address end-user developers on the homepage; put enterprise/ROI/buyer messaging on separate pages (enterprise, pricing, case studies). If you write the homepage for the buyer, you've written it for someone who isn't there.
Framework: the sections, in order (Czakon)
- Hook / core message: immediately: what is it? Use a category ("CI for monorepos"), a known-incumbent comparison ("a Datadog alternative"), or a plain statement. Headline = what it is · subhead = for whom / what job.
- Hero: a real product shot; two CTAs: Get started (signup) and Docs. Answer "what's in it for me?" up top. Lead with the how, not the why.
- Social proof, right after the hero: recognizable logos are the fastest credibility you have. Impressive dynamic metrics (users, stars) if you've got them.
- Value prop & differentiation: why you over the 10 alternatives (see
value-prop-that-converts). - Getting started: a huge conversion lever. Free trial, no credit card, quick setup. Any hard barrier sends developers straight to a competitor.
Design: clean typography, breathing room, no "salesy BS," minimal heavy interactions. An embedded playground / copy-pasteable snippet creates an instant aha.
Framework: what must be on it (Frankl)
Cross-check the copy has all six:
- the problem in the customer's language (before the solution)
- the villain / undeniable trend
- attributed proof with numbers (name · title · company)
- the inciting event / urgency
- social proof (not anonymous)
- a low-friction path to try (free tier · docs · GitHub)
The MVP website (Czakon)
Don't build everything. Start with: homepage · docs · pricing · navbar (login, signup, contact, GitHub) · About (an About page builds trust for an unknown brand). Add later, deliberately: case studies → comparison pages → blog → templates → sandbox → enterprise page.
Transparent pricing. "Contact sales for pricing" reads as "expensive and slow." Show a number wherever you can.
Decision tree: hero CTA
Can a developer get value self-serve?
├─ YES → primary CTA "Get started" (signup/download) + secondary "Docs".
└─ NO → primary CTA "Read the docs" / "See how it works"; don't fake a signup that dead-ends.Mistakes that look reasonable
- Writing for the buyer: ROI language up top; the developer bounces.
- Why before what: three sentences of vision before you say what it is.
- "Contact sales" pricing: kills self-serve trust instantly.
- No getting-started: a beautiful hero and no obvious first step.
- Puffery hero: "The powerful, seamless platform for modern teams." Says nothing (run
value-prop-that-converts).
Your next 30 minutes
- Read your hero as a skeptical developer: in 5 seconds, do you know what it is and if it's for you?
- Confirm the five sections exist in order; move buyer/ROI copy to its own page.
- Put a no-credit-card getting-started step above the fold or one click away.
- Run the page through ShipReady for the full 10-point scorecard.
Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev). Want a line-by-line teardown of your actual homepage from someone who's done hundreds? Reach out to me on LinkedIn.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

