hyperflow-design
Hyperflow design phase. Use when designing a UI / visual system or making a screen look good — verbs like "design the UI", "make it look good", "design the screen", "visual design", "design system". Establishes or extends a domain-grounded design system, researches real-world prior art, and renders it slop-free. Thinking and taste, not building.
git clone --depth 1 https://github.com/jeremylongshore/tons-of-skills-marketplace /tmp/hyperflow-design && cp -r /tmp/hyperflow-design/plugins/ai-agency/hyperflow/templates/antigravity/skills/hyperflow-design ~/.claude/skills/hyperflow-designSKILL.md
# hyperflow-design — design phase (Antigravity single-agent) Design system and taste, not production code. Follow the `hyperflow` doctrine. ## Steps 1. **Design system first.** Ensure `.hyperflow/design/system.md` exists — create it if missing, extend it (never regenerate) if present: tokens, type scale, motion language, voice, component inventory, references, anti-patterns. 2. **Researched, not invented.** Study **≥2** real-world references from the project's own field, combine them, then add one deliberate signature move — never copy a single source. 3. **Taste applied.** Discover and apply the matching local taste skill(s); pass the anti-slop floor (no default AI gradient, no serif-by-default, one accent, locked corner-radius scale, eyebrow restraint, no duplicate-intent CTAs, hero fits the viewport, every motion communicates state). 4. **Record** the bound design-system tokens and the named signature into the spec. When a motion surface is in scope, apply the Motion-language standards (compositor-only props, spring params, reduced-motion fallback); when a mobile surface is in scope, apply the mobile platform/device/accessibility matrix. ## Rules - No production code — only the design system and the spec. - Defer to accessibility on any a11y conflict (the WCAG floor wins) and to security on any security conflict. - Every best-practice claim about a pattern cites a current source.
|
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.