surge-landing
|
git clone --depth 1 https://github.com/jeremylongshore/tons-of-skills-marketplace /tmp/surge-landing && cp -r /tmp/surge-landing/plugins/ai-agency/tonone/bundle/revenue-team/skills/surge-landing ~/.claude/skills/surge-landingSKILL.md
# surge-landing — Growth-Optimized Landing Page
Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
## When to use
User needs a landing page designed for growth: activation funnels, A/B testing, acquisition, or PLG flows.
## Workflow
1. **Identify product type and growth goal** from user request (acquisition, activation, PLG, trial, freemium, etc.)
2. **Search landing page patterns:**
```bash
python3 -m surge_agent.uiux search --domain landing --query "{product_type}" --limit 3
```
3. **Search product reasoning:**
```bash
python3 -m surge_agent.uiux search --domain product --query "{product_type}" --limit 3
```
4. **Search UX for friction points:**
```bash
python3 -m surge_agent.uiux search --domain ux --query "forms validation loading" --limit 3
```
5. **Output** experiment-friendly structure with activation triggers and friction audit
## Output format
```
┌─ Growth Landing Page — {product_type} ──────────────────────────────┐
│ # │ Section │ Purpose │ Experiment? │
├────┼────────────────────┼────────────────────────────┼───────────────┤
│ 1 │ {section_name} │ {purpose} │ A/B headline │
│ 2 │ {section_name} │ {purpose} │ — │
│ 3 │ {section_name} │ {purpose} │ A/B CTA copy │
│ … │ … │ … │ … │
└────┴────────────────────┴────────────────────────────┴───────────────┘
Activation triggers: {activation_triggers}
Funnel structure: {funnel_structure}
Friction points: {friction_points}
Experiment surfaces: {experiment_surfaces}
```
## Anti-patterns
- Never optimize for vanity metrics (page views, time on page) over activation metrics
- Never add friction (sign-up gates, long forms) before demonstrating product value
- Never design sections that can't be independently A/B tested
- Never ship a growth page without identifying at least one experiment surface
## Delivery
If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.|
Engineering lead — hand Apex any task and it routes internally. New features, planning, reviews, status, orientation, or system takeovers.
Plan and scope a project — discovery, challenge assumptions, present S/M/L options with token and cost estimates. Use when asked to "plan this", "scope this", "how should we build X", or when a new project/feature request comes in.
Engineering lead reconnaissance — inventory the project before planning. Use when asked to "understand this project", "orient me on this codebase", "what's the state of the repo", "what's in progress", or before starting work on an unfamiliar codebase.
Cross-cutting review of recent work — catches gaps between specialists. Use when asked to "review what we built", "check the work", "pre-launch review", or after completing a significant chunk of work.
CTO-level project status from git and codebase state. Use when asked "where are we", "project status", "what's done", or at the start of a work session.
System takeover — take ownership of an existing codebase or inherited system. Use when "we acquired this", "previous team left", "take over this system", "inherited this codebase".
Knowledge engineer — architecture docs, ADRs, diagrams, changelogs, onboarding, and reports.