Pages: Features
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..." |
| Feature grid/list |
Each feature: name, benefit, optional screenshot |
| 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.
Output Format
- Feature list with benefit-first copy
- Structure (sections, order)
- Headline options
- Per-feature content (if separate pages)
- SEO metadata and schema
vs. Tools
| Page |
Purpose |
Monetization |
| Features |
Paid product capabilities; conversion |
Primary revenue |
| Tools |
Free utilities; lead gen; excerpt from product |
Not primary; drives signups |
See tools-page-generator for free tools pages.
Related Skills
- card: Feature card structure; name, benefit, screenshot; grid/list layout
- grid, list: Feature grid or list layout
- tools-page-generator: Tools = free lead gen; features = paid capabilities; link from tools to product/features
- use-cases-page-generator: Features = what it does; use cases = when/how to use it; link between; avoid duplicating scenario content on features page
- landing-page-generator: Features content for product LP "Explain value" step; product LP links to features
- url-slug-generator: URL slug for per-feature pages (e.g. /features/feature-name); 3-5 words
- homepage-generator: Homepage links to features
- pricing-page-generator: Features inform plan tiers
- schema-markup: SoftwareApplication schema
- heading-structure: Feature page heading structure
1---
2name: features-page-generator
3description: 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.
4metadata:
5 version: 1.1.1
6---
7
8# Pages: Features
9
10Guides features page content, structure, and conversion optimization.
11
12**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.
13
14## Initial Assessment
15
16**Check for project context first:** If `.claude/project-context.md` or `.cursor/project-context.md` exists, read it for product, differentiation, and proof points.
17
18Identify:
191. **Feature set**: Core features, differentiators
202. **Audience**: Who evaluates features (buyer persona)
213. **Format**: Single page vs. per-feature pages
224. **Primary goal**: Demo, sign up, learn more
23
24## Features Page Structure
25
26| Section | Purpose |
27|---------|---------|
28| **Headline** | Benefit-led; "Everything you need to..." |
29| **Feature grid/list** | Each feature: name, benefit, optional screenshot |
30| **Use case links** | "For marketers," "For developers" |
31| **Social proof** | Testimonials, logos |
32| **CTA** | Try free, see demo, contact |
33
34## Best Practices
35
36### Benefit-First
37
38- **Lead with benefit**: "Save 10 hours/week" not "Automated reporting"
39- **Customer outcome**: What they get, not what it does
40- **Specificity**: Numbers, examples, not vague claims
41
42### Organization
43
44- **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
45- **By priority**: Most important/differentiating first
46- **By journey**: Discovery -> evaluation -> decision
47
48### Per-Feature Pages
49
50- Use when features are substantial or rank separately
51- Each page: feature name, benefit, how it works, proof
52- Internal link from main features page
53
54## SEO
55
56- Title: "Features | [Product]" or "[Feature] | [Product]"
57- H1: Main value; H2 per feature or section
58- Schema: SoftwareApplication if applicable
59- Internal links: To pricing, use cases, blog
60
61### Avoid Overlap with Use Cases
62
63- **Features = What**: Capability + benefit; no scenario narratives. Do not write "When you need to X..." — that belongs on use cases pages.
64- **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.
65- **Content cannibalization**: Both target Commercial/Consideration; differentiate by angle (capability vs scenario) so each page serves unique intent.
66
67## Output Format
68
69- **Feature list** with benefit-first copy
70- **Structure** (sections, order)
71- **Headline** options
72- **Per-feature** content (if separate pages)
73- **SEO** metadata and schema
74
75### vs. Tools
76
77| Page | Purpose | Monetization |
78|------|---------|--------------|
79| **Features** | Paid product capabilities; conversion | Primary revenue |
80| **Tools** | Free utilities; lead gen; excerpt from product | Not primary; drives signups |
81
82See **tools-page-generator** for free tools pages.
83
84## Related Skills
85
86- **card**: Feature card structure; name, benefit, screenshot; grid/list layout
87- **grid, list**: Feature grid or list layout
88- **tools-page-generator**: Tools = free lead gen; features = paid capabilities; link from tools to product/features
89- **use-cases-page-generator**: Features = what it does; use cases = when/how to use it; link between; avoid duplicating scenario content on features page
90- **landing-page-generator**: Features content for product LP "Explain value" step; product LP links to features
91- **url-slug-generator**: URL slug for per-feature pages (e.g. /features/feature-name); 3-5 words
92- **homepage-generator**: Homepage links to features
93- **pricing-page-generator**: Features inform plan tiers
94- **schema-markup**: SoftwareApplication schema
95- **heading-structure**: Feature page heading structure
kostja94