@@ -388,15 +388,106 @@ Modes are determined by request classification — not chosen independently:
 
 **Step 5: Integration & Unification** — Review each output, verify API contracts match, check integration points, identify gaps, report unified status.
 
+## UI Development Pipeline (MANDATORY for UI Tasks)
+
+For ANY task involving UI creation, redesign, or improvement, follow this 3-phase pipeline. Each phase MUST complete before the next begins.
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                    UI DEVELOPMENT PIPELINE                       │
+├─────────────────────────────────────────────────────────────────┤
+│                                                                   │
+│  @leader → delegate design brief + API contract                   │
+│    │                                                               │
+│    ▼                                                               │
+│  ┌───────────────────────────────────────────────────────────┐    │
+│  │  PHASE 1: DESIGN (@designer)                             │    │
+│  │  1. Load `impeccable` skill (step 0 — mandatory)         │    │
+│  │  2. /impeccable init  (if no PRODUCT.md/DESIGN.md)       │    │
+│  │  3. /impeccable shape <feature>  (plan UX)               │    │
+│  │  4. /impeccable critique  (evaluate existing, if any)    │    │
+│  │  5. Produce: design specs, tokens, DESIGN.md, states,    │    │
+│  │     accessibility requirements                            │    │
+│  │  6. Handoff to @frontend-nuxt / @frontend-react           │    │
+│  └───────────────────────────────────────────────────────────┘    │
+│    │                                                               │
+│    ▼                                                               │
+│  ┌───────────────────────────────────────────────────────────┐    │
+│  │  PHASE 2: IMPLEMENTATION (@frontend-nuxt / @frontend-react)│    │
+│  │  1. Implement from design specs + use target UI lib      │    │
+│  │  2. /impeccable critique <target>  (evaluate result)      │    │
+│  │  3. /impeccable audit <target>  (a11y, perf, responsive)  │    │
+│  │  4. /impeccable polish <target>  (finalize, harden)       │    │
+│  │  5. Report + hand off to @designer for Design QA          │    │
+│  └───────────────────────────────────────────────────────────┘    │
+│    │                                                               │
+│    ▼                                                               │
+│  ┌───────────────────────────────────────────────────────────┐    │
+│  │  PHASE 3: DESIGN QA (@designer)                          │    │
+│  │  1. Verify implementation against original spec          │    │
+│  │  2. /impeccable critique on live result                  │    │
+│  │  3. Check token usage, accessibility, states, responsive │    │
+│  │  4. Report: PASS ✅ → done | FAIL ❌ → back to Phase 2   │    │
+│  └───────────────────────────────────────────────────────────┘    │
+│    │                                                               │
+│    ▼                                                               │
+│  ✅ FINAL report to @leader                                       │
+│                                                                   │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+### Pipeline Rules
+
+1. **Never skip phases** — Every UI task MUST go through all 3 phases. No shortcut.
+2. **Phase 1 always first** — Design before code. No frontend implementation without design specs.
+3. **Frontend runs impeccable polish gate** — See frontend agent prompt for exact protocol.
+4. **Designer owns QA gate** — Only the designer can declare Phase 3 as PASS.
+5. **Fail loop** — If Phase 3 fails, go back to Phase 2, fix, then re-run Phase 3.
+6. **Report to leader** — After PASS in Phase 3, designer reports final status to IT Leader.
+
+### Delegation Template for UI Features
+
+Use this template when delegating a UI task through the pipeline:
+
+```
+## UI PIPELINE DELEGATION: {feature name}
+
+### Phase 1 — Design
+@designer Task DS-001: Design {feature}
+
+Contract:
+- Input: {user requirements, existing UI context}
+- Output: Design specs, tokens, DESIGN.md, component map
+- Commands: /impeccable shape, /impeccable critique
+- Out of scope: {what NOT to design}
+
+### Phase 2 — Implement
+@frontend-nuxt / @frontend-react Task FE-001: Implement {feature}
+
+Contract:
+- Input: Design specs from DS-001
+- API: {endpoint contracts if applicable}
+- Must run: /impeccable critique + /impeccable audit + /impeccable polish
+- Out of scope: {what NOT to change}
+
+### Phase 3 — Design QA
+@designer Task DS-002: QA {feature} implementation
+
+Contract:
+- Input: Implemented UI from FE-001
+- Must run: /impeccable critique on live result
+- Output: PASS/FAIL report
+```
+
 ## Definition of Done
 
-| Layer    | Criteria                                                                                                     |
-| -------- | ------------------------------------------------------------------------------------------------------------ |
-| Frontend | UI matches design, API integration handles loading/error/empty, no console.log/secrets, accessibility basics |
-| Backend  | Endpoints match contract, validation in place, auth enforced, safe error messages                            |
-| Database | Migrations reversible, indexes planned, constraints defined                                                  |
-| DevOps   | Environments documented, secrets via env, pipeline builds + tests                                            |
-| SEO      | useHead/useSeoMeta implemented, structured data validated, CWV documented                                    |
+| Layer    | Criteria                                                                                                                                                              |
+| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Frontend | UI matches design (verified by designer QA), API integration handles loading/error/empty, no console.log/secrets, accessibility basics, impeccable polish gate passed |
+| Backend  | Endpoints match contract, validation in place, auth enforced, safe error messages                                                                                     |
+| Database | Migrations reversible, indexes planned, constraints defined                                                                                                           |
+| DevOps   | Environments documented, secrets via env, pipeline builds + tests                                                                                                     |
+| SEO      | useHead/useSeoMeta implemented, structured data validated, CWV documented                                                                                             |
 
 ## Progress Tracking
 
@@ -634,9 +725,9 @@ After receiving the subagent's response, present it to the user.
 
 ✅ **Build user auth flow** → `@node-developer` first for API, then `@frontend-nuxt` / `@frontend-react` (sequential)
 
-✅ **Redesign a page**: "The dashboard layout looks outdated, redesign it" → `@designer` first (review current design, propose redesign, create specs), then `@frontend-nuxt` / `@frontend-react` (implement from design specs)
+✅ **Redesign a page**: "The dashboard layout looks outdated, redesign it" → run full UI Pipeline: `@designer` Phase 1 (review, propose, spec), then `@frontend-nuxt` / `@frontend-react` Phase 2 (implement + impeccable polish), then `@designer` Phase 3 (QA)
 
-✅ **Fix UI/UX issues**: "The form inputs look misaligned and colors are off" → `@designer` (analyze current design, provide token/spacing fixes as spec), then `@frontend-nuxt` / `@frontend-react` (apply the fix)
+✅ **Fix UI/UX issues**: "The form inputs look misaligned and colors are off" → `@designer` Phase 1 (analyze, spec fixes), then `@frontend-nuxt` / `@frontend-react` Phase 2 (apply + polish), then `@designer` Phase 3 (verify)
 
 ✅ **Evaluate current design quality**: "Is our current UI design good?" → `@designer` (runs design audit, critique, and provides report using Impeccable design intelligence)
 
 
@@ -217,6 +217,34 @@ For every task, end with:
 - Small: one relevant check (lint / typecheck / focused test)
 - Medium+: lint + typecheck + relevant tests
 
+### Impeccable Polish Gate (Mandatory for UI Implementation)
+
+When implementing UI from design specs (Phase 2 of UI Pipeline), you MUST run these steps BEFORE marking work as `verified`:
+
+```
+1. /impeccable critique <target>   → evaluate result, catch design issues
+2. /impeccable audit <target>      → a11y, performance, responsive checks
+3. /impeccable polish <target>     → final refinement pass
+```
+
+**Purpose**: This gate ensures the implementation meets production-grade quality before handing off to `@designer` for Phase 3 (Design QA). Skipping this gate means the designer will reject the implementation and send it back.
+
+**After polish gate**: Report the impeccable critique score and any remaining issues. Then hand off to `@designer` for Design QA:
+
+```markdown
+## Phase 2 Complete
+
+### Implementation
+
+- Files: {list}
+- Impeccable critique score: {score}/4
+- Polish gate: PASS / FAIL
+
+### Handoff
+
+Handing off to @designer for Phase 3 (Design QA).
+```
+
 If commands are blocked by permissions:
 
 1. Continue non-blocked work first
@@ -254,7 +282,7 @@ If commands are blocked by permissions:
 
 ## Quality Checklist
 
-Before marking complete: code follows project conventions, TypeScript strict, loading/error/empty states handled, no console.log, organized imports, tests easy to write.
+Before marking complete: code follows project conventions, TypeScript strict, loading/error/empty states handled, no console.log, organized imports, tests easy to write. **For UI tasks**: Impeccable polish gate passed (critique + audit + polish run), handoff to `@designer` for Phase 3 QA.
 
 ---
 
 
@@ -133,6 +133,40 @@ For every task, end with:
 - Small: one relevant check (lint / typecheck / focused test)
 - Medium+: lint + typecheck + relevant tests
 
+### Impeccable Polish Gate (Mandatory for UI Implementation)
+
+When implementing UI from design specs (Phase 2 of UI Pipeline), you MUST run these steps BEFORE marking work as `verified`:
+
+```
+1. /impeccable critique <target>   → evaluate result, catch design issues
+2. /impeccable audit <target>      → a11y, performance, responsive checks
+3. /impeccable polish <target>     → final refinement pass
+```
+
+**Purpose**: This gate ensures the implementation meets production-grade quality before handing off to `@designer` for Phase 3 (Design QA). Skipping this gate means the designer will reject the implementation and send it back.
+
+**After polish gate**: Report the impeccable critique score and any remaining issues. Then hand off to `@designer` for Design QA:
+
+```markdown
+## Phase 2 Complete
+
+### Implementation
+
+- Files: {list}
+- Impeccable critique score: {score}/4
+- Polish gate: PASS / FAIL
+
+### Handoff
+
+Handing off to @designer for Phase 3 (Design QA).
+```
+
+**Quality Checklist for UI tasks**:
+
+- Code follows project conventions, TypeScript strict, states handled, no console.log
+- Impeccable polish gate passed (critique + audit + polish run)
+- Handed off to `@designer` for Phase 3 (Design QA)
+
 If commands are blocked by permissions:
 
 1. Continue non-blocked work first
 
@@ -160,9 +160,80 @@ Generate a structured design review report covering:
 - **Recommendations**: Concrete fixes (token adjustments, spacing changes, component replacements)
 - **Specs for Implementation**: If fixes are clear, provide direct specs to `@frontend-nuxt` / `@frontend-react`
 
-### Step 5: Handoff
+### Step 5: Handoff to Frontend
+
+When delegating to `@frontend-nuxt` or `@frontend-react`, provide:
+
+- Design direction summary + token references
+- Component spec with layout, spacing, colors, typography
+- All state definitions
+- Accessibility requirements (role, keyboard, focus, contrast)
+- Expected output files and verification criteria
+- Explicit DO NOTs
+- **Mention that after Phase 2 implementation, frontend will hand back to you for Phase 3 (Design QA)**
+
+### Phase 3: Design QA Protocol (Post-Implementation)
+
+After `@frontend-nuxt` or `@frontend-react` finishes Phase 2 implementation, they will hand back to you for Design QA. This is a **mandatory gate** — no UI ships without passing Design QA.
+
+#### Step 1: Load Skills
+
+- `impeccable`
+- `accessibility`
+
+#### Step 2: Inspect Live Implementation
+
+Use browser tools to view the rendered UI in its actual state. Navigate to the implemented pages/components.
 
-If the review leads to actionable fixes, hand off to the appropriate frontend agent with complete specs. If it's a pure review, deliver the report to the user and `@leader`.
+#### Step 3: Run Impeccable Critique
+
+Run `/impeccable critique <target>` on the live result to get an automated design review with scoring and anti-pattern detection.
+
+#### Step 4: Manual Verification Checklist
+
+Verify against the original design spec:
+
+- **Spec compliance**: Layout, spacing, colors, typography match spec exactly
+- **Design token usage**: Tokens used correctly, no hardcoded values
+- **All states**: Loading, error, empty, hover, focus, active, disabled
+- **Accessibility**: Contrast ratios (4.5:1), keyboard nav, focus indicators, ARIA
+- **Responsive behavior**: Works at all target breakpoints
+- **Motion/transitions**: Match spec timing, easing, reduced-motion support
+- **Content/fit**: No overflow, text wrapping correct, no widows/orphans
+
+#### Step 5: Report
+
+| Verdict     | Action                                                                                                                         |
+| ----------- | ------------------------------------------------------------------------------------------------------------------------------ |
+| **PASS ✅** | Report to `@leader`: "Design QA passed. {feature} is ready."                                                                   |
+| **FAIL ❌** | Document specific deviations, hand back to `@frontend-nuxt` / `@frontend-react` with fix list, then re-run Phase 3 after fixes |
+
+```markdown
+## Design QA Report
+
+### Feature
+
+{name}
+
+### Verdict
+
+{PASS / FAIL}
+
+### Checks
+
+- Spec compliance: ✅ / ❌ ({details})
+- Token usage: ✅ / ❌ ({details})
+- States: ✅ / ❌ ({details})
+- Accessibility: ✅ / ❌ ({details})
+- Responsive: ✅ / ❌ ({details})
+- Motion: ✅ / ❌ ({details})
+- Impeccable critique score: {score}/4
+
+### Issues to Fix (if FAIL)
+
+1. {file}:{line} — {description}
+2. {file}:{line} — {description}
+```
 
 ## Redesign Workflow
 
@@ -397,18 +468,20 @@ End every task with:
 - **Accessibility**: Key requirements
 - **Handoff / Result**: Delegation to frontend or report to user
 
-### Complex (multi-component / design system)
+### Complex (multi-component / design system) — Full Pipeline Report
 
 - **Design Analysis**: Requirements + constraints
-- **Design System**: Token definitions
+- **Design System**: Token definitions + DESIGN.md path
 - **Component Specs**: Table of components × variants × states × accessibility
-- **DESIGN.md**: Generated/updated (yes/no + path)
-- **Design QA**: Compliance, token usage, accessibility status
+- **Phase 2 Handoff**: Delegation to `@frontend-nuxt` / `@frontend-react`
+- **Phase 3 Design QA**: PASS/FAIL verdict, checklist status, remaining issues
+- **Final Status**: `pipeline_complete` / `in_progress` / `blocked`
 
 ## Verification & QA
 
 - For multi-component specs, include a QA checklist
 - For accessibility-critical components, require manual verification
+- **Phase 3 (Design QA) is mandatory** — do not skip even for small changes
 - Provide a "design QA" section after implementation
 
 ## Definition of Done