Api Page Generator
Draft or audit the public /api introduction page that sells your API to developers and links them to real endpoint documentation elsewhere.
Overview
API Page Generator is an agent skill most often used in Launch (also Validate landing) that structures and optimizes the developer-facing /api overview page separate from API reference docs.
Install
npx skills add https://github.com/kostja94/marketing-skills --skill api-page-generatorWhat is this skill?
- Separates API marketing page (/api) from API reference documentation
- Initial assessment for REST vs GraphQL, audience, and docs URL
- Reads .claude/project-context.md or .cursor/project-context.md when present
- Triggered by “API page,” “API landing,” “developer landing,” and “API for developers”
- Best-practice overview structure for value prop and CTA to docs or signup
- metadata version 1.0.1
Adoption & trust: 509 installs on skills.sh; 586 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Developers hit your marketing site and cannot tell what your API does, who it is for, or where the actual endpoint documentation lives.
Who is it for?
Indie API or SaaS founders shipping a public developer story at /api while keeping OpenAPI-style reference in docs.
Skip if: Generating OpenAPI endpoint reference, code samples per route, or internal-only microservice catalogs with no external audience.
When should I use this skill?
User wants to create, optimize, or audit the API introduction/overview page—API page, /api page, API overview, developer landing, or API for developers.
What do I get? / Deliverables
You get an API introduction page blueprint with overview, use cases, and CTAs that point integrators to docs or signup without duplicating reference material.
- Structured /api page outline with overview and CTAs
- Audience and docs-location assessment notes
- Audit checklist against API introduction best practices
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
The API landing page is a launch-facing distribution asset that drives signups and doc depth after the product exists. Distribution covers developer-facing entry points and CTAs—not the reference docs themselves, which live under docs.
Where it fits
Test whether ‘integrations in minutes’ messaging on a prototype /api page resonates before you freeze the OpenAPI surface.
Ship the public /api page with use cases and a single CTA into hosted docs and API keys.
Align page titles and overview copy with how developers search for your API category without stuffing endpoint lists.
Refresh the API story after adding major endpoints so the overview still matches what docs promise.
How it compares
Pair with docs-page-generator for reference depth; this skill is the marketing landing, not the docs section.
Common Questions / FAQ
Who is api-page-generator for?
Solo builders and small teams launching developer products who need a polished API overview page for evaluators and integrators, not a full endpoint encyclopedia on one URL.
When should I use api-page-generator?
At Launch when writing /api distribution copy; at Validate when shaping a landing that explains API value before full build; whenever you mention API landing page, developer landing, or API marketing.
Is api-page-generator safe to install?
Check the Security Audits panel on this Prism page and review the skill package; it is prose and checklist guidance with optional reads of local project-context files, not credential access.
SKILL.md
READMESKILL.md - Api Page Generator
# Pages: API Introduction Guides the API introduction page →typically at `/api` →that overviews the API, use cases, and links to documentation. API documentation (endpoint reference, code examples) lives on separate pages. **When invoking**: On **first use**, if helpful, open with 1–2 sentences on what this skill covers and why it matters, then provide the main output. On **subsequent use** or when the user asks to skip, go directly to the main output. ## Initial Assessment **Check for project context first:** If `.claude/project-context.md` or `.cursor/project-context.md` exists, read it for product and developer use cases. Identify: 1. **API type**: REST, GraphQL, etc. 2. **Audience**: Developers (integration) vs. decision makers (evaluation) 3. **Docs location**: Where API documentation lives (e.g. `/docs`, `/api/reference`, external) ## Page Role - **API page** (`/api`): Introduction, overview, value prop, CTA to docs or signup - **API documentation**: Lives in docs (docs.*) → API Reference section with endpoint reference, auth, examples ## Best Practices ### Overview and Structure - **What the API does**: Clear value proposition, key capabilities - **Use cases**: Who uses it, common scenarios - **Getting started**: Quick path to first call or docs - **Link to docs**: Prominent CTA to API documentation ### Content - **Key concepts**: High-level, not endpoint-level detail - **Auth overview**: How auth works; link to docs for details - **Pricing/limits**: If relevant for evaluation - **SDKs and tools**: If available; link to docs ### SEO and Discovery - **Developer search**: Target "API" + product/category terms - **Metadata**: Title, description for developer intent - **Internal links**: From homepage, features, resources ## Output Format - **Structure** outline (sections) - **Value proposition** and key messages - **CTA** to documentation or signup - **SEO** metadata for developer search ## Related Skills - **homepage-generator**: Link to API page for developers - **schema-markup**: WebPage or SoftwareApplication schema - **title-tag, meta-description, page-metadata**: API page metadata