Static Site Experience & Release

Use this skill to improve an existing static site without turning it into a feature pile. Prefer clarity, factual consistency, stable interaction, accessibility, and validated release discipline over additional cards, CTAs, animation, or backend services.

Do not use this skill to build a new site from scratch, add a database-backed anonymous comment service, or deploy a persistent server.

Operating Principles

• Preserve the user's confirmed visual baseline. Treat current project-card geometry, Hero hierarchy, key illustrations, and primary contact path as protected until explicitly changed.
• Start with a visitor-path audit, not implementation. Test first-time understanding, project exploration, reading flow, trust/credentials, contact, mobile controls, and third-party loading states.
• Fix factual conflicts before visual enhancements. Treat a user-provided PDF, verified source file, or explicit statement as authoritative; never invent dates, achievements, locations, statistics, or comments.
• Apply subtraction before addition. Reduce competing choices, default-open indexes, redundant CTAs, and unexplained loading states before adding interaction.
• Use progressive disclosure for dense content. Preserve deep content, tags, archives, and full tables of contents behind meaningful native <details> / <summary> controls or equally accessible disclosure.
• Keep deployment static. Do not introduce a database, always-on process, or secret-bearing client implementation merely for interaction polish.
• Respect prefers-reduced-motion, keyboard operation, visible focus, native dialog behavior, and touch target size.

Establish Inputs

Before editing, establish the repository path, production URL, package manager, quality-check command, production-build command, preview command, deployment workflow, branch policy, and static hosting base path. For Astro deployed under a GitHub Pages project subpath, keep internal links and public assets BASE_URL safe.