Frontend Frontier Radar Workflow
Daily frontend/design-engineering radar scans for signals that should change Kevin's stack, taste library, demos, or implementation habits.
The frontend-frontier-radar automation narrows signal radar to surfaces Kevin ships on: CSS, Tailwind, animation, R3F, shadcn, design systems, agent-browser workflows, and product-feeling frontend craft. Source: automations/frontend-frontier-radar.md, 2026-05-31
Routing
Use this page for frontend and design-engineering discovery. Use Signal Radar Workflow for broad tech pulse, SEO GEO Radar Workflow for search/AI visibility, and Content Pipeline Workflow when the output is a publishable post plan.
Trigger
- Daily automation from
automations/frontend-frontier-radar.md. - Manual request after a notable frontend trend, launch, library release, or design-system discussion.
- Before building a high-visibility frontend demo or landing surface.
Inputs
wiki/design/frontend-frontier.mdwiki/design/frontier-stack-2026.mdwiki/skills/frontend-design-taste.md- Public X discussion, GitHub Trending, Show HN, Product Hunt, and high-signal design-engineering creators.
Focus Areas
- Animation and scroll: GSAP, Motion, CSS scroll-driven animation, view transitions.
- React and Next.js performance patterns.
- Design systems, registries, primitives, and component distribution.
- Browser automation for visual QA: Browser Testing Skills, Complementary Browser Testing.
- Anti-slop frontend taste: Frontend and Design Skills, Taste Enforcement - Anti-Slop Frontend Rules, CSS UI Enforcement.
- Rich interaction demos that can become portfolio-quality proof.
Runbook
- Read the context pages before scanning so the run has a baseline.
- Collect candidates from sources updated or discussed recently.
- Reject pure aesthetics without reusable implementation detail unless the visual pattern is unusually strong.
- For each top item, identify what shipped, why it matters technically, and what interaction or aesthetic pattern is worth stealing.
- Decide whether Kevin should reply, ignore, build a demo, update a wiki page, or change a skill/routing entry.
- Pick one "demo bet" only when there is a concrete implementation path.
Promotion
Promote a signal to durable wiki memory only when it changes one of:
- Frontend and Design Skills or Frontier Stack 2026
- a design or style rule
- a tool ranking or Skill Resolver route
- a reusable pattern that belongs in
wiki/design/,wiki/style/, orwiki/tools/
Routine launches and inspiration links stay in outputs/<YYYY-MM-DD>/frontend-frontier-radar/<agent>.md.
Validation
Each promoted item needs a source URL, a concrete technical reason, and the page it changed. If the run cannot access live sources, record that limitation and avoid pretending it saw current trends.
Run Contract
This workflow follows Workflow Run Contract: name the sources, write output or no-op proof, promote only durable facts, update state only when the run really completed, refresh generated surfaces when durable pages or skills change, and log user-visible work.
Timeline
- 2026-07-01 | Rebuilt as a frontend-specific radar contract with routing, trigger, inputs, runbook, promotion criteria, and validation against current design/frontier pages. Source: User request, 2026-07-01
- 2026-05-31 | Workflow page created from frontend-frontier-radar automation. Source: automations/frontend-frontier-radar.md, 2026-05-31