@event4u/agent-config 5.10.1 → 6.1.0

package/.agent-src/skills/fe-design/SKILL.md

@@ -1,255 +0,0 @@
----
-model_tier: medium
-name: fe-design
-description: "Reference for frontend-design heuristics — component architecture, layout patterns, form/table design, responsive strategy, a11y, UX principles. Stack-agnostic; cited by directives/ui/design.py."
-personas:
-  - frontend-engineer
-domain: engineering
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# Frontend Design Skill (Reference)
-
-## Positioning — reference, not executor
-
-`fe-design` is a **universal reference skill**, not an executor. It carries
-stack-agnostic heuristics that the UI directive set cites; it does **not**
-own the flow.
-
-| Concern | Owner |
-|---|---|
-| Layout / states / microcopy lock | [`directives/ui/design.py`](../../templates/scripts/work_engine/directives/ui/design.py) |
-| Stack-dispatched implementation | [`directives/ui/apply.py`](../../templates/scripts/work_engine/directives/ui/apply.py) → `blade-ui` / `livewire` / `flux` / `react-shadcn-ui` |
-| Existing-component inventory + tokens | [`existing-ui-audit`](../existing-ui-audit/SKILL.md) (mandatory pre-step) |
-| Design-review polish loop | [`directives/ui/review.py`](../../templates/scripts/work_engine/directives/ui/review.py) + [`directives/ui/polish.py`](../../templates/scripts/work_engine/directives/ui/polish.py) |
-
-## When to use
-
-Cite this skill when:
-
-- Planning a new page or feature UI before implementing
-- Choosing between component patterns (modal vs. inline, table vs. cards)
-- Designing forms with complex validation or multi-step flows
-- Making responsive design decisions
-- Reviewing UI for accessibility and usability
-
-Do NOT use this skill to:
-
-- Implement components — that is the apply-step's stack-dispatched skill
-- Audit an existing UI — that is `existing-ui-audit`
-- Drive the full UI flow — that is the `directives/ui/` orchestrator
-
-## How the directive set cites this skill
-
-`directives/ui/design.py` produces the design brief (layout, components,
-states, microcopy, a11y). The brief picks heuristics from this reference
-when the audit doesn't already pin a project pattern. Stack-specific
-choices come from the dispatched impl skill, not from here.
-
-## Component Architecture
-
-### Page structure (universal shape)
-
-```
-Page layout
-├── Header (static)
-├── Navigation (interactive — active state)
-├── Content area
-│   ├── Page heading + actions (static)
-│   ├── Filters (interactive — reactive)
-│   ├── Data display (interactive — table / cards)
-│   └── Pagination (interactive)
-└── Footer (static)
-```
-
-The stack-specific mapping (Blade partial vs. Livewire component vs.
-React island vs. Vue SFC) is the apply-step's concern, not this skill's.
-
-### When to use what (kind, not framework)
-
-| Kind | When | Example |
-|---|---|---|
-| **Static partial** | No interactivity, server-rendered only | Header, footer, static info |
-| **Reusable UI component** | Props-only, no state | Button, badge, card shell |
-| **Stateful component** | Needs server interaction or local state | Forms, tables, filters |
-| **Library primitive** | Standard UI from a design system | Modal, dropdown, input, toast |
-| **Client-only micro-interaction** | No server roundtrip needed | Toggle, accordion, clipboard |
-
-### Component granularity
-
-- **One stateful component per concern** — don't build mega-components.
-- **Compose with reusable UI components** for shared shells, headers, fields.
-- **Use the project's library primitives first** — never rebuild what the design system already provides (audit findings tell you which).
-- **Extract when used 3+ times** — DRY applies to UI too.
-
-## Form Design
-
-### Principles
-
-1. **Labels always visible** — no placeholder-only inputs
-2. **Validation on blur + submit** — immediate feedback, not on every keystroke
-3. **Error messages below the field** — red text, specific message
-4. **Required fields marked** — asterisk (*) or "(required)" label
-5. **Logical grouping** — related fields in sections with headings
-6. **Primary action prominent** — submit button stands out, cancel is secondary
-
-### Layout patterns
-
-| Fields | Layout | When |
-|---|---|---|
-| 1–3 fields | Single column | Simple forms (login, search) |
-| 4–8 fields | Two columns on desktop, single on mobile | Standard CRUD forms |
-| 8+ fields | Sections with headings or tabs/steps | Complex entity forms |
-| Related pairs | Side by side (first/last name, city/zip) | Logically paired fields |
-
-### Multi-step forms
-
-```
-Step indicator (1 — 2 — 3)
-├── Step 1: Basic info     → Next
-├── Step 2: Details        → Back / Next
-└── Step 3: Review + Submit → Back / Submit
-```
-
-- Show progress indicator (step numbers or progress bar)
-- Allow going back without losing data
-- Validate each step before allowing next
-- Show summary on final step
-
-## Table Design
-
-### Principles
-
-1. **Right-align numbers** — easier to compare
-2. **Left-align text** — natural reading direction
-3. **Sortable columns** — click header to sort
-4. **Sticky header** — visible when scrolling long tables
-5. **Row actions** — edit/delete as icon buttons or dropdown menu
-6. **Empty state** — helpful message when no data, not just blank
-
-### Responsive tables
-
-| Screen | Strategy |
-|---|---|
-| Desktop (≥1024px) | Full table with all columns |
-| Tablet (768–1023px) | Hide less important columns |
-| Mobile (<768px) | Card layout or horizontal scroll |
-
-### Pagination
-
-- Default: 25 rows per page
-- Show total count: "Showing 1–25 of 142"
-- Allow page size change (10, 25, 50, 100)
-- Prefer server-side pagination — avoid loading the full set client-side
-
-## Responsive Strategy
-
-### Breakpoints (Tailwind reference scale)
-
-| Prefix | Min width | Target |
-|---|---|---|
-| `sm:` | 640px | Large phones |
-| `md:` | 768px | Tablets |
-| `lg:` | 1024px | Small laptops |
-| `xl:` | 1280px | Desktops |
-| `2xl:` | 1536px | Large screens |
-
-### Mobile-first approach
-
-1. Design for mobile first (default styles)
-2. Add complexity at larger breakpoints
-3. Test at each breakpoint, not just desktop
-
-### Common patterns
-
-| Element | Mobile | Desktop |
-|---|---|---|
-| Navigation | Hamburger menu | Sidebar or top nav |
-| Forms | Single column | Two columns |
-| Tables | Cards or scroll | Full table |
-| Actions | Bottom sheet / FAB | Inline buttons |
-| Filters | Collapsible panel | Sidebar or inline |
-
-## Accessibility (a11y)
-
-### Minimum requirements
-
-- **Color contrast:** 4.5:1 for text, 3:1 for large text (WCAG AA)
-- **Keyboard navigation:** All interactive elements reachable via Tab
-- **Focus indicators:** Visible focus ring on all focusable elements
-- **Alt text:** All meaningful images have descriptive alt text
-- **ARIA labels:** Interactive elements without visible text need `aria-label`
-- **Semantic HTML:** Use `<button>`, `<nav>`, `<main>`, `<form>` — not `<div>` for everything
-
-### Common mistakes
-
-| Mistake | Fix |
-|---|---|
-| `<div onclick>` | Use `<button>` |
-| Color-only status | Add icon or text alongside color |
-| Missing form labels | Add `<label for="...">` |
-| Auto-playing content | Provide pause/stop control |
-| Tiny click targets | Min 44×44px touch target |
-
-## UX Principles
-
-1. **Feedback** — Every action gets a response (toast, loading state, success message)
-2. **Forgiveness** — Undo for destructive actions, confirmation for irreversible ones
-3. **Consistency** — Same patterns for same interactions across the app
-4. **Progressive disclosure** — Show basics first, details on demand
-5. **Loading states** — Skeleton screens or spinners, never blank screens
-6. **Error recovery** — Clear error messages with suggested actions
-
-## Aesthetic direction
-
-Audit-pinned tokens and components always take precedence (see `existing-ui-audit`). When the audit pins an aesthetic, honor it without deviation. When the audit shows **no pinned aesthetic** — greenfield surface, marketing landing page, brand-new feature without design-system precedent — the design brief is allowed (and expected) to commit to a deliberate direction instead of defaulting to safe centered hero + 3-column features + CTA.
-
-Pick one direction up front and let composition, typography, and color follow from it. Avoid the "neutral AI default": uniform grid, system fonts as the visible body face, purple-to-blue gradients on white, predictable spacing. A direction that fits the brand intent (editorial / brutalist / refined / playful / retro / maximal / minimal / etc.) and is consistent across the page beats hedging.
-
-Surface the chosen direction in the design brief as a one-line statement (e.g. `aesthetic: editorial-magazine — asymmetric grid, serif display + sans body, generous gutters`). The apply step (`react-shadcn-ui` / `blade-ui` / `livewire` / `flux`) reads this line and matches typography, spacing, and motion to it; if no line is present, the apply step uses project defaults.
-
-## Procedure
-
-When `directives/ui/design.py` (or any caller) cites this skill:
-
-1. **Inspect `state.ui_audit` first** — review the audit produced by [`existing-ui-audit`](../existing-ui-audit/SKILL.md); it is mandatory. Stop and request the audit if missing.
-2. **Pick the smallest matching section** — Component Architecture, Form Design, Table Design, Responsive Strategy, Accessibility, or UX Principles. Cite by H2/H3 heading, never paste the whole skill.
-3. **Defer to audit findings** — when the audit pins a project pattern (token, primitive, layout convention), use it. The heuristics here are fallbacks for gaps, not overrides.
-4. **Defer to the stack apply skill** — Blade vs. Livewire vs. Flux vs. React-shadcn choices come from the dispatched impl skill, never from this reference.
-5. **Surface conflicts** — if a heuristic here contradicts an audit finding or stack convention, name both and let the caller decide; do not silently pick.
-
-## Output format
-
-When this skill's content is folded into a design brief or review:
-
-1. Quote the cited heuristic verbatim, with the H2/H3 heading and a one-line "why this applies" tie-back to the request.
-2. Map each heuristic to a concrete artifact in the brief (component, form section, table column, breakpoint rule, a11y check, UX state).
-3. Keep stack-agnostic — never name Blade/Livewire/Flux/React primitives in the cited prose; the apply step adds those.
-4. Mark anything overridden by audit findings as `[audit override]` and link to the audit entry.
-
-## Related
-
-- **Orchestrator:** [`directives/ui/`](../../templates/scripts/work_engine/directives/ui/) — owns the UI flow
-- **Pre-step (mandatory):** [`existing-ui-audit`](../existing-ui-audit/SKILL.md) — inventory before design
-- **Stack apply skills (dispatched, not standalone):**
-  - [`blade-ui`](../blade-ui/SKILL.md) — Blade template impl
-  - [`livewire`](../livewire/SKILL.md) — Livewire component impl
-  - [`flux`](../flux/SKILL.md) — Flux component library usage
-  - [`react-shadcn-ui`](../react-shadcn-ui/SKILL.md) — React + shadcn primitives
-- **Adjacent reference:** [`dashboard-design`](../dashboard-design/SKILL.md) — monitoring dashboard design (different domain)
-
-## Gotcha
-
-- Don't design components without running `existing-ui-audit` first — the audit's component/token inventory is the canonical source for "what already exists in this project". Reinventing is the #1 failure mode.
-- Heuristics in this reference apply across stacks; do not promote them to project rules without checking the audit.
-- Mobile-first is not optional — every layout must work on 320px width.
-
-## Do NOT
-
-- Do NOT skip mobile viewport testing.
-- Do NOT use fixed pixel widths for responsive layouts.
-- Do NOT ignore accessibility requirements.
-- Do NOT use this skill as an executor — it is a reference cited by `directives/ui/design.py`.

package/.agent-src/skills/feature-planning/SKILL.md

@@ -1,271 +0,0 @@
----
-model_tier: inherit
-name: feature-planning
-description: "Use when the user says "plan a feature", "brainstorm", "explore this idea", or wants to go from idea to structured plan and roadmap."
-domain: product
-workspaces:
-  - product
-packs:
-  - product-basic
-trust:
-  level: professional
-install:
-  removable: true
----
-
-# feature-planning
-
-## When to use
-
-Use this skill when:
-- The user has a feature idea they want to explore or plan
-- An existing feature plan needs refinement
-- A feature plan needs to be turned into actionable roadmaps
-
-Do NOT use when:
-- Bug fixes (use `bug-analyzer` skill)
-- Simple, well-understood changes that don't need planning
-
-## Procedure: Plan a feature
-
-1. **Gather requirements** — What problem does this solve? Who benefits? What's the expected outcome?
-2. **Analyze scope** — Which modules, routes, models, services are affected?
-3. **Write the plan** — Create a feature plan document (see template below).
-4. **Verify** — Confirm all affected areas are identified, no missing dependencies.
-
-A **feature plan** captures the "what and why" of a feature:
-- Problem it solves, who benefits, expected outcome
-- Scope, affected modules, technical approach
-- Open questions and decisions
-
-A **roadmap** captures the "how and when" — the step-by-step implementation plan.
-Feature plans and roadmaps are linked but separate concerns.
-
-## File structure
-
-```
-agents/features/                         # Project-wide feature plans
-├── {feature-name}.md
-
-app/Modules/{Module}/agents/features/    # Module-scoped feature plans
-├── {feature-name}.md
-
-.augment/templates/
-└── features.md                          # Feature plan template
-```
-
-Roadmaps generated from features live in `agents/roadmaps/` (or module-level `agents/roadmaps/`).
-
-## Feature lifecycle
-
-### Quick workflow (small features)
-
-```
-Explore → Plan → Refine → Roadmap → Implement
-  ↑                ↑
-  └── iterate ─────┘
-```
-
-| Phase | Command | Output |
-|---|---|---|
-| **Explore** | `/feature-explore` | Brainstorming notes, feasibility check, rough scope |
-| **Plan** | `/feature-plan` | Structured feature doc in `agents/features/` |
-| **Refine** | `/feature-refactor` | Updated feature doc with changes |
-| **Roadmap** | `/feature-roadmap` | Roadmap(s) in `agents/roadmaps/`, linked from feature |
-
-### Full workflow (complex features, 7 phases)
-
-Use the full workflow for features that span multiple files, require architecture decisions,
-or have unclear requirements. Trigger with `/feature:dev`.
-
-```
-Discovery → Exploration → Questions → Architecture → Implementation → Review → Summary
-```
-
-#### Phase 1: Discovery
-- Clarify the feature request — what problem does it solve?
-- Identify constraints, requirements, and affected users.
-- **Understanding Lock (Hard Gate):** Summarize understanding in 5–7 bullets covering:
-  what is being built, why, who it's for, key constraints, explicit non-goals.
-- List all **assumptions** explicitly.
-- **Wait for explicit confirmation before proceeding.** Do NOT design until confirmed.
-
-#### Phase 2: Codebase Exploration
-- Search for similar features in the codebase.
-- Map the architecture and abstractions in the affected area.
-- Identify key files, services, models, routes involved.
-- Present findings with file references.
-
-#### Phase 3: Clarifying Questions
-- Review codebase findings against the feature request.
-- Identify underspecified aspects: edge cases, error handling, integrations, backward compatibility.
-- **Non-functional requirements** — explicitly clarify or propose defaults for:
-  - Performance expectations (response time, throughput)
-  - Scale (users, data volume, concurrent requests)
-  - Security / privacy constraints
-  - Reliability / availability needs
-  - Maintenance and ownership expectations
-- Present all questions in an organized list.
-- **Wait for answers before proceeding.**
-
-#### Phase 4: Architecture Design
-- Design 2-3 implementation approaches with different tradeoffs:
-  - **Minimal changes** — smallest change, maximum reuse.
-  - **Clean architecture** — maintainability, elegant abstractions.
-  - **Pragmatic balance** — speed + quality.
-- Present comparison with pros/cons and a recommendation.
-- **Ask the user which approach to use** (present as numbered options).
-
-#### Phase 5: Implementation
-- **Wait for explicit approval** before starting.
-- Follow chosen architecture from Phase 4.
-- Follow codebase conventions strictly.
-- Track progress via task list or roadmap.
-
-#### Phase 6: Quality Review
-- Review the implementation for:
-  - Simplicity, DRY, elegance.
-  - Bugs and correctness.
-  - Convention adherence.
-- Present findings with severity levels.
-- **Ask what to fix now vs. later.**
-
-#### Phase 7: Summary
-- Summarize what was built, key decisions, files modified.
-- Suggest next steps (tests, documentation, follow-up features).
-- Update roadmap if applicable.
-
-## Decision log
-
-Maintain a running **decision log** throughout the planning process. For each decision:
-- What was decided
-- Alternatives considered
-- Why this option was chosen
-
-Include the decision log in the feature plan file under a `## Decisions` section.
-This ensures future developers (and agents) understand the reasoning, not just the outcome.
-
-## Bite-sized task granularity (structural roadmaps only)
-
-When a feature plan's generated roadmap declares `complexity: structural` in its frontmatter, every task bullet must be self-contained and 2–5 minutes of work. Lightweight roadmaps (the default) skip this section — coarse-grained tasks ("Add login endpoint", "Update tests") are correct when the work is well-scoped and low-risk.
-
-Structural roadmap tasks must include:
-
-1. **Exact file path** — `app/Modules/Auth/Services/LoginService.php`, never *"the login service"*.
-2. **Complete code** — every method body, import, and signature ready to paste; no `// existing code` ellipses, no `…`.
-3. **Exact command** — the precise CLI invocation, never *"run the migration"*. Examples: `php artisan migrate --path=database/migrations/2026_05_09_create_logins.php` (Laravel), `bin/console doctrine:migrations:migrate --no-interaction` (Symfony), `bin/rails db:migrate VERSION=20260509…` (Rails), `npx prisma migrate deploy` (Prisma), `alembic upgrade +1` (Python / Alembic), `sqlx migrate run` (Rust).
-4. **Expected output** — what success looks like (`Migrated: 2026_05_09_create_logins`) and the exit code.
-5. **No placeholders** — angle-bracket placeholders, `TODO`, `FIXME`, `tbd`, and `???` are blockers; resolve before the task ships.
-
-The complexity flag lives in the roadmap's YAML frontmatter:
-
-```yaml
----
-complexity: structural   # triggers bite-sized granularity
-# or
-complexity: lightweight  # default — skips bite-sized granularity
----
-```
-
-Source: adapted from `obra/superpowers` `writing-plans/SKILL.md` § Task Structure + § No Placeholders (v5.1.0); complexity-gating is our addition (Council Round 1, Q4 — mitigates UX pushback for senior engineers on well-scoped work).
-
-## Self-review (3-scan checklist)
-
-Before presenting any plan, run these three scans in order. Each is a fast pass — not a deep review. Failures block presentation; fix and re-scan.
-
-1. **Spec coverage** — every requirement, AC bullet, or constraint from the input has a corresponding section / AC / scope item in the plan. Walk the input top-to-bottom; tick each requirement against the plan; missing items become open questions or new AC.
-2. **Placeholder / TODO scan** — grep the draft for `<placeholder>`, `TODO`, `FIXME`, `tbd`, `???`, `XXX`. Either resolve them now or surface them in the *Open questions* section. No placeholder ships unflagged.
-3. **Type / shape consistency** — proposed data structures, API shapes, file paths, and module names match existing codebase patterns. Cite at least one existing file per new structure as the convention anchor.
-
-This scan is **separate from** adversarial-review (below). Self-review catches mechanical gaps (missing AC, leftover placeholders, mis-shaped types); adversarial-review challenges the plan's reasoning.
-
-Source: adapted from `obra/superpowers` `writing-plans/SKILL.md` § Self-Review (v5.1.0).
-
-## Adversarial self-review
-
-After the 3-scan self-review passes, run the **`adversarial-review`** skill before presenting.
-Focus on the "Feature plans / Architecture" attack questions. See that skill for the full process.
-
-## Feature plan format
-
-See `.augment/templates/features.md` for the full structure. Key sections:
-
-- **Problem** — What pain point does this solve?
-- **Proposal** — What's the solution?
-- **Scope** — What's in, what's out?
-- **Affected Areas** — Which modules, models, services, routes?
-- **Technical Approach** — High-level architecture decisions
-- **Non-Functional Requirements** — Performance, scale, security, reliability
-- **Decisions** — Decision log with alternatives and reasoning
-- **Open Questions** — Unresolved decisions
-- **Roadmaps** — Links to generated roadmap files
-
-## Integration with other systems
-
-### Sessions
-
-```markdown
-- **Feature:** `agents/features/my-feature.md`
-```
-
-### Roadmaps
-
-Feature plans link to their roadmaps in the `## Roadmaps` section.
-Roadmaps reference their source feature in the `## Context` section.
-
-### Modules
-
-If a feature is scoped to a single module, the feature plan and roadmaps live in the
-module's `agents/` directory:
-- Feature: `app/Modules/{Module}/agents/features/`
-- Roadmaps: `app/Modules/{Module}/agents/roadmaps/`
-
-
-## Behavior rules
-
-### Research before planning
-
-Before creating a feature plan, always:
-1. **Search the codebase** for related code, existing patterns, and affected areas.
-2. **Read module docs** if the feature touches a specific module.
-3. **Check existing features** in `agents/features/` for overlap or dependencies.
-
-### Be collaborative
-
-- **Ask questions** — don't assume requirements.
-- **Challenge scope** — suggest what can be deferred.
-- **Show tradeoffs** — present options with pros/cons.
-- **Validate feasibility** — check if the codebase supports the approach.
-
-### Keep it navigational
-
-Feature plans are decision documents, not implementation guides.
-Implementation details belong in roadmaps.
-
-## Output format
-
-1. Feature plan document following the template structure
-2. Decision log with rationale for key choices
-3. Implementation roadmap with ordered tasks
-
-## Auto-trigger keywords
-
-- feature planning
-- feature exploration
-- feature roadmap
-- requirements
-
-## Gotcha
-
-- Don't plan features without understanding the business context — ask the user before assuming.
-- The model tends to over-engineer plans — start with the simplest viable solution.
-- A plan without acceptance criteria is incomplete — always define what "done" means.
-- Don't create plans for features that already exist — search the codebase first.
-
-## Do NOT
-
-- Do NOT create feature plans without user input — always collaborate.
-- Do NOT skip codebase research — always check what exists.
-- Do NOT put implementation steps in the feature plan — that's the roadmap's job.
-- Do NOT commit or push without permission.
-- Do NOT duplicate information from `AGENTS.md` or module docs.

package/.agent-src/skills/flux/SKILL.md

@@ -1,121 +0,0 @@
----
-model_tier: medium
-name: flux
-description: "Use when the project uses `livewire/flux` — dispatched by `directives/ui/{apply,review,polish}.py`. Covers Flux components, slots, variants, and form primitives."
-domain: engineering
-workspaces:
-  - engineering
-packs:
-  - laravel
-trust:
-  level: professional
-install:
-  default: false
-  removable: true
----
-
-# flux
-
-## Positioning — dispatched, not standalone
-
-`flux` is the **primitive-library executor** for projects on the
-Livewire + Flux stack. It is invoked by
-[`directives/ui/apply.py`](../../templates/scripts/work_engine/directives/ui/apply.py)
-once the design brief is locked, and revisited by `review.py` /
-`polish.py` during the design-review loop. It does **not** own the
-flow, does **not** drive the audit, and does **not** lock the design.
-
-| Concern | Owner |
-|---|---|
-| Audit + token inventory (mandatory pre-step) | [`existing-ui-audit`](../existing-ui-audit/SKILL.md) |
-| Design brief (layout / states / microcopy) | [`directives/ui/design.py`](../../templates/scripts/work_engine/directives/ui/design.py) |
-| Universal design heuristics | [`fe-design`](../fe-design/SKILL.md) |
-| Component logic / state / actions | [`livewire`](../livewire/SKILL.md) |
-| Static Blade partials | [`blade-ui`](../blade-ui/SKILL.md) |
-
-## When to use
-
-Cite this skill when:
-
-- The project depends on `livewire/flux` and `directives/ui/apply.py` dispatches Flux primitives
-- Building forms, modals, dropdowns, toasts, or other standard UI elements that Flux already provides
-
-Do NOT use when:
-
-- Raw Blade templates without Flux (use `blade-ui` skill)
-- Livewire component logic / state (use `livewire` skill)
-- React + shadcn (use `react-shadcn-ui` skill)
-- Driving the full UI flow yourself — that is the `directives/ui/` orchestrator
-
-## Procedure: Create a Flux view
-
-### Step 0: Inspect
-
-1. Confirm Flux is installed — check `composer.json` for `livewire/flux`.
-2. Check existing views — match Flux component usage patterns.
-3. Check Flux docs — https://fluxui.dev/docs for latest API.
-
-### Step 1: Build the view
-
-1. Use `<flux:*>` components instead of raw HTML.
-2. Use `variant` prop for styling (not custom Tailwind for standard styles).
-3. Use `wire:model` for Livewire binding.
-4. Use `label` prop on form fields (accessibility).
-
-### Step 2: Validate
-
-1. No raw HTML form elements where Flux equivalents exist.
-2. No manual error rendering (Flux has built-in validation display).
-3. No conflicting Tailwind classes overriding Flux styles.
-
-## Conventions
-
-→ See guideline `php/flux.md` for component reference, variants, forms, icons.
-
-## Output format
-
-1. Blade view using Flux components with correct props and slots
-2. Livewire component class if interactive behavior is needed
-
-### Review pass — a11y findings + preview envelope
-
-When this skill is dispatched by `directives/ui/review.py` (test slot)
-or `directives/ui/polish.py` (verify slot) — i.e. a review/polish run,
-not the initial apply — it also emits:
-
-- `state.ui_review.a11y` — `{violations: [{rule, selector, severity}, ...],
-  severity_floor?, accepted_violations?}`. Use the same `(rule, selector)`
-  shape as `state.ui_audit.a11y_baseline` so the engine's de-dup matches
-  pre-existing entries on replay. Omit the envelope on apply passes; the
-  engine's `_apply_a11y_gate` only fires when a baseline is present.
-- `state.ui_review.preview` — `{render_ok: bool, screenshot_path?,
-  dom_dump_path?, error?, skipped?}`. `render_ok: false` with `error`
-  populated triggers the `preview_render_failed` halt; `render_ok: true`
-  with `screenshot_path` threads the screenshot into the delivery
-  report's `artifacts` list. Browser tooling (Playwright/Cypress/…) is
-  a consumer-project dependency — this package does not ship one.
-
-Polish dispatch: when the dispatcher skips `review` because a previous
-review pass already returned `SUCCESS`, this skill MUST itself
-synthesise the updated `state.ui_review.findings` (including any
-remaining `a11y_violation` entries) so the engine's gate sees the
-current state on the next polish round.
-
-## Gotcha
-
-- The model tends to use old Flux API syntax — always check latest docs.
-- Flux has built-in validation display — don't add manual error rendering alongside it.
-- Don't mix Flux with raw HTML form elements in the same form.
-
-## Do NOT
-
-- Do NOT use raw `<input>`, `<select>`, `<button>` when Flux equivalents exist.
-- Do NOT override Flux styles with conflicting Tailwind — use variants or slots.
-- Do NOT skip the `label` prop on form fields — accessibility.
-
-## Auto-trigger keywords
-
-- Flux UI
-- Livewire components
-- Flux component
-- Laravel Flux