| name | iced-shadcn |
| description | Plan, build, and audit shadcn-inspired Iced components: architecture, family decomposition, and parity audits. |
| license | MIT |
| dependencies | {"required":["iced-rs"]} |
| metadata | {"author":"vanillagreen","source":"vstack","repository":"https://github.com/vanillagreencom/vstack","bugs":"https://github.com/vanillagreencom/vstack/issues","version":"1.0.0"} |
iced-shadcn
Component design skill for building shadcn Base UI-inspired components in Iced. Covers architecture decisions, family decomposition, implementation methodology, and parity audits.
Resources
ctx7 CLI
| Library | ctx7 ID | Use For |
|---|
| Iced | /websites/rs_iced_iced | Widget API, overlay system, advanced traits |
Web
| Source | URL | Use For |
|---|
| shadcn Base UI | https://ui.shadcn.com/docs/components/base/ | Component behavior truth |
| iced-shadcn crate | https://github.com/FerrisMind/shadcn-rs/tree/master/crates/iced-shadcn | Architecture patterns |
Workflows
| Workflow | When to use |
|---|
| component-plan | Planning new components, family decomposition, architecture decisions, implementation |
| parity-audit | Post-implementation audit of leaf components against Base UI reference before closure |
References
- Component families:
references/families.md
- Foundation issue shape:
references/issue-structure.md
- Parity checklist:
references/checklist.md
- Viewer page template:
references/page-template.md
- Issue guidance:
references/issue-guidance.md
Source Authority (ordered)
- shadcn Base UI docs (
https://ui.shadcn.com/docs/components/base/) — behavior truth, example coverage, interaction contracts
- Iced 0.14 docs via ctx7 (
/websites/rs_iced_iced) — framework constraints, iced::advanced widget/overlay API. Consult the iced-rs skill's widget catalog before choosing built-in vs custom Widget impl.
- Project architecture docs — overlay/menu system, token system, viewer/page ownership, widget patterns
- iced-shadcn reference crate — implementation ideas, architecture patterns. Never final authority.
Reference Crate Patterns
From iced-shadcn (43k lines, 80+ components):
- Overlay module: separate
positioning.rs, keyboard.rs, focus.rs for clean separation
- menu_primitives: shared by
dropdown_menu and context_menu
- Props + State separation: simple components use
Props struct only; complex ones add State + custom Widget impl
- Component dependency tree:
overlay → popover → combobox/hover_card/tooltip/navigation_menu; menu_primitives → dropdown_menu/context_menu
Do not copy: their theme/token system (use your project's tokens), their import structure, their lucide-icons dependency. Borrow architecture and algorithms only.
Rules
- Do not make
iced-shadcn a production dependency — reference crate is for study only
- Always use
find-docs / ctx7 before coding advanced Iced behavior (overlays, custom widgets, keyboard handling)
- Prefer the shadcn Base UI tab; use Radix only when Base UI is absent
- Mirror Base UI example headings and ordering exactly before adding local extras. Extra or missing sections require explicit mapping-table justification.
- For menus/selects/comboboxes, capture interaction semantics in the widget layer, not viewer/preview code
- Parity work must record fine-grained deviations explicitly: whole-row hit targets, separator treatment, alignment, type hierarchy, focus/outline treatment, and per-example layout gaps
- When a component family needs distinct subpart behavior (trigger/body/icon/padding/surface), define semantic component tokens and roles instead of repeatedly selecting generic globals inside the widget
- When visual treatments differ by variant or surface (plain, bordered, card, inset, etc.), model those differences in the semantic component contract instead of forcing one token set to serve every variant
- When multiple components need the same animation pattern, extract a shared motion primitive instead of embedding per-component tween logic
- Every exposed variant must map end-to-end: widget API → preview state → viewer page → tests
- Do not scope installation instructions, CLI snippets, or docs-site chrome into parity work
- Update architecture docs when work changes overlay/menu/widget patterns
- Consult the iced-rs skill's widget catalog before implementing custom
Widget/overlay::Overlay — prefer Iced built-ins per the Built-in First principle
