feat(wix-cli-auto-patterns-dashboard): add auto patterns dashboard skill

[AlonTzukermanWIX]

Summary

• Add new wix-cli-auto-patterns-dashboard skill for declarative CRUD dashboard pages (single-collection management with standard table/grid views and forms)
• Update wix-cli-orchestrator SKILL.md with auto-patterns routing logic and decision tree
• Add skill to README.md available skills table and .claude-plugin/plugin.json skills array

Test plan

• Verify wix-cli-auto-patterns-dashboard skill loads correctly in Claude Code
• Verify orchestrator routes to auto-patterns for simple CRUD use cases
• Verify orchestrator still routes to wix-cli-dashboard-page for complex use cases

🤖 Generated with Claude Code

[mirivoWix]

Update — actually typechecked the snippets against @wix/auto-patterns@latest.

Built a harness (TS strict, real @wix/auto-patterns + @wix/patterns + @wix/design-system types) and compiled both example-patterns.json (as AppConfig) and the resolver shapes from each markdown file. Retracting my earlier resolved-action.md line-7 comment about icon being optional — the real ResolvedAction.icon is required, the docs match. Deleted that comment.

What the typecheck did surface, in order of impact:

1. action-cell.md collapses two distinct resolver types into one. The docs declare a single CustomActionCellResolver returning ResolvedAction. The real package exports two:

   • CustomActionCellPrimaryActionResolver → ResolvedActionCellPrimaryAction (= Omit<ResolvedAction, 'icon'> with optional prefixIcon / suffixIcon)
   • CustomActionCellSecondaryActionResolver → ResolvedAction

   A user following the docs to write a primary-action resolver will use icon, but the real type doesn't accept icon on primary-cell actions — it expects prefixIcon / suffixIcon. Worth either documenting both resolver types or steering primary actions to prefixIcon.

2. resolved-action.md line 9 marks biName as required, but real type is biName?: string. The docs' "MUST include biName" is a project convention, not enforced by the type. Either say so explicitly or note that the type is optional but the convention is to always set it.

3. resolved-action.md line 13 narrows skin to 'standard' | 'inverted' | 'premium' | 'dark' | 'destructive'. Real type is skin?: string. Narrowing in docs is fine for guidance; just worth flagging that the type itself is wider.

4. resolved-action.md line 8 declares onClick: () => void | Promise<void>; real is () => void. Async handlers still typecheck (TS void-return bivariance), so this is a documentation accuracy point, not a type error in practice.

5. ✅ example-patterns.json cast as AppConfig typechecks cleanly against the real AppConfig — the cast is needed only because import ... from '*.json' widens string-literal discriminators.

Net: snippets are mostly type-safe in spirit, but the inline type definitions in the markdown drift from the real package types in the four spots above. Long-term fix is a proper typecheck harness in CI; short-term fix is reconciling those four declarations with the published @wix/auto-patterns types.

[mirivoWix]

Still reviewing

[mirivoWix]

Please add more info about auto patters (e.g faster and cheaper way... )
And also add about iteration (e.g pattern.json...)

[AlonTzukermanWIX]

Done — moved the decision criteria into SKILL.md with the why (declarative patterns.json, faster to author, iterate by editing JSON) and disqualifiers inline. See skills/wix-app/SKILL.md:63-64.

[mirivoWix]

I think you should move it into SKILL.md

[AlonTzukermanWIX]

Done — "When to Use" section dropped from this file; criteria now live in SKILL.md so the model self-routes without needing to load this reference.

[mirivoWix]

This is not how we write a dashboard page extension, please go over the dashboard page extension, for example:

### Step 1: Create Page-Specific Extension File

Each dashboard page requires an `extensions.ts` file in its folder:

**File:** `src/extensions/dashboard/pages/<page-name>/extensions.ts`

```typescript
import { extensions } from "@wix/astro/builders";

export const dashboardpageMyPage = extensions.dashboardPage({
  id: "{{GENERATE_UUID}}",
  title: "My Page",
  routePath: "my-page",
  component: "./extensions/dashboard/pages/my-page/page.tsx",
});

[mirivoWix]

Also add about UUID Generation same as in dashboard page

[mirivoWix]

Can you maybe also add how the directory should look like (e.g patterns.json, page.tsx, extensions.ts ...) ? we have it in our other extensions refernces.

[AlonTzukermanWIX]

Done — rewrote the snippet to use extensions.dashboardPage() from @wix/astro/builders matching the canonical pattern in DASHBOARD_PAGE.md. Also added directory-layout block and UUID generation note in the same edit (replying to your follow-ups on this thread).

[mirivoWix]

I think you can put it in AUTO_PATTERNS_DASHBOARD.md, it's very short, and adding us more tool calls to read this very short file

[AlonTzukermanWIX]

Done — inlined as a new "Core Rules" section at the top of AUTO_PATTERNS_DASHBOARD.md and deleted the file. Topic-index row removed too.

[AlonTzukermanWIX]

Thanks for the typecheck pass — addressed all four findings:

1. action-cell.md — split into CustomActionCellPrimaryActionResolver (returns ResolvedActionCellPrimaryAction, uses prefixIcon/suffixIcon) and CustomActionCellSecondaryActionResolver (returns ResolvedAction). Canonical example now shows both forms with the correct icon prop for each.
2. resolved-action.md:9 — biName?: string with note that the project convention is to always set it.
3. resolved-action.md:13 — skin?: string with the recommended values listed inline.
4. resolved-action.md:8 — onClick: () => void with note about TS bivariance.

Force-pushed as 4d72098.

[mirivoWix]

Make it more stronger, add more description, i tried to run it 4 times and it keep ignoring AUTO_PATTERNS_DASHBOARD.md and not loading it at all.
Another solution is maybe move it into the Dashboard Page file? and there add explanation about auto patterns.

[AlonTzukermanWIX]

Routing fix for real-world feedback: agents weren't picking auto-patterns unless the user explicitly said "use auto patterns". Promoted auto-patterns from suggestion to MANDATORY default for single-collection CRUD admin pages (with disqualifiers as the explicit opt-out).

5 surgical edits across 2 files:

• SKILL.md: 🛑 Auto-Patterns Gate sub-step in MANDATORY WORKFLOW Step 1; new anti-pattern row; Decision Flow Admin sentence flipped to lead with auto-patterns; Quick Decision Helper restructured to put auto-patterns first.
• DASHBOARD_PAGE.md: STOP banner at the top redirecting to AUTO_PATTERNS_DASHBOARD.md when the use case fits.

Disqualifiers (multi-collection joins / custom business logic / embedded scripts / external APIs / explicit user request for custom React) are listed inline at every gate so the model evaluates them before descending. Force-pushed as 76444e5.

[AlonTzukermanWIX]

Iteration-flow fix for second round of real-world feedback: when iterating on an existing auto-patterns page, agents were editing page.tsx directly to add banners/headers instead of using the override pattern (custom-slots-override.md etc.).

3 edits, same shape as the previous routing fix:

• SKILL.md: 🛑 Iteration Gate sub-step in MANDATORY WORKFLOW Step 1 (detect sibling patterns.json before editing any dashboard page file → use AUTO_PATTERNS_DASHBOARD.md Part B + the override topic-index).
• SKILL.md: anti-pattern row for editing page.tsx to add UI when patterns.json exists.
• AUTO_PATTERNS_DASHBOARD.md Part B: STOP banner reinforcing "UI changes go through overrides, not page.tsx edits".

Force-pushed as f36732f.

[mirivoWix]

We have switched to non-interactive mode, so please delete this. Make sure Auto Patterns generates extensions.ts with commands instead of writing it manually (see #196)

[AlonTzukermanWIX]

Done in 7be38c8 — replaced the manual directory block with a new Step 1: Scaffold the Dashboard Page that uses wix generate --params '{"extensionType":"DASHBOARD_PAGE",...}'. The CLI now creates the folder, page.tsx, builder file, UUID, and src/extensions.ts registration; the "resulting structure" snippet is now just orientation, not something to hand-create.

[mirivoWix]

We have switched to non-interactive mode, so please delete this. Make sure Auto Patterns generates extensions.ts with commands instead of writing it manually (see #196)

[AlonTzukermanWIX]

Done in 7be38c8 — dropped the manual "Create extensions.ts" and "Register the extension" sub-steps entirely. The page is scaffolded via wix generate (new Step 1), and the generator script's --output now targets that scaffolded folder, overwriting the stub page.tsx and adding patterns.json. No hand-written registration anymore — aligned with #196.

[mirivoWix]

Bug: auto-patterns scaffolding leaves a stray default component and the registered component is never the auto-patterns wrapper

When the skill runs wix generate to scaffold a new dashboard page, the CLI creates <page-name>.tsx (e.g. shift-manager.tsx) as the component stub and writes extensions.ts pointing to that file. The generator script then writes page.tsx (the actual auto-patterns wrapper) into the same folder — but extensions.ts is never updated, so the registered component remains the empty EmptyState stub, not the auto-patterns app.

End result: two component files exist side-by-side:

src/extensions/dashboard/pages/shift-manager/
├── shift-manager.ts        # builder file — component still points to shift-manager.tsx
├── shift-manager.tsx       # original CLI stub with EmptyState (registered but wrong)
├── page.tsx                # auto-patterns wrapper (correct, but never registered)
└── patterns.json           # declarative config

The patterns.json and page.tsx are correct, but the registered component in extensions.ts (shift-manager.tsx) is the boilerplate — so the dashboard shows an empty page instead of the auto-patterns UI.

[mirivoWix]