@jakkrichm/create-nexus-devflow 2.0.20 → 2.0.21

package/template/.claude/skills/followup/SKILL.md

@@ -1,83 +0,0 @@
----
-name: followup
-description: "[Devflow] Followup task tracking, post-verification iteration, and routing unresolved items to subsequent runs."
----
-
----
-description: Follow-up Planning - Extend an existing completed or reviewed task without replacing the existing implementation plan.
----
-
-# Phase 35: Follow-up Planning
-
-## Request: $ARGUMENTS
-
-Use this workflow when the user wants to add more functionality to an existing task after implementation, QA, or human review.
-
-Primary behavior now lives in the `review-followup-routing` skill using `task-followup` mode. Keep this workflow as the compatibility wrapper for extending an existing running ID.
-
-## Prompt Source
-
-Adapted from:
-
-- `followup_planner.md`
-
-## Core Rule
-
-Extend, do not replace.
-
-Preserve existing phases, subtasks, statuses, logs, QA results, and completed context.
-
-## Process
-
-### 1. Load Existing Task
-
-Read:
-
-- `devflow/runs/{ID}-*10-define.md`
-- `devflow/runs/{ID}-*20-spec.md`
-- `devflow/runs/{ID}-*30-plan.md`
-- `devflow/runs/{ID}-*40-execute.md`
-- `devflow/runs/{ID}-*50-verify.md` if present
-
-### 2. Classify The Follow-Up
-
-Classify the request:
-
-- extension
-- enhancement
-- integration
-- refinement
-- bug fix after review
-
-### 3. Append New Work
-
-Use plan helpers:
-
-Append the follow-up scope directly to the relevant stage markdown files for the same running ID. Add new phases, subtasks, and validation notes in `30-plan.md` and carry resulting work into later stages.
-
-### 4. Ask For Confirmation
-
-After adding or proposing follow-up subtasks, ask the user to confirm before `40-execute`.
-
-## Output
-
-Return:
-
-- follow-up category
-- new phase/subtask plan
-- validation result
-- next command: `40-execute {ID}`
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: after review, triage, or release follow-up work is identified
-- Typical handoff targets: `10-define`, `20-spec`, `30-plan`, `40-execute`
-
-## Sources
-
-- `AGENTS.md`
-- Related commands: `PR-Followup`, `Issue-Triage`, `Human-Feedback`, `10-define`, `20-spec`, `40-execute`
-
-

package/template/.claude/skills/frontend-ui-engineering/SKILL.md

@@ -1,326 +0,0 @@
----
-name: frontend-ui-engineering
-description: "[Devflow] Builds production-quality UIs. Use when building or modifying user-facing interfaces. Use when creating components, implementing layouts, managing state, or when the output needs to look and feel production-quality rather than AI-generated."
----
-
-# Frontend UI Engineering
-
-## Overview
-
-Build production-quality user interfaces that are accessible, performant, and visually polished. The goal is UI that looks like it was built by a design-aware engineer at a top company — not like it was generated by an AI. This means real design system adherence, proper accessibility, thoughtful interaction patterns, and no generic "AI aesthetic."
-
-## When to Use
-
-- Building new UI components or pages
-- Modifying existing user-facing interfaces
-- Implementing responsive layouts
-- Adding interactivity or state management
-- Fixing visual or UX issues
-
-## Component Architecture
-
-### File Structure
-
-Colocate everything related to a component:
-
-```
-src/components/
-  TaskList/
-    TaskList.tsx          # Component implementation
-    TaskList.test.tsx     # Tests
-    TaskList.stories.tsx  # Storybook stories (if using)
-    use-task-list.ts      # Custom hook (if complex state)
-    types.ts              # Component-specific types (if needed)
-```
-
-### Component Patterns
-
-**Prefer composition over configuration:**
-
-```tsx
-// Good: Composable
-<Card>
-  <CardHeader>
-    <CardTitle>Tasks</CardTitle>
-  </CardHeader>
-  <CardBody>
-    <TaskList tasks={tasks} />
-  </CardBody>
-</Card>
-
-// Avoid: Over-configured
-<Card
-  title="Tasks"
-  headerVariant="large"
-  bodyPadding="md"
-  content={<TaskList tasks={tasks} />}
-/>
-```
-
-**Keep components focused:**
-
-```tsx
-// Good: Does one thing
-export function TaskItem({ task, onToggle, onDelete }: TaskItemProps) {
-  return (
-    <li className="flex items-center gap-3 p-3">
-      <Checkbox checked={task.done} onChange={() => onToggle(task.id)} />
-      <span className={task.done ? 'line-through text-muted' : ''}>{task.title}</span>
-      <Button variant="ghost" size="sm" onClick={() => onDelete(task.id)}>
-        <TrashIcon />
-      </Button>
-    </li>
-  );
-}
-```
-
-**Separate data fetching from presentation:**
-
-```tsx
-// Container: handles data
-export function TaskListContainer() {
-  const { tasks, isLoading, error } = useTasks();
-
-  if (isLoading) return <TaskListSkeleton />;
-  if (error) return <ErrorState message="Failed to load tasks" retry={refetch} />;
-  if (tasks.length === 0) return <EmptyState message="No tasks yet" />;
-
-  return <TaskList tasks={tasks} />;
-}
-
-// Presentation: handles rendering
-export function TaskList({ tasks }: { tasks: Task[] }) {
-  return (
-    <ul role="list" className="divide-y">
-      {tasks.map(task => <TaskItem key={task.id} task={task} />)}
-    </ul>
-  );
-}
-```
-
-## State Management
-
-**Choose the simplest approach that works:**
-
-```
-Local state (useState)           → Component-specific UI state
-Lifted state                     → Shared between 2-3 sibling components
-Context                          → Theme, auth, locale (read-heavy, write-rare)
-URL state (searchParams)         → Filters, pagination, shareable UI state
-Server state (React Query, SWR)  → Remote data with caching
-Global store (Zustand, Redux)    → Complex client state shared app-wide
-```
-
-**Avoid prop drilling deeper than 3 levels.** If you're passing props through components that don't use them, introduce context or restructure the component tree.
-
-## Design System Adherence
-
-### Avoid the AI Aesthetic
-
-AI-generated UI has recognizable patterns. Avoid all of them:
-
-| AI Default | Why It Is a Problem | Production Quality |
-|---|---|---|
-| Purple/indigo everything | Models default to visually "safe" palettes | Use project-specific color palettes |
-| Excessive gradients | Adds visual noise | Subtle or no gradients |
-| Rounded everything | Generic signals "safe" | Purposeful corner radii (sharp vs rounded) |
-| Generic hero sections | Template-driven, no context | Content-first, unique layouts |
-| Bento Grids | Used in every AI design | Use only when content truly benefits from it |
-| Shadows everywhere | Competitive depth noise | Subtle or no shadows |
-
-### UX Psychology & Layout
-- **Hick's Law**: More choices = slower decisions. Limit options, use progressive disclosure.
-- **8-Point Grid**: All spacing and sizing in multiples of 8 (Tight: 8px, Med: 16px, Large: 24px, XL: 48px+).
-- **Whitespace**: Generous whitespace signals luxury and improves scannability.
-- **Contrast**: Check WCAG (4.5:1 for normal text). Do not rely solely on color to convey information.
-
-### Spacing and Layout
-
-Use a consistent spacing scale. Don't invent values:
-
-```css
-/* Use the scale: 0.25rem increments (or whatever the project uses) */
-/* Good */  padding: 1rem;      /* 16px */
-/* Good */  gap: 0.75rem;       /* 12px */
-/* Bad */   padding: 13px;      /* Not on any scale */
-/* Bad */   margin-top: 2.3rem; /* Not on any scale */
-```
-
-### Typography
-
-Respect the type hierarchy:
-
-```
-h1 → Page title (one per page)
-h2 → Section title
-h3 → Subsection title
-body → Default text
-small → Secondary/helper text
-```
-
-Don't skip heading levels. Don't use heading styles for non-heading content.
-
-### Color
-
-- Use semantic color tokens: `text-primary`, `bg-surface`, `border-default` — not raw hex values
-- Ensure sufficient contrast (4.5:1 for normal text, 3:1 for large text)
-- Don't rely solely on color to convey information (use icons, text, or patterns too)
-
-## Accessibility (WCAG 2.1 AA)
-
-Every component must meet these standards:
-
-### Keyboard Navigation
-
-```tsx
-// Every interactive element must be keyboard accessible
-<button onClick={handleClick}>Click me</button>        // ✓ Focusable by default
-<div onClick={handleClick}>Click me</div>               // ✗ Not focusable
-<div role="button" tabIndex={0} onClick={handleClick}    // ✓ But prefer <button>
-     onKeyDown={e => e.key === 'Enter' && handleClick()}>
-  Click me
-</div>
-```
-
-### ARIA Labels
-
-```tsx
-// Label interactive elements that lack visible text
-<button aria-label="Close dialog"><XIcon /></button>
-
-// Label form inputs
-<label htmlFor="email">Email</label>
-<input id="email" type="email" />
-
-// Or use aria-label when no visible label exists
-<input aria-label="Search tasks" type="search" />
-```
-
-### Focus Management
-
-```tsx
-// Move focus when content changes
-function Dialog({ isOpen, onClose }: DialogProps) {
-  const closeRef = useRef<HTMLButtonElement>(null);
-
-  useEffect(() => {
-    if (isOpen) closeRef.current?.focus();
-  }, [isOpen]);
-
-  // Trap focus inside dialog when open
-  return (
-    <dialog open={isOpen}>
-      <button ref={closeRef} onClick={onClose}>Close</button>
-      {/* dialog content */}
-    </dialog>
-  );
-}
-```
-
-### Meaningful Empty and Error States
-
-```tsx
-// Don't show blank screens
-function TaskList({ tasks }: { tasks: Task[] }) {
-  if (tasks.length === 0) {
-    return (
-      <div role="status" className="text-center py-12">
-        <TasksEmptyIcon className="mx-auto h-12 w-12 text-muted" />
-        <h3 className="mt-2 text-sm font-medium">No tasks</h3>
-        <p className="mt-1 text-sm text-muted">Get started by creating a new task.</p>
-        <Button className="mt-4" onClick={onCreateTask}>Create Task</Button>
-      </div>
-    );
-  }
-
-  return <ul role="list">...</ul>;
-}
-```
-
-## Responsive Design
-
-Design for mobile first, then expand:
-
-```tsx
-// Tailwind: mobile-first responsive
-<div className="
-  grid grid-cols-1      /* Mobile: single column */
-  sm:grid-cols-2        /* Small: 2 columns */
-  lg:grid-cols-3        /* Large: 3 columns */
-  gap-4
-">
-```
-
-Test at these breakpoints: 320px, 768px, 1024px, 1440px.
-
-## Loading and Transitions
-
-```tsx
-// Skeleton loading (not spinners for content)
-function TaskListSkeleton() {
-  return (
-    <div className="space-y-3" aria-busy="true" aria-label="Loading tasks">
-      {Array.from({ length: 3 }).map((_, i) => (
-        <div key={i} className="h-12 bg-muted animate-pulse rounded" />
-      ))}
-    </div>
-  );
-}
-
-// Optimistic updates for perceived speed
-function useToggleTask() {
-  const queryClient = useQueryClient();
-
-  return useMutation({
-    mutationFn: toggleTask,
-    onMutate: async (taskId) => {
-      await queryClient.cancelQueries({ queryKey: ['tasks'] });
-      const previous = queryClient.getQueryData(['tasks']);
-
-      queryClient.setQueryData(['tasks'], (old: Task[]) =>
-        old.map(t => t.id === taskId ? { ...t, done: !t.done } : t)
-      );
-
-      return { previous };
-    },
-    onError: (_err, _taskId, context) => {
-      queryClient.setQueryData(['tasks'], context?.previous);
-    },
-  });
-}
-```
-
-## See Also
-
-For detailed accessibility requirements and testing tools, see `accessibility-checklist.md`.
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "Accessibility is a nice-to-have" | It's a legal requirement in many jurisdictions and an engineering quality standard. |
-| "We'll make it responsive later" | Retrofitting responsive design is 3x harder than building it from the start. |
-| "The design isn't final, so I'll skip styling" | Use the design system defaults. Unstyled UI creates a broken first impression for reviewers. |
-| "This is just a prototype" | Prototypes become production code. Build the foundation right. |
-| "The AI aesthetic is fine for now" | It signals low quality. Use the project's actual design system from the start. |
-
-## Red Flags
-
-- Components with more than 200 lines (split them)
-- Inline styles or arbitrary pixel values
-- Missing error states, loading states, or empty states
-- No keyboard navigation testing
-- Color as the sole indicator of state (red/green without text or icons)
-- Generic "AI look" (purple gradients, oversized cards, stock layouts)
-
-## Verification
-
-After building UI:
-
-- [ ] Component renders without console errors
-- [ ] All interactive elements are keyboard accessible (Tab through the page)
-- [ ] Screen reader can convey the page's content and structure
-- [ ] Responsive: works at 320px, 768px, 1024px, 1440px
-- [ ] Loading, error, and empty states all handled
-- [ ] Follows the project's design system (spacing, colors, typography)
-- [ ] No accessibility warnings in dev tools or axe-core

package/template/.claude/skills/frontend-ui-engineering/accessibility-checklist.md

@@ -1,159 +0,0 @@
-# Accessibility Checklist
-
-Quick reference for WCAG 2.1 AA compliance. Use alongside the `frontend-ui-engineering` skill.
-
-## Table of Contents
-
-- [Essential Checks](#essential-checks)
-- [Common HTML Patterns](#common-html-patterns)
-- [Testing Tools](#testing-tools)
-- [Quick Reference: ARIA Live Regions](#quick-reference-aria-live-regions)
-- [Common Anti-Patterns](#common-anti-patterns)
-
-## Essential Checks
-
-### Keyboard Navigation
-- [ ] All interactive elements focusable via Tab key
-- [ ] Focus order follows visual/logical order
-- [ ] Focus is visible (outline/ring on focused elements)
-- [ ] Custom widgets have keyboard support (Enter to activate, Escape to close)
-- [ ] No keyboard traps (user can always Tab away from a component)
-- [ ] Skip-to-content link at top of page
-- [ ] Modals trap focus while open, return focus on close
-
-### Screen Readers
-- [ ] All images have `alt` text (or `alt=""` for decorative images)
-- [ ] All form inputs have associated labels (`<label>` or `aria-label`)
-- [ ] Buttons and links have descriptive text (not "Click here")
-- [ ] Icon-only buttons have `aria-label`
-- [ ] Page has one `<h1>` and headings don't skip levels
-- [ ] Dynamic content changes announced (`aria-live` regions)
-- [ ] Tables have `<th>` headers with scope
-
-### Visual
-- [ ] Text contrast ≥ 4.5:1 (normal text) or ≥ 3:1 (large text, 18px+)
-- [ ] UI components contrast ≥ 3:1 against background
-- [ ] Color is not the only way to convey information
-- [ ] Text resizable to 200% without breaking layout
-- [ ] No content that flashes more than 3 times per second
-
-### Forms
-- [ ] Every input has a visible label
-- [ ] Required fields indicated (not by color alone)
-- [ ] Error messages specific and associated with the field
-- [ ] Error state visible by more than color (icon, text, border)
-- [ ] Form submission errors summarized and focusable
-
-### Content
-- [ ] Language declared (`<html lang="en">`)
-- [ ] Page has a descriptive `<title>`
-- [ ] Links distinguish from surrounding text (not by color alone)
-- [ ] Touch targets ≥ 44x44px on mobile
-- [ ] Meaningful empty states (not blank screens)
-
-## Common HTML Patterns
-
-### Buttons vs. Links
-
-```html
-<!-- Use <button> for actions -->
-<button onClick={handleDelete}>Delete Task</button>
-
-<!-- Use <a> for navigation -->
-<a href="/tasks/123">View Task</a>
-
-<!-- NEVER use div/span as buttons -->
-<div onClick={handleDelete}>Delete</div>  <!-- BAD -->
-```
-
-### Form Labels
-
-```html
-<!-- Explicit label association -->
-<label htmlFor="email">Email address</label>
-<input id="email" type="email" required />
-
-<!-- Implicit wrapping -->
-<label>
-  Email address
-  <input type="email" required />
-</label>
-
-<!-- Hidden label (visible label preferred) -->
-<input type="search" aria-label="Search tasks" />
-```
-
-### ARIA Roles
-
-```html
-<!-- Navigation -->
-<nav aria-label="Main navigation">...</nav>
-<nav aria-label="Footer links">...</nav>
-
-<!-- Status messages -->
-<div role="status" aria-live="polite">Task saved</div>
-
-<!-- Alert messages -->
-<div role="alert">Error: Title is required</div>
-
-<!-- Modal dialogs -->
-<dialog aria-modal="true" aria-labelledby="dialog-title">
-  <h2 id="dialog-title">Confirm Delete</h2>
-  ...
-</dialog>
-
-<!-- Loading states -->
-<div aria-busy="true" aria-label="Loading tasks">
-  <Spinner />
-</div>
-```
-
-### Accessible Lists
-
-```html
-<ul role="list" aria-label="Tasks">
-  <li>
-    <input type="checkbox" id="task-1" aria-label="Complete: Buy groceries" />
-    <label htmlFor="task-1">Buy groceries</label>
-  </li>
-</ul>
-```
-
-## Testing Tools
-
-```bash
-# Automated audit
-npx axe-core          # Programmatic accessibility testing
-npx pa11y             # CLI accessibility checker
-
-# In browser
-# Chrome DevTools → Lighthouse → Accessibility
-# Chrome DevTools → Elements → Accessibility tree
-
-# Screen reader testing
-# macOS: VoiceOver (Cmd + F5)
-# Windows: NVDA (free) or JAWS
-# Linux: Orca
-```
-
-## Quick Reference: ARIA Live Regions
-
-| Value | Behavior | Use For |
-|-------|----------|---------|
-| `aria-live="polite"` | Announced at next pause | Status updates, saved confirmations |
-| `aria-live="assertive"` | Announced immediately | Errors, time-sensitive alerts |
-| `role="status"` | Same as `polite` | Status messages |
-| `role="alert"` | Same as `assertive` | Error messages |
-
-## Common Anti-Patterns
-
-| Anti-Pattern | Problem | Fix |
-|---|---|---|
-| `div` as button | Not focusable, no keyboard support | Use `<button>` |
-| Missing `alt` text | Images invisible to screen readers | Add descriptive `alt` |
-| Color-only states | Invisible to color-blind users | Add icons, text, or patterns |
-| Autoplaying media | Disorienting, can't be stopped | Add controls, don't autoplay |
-| Custom dropdown with no ARIA | Unusable by keyboard/screen reader | Use native `<select>` or proper ARIA listbox |
-| Removing focus outlines | Users can't see where they are | Style outlines, don't remove them |
-| Empty links/buttons | "Link" announced with no description | Add text or `aria-label` |
-| `tabindex > 0` | Breaks natural tab order | Use `tabindex="0"` or `-1` only |