plan-frontend

Route frontend planning tasks to the unified /plan workflow.

Updated Mar 25, 2026
One-click install
npx skills add https://github.com/Lbstrydom/claude-engineering-skills --skill plan-frontend
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: plan-frontend
Source: https://github.com/Lbstrydom/claude-engineering-skills/tree/main/.claude/skills/plan-frontend
Command: npx skills add https://github.com/Lbstrydom/claude-engineering-skills --skill plan-frontend

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

DEPRECATED — thin alias for /plan --scope=frontend. The unified /plan skill auto-detects scope (backend / frontend / full-stack) and applies the right principle sets without you having to choose. Existing trigger words still route here for muscle memory; this just delegates.

Use when the user asks to plan, design, or build frontend features — including UI components, pages, layouts, user flows, modals, forms, or visual changes. Auto-invokes on: design the UI for, plan the user flow, add a new view, build a component, improve the UX of, create a form for, or redesign the layout.

Accepts arguments describing the task: plan-frontend redesign the cellar grid view

Core Features & Use Cases

This skill is a backward-compatibility shim. The unified /plan replaces both plan-frontend and plan-backend, with scope detection in Phase 0 and lazy reference loading so per-invocation token cost is the same as before — and the output is one consolidated plan instead of two that need merging.

What to do: invoke /plan (or pass the same arguments here — they forward). The unified skill will detect scope as frontend based on:

  • Files cited in the task (components, pages, layouts, styles, forms)
  • Phrasing ("UI", "UX", "modal", "form", "layout", "design", "view", "page")
  • An explicit --scope=frontend flag

If you genuinely want frontend-only planning regardless of detection, pass --scope=frontend to /plan (or invoke this alias — it injects the flag).

Why deprecated: for cross-stack work, plan-frontend + plan-backend produced two separate plans that had to be merged manually, and the child plans drifted from the merged file. The unified /plan produces one document for one or both stacks, which is what /audit-plan, /audit-code, /ux-lock verify, and /ship all consume anyway.

Schedule: kept as an alias indefinitely so muscle memory + existing docs/links still work. Do NOT add new content to this file — edit skills/plan/SKILL.md instead.

Quick Start

Invoke the unified /plan with a frontend task, e.g., redesign the cellar grid view

Frequently Asked Questions about plan-frontend

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I plan frontend UI components and user flows in one step?

Frontend planning for UI components and user flows is handled by a unified workflow that auto-detects scope from cited files and phrasing, routing your task to the correct design principles without requiring separate prompts for each visual layer.

What is unified frontend planning and how does it handle backwards compatibility?

Unified frontend planning consolidates UI design, layouts, and forms into a single workflow. It maintains backwards compatibility by detecting frontend scope from trigger words like 'modal' or 'view' and forwarding content without loss to the consolidated planner.

Do I need separate prompts to plan frontend and backend features together?

You do not need separate prompts to plan frontend and backend features together. The unified planner detects the appropriate scope per invocation, producing one consolidated document instead of separate child plans that require manual merging.

Can I force the planner to only generate a frontend design scope?

Yes, you can force frontend-only planning by passing an explicit scope flag. This bypasses automatic file and phrasing detection, ensuring the output strictly applies frontend design principles to your UI components and layouts.

Why does my cross-stack plan drift when using separate frontend and backend planners?

Cross-stack plans drift because separate frontend and backend planners produce two distinct documents that must be merged manually. Using a unified planner generates one synchronized document that downstream audit and ship workflows consume directly.