feat: import berd repository

.agents/checks/design-system-tokens.md

@@ -0,0 +1,72 @@
+---
+name: design-system-tokens
+description: Ensure UI color changes use the Berd shadcn-first token contract instead of raw palette values or broad custom tokens.
+severity-default: medium
+tools: [Grep, Read]
+---
+
+Review changed frontend styling for design-system token drift.
+
+Use `docs/color-token-mapping.md` as the source of truth for how colors should
+be chosen. The short version:
+
+- Shared UI should use shadcn semantic tokens first: `background`,
+  `foreground`, `card`, `popover`, `muted`, `accent`, `primary`,
+  `secondary`, `destructive`, `border`, `input`, and `ring`.
+- Sidebar rows and text should use the shadcn sidebar state tokens:
+  `sidebar-foreground`, `sidebar-accent`, `sidebar-border`, and
+  `sidebar-ring`. Floating chrome shells (nav panes, right rail, top bar)
+  paint `card-glass`; the bare `sidebar` shell token is retired.
+- Berd-specific tokens are allowed only for product-specific surfaces that do
+  not map cleanly to shadcn, such as `canvas-*`, `surface-composer`,
+  `surface-editor-panel`, `message-user-bg`, `chip-*-bg`, `chip-*-fg`,
+  `success`, `warning`, `info`, and clock/status/chart tokens.
+
+## What to flag
+
+- **Raw Tailwind palette utilities** like `text-gray-*`, `bg-zinc-*`,
+  `border-neutral-*`, `ring-blue-*`, `fill-slate-*`, or `stroke-stone-*`.
+  Suggest the closest semantic token instead, such as `text-muted-foreground`,
+  `bg-accent`, `border-border`, `border-input`, or `ring-ring`.
+- **Deleted broad Berd token families** such as `background-default`,
+  `background-hover`, `text-default`, `text-muted`, `border-default`,
+  `border-focus`, `surface-card`, `surface-overlay`, `surface-chrome`,
+  `sidebar-nav-bg-hover`, or `sidebar-nav-fg` — and the retired shell tokens
+  `bg-sidebar`/`--sidebar`, `sidebar-navigation-panel-bg`,
+  `canvas-project-tint`, and `surface-agent-profile-bg`. Suggest the mapping
+  in `docs/color-token-mapping.md`.
+- **New broad custom color tokens** that duplicate shadcn concepts. For
+  example, do not introduce a new token that means "normal page background",
+  "hover gray", "secondary text", "card surface", "popover surface",
+  "default border", "input border", or "focus ring"; use shadcn tokens.
+- **Berd extension tokens without a narrow product job.** If a new token is
+  added, it should name a real Berd-specific surface or identity role, and the
+  PR should update both `docs/color-token-mapping.md` and
+  `scripts/design-system-tokens.mjs`.
+- **Component-level one-off color decisions** where the same role already
+  exists in a shared UI primitive. Prefer adjusting the shared primitive or
+  design token over scattering local styling.
+
+## What not to flag
+
+- Approved shadcn token utilities such as `bg-background`, `text-foreground`,
+  `bg-card`, `bg-popover`, `bg-muted`, `bg-accent`, `bg-primary`,
+  `bg-secondary`, `bg-destructive`, `border-border`, `border-input`, or
+  `ring-ring`.
+- Approved sidebar state utilities such as `text-sidebar-foreground`,
+  `hover:bg-sidebar-accent`, `border-sidebar-border`, and
+  `ring-sidebar-ring`. The pane shell itself is `bg-card-glass`, not
+  `bg-sidebar`.
+- Approved narrow Berd extension utilities documented in
+  `docs/color-token-mapping.md`, such as `bg-canvas-base`,
+  `bg-surface-composer`, `bg-message-user-bg`, chip tokens, status tokens, and
+  clock/chart tokens.
+- Opacity modifiers on semantic tokens when they preserve the role, such as
+  `border-border/70`, `bg-destructive/10`, or `text-muted-foreground/70`.
+
+## Review posture
+
+Only leave comments that are actionable. Name the specific semantic token or
+shared primitive the author should use. If the automated
+`design-system:tokens` check already catches the issue, mention that command as
+the quick local verification path rather than restating the entire token system.

.agents/skills/assistive-ux/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: assistive-ux
+description: Use when adding, reviewing, designing, testing, or managing Assistive UX moments in Berd, including discover, suggest, and autoApply guidance, adaptive settings, behavior signals, retirement rules, or changes under src/shared/assistive-ux.
+---
+
+# Assistive UX
+
+Use this skill for Berd product intelligence moments that teach,
+suggest, or adapt settings based on user behavior.
+
+Before changing code, read `docs/assistive-ux.md`. Treat that doc as the source
+of product intent and architecture.
+
+## Core Rule
+
+Keep assistive state separate from user settings:
+
+```text
+User settings answer: what should the product do?
+Assistive UX answers: what has the app shown, observed, accepted, retired, or applied?
+```
+
+Do not store guidance lifecycle state inside a feature setting. Do not use
+assistive state as the source of truth for product behavior.
+
+## Types
+
+- `discover`: teaches that a control, setting, or capability exists. It should
+  not change settings.
+- `suggest`: notices a repeated behavior and asks before changing a setting.
+- `autoApply`: changes a reversible local setting only after strong evidence,
+  then explains the change and offers undo.
+
+Use `autoApply` conservatively. Never auto-apply changes involving secrets,
+credentials, permissions, destructive actions, provider setup, billing-like
+behavior, or hard-to-reverse choices.
+
+## Implementation Workflow
+
+1. Define or update the rule in `src/shared/assistive-ux/registry.ts`.
+2. Keep lifecycle reads and writes in `src/shared/assistive-ux/runtime.ts` and
+   `src/shared/assistive-ux/state.ts`.
+3. Render the moment from the relevant feature surface.
+4. Retire the moment when the user accepts it, dismisses it, sees it enough
+   times, or manually changes the related setting.
+5. If the moment changes a setting, call the setting's public setter and provide
+   an undo path when the change is automatic.
+6. Keep stored signals coarse. Do not store chat text, file paths, provider
+   secrets, credentials, or message contents.
+
+## UX Checklist
+
+Before shipping, confirm:
+
+- The moment appears close to the behavior it helps with.
+- The copy explains the next action without selling the feature.
+- The primary workflow still has visual priority.
+- The moment has a clear retirement path.
+- Repeated exposure is capped.
+- Manual setting changes stop or reset related guidance.
+- The behavior works in light and dark themes.
+
+## Testing
+
+Add focused tests for:
+
+- fresh eligibility
+- shown-count updates
+- max-show expiration
+- acceptance or dismissal retirement
+- related setting-change retirement
+- invalid localStorage fallback
+- any feature surface that renders or applies the moment
+
+For broad behavior, add Playwright coverage only when the flow benefits from
+real app navigation or persistence across reloads.

.agents/skills/berdctl-new-command/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: berdctl-new-command
+description: Use when adding, extending, modifying, or removing berdctl commands, verbs, nouns, schemas, help text, or any of the berdctl surface.
+---
+
+# berdctl command changes
+
+One command is one renderer module. Descriptors are the source for zod
+validation, TS input types, CLI help, and generated contract JSON. Background:
+`docs/berdctl-architecture.md`.
+
+## Rules
+
+- Verbs must be UI-visible. Prefer reversible mutations, but one-way visible
+  product actions like creating a session or sending a prompt are allowed.
+  Delete, bulk, silent, invisible, or broadly destructive work requires
+  auth/confirmation design review.
+- Put bounds in zod; clap mirrors them.
+- Keep descriptors import-pure. Import stores, Tauri APIs, navigation,
+  providers, and caches only inside `execute`/`precheck`.
+- Do not hand-edit generated contract JSON.
+- Keep the broker command-agnostic; normal command changes do not touch
+  `src-tauri/plugins/berdctl/`.
+- Breaking wire reshapes bump both discovery.rs constants and the contract
+  mirror. New commands and optional fields are not reshapes.
+
+## Workflow
+
+- Add commands with `just new-command <noun> <verb>`.
+- Implement `src/features/berdctl/commands/impl/<verbNoun>.ts` with:
+  `.strict()` schema, `.describe()` on every field, `summary`, `description`,
+  `helpFooter`, safety metadata, optional `precheck`, and `execute`.
+- Update inventories only when needed: `registry.ts` group `cli.about`,
+  top-level help pins in `tree.rs`, and `distro/skills/berdctl/SKILL.md` for
+  overview changes.
+- Run `pnpm generate:berdctl-contract`,
+  `pnpm vitest run src/features/berdctl`, and `cargo test -p berdctl` from
+  `src-tauri/`.
+- Before review, confirm the verb is UI-visible and either reversible or a
+  direct visible product action, help is complete, error messages name the
+  fixing command, artifacts are regenerated, and tests cover the behavior.
+
+Keep CLI shapes expressible by the generated field walker. If a requested
+operation needs an explicit null or another shape that generic flags cannot
+represent safely, model it as a separate command action instead of adding
+command-specific Rust mapping. Example: use `session move --project-id <id>`
+for moving into a project and `session clear-project` for moving out.