{"owner":"rajnandan1","repo":"kener","hasSkills":true,"totalSkillsCount":7,"totalTokensCount":5929,"categories":["anthropic-skill","root-instruction","claude-rule","subagent-persona"],"hasMcp":false,"mcpConfig":null,"found":[".claude/skills/documentation-writer/SKILL.md",".claude/skills/svelte-code-writer/SKILL.md","AGENTS.md","CLAUDE.md",".agents/skills/ss-shadcn-svelte/SKILL.md",".claude/skills/tailwindcss/SKILL.md","docs/agents/issue-tracker.md"],"skills":{".claude/skills/documentation-writer/SKILL.md":"---\nname: documentation-writer\ndescription: Specialized skill for creating and editing high-quality Kener documentation. MUST be used whenever creating or editing documentation files in the src/routes/(docs)/docs/content/ directory or updating docs.json navigation.\n---\n\n# Documentation Writer\n\nUse this skill for all docs edits in `src/routes/(docs)/docs/content/` and when updating docs navigation in `src/routes/(docs)/docs.json`.\n\n## Non-negotiable rules\n\n1. **Be concise**: remove repetition and background that does not help the user complete a task.\n2. **Be actionable**: prioritize “what to do” over theory.\n3. **One source of truth**: if another page already has details, link to it instead of duplicating.\n4. **Preserve structure**: keep valid frontmatter and heading anchor IDs.\n5. **Keep examples copyable**: minimal, tested-looking, and directly relevant.\n6. **Search before writing**: always check if the content already exists in some form before adding new sections or pages.\n7. **Check Relevant Code**: Search the codebase inside `src/` for any relevant code, comments, or tests that can inform the documentation content and ensure accuracy.\n\n## Docs config model (current)\n\n`docs.json` is versioned. Sidebar lives inside tabs:\n\n- `versions[].content.navigation.tabs[].sidebar`\n- Sidebar groups contain `pages`\n- Page paths use `content` (legacy `slug` may still appear in older content)\n\nWhen adding a new doc page, add it to the appropriate tab sidebar path.\n\n## Versioned link policy (mandatory)\n\n- For v4 docs content, internal links MUST use explicit v4 paths: `/docs/v4/...`.\n- Do not use unversioned shortcuts like `/docs/alerting/...` in v4 pages.\n- Before finalizing, verify every internal link in edited files resolves to the intended version.\n\n## Required page format\n\n```markdown\n---\ntitle: Page Title\ndescription: One-line summary of user outcome\n---\n```\n\n- Use custom anchors for H2/H3 headings: `## Section {#section}`\n- Use GitHub admonitions only when needed: `[!NOTE]`, `[!IMPORTANT]`, `[!WARNING]`, `[!CAUTION]`, `[!TIP]`\n- Prefer short sections and short lists\n\n## Preferred structure (default)\n\n1. Short intro (1–2 sentences)\n2. Quick setup / minimum config\n3. Required variables/options table\n4. Verification step\n5. Top troubleshooting items\n\nOnly add extra sections if they materially improve task completion.\n\n## Keep docs lean\n\nRemove or avoid:\n\n- Multiple near-identical examples\n- Long conceptual explainers\n- Platform-by-platform repetition unless behavior differs\n- Large checklists that restate earlier content\n\n## Editing workflow\n\n1. Read the whole target document.\n2. Compress verbose sections first.\n3. Keep critical caveats and breaking notes.\n4. Ensure internal links and anchors still work.\n5. If adding files, update `docs.json` navigation in the correct version/tab.\n\n## Review checklist\n\n- [ ] Title/description frontmatter exists\n- [ ] Key steps are clear and copyable\n- [ ] Content is concise and non-duplicative\n- [ ] Headings keep stable custom anchors\n- [ ] Navigation updated (if new page)\n- [ ] Internal links point to correct paths\n- [ ] v4 pages use `/docs/v4/...` internal links (no unversioned `/docs/...` shortcuts)\n- [ ] No outdated or irrelevant content remains\n- [ ] Admonitions used appropriately for important notes\n",".claude/skills/svelte-code-writer/SKILL.md":"---\nname: svelte-code-writer\ndescription: CLI tools for Svelte 5 documentation lookup and code analysis. MUST be used whenever creating or editing any Svelte component (.svelte) or Svelte module (.svelte.ts/.svelte.js). If possible, this skill should be executed within the svelte-file-editor agent for optimal results.\n---\n\n# Svelte 5 Code Writer\n\n## CLI Tools\n\nYou have access to `@sveltejs/mcp` CLI for Svelte-specific assistance. Use these commands via `npx`:\n\n### List Documentation Sections\n\n```bash\nnpx @sveltejs/mcp list-sections\n```\n\nLists all available Svelte 5 and SvelteKit documentation sections with titles and paths.\n\n### Get Documentation\n\n```bash\nnpx @sveltejs/mcp get-documentation \",,...\"\n```\n\nRetrieves full documentation for specified sections. Use after `list-sections` to fetch relevant docs.\n\n**Example:**\n\n```bash\nnpx @sveltejs/mcp get-documentation \"$state,$derived,$effect\"\n```\n\n### Svelte Autofixer\n\n```bash\nnpx @sveltejs/mcp svelte-autofixer \"\" [options]\n```\n\nAnalyzes Svelte code and suggests fixes for common issues.\n\n**Options:**\n\n- `--async` - Enable async Svelte mode (default: false)\n- `--svelte-version` - Target version: 4 or 5 (default: 5)\n\n**Examples:**\n\n```bash\n# Analyze inline code (escape $ as \\$)\nnpx @sveltejs/mcp svelte-autofixer ''\n\n# Analyze a file\nnpx @sveltejs/mcp svelte-autofixer ./src/lib/Component.svelte\n\n# Target Svelte 4\nnpx @sveltejs/mcp svelte-autofixer ./Component.svelte --svelte-version 4\n```\n\n**Important:** When passing code with runes (`$state`, `$derived`, etc.) via the terminal, escape the `$` character as `\\$` to prevent shell variable substitution.\n\n## Workflow\n\n1. **Uncertain about syntax?** Run `list-sections` then `get-documentation` for relevant topics\n2. **Reviewing/debugging?** Run `svelte-autofixer` on the code to detect issues\n3. **Always validate** - Run `svelte-autofixer` before finalizing any Svelte component\n","AGENTS.md":"# Kener — Agent Instructions\n\n## Run\n\nDev needs Redis on `REDIS_URL`: `cp .env-min.example .env`, then `docker compose -f docker-compose.dev.yml up -d redis`. `npm run dev` migrates and seeds the database before it starts. `npm run build` leaves out the docs site in `src/routes/(docs)/`; `npm run build-with-docs` keeps it.\n\n## Finish a Change\n\n1. Put a test next to new server logic (`apiCall.ts` and `apiCall.test.ts`). Name a component test `.svelte.test.ts` so it runs in Chromium.\n2. A change that reads, writes, or updates the database, or adds a migration or seed, must pass on SQLite, PostgreSQL, and MySQL. `npm test` runs on SQLite only. Run the change on the other two as the Database section of `CODING_STANDARDS.md` shows.\n3. When the change alters what a user sees or can do, update every text that describes the old behavior: the docs in `src/routes/(docs)/docs/content/v4/` and the help text in `.svelte` files. Search all of `src/routes` for the setting key and its UI label, for example `rg -i 'is_hidden|hidden in status page|hidden monitor' src/routes`.\n4. Format only the files you changed: `npx prettier --write `. Some files elsewhere are not formatted yet.\n5. Run `npm run check` and `npm test` until both pass. Run a single test through the npm scripts, which set `TZ=UTC`: `npm run test:server -- `.\n\n## Ask First\n\nAsk the maintainer before you add a dependency, change the database schema or the `/api/v4` request and response shapes, or edit `.github/workflows/`, `Dockerfile`, or `docker-compose*.yml`.\n\n## Guides\n\n- **Coding standards**: read `CODING_STANDARDS.md` before you write or review code that touches the database, a migration or seed, a timestamp, or an API route.\n- **Skills**: read the matching `.claude/skills//SKILL.md` before you edit a `.svelte` or `.svelte.ts` file (`svelte-code-writer`), the docs site in `src/routes/(docs)/` (`documentation-writer`), Tailwind classes (`tailwindcss`), or `src/lib/components/ui/` (`ss-shadcn-svelte`).\n- **Monitor types**: copy the closest existing type into each file where `rg -il src` finds it. A type with no branch in `src/lib/server/services/service.ts` falls through to `NoneCall`: it runs no checks, reports no error, and passes `npm run check`.\n- **Locales**: the app loads every `src/lib/locales/{code}.json` with no registration. `node scripts/check-translations.js` writes each locale's missing and unused keys to `translation-report.json`.\n- **Environment variables**: `src/routes/(docs)/docs/content/v4/setup/environment-variables.md` documents each one. Add a new one there.\n- **Issues**: read `docs/agents/issue-tracker.md` before you create, read, or update a GitHub issue in `rajnandan1/kener`, and `docs/agents/triage-labels.md` before you label one.\n- **Domain docs**: read `docs/agents/domain.md` before you name a domain concept or record an architecture decision.\n","CLAUDE.md":"# CLAUDE.md\n\n@AGENTS.md\n",".agents/skills/ss-shadcn-svelte/SKILL.md":"---\nname: ss-shadcn-svelte\ndescription: >\n Use shadcn-svelte components in SvelteKit projects. Detects whether the current project is a SvelteKit\n app with shadcn-svelte installed, lists available components, and provides access to full component\n documentation via the official llms.txt. Helps choose the right UI components for the job — buttons,\n forms, dialogs, tables, charts, and more — following shadcn-svelte best practices.\n Use this skill whenever the user is working in a SvelteKit project and wants to: add UI components,\n build forms, create dialogs or modals, add a data table, use a date picker, build a sidebar or\n navigation, add charts, use a combobox or select, create an alert or toast notification, or generally\n build UI with pre-built accessible components. Also trigger when the user mentions \"shadcn\", \"shadcn-svelte\",\n \"bits-ui\", or asks about available components in their Svelte project.\n---\n\n# shadcn-svelte — Component-Aware Svelte UI Assistant\n\nUse the right shadcn-svelte components when building UI in SvelteKit projects. This skill detects your project setup, shows what's available, and gives you access to full component documentation.\n\n## Prerequisites\n\nThe project must be a SvelteKit app with shadcn-svelte initialized:\n\n```bash\n# Initialize shadcn-svelte in an existing SvelteKit project\nnpx shadcn-svelte@latest init\n```\n\n## How to use\n\n### Step 1: Detect project setup\n\nRun the detection script to verify this is a SvelteKit project with shadcn-svelte and see which components are already installed:\n\n```bash\nbash /scripts/detect.sh .\n```\n\nThis will:\n- Confirm it's a SvelteKit project (checks for `svelte.config.js/ts` and `@sveltejs/kit` in package.json)\n- Confirm shadcn-svelte is installed (checks for `components.json`, `bits-ui`, or `shadcn-svelte` in package.json)\n- List all currently installed components in the project's UI directory\n- Provide the documentation URL\n\nIf the script exits with code 1, the project either isn't SvelteKit or doesn't have shadcn-svelte — do not proceed with shadcn-svelte components in that case.\n\n### Step 2: Read the component documentation\n\nThe full component documentation for LLMs is available at:\n\n```\nhttps://www.shadcn-svelte.com/llms.txt\n```\n\nFetch this URL to get a structured index of all available components organized by category, with links to individual component documentation pages (in `.md` format).\n\nWhen you need to use a specific component, read its individual documentation page from the links provided in `llms.txt`. Each component doc includes:\n- Import statements and usage examples\n- Available props, events, and slots\n- Variants and configuration options\n- Accessibility information\n\n### Step 3: Use the right component for the job\n\nWhen building UI, follow this decision process:\n\n1. **Run detection** to confirm shadcn-svelte is available and see installed components\n2. **Fetch llms.txt** to see all available components\n3. **Read the specific component docs** for the components you plan to use\n4. **Check if the component is installed** — if not, add it:\n ```bash\n npx shadcn-svelte@latest add \n ```\n5. **Import and use the component** following the documentation patterns\n\n### Component categories\n\nshadcn-svelte components are organized into these categories:\n\n| Category | Components |\n|----------|-----------|\n| **Layout** | Aspect Ratio, Collapsible, Resizable, Scroll Area, Separator, Sidebar |\n| **Form & Input** | Button, Calendar, Checkbox, Combobox, Date Picker, Input, Input OTP, Label, Radio Group, Range Calendar, Select, Slider, Switch, Textarea, Toggle, Toggle Group |\n| **Data Display** | Accordion, Avatar, Badge, Card, Carousel, Chart, Table, Data Table |\n| **Feedback** | Alert, Alert Dialog, Progress, Skeleton, Sonner (Toast) |\n| **Overlay** | Context Menu, Dialog, Drawer, Dropdown Menu, Hover Card, Menubar, Popover, Sheet, Tooltip |\n| **Navigation** | Breadcrumb, Command, Pagination, Tabs |\n| **Typography** | Typography |\n\n### Adding new components\n\n```bash\n# Add a single component\nnpx shadcn-svelte@latest add button\n\n# Add multiple components\nnpx shadcn-svelte@latest add button card dialog\n\n# List all available components\nnpx shadcn-svelte@latest add\n```\n\n### Import patterns\n\nComponents are typically imported from the project's `$lib/components/ui` directory:\n\n```svelte\n\n```\n\nSome components use namespace imports (with `* as`) when they have multiple sub-components (Card, Dialog, Sheet, Table, etc.), while simpler components use named imports (Button, Input, Badge, etc.).\n\n## Important guidelines\n\n- **Always run detection first** before suggesting shadcn-svelte components\n- **Always read component docs** before using a component — don't guess at props or patterns\n- **Check installed components** and add missing ones before importing\n- **Use the project's configured path** — the components directory may vary based on `components.json` configuration\n- **Follow Svelte 5 patterns** — shadcn-svelte uses runes (`$state`, `$derived`, `$effect`) and snippet-based composition\n- **Prefer composition** — shadcn-svelte components are designed to be composed together, not used as monolithic blocks\n",".claude/skills/tailwindcss/SKILL.md":"---\nname: tailwindcss\ndescription: Tailwind CSS v4 utility-first styling patterns including responsive design, dark mode, and custom configuration. Use when styling with Tailwind, adding utility classes, configuring Tailwind, setting up dark mode, or customizing the theme.\nuser-invokable: false\nmetadata:\n category: styling\n---\n\n# Tailwind CSS v4 Development Guidelines\n\nBest practices for using Tailwind CSS v4 utility classes effectively.\n\n**Note**: Tailwind CSS v4 (released January 2025) uses a CSS-first configuration approach. If you need v3 compatibility, tailwind.config.js is still supported.\n\n## Core Principles\n\n1. **Utility-First**: Use utility classes instead of custom CSS\n2. **Mobile-First**: Design for mobile, then scale up with responsive modifiers\n3. **Component Extraction**: Extract repeated patterns into components\n4. **Consistent Spacing**: Use Tailwind's spacing scale\n5. **Custom Configuration**: Extend the default theme for brand consistency\n\n## Basic Utilities\n\n### Layout\n\n```tsx\n// Flexbox\n
\n
Content
\n
Sidebar
\n
\n\n// Grid\n
\n
1
\n
2
\n
3
\n
\n\n// Positioning\n
\n
Badge
\n
\n```\n\n### Spacing\n\n```tsx\n// Padding and Margin\n
{/* padding: 1rem, margin: 0.5rem */}\n
{/* padding-x: 1.5rem, padding-y: 1rem */}\n
{/* margin-top: 2rem, margin-bottom: 1rem */}\n\n// Space between children\n
{/* margin-bottom on all but last child */}\n
Item 1
\n
Item 2
\n
\n```\n\n### Typography\n\n```tsx\n

Heading

\n

\n Paragraph text with comfortable line height.\n

\nLabel\n```\n\n### Colors\n\n```tsx\n// Text colors\n

Text

\n\n// Background colors\n
Button
\n\n// Border colors\n
Box
\n```\n\n## Responsive Design\n\n### Breakpoints\n\n```tsx\n// Mobile-first responsive classes\n
\n {/* Full width on mobile, half on medium screens, third on large */}\n
\n\n

\n {/* Responsive text sizes */}\n

\n\n
\n {/* Responsive grid */}\n
\n```\n\n### Container\n\n```tsx\n
\n {/* Centered container with horizontal padding */}\n
\n\n
\n {/* Responsive container padding */}\n
\n```\n\n## Component Patterns\n\n### Button\n\n```tsx\n\n\n// Variants\n\n```\n\n### Card\n\n```tsx\n
\n \"\"\n
\n

Card Title

\n

Card content goes here.

\n
\n
\n```\n\n### Form Input\n\n```tsx\n
\n \n \n

We'll never share your email.

\n
\n```\n\n## State Variants\n\n### Hover, Focus, Active\n\n```tsx\n\n\n\n Link\n\n```\n\n### Group Hover\n\n```tsx\n
\n \n

Hover the container

\n
\n```\n\n### Disabled\n\n```tsx\n\n```\n\n## Dark Mode\n\n```css\n/* Tailwind v4: Configure in app/globals.css */\n@import \"tailwindcss\";\n\n@media (prefers-color-scheme: dark) {\n /* Or use class-based: .dark */\n}\n```\n\n```tsx\n// Usage (same as v3)\n
\n

Title

\n

Description

\n
\n```\n\n## Custom Styles\n\n### Arbitrary Values\n\n```tsx\n
{/* Custom top value */}\n
{/* Custom color */}\n
{/* Custom grid template */}\n```\n\n### @apply Directive\n\n```css\n/* components/button.css */\n.btn-primary {\n @apply rounded-md bg-blue-600 px-4 py-2 font-medium text-white;\n @apply hover:bg-blue-700 focus:ring-2 focus:ring-blue-500 focus:outline-none;\n @apply disabled:cursor-not-allowed disabled:opacity-50;\n}\n```\n\n## Configuration\n\n### Tailwind v4: CSS-First Configuration\n\n```css\n/* app/globals.css */\n@import \"tailwindcss\";\n\n@theme {\n /* Custom colors */\n --color-brand-50: #eff6ff;\n --color-brand-100: #dbeafe;\n --color-brand-900: #1e3a8a;\n\n /* Custom spacing */\n --spacing-128: 32rem;\n\n /* Custom fonts */\n --font-family-sans: \"Inter\", sans-serif;\n\n /* Custom breakpoints */\n --breakpoint-3xl: 1920px;\n}\n```\n\n### Tailwind v3 Config (Still Supported)\n\n```javascript\n// tailwind.config.js (optional in v4)\nmodule.exports = {\n content: [\"./app/**/*.{js,ts,jsx,tsx,mdx}\", \"./components/**/*.{js,ts,jsx,tsx,mdx}\"],\n theme: {\n extend: {\n colors: {\n brand: {\n 50: \"#eff6ff\",\n 100: \"#dbeafe\",\n 900: \"#1e3a8a\"\n }\n },\n spacing: {\n 128: \"32rem\"\n },\n fontFamily: {\n sans: [\"Inter\", \"sans-serif\"]\n }\n }\n },\n plugins: [require(\"@tailwindcss/forms\"), require(\"@tailwindcss/typography\")]\n}\n```\n\n## Plugins\n\n### Official Plugins\n\n```bash\nnpm install @tailwindcss/forms\nnpm install @tailwindcss/typography\nnpm install @tailwindcss/aspect-ratio\nnpm install @tailwindcss/container-queries\n```\n\n```tsx\n// @tailwindcss/forms\n\n\n// @tailwindcss/typography\n
\n

Article Title

\n

Content...

\n
\n```\n\n## Performance\n\n### Automatic Content Detection\n\nTailwind v4 automatically detects and scans all template files - no `content` configuration needed.\n\n### Build Performance\n\nTailwind v4 delivers 3.5x faster full builds (~100ms) compared to v3 using modern CSS features like `@property` and `color-mix()`.\n\n**Browser Requirements**: Safari 16.4+, Chrome 111+, Firefox 128+\n\n## Common Patterns\n\n### Centered Content\n\n```tsx\n
\n
Centered content
\n
\n```\n\n### Sticky Header\n\n```tsx\n
\n \n
\n```\n\n### Grid Layout\n\n```tsx\n
\n {posts.map((post) => (\n \n ))}\n
\n```\n\n### Truncate Text\n\n```tsx\n

This text will be truncated with ellipsis if too long

\n

This text will show max 3 lines with ellipsis

\n```\n\n## Best Practices\n\n1. **Use Consistent Spacing**: Stick to Tailwind's spacing scale\n2. **Responsive by Default**: Always consider mobile-first design\n3. **Extract Components**: Avoid repeating long class lists\n4. **Use Theme Colors**: Define custom colors in config, not arbitrary values\n5. **Leverage @apply Sparingly**: Prefer utility classes in JSX\n6. **Enable Dark Mode**: Plan for dark mode from the start\n7. **Use Plugins**: Leverage official plugins for common needs\n8. **Optimize Production**: Ensure purge is configured correctly\n","docs/agents/issue-tracker.md":"# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.\n\n## Conventions\n\n- **Create an issue**: `gh issue create --title \"...\" --body \"...\"`. Use a heredoc for multi-line bodies.\n- **Read an issue**: `gh issue view --comments`, filtering comments by `jq` and also fetching labels.\n- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.\n- **Comment on an issue**: `gh issue comment --body \"...\"`\n- **Apply / remove labels**: `gh issue edit --add-label \"...\"` / `--remove-label \"...\"`\n- **Close**: `gh issue close --comment \"...\"`\n\nInfer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.\n\n## When a skill says \"publish to the issue tracker\"\n\nCreate a GitHub issue.\n\n## When a skill says \"fetch the relevant ticket\"\n\nRun `gh issue view --comments`.\n"},"files":{".claude/skills/documentation-writer/SKILL.md":"---\nname: documentation-writer\ndescription: Specialized skill for creating and editing high-quality Kener documentation. MUST be used whenever creating or editing documentation files in the src/routes/(docs)/docs/content/ directory or updating docs.json navigation.\n---\n\n# Documentation Writer\n\nUse this skill for all docs edits in `src/routes/(docs)/docs/content/` and when updating docs navigation in `src/routes/(docs)/docs.json`.\n\n## Non-negotiable rules\n\n1. **Be concise**: remove repetition and background that does not help the user complete a task.\n2. **Be actionable**: prioritize “what to do” over theory.\n3. **One source of truth**: if another page already has details, link to it instead of duplicating.\n4. **Preserve structure**: keep valid frontmatter and heading anchor IDs.\n5. **Keep examples copyable**: minimal, tested-looking, and directly relevant.\n6. **Search before writing**: always check if the content already exists in some form before adding new sections or pages.\n7. **Check Relevant Code**: Search the codebase inside `src/` for any relevant code, comments, or tests that can inform the documentation content and ensure accuracy.\n\n## Docs config model (current)\n\n`docs.json` is versioned. Sidebar lives inside tabs:\n\n- `versions[].content.navigation.tabs[].sidebar`\n- Sidebar groups contain `pages`\n- Page paths use `content` (legacy `slug` may still appear in older content)\n\nWhen adding a new doc page, add it to the appropriate tab sidebar path.\n\n## Versioned link policy (mandatory)\n\n- For v4 docs content, internal links MUST use explicit v4 paths: `/docs/v4/...`.\n- Do not use unversioned shortcuts like `/docs/alerting/...` in v4 pages.\n- Before finalizing, verify every internal link in edited files resolves to the intended version.\n\n## Required page format\n\n```markdown\n---\ntitle: Page Title\ndescription: One-line summary of user outcome\n---\n```\n\n- Use custom anchors for H2/H3 headings: `## Section {#section}`\n- Use GitHub admonitions only when needed: `[!NOTE]`, `[!IMPORTANT]`, `[!WARNING]`, `[!CAUTION]`, `[!TIP]`\n- Prefer short sections and short lists\n\n## Preferred structure (default)\n\n1. Short intro (1–2 sentences)\n2. Quick setup / minimum config\n3. Required variables/options table\n4. Verification step\n5. Top troubleshooting items\n\nOnly add extra sections if they materially improve task completion.\n\n## Keep docs lean\n\nRemove or avoid:\n\n- Multiple near-identical examples\n- Long conceptual explainers\n- Platform-by-platform repetition unless behavior differs\n- Large checklists that restate earlier content\n\n## Editing workflow\n\n1. Read the whole target document.\n2. Compress verbose sections first.\n3. Keep critical caveats and breaking notes.\n4. Ensure internal links and anchors still work.\n5. If adding files, update `docs.json` navigation in the correct version/tab.\n\n## Review checklist\n\n- [ ] Title/description frontmatter exists\n- [ ] Key steps are clear and copyable\n- [ ] Content is concise and non-duplicative\n- [ ] Headings keep stable custom anchors\n- [ ] Navigation updated (if new page)\n- [ ] Internal links point to correct paths\n- [ ] v4 pages use `/docs/v4/...` internal links (no unversioned `/docs/...` shortcuts)\n- [ ] No outdated or irrelevant content remains\n- [ ] Admonitions used appropriately for important notes\n",".claude/skills/svelte-code-writer/SKILL.md":"---\nname: svelte-code-writer\ndescription: CLI tools for Svelte 5 documentation lookup and code analysis. MUST be used whenever creating or editing any Svelte component (.svelte) or Svelte module (.svelte.ts/.svelte.js). If possible, this skill should be executed within the svelte-file-editor agent for optimal results.\n---\n\n# Svelte 5 Code Writer\n\n## CLI Tools\n\nYou have access to `@sveltejs/mcp` CLI for Svelte-specific assistance. Use these commands via `npx`:\n\n### List Documentation Sections\n\n```bash\nnpx @sveltejs/mcp list-sections\n```\n\nLists all available Svelte 5 and SvelteKit documentation sections with titles and paths.\n\n### Get Documentation\n\n```bash\nnpx @sveltejs/mcp get-documentation \",,...\"\n```\n\nRetrieves full documentation for specified sections. Use after `list-sections` to fetch relevant docs.\n\n**Example:**\n\n```bash\nnpx @sveltejs/mcp get-documentation \"$state,$derived,$effect\"\n```\n\n### Svelte Autofixer\n\n```bash\nnpx @sveltejs/mcp svelte-autofixer \"\" [options]\n```\n\nAnalyzes Svelte code and suggests fixes for common issues.\n\n**Options:**\n\n- `--async` - Enable async Svelte mode (default: false)\n- `--svelte-version` - Target version: 4 or 5 (default: 5)\n\n**Examples:**\n\n```bash\n# Analyze inline code (escape $ as \\$)\nnpx @sveltejs/mcp svelte-autofixer ''\n\n# Analyze a file\nnpx @sveltejs/mcp svelte-autofixer ./src/lib/Component.svelte\n\n# Target Svelte 4\nnpx @sveltejs/mcp svelte-autofixer ./Component.svelte --svelte-version 4\n```\n\n**Important:** When passing code with runes (`$state`, `$derived`, etc.) via the terminal, escape the `$` character as `\\$` to prevent shell variable substitution.\n\n## Workflow\n\n1. **Uncertain about syntax?** Run `list-sections` then `get-documentation` for relevant topics\n2. **Reviewing/debugging?** Run `svelte-autofixer` on the code to detect issues\n3. **Always validate** - Run `svelte-autofixer` before finalizing any Svelte component\n","AGENTS.md":"# Kener — Agent Instructions\n\n## Run\n\nDev needs Redis on `REDIS_URL`: `cp .env-min.example .env`, then `docker compose -f docker-compose.dev.yml up -d redis`. `npm run dev` migrates and seeds the database before it starts. `npm run build` leaves out the docs site in `src/routes/(docs)/`; `npm run build-with-docs` keeps it.\n\n## Finish a Change\n\n1. Put a test next to new server logic (`apiCall.ts` and `apiCall.test.ts`). Name a component test `.svelte.test.ts` so it runs in Chromium.\n2. A change that reads, writes, or updates the database, or adds a migration or seed, must pass on SQLite, PostgreSQL, and MySQL. `npm test` runs on SQLite only. Run the change on the other two as the Database section of `CODING_STANDARDS.md` shows.\n3. When the change alters what a user sees or can do, update every text that describes the old behavior: the docs in `src/routes/(docs)/docs/content/v4/` and the help text in `.svelte` files. Search all of `src/routes` for the setting key and its UI label, for example `rg -i 'is_hidden|hidden in status page|hidden monitor' src/routes`.\n4. Format only the files you changed: `npx prettier --write `. Some files elsewhere are not formatted yet.\n5. Run `npm run check` and `npm test` until both pass. Run a single test through the npm scripts, which set `TZ=UTC`: `npm run test:server -- `.\n\n## Ask First\n\nAsk the maintainer before you add a dependency, change the database schema or the `/api/v4` request and response shapes, or edit `.github/workflows/`, `Dockerfile`, or `docker-compose*.yml`.\n\n## Guides\n\n- **Coding standards**: read `CODING_STANDARDS.md` before you write or review code that touches the database, a migration or seed, a timestamp, or an API route.\n- **Skills**: read the matching `.claude/skills//SKILL.md` before you edit a `.svelte` or `.svelte.ts` file (`svelte-code-writer`), the docs site in `src/routes/(docs)/` (`documentation-writer`), Tailwind classes (`tailwindcss`), or `src/lib/components/ui/` (`ss-shadcn-svelte`).\n- **Monitor types**: copy the closest existing type into each file where `rg -il src` finds it. A type with no branch in `src/lib/server/services/service.ts` falls through to `NoneCall`: it runs no checks, reports no error, and passes `npm run check`.\n- **Locales**: the app loads every `src/lib/locales/{code}.json` with no registration. `node scripts/check-translations.js` writes each locale's missing and unused keys to `translation-report.json`.\n- **Environment variables**: `src/routes/(docs)/docs/content/v4/setup/environment-variables.md` documents each one. Add a new one there.\n- **Issues**: read `docs/agents/issue-tracker.md` before you create, read, or update a GitHub issue in `rajnandan1/kener`, and `docs/agents/triage-labels.md` before you label one.\n- **Domain docs**: read `docs/agents/domain.md` before you name a domain concept or record an architecture decision.\n","CLAUDE.md":"# CLAUDE.md\n\n@AGENTS.md\n",".agents/skills/ss-shadcn-svelte/SKILL.md":"---\nname: ss-shadcn-svelte\ndescription: >\n Use shadcn-svelte components in SvelteKit projects. Detects whether the current project is a SvelteKit\n app with shadcn-svelte installed, lists available components, and provides access to full component\n documentation via the official llms.txt. Helps choose the right UI components for the job — buttons,\n forms, dialogs, tables, charts, and more — following shadcn-svelte best practices.\n Use this skill whenever the user is working in a SvelteKit project and wants to: add UI components,\n build forms, create dialogs or modals, add a data table, use a date picker, build a sidebar or\n navigation, add charts, use a combobox or select, create an alert or toast notification, or generally\n build UI with pre-built accessible components. Also trigger when the user mentions \"shadcn\", \"shadcn-svelte\",\n \"bits-ui\", or asks about available components in their Svelte project.\n---\n\n# shadcn-svelte — Component-Aware Svelte UI Assistant\n\nUse the right shadcn-svelte components when building UI in SvelteKit projects. This skill detects your project setup, shows what's available, and gives you access to full component documentation.\n\n## Prerequisites\n\nThe project must be a SvelteKit app with shadcn-svelte initialized:\n\n```bash\n# Initialize shadcn-svelte in an existing SvelteKit project\nnpx shadcn-svelte@latest init\n```\n\n## How to use\n\n### Step 1: Detect project setup\n\nRun the detection script to verify this is a SvelteKit project with shadcn-svelte and see which components are already installed:\n\n```bash\nbash /scripts/detect.sh .\n```\n\nThis will:\n- Confirm it's a SvelteKit project (checks for `svelte.config.js/ts` and `@sveltejs/kit` in package.json)\n- Confirm shadcn-svelte is installed (checks for `components.json`, `bits-ui`, or `shadcn-svelte` in package.json)\n- List all currently installed components in the project's UI directory\n- Provide the documentation URL\n\nIf the script exits with code 1, the project either isn't SvelteKit or doesn't have shadcn-svelte — do not proceed with shadcn-svelte components in that case.\n\n### Step 2: Read the component documentation\n\nThe full component documentation for LLMs is available at:\n\n```\nhttps://www.shadcn-svelte.com/llms.txt\n```\n\nFetch this URL to get a structured index of all available components organized by category, with links to individual component documentation pages (in `.md` format).\n\nWhen you need to use a specific component, read its individual documentation page from the links provided in `llms.txt`. Each component doc includes:\n- Import statements and usage examples\n- Available props, events, and slots\n- Variants and configuration options\n- Accessibility information\n\n### Step 3: Use the right component for the job\n\nWhen building UI, follow this decision process:\n\n1. **Run detection** to confirm shadcn-svelte is available and see installed components\n2. **Fetch llms.txt** to see all available components\n3. **Read the specific component docs** for the components you plan to use\n4. **Check if the component is installed** — if not, add it:\n ```bash\n npx shadcn-svelte@latest add \n ```\n5. **Import and use the component** following the documentation patterns\n\n### Component categories\n\nshadcn-svelte components are organized into these categories:\n\n| Category | Components |\n|----------|-----------|\n| **Layout** | Aspect Ratio, Collapsible, Resizable, Scroll Area, Separator, Sidebar |\n| **Form & Input** | Button, Calendar, Checkbox, Combobox, Date Picker, Input, Input OTP, Label, Radio Group, Range Calendar, Select, Slider, Switch, Textarea, Toggle, Toggle Group |\n| **Data Display** | Accordion, Avatar, Badge, Card, Carousel, Chart, Table, Data Table |\n| **Feedback** | Alert, Alert Dialog, Progress, Skeleton, Sonner (Toast) |\n| **Overlay** | Context Menu, Dialog, Drawer, Dropdown Menu, Hover Card, Menubar, Popover, Sheet, Tooltip |\n| **Navigation** | Breadcrumb, Command, Pagination, Tabs |\n| **Typography** | Typography |\n\n### Adding new components\n\n```bash\n# Add a single component\nnpx shadcn-svelte@latest add button\n\n# Add multiple components\nnpx shadcn-svelte@latest add button card dialog\n\n# List all available components\nnpx shadcn-svelte@latest add\n```\n\n### Import patterns\n\nComponents are typically imported from the project's `$lib/components/ui` directory:\n\n```svelte\n\n```\n\nSome components use namespace imports (with `* as`) when they have multiple sub-components (Card, Dialog, Sheet, Table, etc.), while simpler components use named imports (Button, Input, Badge, etc.).\n\n## Important guidelines\n\n- **Always run detection first** before suggesting shadcn-svelte components\n- **Always read component docs** before using a component — don't guess at props or patterns\n- **Check installed components** and add missing ones before importing\n- **Use the project's configured path** — the components directory may vary based on `components.json` configuration\n- **Follow Svelte 5 patterns** — shadcn-svelte uses runes (`$state`, `$derived`, `$effect`) and snippet-based composition\n- **Prefer composition** — shadcn-svelte components are designed to be composed together, not used as monolithic blocks\n",".claude/skills/tailwindcss/SKILL.md":"---\nname: tailwindcss\ndescription: Tailwind CSS v4 utility-first styling patterns including responsive design, dark mode, and custom configuration. Use when styling with Tailwind, adding utility classes, configuring Tailwind, setting up dark mode, or customizing the theme.\nuser-invokable: false\nmetadata:\n category: styling\n---\n\n# Tailwind CSS v4 Development Guidelines\n\nBest practices for using Tailwind CSS v4 utility classes effectively.\n\n**Note**: Tailwind CSS v4 (released January 2025) uses a CSS-first configuration approach. If you need v3 compatibility, tailwind.config.js is still supported.\n\n## Core Principles\n\n1. **Utility-First**: Use utility classes instead of custom CSS\n2. **Mobile-First**: Design for mobile, then scale up with responsive modifiers\n3. **Component Extraction**: Extract repeated patterns into components\n4. **Consistent Spacing**: Use Tailwind's spacing scale\n5. **Custom Configuration**: Extend the default theme for brand consistency\n\n## Basic Utilities\n\n### Layout\n\n```tsx\n// Flexbox\n
\n
Content
\n
Sidebar
\n
\n\n// Grid\n
\n
1
\n
2
\n
3
\n
\n\n// Positioning\n
\n
Badge
\n
\n```\n\n### Spacing\n\n```tsx\n// Padding and Margin\n
{/* padding: 1rem, margin: 0.5rem */}\n
{/* padding-x: 1.5rem, padding-y: 1rem */}\n
{/* margin-top: 2rem, margin-bottom: 1rem */}\n\n// Space between children\n
{/* margin-bottom on all but last child */}\n
Item 1
\n
Item 2
\n
\n```\n\n### Typography\n\n```tsx\n

Heading

\n

\n Paragraph text with comfortable line height.\n

\nLabel\n```\n\n### Colors\n\n```tsx\n// Text colors\n

Text

\n\n// Background colors\n
Button
\n\n// Border colors\n
Box
\n```\n\n## Responsive Design\n\n### Breakpoints\n\n```tsx\n// Mobile-first responsive classes\n
\n {/* Full width on mobile, half on medium screens, third on large */}\n
\n\n

\n {/* Responsive text sizes */}\n

\n\n
\n {/* Responsive grid */}\n
\n```\n\n### Container\n\n```tsx\n
\n {/* Centered container with horizontal padding */}\n
\n\n
\n {/* Responsive container padding */}\n
\n```\n\n## Component Patterns\n\n### Button\n\n```tsx\n\n\n// Variants\n\n```\n\n### Card\n\n```tsx\n
\n \"\"\n
\n

Card Title

\n

Card content goes here.

\n
\n
\n```\n\n### Form Input\n\n```tsx\n
\n \n \n

We'll never share your email.

\n
\n```\n\n## State Variants\n\n### Hover, Focus, Active\n\n```tsx\n\n\n\n Link\n\n```\n\n### Group Hover\n\n```tsx\n
\n \n

Hover the container

\n
\n```\n\n### Disabled\n\n```tsx\n\n```\n\n## Dark Mode\n\n```css\n/* Tailwind v4: Configure in app/globals.css */\n@import \"tailwindcss\";\n\n@media (prefers-color-scheme: dark) {\n /* Or use class-based: .dark */\n}\n```\n\n```tsx\n// Usage (same as v3)\n
\n

Title

\n

Description

\n
\n```\n\n## Custom Styles\n\n### Arbitrary Values\n\n```tsx\n
{/* Custom top value */}\n
{/* Custom color */}\n
{/* Custom grid template */}\n```\n\n### @apply Directive\n\n```css\n/* components/button.css */\n.btn-primary {\n @apply rounded-md bg-blue-600 px-4 py-2 font-medium text-white;\n @apply hover:bg-blue-700 focus:ring-2 focus:ring-blue-500 focus:outline-none;\n @apply disabled:cursor-not-allowed disabled:opacity-50;\n}\n```\n\n## Configuration\n\n### Tailwind v4: CSS-First Configuration\n\n```css\n/* app/globals.css */\n@import \"tailwindcss\";\n\n@theme {\n /* Custom colors */\n --color-brand-50: #eff6ff;\n --color-brand-100: #dbeafe;\n --color-brand-900: #1e3a8a;\n\n /* Custom spacing */\n --spacing-128: 32rem;\n\n /* Custom fonts */\n --font-family-sans: \"Inter\", sans-serif;\n\n /* Custom breakpoints */\n --breakpoint-3xl: 1920px;\n}\n```\n\n### Tailwind v3 Config (Still Supported)\n\n```javascript\n// tailwind.config.js (optional in v4)\nmodule.exports = {\n content: [\"./app/**/*.{js,ts,jsx,tsx,mdx}\", \"./components/**/*.{js,ts,jsx,tsx,mdx}\"],\n theme: {\n extend: {\n colors: {\n brand: {\n 50: \"#eff6ff\",\n 100: \"#dbeafe\",\n 900: \"#1e3a8a\"\n }\n },\n spacing: {\n 128: \"32rem\"\n },\n fontFamily: {\n sans: [\"Inter\", \"sans-serif\"]\n }\n }\n },\n plugins: [require(\"@tailwindcss/forms\"), require(\"@tailwindcss/typography\")]\n}\n```\n\n## Plugins\n\n### Official Plugins\n\n```bash\nnpm install @tailwindcss/forms\nnpm install @tailwindcss/typography\nnpm install @tailwindcss/aspect-ratio\nnpm install @tailwindcss/container-queries\n```\n\n```tsx\n// @tailwindcss/forms\n\n\n// @tailwindcss/typography\n
\n

Article Title

\n

Content...

\n
\n```\n\n## Performance\n\n### Automatic Content Detection\n\nTailwind v4 automatically detects and scans all template files - no `content` configuration needed.\n\n### Build Performance\n\nTailwind v4 delivers 3.5x faster full builds (~100ms) compared to v3 using modern CSS features like `@property` and `color-mix()`.\n\n**Browser Requirements**: Safari 16.4+, Chrome 111+, Firefox 128+\n\n## Common Patterns\n\n### Centered Content\n\n```tsx\n
\n
Centered content
\n
\n```\n\n### Sticky Header\n\n```tsx\n
\n \n
\n```\n\n### Grid Layout\n\n```tsx\n
\n {posts.map((post) => (\n \n ))}\n
\n```\n\n### Truncate Text\n\n```tsx\n

This text will be truncated with ellipsis if too long

\n

This text will show max 3 lines with ellipsis

\n```\n\n## Best Practices\n\n1. **Use Consistent Spacing**: Stick to Tailwind's spacing scale\n2. **Responsive by Default**: Always consider mobile-first design\n3. **Extract Components**: Avoid repeating long class lists\n4. **Use Theme Colors**: Define custom colors in config, not arbitrary values\n5. **Leverage @apply Sparingly**: Prefer utility classes in JSX\n6. **Enable Dark Mode**: Plan for dark mode from the start\n7. **Use Plugins**: Leverage official plugins for common needs\n8. **Optimize Production**: Ensure purge is configured correctly\n","docs/agents/issue-tracker.md":"# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.\n\n## Conventions\n\n- **Create an issue**: `gh issue create --title \"...\" --body \"...\"`. Use a heredoc for multi-line bodies.\n- **Read an issue**: `gh issue view --comments`, filtering comments by `jq` and also fetching labels.\n- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.\n- **Comment on an issue**: `gh issue comment --body \"...\"`\n- **Apply / remove labels**: `gh issue edit --add-label \"...\"` / `--remove-label \"...\"`\n- **Close**: `gh issue close --comment \"...\"`\n\nInfer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.\n\n## When a skill says \"publish to the issue tracker\"\n\nCreate a GitHub issue.\n\n## When a skill says \"fetch the relevant ticket\"\n\nRun `gh issue view --comments`.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/rajnandan1/kener/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Kener — Agent Instructions\n\n## Run\n\nDev needs Redis on `REDIS_URL`: `cp .env-min.example .env`, then `docker compose -f docker-compose.dev.yml up -d redis`. `npm run dev` migrates and seeds the database before it starts. `npm run build` leaves out the docs site in `src/routes/(docs)/`; `npm run build-with-docs` keeps it.\n\n## Finish a Change\n\n1. Put a test next to new server logic (`apiCall.ts` and `apiCall.test.ts`). Name a component test `.svelte.test.ts` so it runs in Chromium.\n2. A change that reads, writes, or updates the database, or adds a migration or seed, must pass on SQLite, PostgreSQL, and MySQL. `npm test` runs on SQLite only. Run the change on the other two as the Database section of `CODING_STANDARDS.md` shows.\n3. When the change alters what a user sees or can do, update every text that describes the old behavior: the docs in `src/routes/(docs)/docs/content/v4/` and the help text in `.svelte` files. Search all of `src/routes` for the setting key and its UI label, for example `rg -i 'is_hidden|hidden in status page|hidden monitor' src/routes`.\n4. Format only the files you changed: `npx prettier --write `. Some files elsewhere are not formatted yet.\n5. Run `npm run check` and `npm test` until both pass. Run a single test through the npm scripts, which set `TZ=UTC`: `npm run test:server -- `.\n\n## Ask First\n\nAsk the maintainer before you add a dependency, change the database schema or the `/api/v4` request and response shapes, or edit `.github/workflows/`, `Dockerfile`, or `docker-compose*.yml`.\n\n## Guides\n\n- **Coding standards**: read `CODING_STANDARDS.md` before you write or review code that touches the database, a migration or seed, a timestamp, or an API route.\n- **Skills**: read the matching `.claude/skills//SKILL.md` before you edit a `.svelte` or `.svelte.ts` file (`svelte-code-writer`), the docs site in `src/routes/(docs)/` (`documentation-writer`), Tailwind classes (`tailwindcss`), or `src/lib/components/ui/` (`ss-shadcn-svelte`).\n- **Monitor types**: copy the closest existing type into each file where `rg -il src` finds it. A type with no branch in `src/lib/server/services/service.ts` falls through to `NoneCall`: it runs no checks, reports no error, and passes `npm run check`.\n- **Locales**: the app loads every `src/lib/locales/{code}.json` with no registration. `node scripts/check-translations.js` writes each locale's missing and unused keys to `translation-report.json`.\n- **Environment variables**: `src/routes/(docs)/docs/content/v4/setup/environment-variables.md` documents each one. Add a new one there.\n- **Issues**: read `docs/agents/issue-tracker.md` before you create, read, or update a GitHub issue in `rajnandan1/kener`, and `docs/agents/triage-labels.md` before you label one.\n- **Domain docs**: read `docs/agents/domain.md` before you name a domain concept or record an architecture decision.\n","isInternal":false,"tokens":743,"sizeBytes":2910},{"name":"SKILL.md","path":".agents/skills/ss-shadcn-svelte/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rajnandan1/kener/HEAD/.agents/skills/ss-shadcn-svelte/SKILL.md","title":"ss-shadcn-svelte","category":"anthropic-skill","format":"markdown","content":"---\nname: ss-shadcn-svelte\ndescription: >\n Use shadcn-svelte components in SvelteKit projects. Detects whether the current project is a SvelteKit\n app with shadcn-svelte installed, lists available components, and provides access to full component\n documentation via the official llms.txt. Helps choose the right UI components for the job — buttons,\n forms, dialogs, tables, charts, and more — following shadcn-svelte best practices.\n Use this skill whenever the user is working in a SvelteKit project and wants to: add UI components,\n build forms, create dialogs or modals, add a data table, use a date picker, build a sidebar or\n navigation, add charts, use a combobox or select, create an alert or toast notification, or generally\n build UI with pre-built accessible components. Also trigger when the user mentions \"shadcn\", \"shadcn-svelte\",\n \"bits-ui\", or asks about available components in their Svelte project.\n---\n\n# shadcn-svelte — Component-Aware Svelte UI Assistant\n\nUse the right shadcn-svelte components when building UI in SvelteKit projects. This skill detects your project setup, shows what's available, and gives you access to full component documentation.\n\n## Prerequisites\n\nThe project must be a SvelteKit app with shadcn-svelte initialized:\n\n```bash\n# Initialize shadcn-svelte in an existing SvelteKit project\nnpx shadcn-svelte@latest init\n```\n\n## How to use\n\n### Step 1: Detect project setup\n\nRun the detection script to verify this is a SvelteKit project with shadcn-svelte and see which components are already installed:\n\n```bash\nbash /scripts/detect.sh .\n```\n\nThis will:\n- Confirm it's a SvelteKit project (checks for `svelte.config.js/ts` and `@sveltejs/kit` in package.json)\n- Confirm shadcn-svelte is installed (checks for `components.json`, `bits-ui`, or `shadcn-svelte` in package.json)\n- List all currently installed components in the project's UI directory\n- Provide the documentation URL\n\nIf the script exits with code 1, the project either isn't SvelteKit or doesn't have shadcn-svelte — do not proceed with shadcn-svelte components in that case.\n\n### Step 2: Read the component documentation\n\nThe full component documentation for LLMs is available at:\n\n```\nhttps://www.shadcn-svelte.com/llms.txt\n```\n\nFetch this URL to get a structured index of all available components organized by category, with links to individual component documentation pages (in `.md` format).\n\nWhen you need to use a specific component, read its individual documentation page from the links provided in `llms.txt`. Each component doc includes:\n- Import statements and usage examples\n- Available props, events, and slots\n- Variants and configuration options\n- Accessibility information\n\n### Step 3: Use the right component for the job\n\nWhen building UI, follow this decision process:\n\n1. **Run detection** to confirm shadcn-svelte is available and see installed components\n2. **Fetch llms.txt** to see all available components\n3. **Read the specific component docs** for the components you plan to use\n4. **Check if the component is installed** — if not, add it:\n ```bash\n npx shadcn-svelte@latest add \n ```\n5. **Import and use the component** following the documentation patterns\n\n### Component categories\n\nshadcn-svelte components are organized into these categories:\n\n| Category | Components |\n|----------|-----------|\n| **Layout** | Aspect Ratio, Collapsible, Resizable, Scroll Area, Separator, Sidebar |\n| **Form & Input** | Button, Calendar, Checkbox, Combobox, Date Picker, Input, Input OTP, Label, Radio Group, Range Calendar, Select, Slider, Switch, Textarea, Toggle, Toggle Group |\n| **Data Display** | Accordion, Avatar, Badge, Card, Carousel, Chart, Table, Data Table |\n| **Feedback** | Alert, Alert Dialog, Progress, Skeleton, Sonner (Toast) |\n| **Overlay** | Context Menu, Dialog, Drawer, Dropdown Menu, Hover Card, Menubar, Popover, Sheet, Tooltip |\n| **Navigation** | Breadcrumb, Command, Pagination, Tabs |\n| **Typography** | Typography |\n\n### Adding new components\n\n```bash\n# Add a single component\nnpx shadcn-svelte@latest add button\n\n# Add multiple components\nnpx shadcn-svelte@latest add button card dialog\n\n# List all available components\nnpx shadcn-svelte@latest add\n```\n\n### Import patterns\n\nComponents are typically imported from the project's `$lib/components/ui` directory:\n\n```svelte\n\n```\n\nSome components use namespace imports (with `* as`) when they have multiple sub-components (Card, Dialog, Sheet, Table, etc.), while simpler components use named imports (Button, Input, Badge, etc.).\n\n## Important guidelines\n\n- **Always run detection first** before suggesting shadcn-svelte components\n- **Always read component docs** before using a component — don't guess at props or patterns\n- **Check installed components** and add missing ones before importing\n- **Use the project's configured path** — the components directory may vary based on `components.json` configuration\n- **Follow Svelte 5 patterns** — shadcn-svelte uses runes (`$state`, `$derived`, `$effect`) and snippet-based composition\n- **Prefer composition** — shadcn-svelte components are designed to be composed together, not used as monolithic blocks\n","frontmatter":{"name":"ss-shadcn-svelte","description":"Use shadcn-svelte components in SvelteKit projects. Detects whether the current project is a SvelteKit app with shadcn-svelte installed, lists available components, and provides access to full component documentation via the official llms.txt. Helps choose the right UI components for the job — buttons, forms, dialogs, tables, charts, and more — following shadcn-svelte best practices. Use this skill whenever the user is working in a SvelteKit project and wants to: add UI components, build forms, create dialogs or modals, add a data table, use a date picker, build a sidebar or navigation, add charts, use a combobox or select, create an alert or toast notification, or generally build UI with pre-built accessible components. Also trigger when the user mentions \"shadcn\", \"shadcn-svelte\", \"bits-ui\", or asks about available components in their Svelte project.\n"},"isInternal":false,"tokens":1254,"sizeBytes":5397},{"name":"SKILL.md","path":".claude/skills/documentation-writer/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rajnandan1/kener/HEAD/.claude/skills/documentation-writer/SKILL.md","title":"documentation-writer","category":"anthropic-skill","format":"markdown","content":"---\nname: documentation-writer\ndescription: Specialized skill for creating and editing high-quality Kener documentation. MUST be used whenever creating or editing documentation files in the src/routes/(docs)/docs/content/ directory or updating docs.json navigation.\n---\n\n# Documentation Writer\n\nUse this skill for all docs edits in `src/routes/(docs)/docs/content/` and when updating docs navigation in `src/routes/(docs)/docs.json`.\n\n## Non-negotiable rules\n\n1. **Be concise**: remove repetition and background that does not help the user complete a task.\n2. **Be actionable**: prioritize “what to do” over theory.\n3. **One source of truth**: if another page already has details, link to it instead of duplicating.\n4. **Preserve structure**: keep valid frontmatter and heading anchor IDs.\n5. **Keep examples copyable**: minimal, tested-looking, and directly relevant.\n6. **Search before writing**: always check if the content already exists in some form before adding new sections or pages.\n7. **Check Relevant Code**: Search the codebase inside `src/` for any relevant code, comments, or tests that can inform the documentation content and ensure accuracy.\n\n## Docs config model (current)\n\n`docs.json` is versioned. Sidebar lives inside tabs:\n\n- `versions[].content.navigation.tabs[].sidebar`\n- Sidebar groups contain `pages`\n- Page paths use `content` (legacy `slug` may still appear in older content)\n\nWhen adding a new doc page, add it to the appropriate tab sidebar path.\n\n## Versioned link policy (mandatory)\n\n- For v4 docs content, internal links MUST use explicit v4 paths: `/docs/v4/...`.\n- Do not use unversioned shortcuts like `/docs/alerting/...` in v4 pages.\n- Before finalizing, verify every internal link in edited files resolves to the intended version.\n\n## Required page format\n\n```markdown\n---\ntitle: Page Title\ndescription: One-line summary of user outcome\n---\n```\n\n- Use custom anchors for H2/H3 headings: `## Section {#section}`\n- Use GitHub admonitions only when needed: `[!NOTE]`, `[!IMPORTANT]`, `[!WARNING]`, `[!CAUTION]`, `[!TIP]`\n- Prefer short sections and short lists\n\n## Preferred structure (default)\n\n1. Short intro (1–2 sentences)\n2. Quick setup / minimum config\n3. Required variables/options table\n4. Verification step\n5. Top troubleshooting items\n\nOnly add extra sections if they materially improve task completion.\n\n## Keep docs lean\n\nRemove or avoid:\n\n- Multiple near-identical examples\n- Long conceptual explainers\n- Platform-by-platform repetition unless behavior differs\n- Large checklists that restate earlier content\n\n## Editing workflow\n\n1. Read the whole target document.\n2. Compress verbose sections first.\n3. Keep critical caveats and breaking notes.\n4. Ensure internal links and anchors still work.\n5. If adding files, update `docs.json` navigation in the correct version/tab.\n\n## Review checklist\n\n- [ ] Title/description frontmatter exists\n- [ ] Key steps are clear and copyable\n- [ ] Content is concise and non-duplicative\n- [ ] Headings keep stable custom anchors\n- [ ] Navigation updated (if new page)\n- [ ] Internal links point to correct paths\n- [ ] v4 pages use `/docs/v4/...` internal links (no unversioned `/docs/...` shortcuts)\n- [ ] No outdated or irrelevant content remains\n- [ ] Admonitions used appropriately for important notes\n","frontmatter":{"name":"documentation-writer","description":"Specialized skill for creating and editing high-quality Kener documentation. MUST be used whenever creating or editing documentation files in the src/routes/(docs)/docs/content/ directory or updating docs.json navigation."},"isInternal":false,"tokens":743,"sizeBytes":3297},{"name":"SKILL.md","path":".claude/skills/svelte-code-writer/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rajnandan1/kener/HEAD/.claude/skills/svelte-code-writer/SKILL.md","title":"svelte-code-writer","category":"anthropic-skill","format":"markdown","content":"---\nname: svelte-code-writer\ndescription: CLI tools for Svelte 5 documentation lookup and code analysis. MUST be used whenever creating or editing any Svelte component (.svelte) or Svelte module (.svelte.ts/.svelte.js). If possible, this skill should be executed within the svelte-file-editor agent for optimal results.\n---\n\n# Svelte 5 Code Writer\n\n## CLI Tools\n\nYou have access to `@sveltejs/mcp` CLI for Svelte-specific assistance. Use these commands via `npx`:\n\n### List Documentation Sections\n\n```bash\nnpx @sveltejs/mcp list-sections\n```\n\nLists all available Svelte 5 and SvelteKit documentation sections with titles and paths.\n\n### Get Documentation\n\n```bash\nnpx @sveltejs/mcp get-documentation \",,...\"\n```\n\nRetrieves full documentation for specified sections. Use after `list-sections` to fetch relevant docs.\n\n**Example:**\n\n```bash\nnpx @sveltejs/mcp get-documentation \"$state,$derived,$effect\"\n```\n\n### Svelte Autofixer\n\n```bash\nnpx @sveltejs/mcp svelte-autofixer \"\" [options]\n```\n\nAnalyzes Svelte code and suggests fixes for common issues.\n\n**Options:**\n\n- `--async` - Enable async Svelte mode (default: false)\n- `--svelte-version` - Target version: 4 or 5 (default: 5)\n\n**Examples:**\n\n```bash\n# Analyze inline code (escape $ as \\$)\nnpx @sveltejs/mcp svelte-autofixer ''\n\n# Analyze a file\nnpx @sveltejs/mcp svelte-autofixer ./src/lib/Component.svelte\n\n# Target Svelte 4\nnpx @sveltejs/mcp svelte-autofixer ./Component.svelte --svelte-version 4\n```\n\n**Important:** When passing code with runes (`$state`, `$derived`, etc.) via the terminal, escape the `$` character as `\\$` to prevent shell variable substitution.\n\n## Workflow\n\n1. **Uncertain about syntax?** Run `list-sections` then `get-documentation` for relevant topics\n2. **Reviewing/debugging?** Run `svelte-autofixer` on the code to detect issues\n3. **Always validate** - Run `svelte-autofixer` before finalizing any Svelte component\n","frontmatter":{"name":"svelte-code-writer","description":"CLI tools for Svelte 5 documentation lookup and code analysis. MUST be used whenever creating or editing any Svelte component (.svelte) or Svelte module (.svelte.ts/.svelte.js). If possible, this skill should be executed within the svelte-file-editor agent for optimal results."},"isInternal":false,"tokens":532,"sizeBytes":1971},{"name":"SKILL.md","path":".claude/skills/tailwindcss/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rajnandan1/kener/HEAD/.claude/skills/tailwindcss/SKILL.md","title":"tailwindcss","category":"anthropic-skill","format":"markdown","content":"---\nname: tailwindcss\ndescription: Tailwind CSS v4 utility-first styling patterns including responsive design, dark mode, and custom configuration. Use when styling with Tailwind, adding utility classes, configuring Tailwind, setting up dark mode, or customizing the theme.\nuser-invokable: false\nmetadata:\n category: styling\n---\n\n# Tailwind CSS v4 Development Guidelines\n\nBest practices for using Tailwind CSS v4 utility classes effectively.\n\n**Note**: Tailwind CSS v4 (released January 2025) uses a CSS-first configuration approach. If you need v3 compatibility, tailwind.config.js is still supported.\n\n## Core Principles\n\n1. **Utility-First**: Use utility classes instead of custom CSS\n2. **Mobile-First**: Design for mobile, then scale up with responsive modifiers\n3. **Component Extraction**: Extract repeated patterns into components\n4. **Consistent Spacing**: Use Tailwind's spacing scale\n5. **Custom Configuration**: Extend the default theme for brand consistency\n\n## Basic Utilities\n\n### Layout\n\n```tsx\n// Flexbox\n
\n
Content
\n
Sidebar
\n
\n\n// Grid\n
\n
1
\n
2
\n
3
\n
\n\n// Positioning\n
\n
Badge
\n
\n```\n\n### Spacing\n\n```tsx\n// Padding and Margin\n
{/* padding: 1rem, margin: 0.5rem */}\n
{/* padding-x: 1.5rem, padding-y: 1rem */}\n
{/* margin-top: 2rem, margin-bottom: 1rem */}\n\n// Space between children\n
{/* margin-bottom on all but last child */}\n
Item 1
\n
Item 2
\n
\n```\n\n### Typography\n\n```tsx\n

Heading

\n

\n Paragraph text with comfortable line height.\n

\nLabel\n```\n\n### Colors\n\n```tsx\n// Text colors\n

Text

\n\n// Background colors\n
Button
\n\n// Border colors\n
Box
\n```\n\n## Responsive Design\n\n### Breakpoints\n\n```tsx\n// Mobile-first responsive classes\n
\n {/* Full width on mobile, half on medium screens, third on large */}\n
\n\n

\n {/* Responsive text sizes */}\n

\n\n
\n {/* Responsive grid */}\n
\n```\n\n### Container\n\n```tsx\n
\n {/* Centered container with horizontal padding */}\n
\n\n
\n {/* Responsive container padding */}\n
\n```\n\n## Component Patterns\n\n### Button\n\n```tsx\n\n\n// Variants\n\n```\n\n### Card\n\n```tsx\n
\n \"\"\n
\n

Card Title

\n

Card content goes here.

\n
\n
\n```\n\n### Form Input\n\n```tsx\n
\n \n \n

We'll never share your email.

\n
\n```\n\n## State Variants\n\n### Hover, Focus, Active\n\n```tsx\n\n\n\n Link\n\n```\n\n### Group Hover\n\n```tsx\n
\n \n

Hover the container

\n
\n```\n\n### Disabled\n\n```tsx\n\n```\n\n## Dark Mode\n\n```css\n/* Tailwind v4: Configure in app/globals.css */\n@import \"tailwindcss\";\n\n@media (prefers-color-scheme: dark) {\n /* Or use class-based: .dark */\n}\n```\n\n```tsx\n// Usage (same as v3)\n
\n

Title

\n

Description

\n
\n```\n\n## Custom Styles\n\n### Arbitrary Values\n\n```tsx\n
{/* Custom top value */}\n
{/* Custom color */}\n
{/* Custom grid template */}\n```\n\n### @apply Directive\n\n```css\n/* components/button.css */\n.btn-primary {\n @apply rounded-md bg-blue-600 px-4 py-2 font-medium text-white;\n @apply hover:bg-blue-700 focus:ring-2 focus:ring-blue-500 focus:outline-none;\n @apply disabled:cursor-not-allowed disabled:opacity-50;\n}\n```\n\n## Configuration\n\n### Tailwind v4: CSS-First Configuration\n\n```css\n/* app/globals.css */\n@import \"tailwindcss\";\n\n@theme {\n /* Custom colors */\n --color-brand-50: #eff6ff;\n --color-brand-100: #dbeafe;\n --color-brand-900: #1e3a8a;\n\n /* Custom spacing */\n --spacing-128: 32rem;\n\n /* Custom fonts */\n --font-family-sans: \"Inter\", sans-serif;\n\n /* Custom breakpoints */\n --breakpoint-3xl: 1920px;\n}\n```\n\n### Tailwind v3 Config (Still Supported)\n\n```javascript\n// tailwind.config.js (optional in v4)\nmodule.exports = {\n content: [\"./app/**/*.{js,ts,jsx,tsx,mdx}\", \"./components/**/*.{js,ts,jsx,tsx,mdx}\"],\n theme: {\n extend: {\n colors: {\n brand: {\n 50: \"#eff6ff\",\n 100: \"#dbeafe\",\n 900: \"#1e3a8a\"\n }\n },\n spacing: {\n 128: \"32rem\"\n },\n fontFamily: {\n sans: [\"Inter\", \"sans-serif\"]\n }\n }\n },\n plugins: [require(\"@tailwindcss/forms\"), require(\"@tailwindcss/typography\")]\n}\n```\n\n## Plugins\n\n### Official Plugins\n\n```bash\nnpm install @tailwindcss/forms\nnpm install @tailwindcss/typography\nnpm install @tailwindcss/aspect-ratio\nnpm install @tailwindcss/container-queries\n```\n\n```tsx\n// @tailwindcss/forms\n\n\n// @tailwindcss/typography\n
\n

Article Title

\n

Content...

\n
\n```\n\n## Performance\n\n### Automatic Content Detection\n\nTailwind v4 automatically detects and scans all template files - no `content` configuration needed.\n\n### Build Performance\n\nTailwind v4 delivers 3.5x faster full builds (~100ms) compared to v3 using modern CSS features like `@property` and `color-mix()`.\n\n**Browser Requirements**: Safari 16.4+, Chrome 111+, Firefox 128+\n\n## Common Patterns\n\n### Centered Content\n\n```tsx\n
\n
Centered content
\n
\n```\n\n### Sticky Header\n\n```tsx\n
\n \n
\n```\n\n### Grid Layout\n\n```tsx\n
\n {posts.map((post) => (\n \n ))}\n
\n```\n\n### Truncate Text\n\n```tsx\n

This text will be truncated with ellipsis if too long

\n

This text will show max 3 lines with ellipsis

\n```\n\n## Best Practices\n\n1. **Use Consistent Spacing**: Stick to Tailwind's spacing scale\n2. **Responsive by Default**: Always consider mobile-first design\n3. **Extract Components**: Avoid repeating long class lists\n4. **Use Theme Colors**: Define custom colors in config, not arbitrary values\n5. **Leverage @apply Sparingly**: Prefer utility classes in JSX\n6. **Enable Dark Mode**: Plan for dark mode from the start\n7. **Use Plugins**: Leverage official plugins for common needs\n8. **Optimize Production**: Ensure purge is configured correctly\n","frontmatter":{"name":"tailwindcss","description":"Tailwind CSS v4 utility-first styling patterns including responsive design, dark mode, and custom configuration. Use when styling with Tailwind, adding utility classes, configuring Tailwind, setting up dark mode, or customizing the theme.","user-invokable":false,"metadata":{"category":"styling"}},"isInternal":false,"tokens":2371,"sizeBytes":8888},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/rajnandan1/kener/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# CLAUDE.md\n\n@AGENTS.md\n","isInternal":false,"tokens":11,"sizeBytes":24},{"name":"issue-tracker.md","path":"docs/agents/issue-tracker.md","rawUrl":"https://raw.githubusercontent.com/rajnandan1/kener/HEAD/docs/agents/issue-tracker.md","title":"Subagent: issue-tracker","category":"subagent-persona","format":"markdown","content":"# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.\n\n## Conventions\n\n- **Create an issue**: `gh issue create --title \"...\" --body \"...\"`. Use a heredoc for multi-line bodies.\n- **Read an issue**: `gh issue view --comments`, filtering comments by `jq` and also fetching labels.\n- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.\n- **Comment on an issue**: `gh issue comment --body \"...\"`\n- **Apply / remove labels**: `gh issue edit --add-label \"...\"` / `--remove-label \"...\"`\n- **Close**: `gh issue close --comment \"...\"`\n\nInfer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.\n\n## When a skill says \"publish to the issue tracker\"\n\nCreate a GitHub issue.\n\n## When a skill says \"fetch the relevant ticket\"\n\nRun `gh issue view --comments`.\n","isInternal":false,"tokens":275,"sizeBytes":1065}],"systemPromptSnippet":"\n\n# Kener — Agent Instructions\n\n## Run\n\nDev needs Redis on `REDIS_URL`: `cp .env-min.example .env`, then `docker compose -f docker-compose.dev.yml up -d redis`. `npm run dev` migrates and seeds the database before it starts. `npm run build` leaves out the docs site in `src/routes/(docs)/`; `npm run build-with-docs` keeps it.\n\n## Finish a Change\n\n1. Put a test next to new server logic (`apiCall.ts` and `apiCall.test.ts`). Name a component test `.svelte.test.ts` so it runs in Chromium.\n2. A change that reads, writes, or updates the database, or adds a migration or seed, must pass on SQLite, PostgreSQL, and MySQL. `npm test` runs on SQLite only. Run the change on the other two as the Database section of `CODING_STANDARDS.md` shows.\n3. When the change alters what a user sees or can do, update every text that describes the old behavior: the docs in `src/routes/(docs)/docs/content/v4/` and the help text in `.svelte` files. Search all of `src/routes` for the setting key and its UI label, for example `rg -i 'is_hidden|hidden in status page|hidden monitor' src/routes`.\n4. Format only the files you changed: `npx prettier --write `. Some files elsewhere are not formatted yet.\n5. Run `npm run check` and `npm test` until both pass. Run a single test through the npm scripts, which set `TZ=UTC`: `npm run test:server -- `.\n\n## Ask First\n\nAsk the maintainer before you add a dependency, change the database schema or the `/api/v4` request and response shapes, or edit `.github/workflows/`, `Dockerfile`, or `docker-compose*.yml`.\n\n## Guides\n\n- **Coding standards**: read `CODING_STANDARDS.md` before you write or review code that touches the database, a migration or seed, a timestamp, or an API route.\n- **Skills**: read the matching `.claude/skills//SKILL.md` before you edit a `.svelte` or `.svelte.ts` file (`svelte-code-writer`), the docs site in `src/routes/(docs)/` (`documentation-writer`), Tailwind classes (`tailwindcss`), or `src/lib/components/ui/` (`ss-shadcn-svelte`).\n- **Monitor types**: copy the closest existing type into each file where `rg -il src` finds it. A type with no branch in `src/lib/server/services/service.ts` falls through to `NoneCall`: it runs no checks, reports no error, and passes `npm run check`.\n- **Locales**: the app loads every `src/lib/locales/{code}.json` with no registration. `node scripts/check-translations.js` writes each locale's missing and unused keys to `translation-report.json`.\n- **Environment variables**: `src/routes/(docs)/docs/content/v4/setup/environment-variables.md` documents each one. Add a new one there.\n- **Issues**: read `docs/agents/issue-tracker.md` before you create, read, or update a GitHub issue in `rajnandan1/kener`, and `docs/agents/triage-labels.md` before you label one.\n- **Domain docs**: read `docs/agents/domain.md` before you name a domain concept or record an architecture decision.\n\n\n---\nname: ss-shadcn-svelte\ndescription: >\n Use shadcn-svelte components in SvelteKit projects. Detects whether the current project is a SvelteKit\n app with shadcn-svelte installed, lists available components, and provides access to full component\n documentation via the official llms.txt. Helps choose the right UI components for the job — buttons,\n forms, dialogs, tables, charts, and more — following shadcn-svelte best practices.\n Use this skill whenever the user is working in a SvelteKit project and wants to: add UI components,\n build forms, create dialogs or modals, add a data table, use a date picker, build a sidebar or\n navigation, add charts, use a combobox or select, create an alert or toast notification, or generally\n build UI with pre-built accessible components. Also trigger when the user mentions \"shadcn\", \"shadcn-svelte\",\n \"bits-ui\", or asks about available components in their Svelte project.\n---\n\n# shadcn-svelte — Component-Aware Svelte UI Assistant\n\nUse the right shadcn-svelte components when building UI in SvelteKit projects. This skill detects your project setup, shows what's available, and gives you access to full component documentation.\n\n## Prerequisites\n\nThe project must be a SvelteKit app with shadcn-svelte initialized:\n\n```bash\n# Initialize shadcn-svelte in an existing SvelteKit project\nnpx shadcn-svelte@latest init\n```\n\n## How to use\n\n### Step 1: Detect project setup\n\nRun the detection script to verify this is a SvelteKit project with shadcn-svelte and see which components are already installed:\n\n```bash\nbash /scripts/detect.sh .\n```\n\nThis will:\n- Confirm it's a SvelteKit project (checks for `svelte.config.js/ts` and `@sveltejs/kit` in package.json)\n- Confirm shadcn-svelte is installed (checks for `components.json`, `bits-ui`, or `shadcn-svelte` in package.json)\n- List all currently installed components in the project's UI directory\n- Provide the documentation URL\n\nIf the script exits with code 1, the project either isn't SvelteKit or doesn't have shadcn-svelte — do not proceed with shadcn-svelte components in that case.\n\n### Step 2: Read the component documentation\n\nThe full component documentation for LLMs is available at:\n\n```\nhttps://www.shadcn-svelte.com/llms.txt\n```\n\nFetch this URL to get a structured index of all available components organized by category, with links to individual component documentation pages (in `.md` format).\n\nWhen you need to use a specific component, read its individual documentation page from the links provided in `llms.txt`. Each component doc includes:\n- Import statements and usage examples\n- Available props, events, and slots\n- Variants and configuration options\n- Accessibility information\n\n### Step 3: Use the right component for the job\n\nWhen building UI, follow this decision process:\n\n1. **Run detection** to confirm shadcn-svelte is available and see installed components\n2. **Fetch llms.txt** to see all available components\n3. **Read the specific component docs** for the components you plan to use\n4. **Check if the component is installed** — if not, add it:\n ```bash\n npx shadcn-svelte@latest add \n ```\n5. **Import and use the component** following the documentation patterns\n\n### Component categories\n\nshadcn-svelte components are organized into these categories:\n\n| Category | Components |\n|----------|-----------|\n| **Layout** | Aspect Ratio, Collapsible, Resizable, Scroll Area, Separator, Sidebar |\n| **Form & Input** | Button, Calendar, Checkbox, Combobox, Date Picker, Input, Input OTP, Label, Radio Group, Range Calendar, Select, Slider, Switch, Textarea, Toggle, Toggle Group |\n| **Data Display** | Accordion, Avatar, Badge, Card, Carousel, Chart, Table, Data Table |\n| **Feedback** | Alert, Alert Dialog, Progress, Skeleton, Sonner (Toast) |\n| **Overlay** | Context Menu, Dialog, Drawer, Dropdown Menu, Hover Card, Menubar, Popover, Sheet, Tooltip |\n| **Navigation** | Breadcrumb, Command, Pagination, Tabs |\n| **Typography** | Typography |\n\n### Adding new components\n\n```bash\n# Add a single component\nnpx shadcn-svelte@latest add button\n\n# Add multiple components\nnpx shadcn-svelte@latest add button card dialog\n\n# List all available components\nnpx shadcn-svelte@latest add\n```\n\n### Import patterns\n\nComponents are typically imported from the project's `$lib/components/ui` directory:\n\n```svelte\n\n```\n\nSome components use namespace imports (with `* as`) when they have multiple sub-components (Card, Dialog, Sheet, Table, etc.), while simpler components use named imports (Button, Input, Badge, etc.).\n\n## Important guidelines\n\n- **Always run detection first** before suggesting shadcn-svelte components\n- **Always read component docs** before using a component — don't guess at props or patterns\n- **Check installed components** and add missing ones before importing\n- **Use the project's configured path** — the components directory may vary based on `components.json` configuration\n- **Follow Svelte 5 patterns** — shadcn-svelte uses runes (`$state`, `$derived`, `$effect`) and snippet-based composition\n- **Prefer composition** — shadcn-svelte components are designed to be composed together, not used as monolithic blocks\n\n\n---\nname: documentation-writer\ndescription: Specialized skill for creating and editing high-quality Kener documentation. MUST be used whenever creating or editing documentation files in the src/routes/(docs)/docs/content/ directory or updating docs.json navigation.\n---\n\n# Documentation Writer\n\nUse this skill for all docs edits in `src/routes/(docs)/docs/content/` and when updating docs navigation in `src/routes/(docs)/docs.json`.\n\n## Non-negotiable rules\n\n1. **Be concise**: remove repetition and background that does not help the user complete a task.\n2. **Be actionable**: prioritize “what to do” over theory.\n3. **One source of truth**: if another page already has details, link to it instead of duplicating.\n4. **Preserve structure**: keep valid frontmatter and heading anchor IDs.\n5. **Keep examples copyable**: minimal, tested-looking, and directly relevant.\n6. **Search before writing**: always check if the content already exists in some form before adding new sections or pages.\n7. **Check Relevant Code**: Search the codebase inside `src/` for any relevant code, comments, or tests that can inform the documentation content and ensure accuracy.\n\n## Docs config model (current)\n\n`docs.json` is versioned. Sidebar lives inside tabs:\n\n- `versions[].content.navigation.tabs[].sidebar`\n- Sidebar groups contain `pages`\n- Page paths use `content` (legacy `slug` may still appear in older content)\n\nWhen adding a new doc page, add it to the appropriate tab sidebar path.\n\n## Versioned link policy (mandatory)\n\n- For v4 docs content, internal links MUST use explicit v4 paths: `/docs/v4/...`.\n- Do not use unversioned shortcuts like `/docs/alerting/...` in v4 pages.\n- Before finalizing, verify every internal link in edited files resolves to the intended version.\n\n## Required page format\n\n```markdown\n---\ntitle: Page Title\ndescription: One-line summary of user outcome\n---\n```\n\n- Use custom anchors for H2/H3 headings: `## Section {#section}`\n- Use GitHub admonitions only when needed: `[!NOTE]`, `[!IMPORTANT]`, `[!WARNING]`, `[!CAUTION]`, `[!TIP]`\n- Prefer short sections and short lists\n\n## Preferred structure (default)\n\n1. Short intro (1–2 sentences)\n2. Quick setup / minimum config\n3. Required variables/options table\n4. Verification step\n5. Top troubleshooting items\n\nOnly add extra sections if they materially improve task completion.\n\n## Keep docs lean\n\nRemove or avoid:\n\n- Multiple near-identical examples\n- Long conceptual explainers\n- Platform-by-platform repetition unless behavior differs\n- Large checklists that restate earlier content\n\n## Editing workflow\n\n1. Read the whole target document.\n2. Compress verbose sections first.\n3. Keep critical caveats and breaking notes.\n4. Ensure internal links and anchors still work.\n5. If adding files, update `docs.json` navigation in the correct version/tab.\n\n## Review checklist\n\n- [ ] Title/description frontmatter exists\n- [ ] Key steps are clear and copyable\n- [ ] Content is concise and non-duplicative\n- [ ] Headings keep stable custom anchors\n- [ ] Navigation updated (if new page)\n- [ ] Internal links point to correct paths\n- [ ] v4 pages use `/docs/v4/...` internal links (no unversioned `/docs/...` shortcuts)\n- [ ] No outdated or irrelevant content remains\n- [ ] Admonitions used appropriately for important notes\n\n\n---\nname: svelte-code-writer\ndescription: CLI tools for Svelte 5 documentation lookup and code analysis. MUST be used whenever creating or editing any Svelte component (.svelte) or Svelte module (.svelte.ts/.svelte.js). If possible, this skill should be executed within the svelte-file-editor agent for optimal results.\n---\n\n# Svelte 5 Code Writer\n\n## CLI Tools\n\nYou have access to `@sveltejs/mcp` CLI for Svelte-specific assistance. Use these commands via `npx`:\n\n### List Documentation Sections\n\n```bash\nnpx @sveltejs/mcp list-sections\n```\n\nLists all available Svelte 5 and SvelteKit documentation sections with titles and paths.\n\n### Get Documentation\n\n```bash\nnpx @sveltejs/mcp get-documentation \",,...\"\n```\n\nRetrieves full documentation for specified sections. Use after `list-sections` to fetch relevant docs.\n\n**Example:**\n\n```bash\nnpx @sveltejs/mcp get-documentation \"$state,$derived,$effect\"\n```\n\n### Svelte Autofixer\n\n```bash\nnpx @sveltejs/mcp svelte-autofixer \"\" [options]\n```\n\nAnalyzes Svelte code and suggests fixes for common issues.\n\n**Options:**\n\n- `--async` - Enable async Svelte mode (default: false)\n- `--svelte-version` - Target version: 4 or 5 (default: 5)\n\n**Examples:**\n\n```bash\n# Analyze inline code (escape $ as \\$)\nnpx @sveltejs/mcp svelte-autofixer ''\n\n# Analyze a file\nnpx @sveltejs/mcp svelte-autofixer ./src/lib/Component.svelte\n\n# Target Svelte 4\nnpx @sveltejs/mcp svelte-autofixer ./Component.svelte --svelte-version 4\n```\n\n**Important:** When passing code with runes (`$state`, `$derived`, etc.) via the terminal, escape the `$` character as `\\$` to prevent shell variable substitution.\n\n## Workflow\n\n1. **Uncertain about syntax?** Run `list-sections` then `get-documentation` for relevant topics\n2. **Reviewing/debugging?** Run `svelte-autofixer` on the code to detect issues\n3. **Always validate** - Run `svelte-autofixer` before finalizing any Svelte component\n\n\n---\nname: tailwindcss\ndescription: Tailwind CSS v4 utility-first styling patterns including responsive design, dark mode, and custom configuration. Use when styling with Tailwind, adding utility classes, configuring Tailwind, setting up dark mode, or customizing the theme.\nuser-invokable: false\nmetadata:\n category: styling\n---\n\n# Tailwind CSS v4 Development Guidelines\n\nBest practices for using Tailwind CSS v4 utility classes effectively.\n\n**Note**: Tailwind CSS v4 (released January 2025) uses a CSS-first configuration approach. If you need v3 compatibility, tailwind.config.js is still supported.\n\n## Core Principles\n\n1. **Utility-First**: Use utility classes instead of custom CSS\n2. **Mobile-First**: Design for mobile, then scale up with responsive modifiers\n3. **Component Extraction**: Extract repeated patterns into components\n4. **Consistent Spacing**: Use Tailwind's spacing scale\n5. **Custom Configuration**: Extend the default theme for brand consistency\n\n## Basic Utilities\n\n### Layout\n\n```tsx\n// Flexbox\n
\n
Content
\n
Sidebar
\n
\n\n// Grid\n
\n
1
\n
2
\n
3
\n
\n\n// Positioning\n
\n
Badge
\n
\n```\n\n### Spacing\n\n```tsx\n// Padding and Margin\n
{/* padding: 1rem, margin: 0.5rem */}\n
{/* padding-x: 1.5rem, padding-y: 1rem */}\n
{/* margin-top: 2rem, margin-bottom: 1rem */}\n\n// Space between children\n
{/* margin-bottom on all but last child */}\n
Item 1
\n
Item 2
\n
\n```\n\n### Typography\n\n```tsx\n

Heading

\n

\n Paragraph text with comfortable line height.\n

\nLabel\n```\n\n### Colors\n\n```tsx\n// Text colors\n

Text

\n\n// Background colors\n
Button
\n\n// Border colors\n
Box
\n```\n\n## Responsive Design\n\n### Breakpoints\n\n```tsx\n// Mobile-first responsive classes\n
\n {/* Full width on mobile, half on medium screens, third on large */}\n
\n\n

\n {/* Responsive text sizes */}\n

\n\n
\n {/* Responsive grid */}\n
\n```\n\n### Container\n\n```tsx\n
\n {/* Centered container with horizontal padding */}\n
\n\n
\n {/* Responsive container padding */}\n
\n```\n\n## Component Patterns\n\n### Button\n\n```tsx\n\n\n// Variants\n\n```\n\n### Card\n\n```tsx\n
\n \"\"\n
\n

Card Title

\n

Card content goes here.

\n
\n
\n```\n\n### Form Input\n\n```tsx\n
\n \n \n

We'll never share your email.

\n
\n```\n\n## State Variants\n\n### Hover, Focus, Active\n\n```tsx\n\n\n\n Link\n\n```\n\n### Group Hover\n\n```tsx\n
\n \n

Hover the container

\n
\n```\n\n### Disabled\n\n```tsx\n\n```\n\n## Dark Mode\n\n```css\n/* Tailwind v4: Configure in app/globals.css */\n@import \"tailwindcss\";\n\n@media (prefers-color-scheme: dark) {\n /* Or use class-based: .dark */\n}\n```\n\n```tsx\n// Usage (same as v3)\n
\n

Title

\n

Description

\n
\n```\n\n## Custom Styles\n\n### Arbitrary Values\n\n```tsx\n
{/* Custom top value */}\n
{/* Custom color */}\n
{/* Custom grid template */}\n```\n\n### @apply Directive\n\n```css\n/* components/button.css */\n.btn-primary {\n @apply rounded-md bg-blue-600 px-4 py-2 font-medium text-white;\n @apply hover:bg-blue-700 focus:ring-2 focus:ring-blue-500 focus:outline-none;\n @apply disabled:cursor-not-allowed disabled:opacity-50;\n}\n```\n\n## Configuration\n\n### Tailwind v4: CSS-First Configuration\n\n```css\n/* app/globals.css */\n@import \"tailwindcss\";\n\n@theme {\n /* Custom colors */\n --color-brand-50: #eff6ff;\n --color-brand-100: #dbeafe;\n --color-brand-900: #1e3a8a;\n\n /* Custom spacing */\n --spacing-128: 32rem;\n\n /* Custom fonts */\n --font-family-sans: \"Inter\", sans-serif;\n\n /* Custom breakpoints */\n --breakpoint-3xl: 1920px;\n}\n```\n\n### Tailwind v3 Config (Still Supported)\n\n```javascript\n// tailwind.config.js (optional in v4)\nmodule.exports = {\n content: [\"./app/**/*.{js,ts,jsx,tsx,mdx}\", \"./components/**/*.{js,ts,jsx,tsx,mdx}\"],\n theme: {\n extend: {\n colors: {\n brand: {\n 50: \"#eff6ff\",\n 100: \"#dbeafe\",\n 900: \"#1e3a8a\"\n }\n },\n spacing: {\n 128: \"32rem\"\n },\n fontFamily: {\n sans: [\"Inter\", \"sans-serif\"]\n }\n }\n },\n plugins: [require(\"@tailwindcss/forms\"), require(\"@tailwindcss/typography\")]\n}\n```\n\n## Plugins\n\n### Official Plugins\n\n```bash\nnpm install @tailwindcss/forms\nnpm install @tailwindcss/typography\nnpm install @tailwindcss/aspect-ratio\nnpm install @tailwindcss/container-queries\n```\n\n```tsx\n// @tailwindcss/forms\n\n\n// @tailwindcss/typography\n
\n

Article Title

\n

Content...

\n
\n```\n\n## Performance\n\n### Automatic Content Detection\n\nTailwind v4 automatically detects and scans all template files - no `content` configuration needed.\n\n### Build Performance\n\nTailwind v4 delivers 3.5x faster full builds (~100ms) compared to v3 using modern CSS features like `@property` and `color-mix()`.\n\n**Browser Requirements**: Safari 16.4+, Chrome 111+, Firefox 128+\n\n## Common Patterns\n\n### Centered Content\n\n```tsx\n
\n
Centered content
\n
\n```\n\n### Sticky Header\n\n```tsx\n
\n \n
\n```\n\n### Grid Layout\n\n```tsx\n
\n {posts.map((post) => (\n \n ))}\n
\n```\n\n### Truncate Text\n\n```tsx\n

This text will be truncated with ellipsis if too long

\n

This text will show max 3 lines with ellipsis

\n```\n\n## Best Practices\n\n1. **Use Consistent Spacing**: Stick to Tailwind's spacing scale\n2. **Responsive by Default**: Always consider mobile-first design\n3. **Extract Components**: Avoid repeating long class lists\n4. **Use Theme Colors**: Define custom colors in config, not arbitrary values\n5. **Leverage @apply Sparingly**: Prefer utility classes in JSX\n6. **Enable Dark Mode**: Plan for dark mode from the start\n7. **Use Plugins**: Leverage official plugins for common needs\n8. **Optimize Production**: Ensure purge is configured correctly\n\n\n# CLAUDE.md\n\n@AGENTS.md\n\n\n# Issue tracker: GitHub\n\nIssues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.\n\n## Conventions\n\n- **Create an issue**: `gh issue create --title \"...\" --body \"...\"`. Use a heredoc for multi-line bodies.\n- **Read an issue**: `gh issue view --comments`, filtering comments by `jq` and also fetching labels.\n- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.\n- **Comment on an issue**: `gh issue comment --body \"...\"`\n- **Apply / remove labels**: `gh issue edit --add-label \"...\"` / `--remove-label \"...\"`\n- **Close**: `gh issue close --comment \"...\"`\n\nInfer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.\n\n## When a skill says \"publish to the issue tracker\"\n\nCreate a GitHub issue.\n\n## When a skill says \"fetch the relevant ticket\"\n\nRun `gh issue view --comments`.\n"}