When the user wants to create, optimize, or audit features page content. Also use when the user mentions "features page," "product features," "capabilities," "what it does," "feature list," "feature comparison," "product capabilities," or "features section." For sitewide page planning, use website-structure.
1k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
836
stars on the repo
on the repository, not the skill itself
Install
one command, takes just this skill from the repository
Guides features page content, structure, and conversion optimization.
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, differentiation, and proof points.
Identify:
Feature set: Core features, differentiators
Audience: Who evaluates features (buyer persona)
Format: Single page vs. per-feature pages
Primary goal: Demo, sign up, learn more
Features Page Structure
| Section | Purpose |
|---------|---------|
| Headline | Benefit-led; "Everything you need to..." |
| Use case links | "For marketers," "For developers" |
| Social proof | Testimonials, logos |
| CTA | Try free, see demo, contact |
Best Practices
Benefit-First
Lead with benefit: "Save 10 hours/week" not "Automated reporting"
Customer outcome: What they get, not what it does
Specificity: Numbers, examples, not vague claims
Organization
By capability: Group by product area or capability (e.g., Analytics, Automation, Integrations) — avoid organizing by use case to prevent overlap with use cases pages
By priority: Most important/differentiating first
By journey: Discovery -> evaluation -> decision
Per-Feature Pages
Use when features are substantial or rank separately
Each page: feature name, benefit, how it works, proof
Internal link from main features page
SEO
Title: "Features | [Product]" or "[Feature] | [Product]"
H1: Main value; H2 per feature or section
Schema: SoftwareApplication if applicable
Internal links: To pricing, use cases, blog
Avoid Overlap with Use Cases
Features = What: Capability + benefit; no scenario narratives. Do not write "When you need to X..." — that belongs on use cases pages.
Link, don't duplicate: Use "Use case links" (e.g., "For marketers," "For developers") to send users to use cases pages; do not replicate scenario content.
Content cannibalization: Both target Commercial/Consideration; differentiate by angle (capability vs scenario) so each page serves unique intent.