| name | devtools-landing-page |
| description | Design and review landing pages for early-stage B2B devtools, developer infrastructure, AI developer tools, and technical SaaS startups. Use when Claude is asked to create, redesign, critique, or review changes to a startup homepage, launch page, hero section, messaging hierarchy, product-proof section, CTA strategy, visual direction, responsive implementation, or conversion-focused landing page for developers, platform teams, security teams, product engineers, or technical buyers. |
Devtools Landing Page
Workflow
- Establish the wedge: target user, technical workflow, buyer, buying motion, launch stage, available proof, and the one action the page should drive.
- Inspect the actual artifact before judging it: source files, design system, assets, screenshots, local browser, copy, analytics hooks, and responsive behavior when available.
- Load
references/devtools-b2b-style-notes.md when choosing a visual direction, comparing against current devtools/B2B patterns, or reviewing whether a page feels credible and current.
- Choose one style lane that matches the company: precision/minimal, code-native, enterprise proof, opinionated/playful, or component/product-suite.
- Design or review top-down: first viewport, product proof, credibility, section pacing, CTAs, implementation quality, and mobile fit.
- Validate with screenshots or a local browser when editing frontend code. Check desktop and mobile for text overflow, incoherent overlap, non-loading media, empty decorative visuals, and CTA visibility.
Design Rules
- Lead with the specific workflow outcome, not the category. Prefer "Review agent PRs before merge" over "AI-powered review automation".
- Show real product proof in the first viewport: UI screenshot, terminal command, code sample, trace, architecture flow, eval, benchmark, or short interactive demo.
- Keep early-stage pages narrow. Use one primary persona and one primary CTA unless the startup truly supports both product-led and sales-led motions.
- Pair developer-native proof with buyer-safe reassurance: docs, SDKs, install commands, GitHub stars, changelog, security posture, compliance, integration ecosystem, cost, reliability, or customer logos.
- Use trust only when it is real. Do not invent logos, quotes, usage metrics, compliance claims, or benchmark numbers.
- Use AI language only when the page explains the concrete job AI performs, the human control point, and the failure mode it reduces.
- Make the visual system feel technical through product surfaces, dense but legible UI, code, diagrams, and measured motion. Avoid generic SaaS blobs, oversized decorative cards, and vague gradient hero art.
- Make the first viewport practical: clear H1, concrete subcopy, product visual, primary CTA, secondary docs/demo CTA, and at least a hint of the next section on common desktop and mobile viewports.
Review Routine
When reviewing a landing page change, lead with findings ordered by severity and cite files/lines or screenshots when possible.
- Blocker: misleading claims, fake proof, missing actionable CTA, broken/mobile-overlapping first viewport, unreadable text, inaccessible primary action, or product media that fails to load.
- Major: generic positioning, unclear ICP, product not visible above the fold, too many equal-weight CTAs, unsupported enterprise/security claims, weak proof for a paid B2B buyer, or visual style copied too closely from a competitor.
- Minor: section rhythm, microcopy, CTA labels, logo density, animation restraint, contrast polish, image cropping, or responsive spacing.
Check these questions before signing off:
- Can a technical visitor tell what it does, who it is for, and what changes in their workflow within 5 seconds?
- Does the first screen show the product or a concrete technical artifact?
- Is there a credible next action for both an individual developer and a B2B evaluator?
- Are claims backed by visible proof close to the claim?
- Does the mobile layout preserve hierarchy without text overflow or card-on-card clutter?
- Does the page balance developer taste with the buyer's need for security, governance, reliability, and ROI?
Output Shape
- For design work, provide a compact page plan with positioning, visual lane, first viewport composition, section sequence, CTA strategy, and key copy.
- For implementation work, make scoped code changes that follow the existing app conventions and verify the result.
- For reviews, list findings first, then open questions, then a brief summary. Avoid rewriting the whole page unless the user asks for redesign work.
