feat: scaffold SvelteKit project with Tailwind, TypeScript, ESLint, Prettier

Initialize the llm-multiverse-ui project with:
- SvelteKit + Svelte 5 (runes mode enabled)
- Tailwind CSS v4 via @tailwindcss/vite plugin
- TypeScript strict mode
- ESLint 9 flat config with svelte and typescript-eslint plugins
- Prettier with svelte plugin
- Directory structure: src/lib/components/, src/lib/services/
- All required scripts: dev, build, preview, lint, format, check

Closes #1

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.claude/commands/auto-dev.md

@@ -10,6 +10,7 @@ You are the **Auto Dev Orchestrator**. You run the full development pipeline in
 ## Auto-Merge Eligibility
 
 An issue is **auto-merge eligible** (no user approval needed) if ALL of these are true:
+
 - The issue does NOT have a `workflow:manual-review` label
 - All quality gates pass
 - Code review by the review agent returns APPROVE (no critical/major findings)
@@ -35,6 +36,7 @@ Run the story selection logic (same as `/project:select-story`):
 7. Present the top candidate to the user with issue number, title, milestone, labels, and summary
 
 **PAUSE HERE** — Wait for user confirmation before proceeding. The user may:
+
 - Confirm the selection
 - Pick a different issue number
 - Say "stop" to end the loop
@@ -87,6 +89,7 @@ Run the code review logic autonomously (same as `/project:code-review`):
 Based on verification AND code review results:
 
 **On PASS (verification passes AND code review APPROVE):**
+
 1. Update plan status to `COMPLETED`
 2. Push the feature branch to origin
 3. Create a Gitea pull request targeting `main`
@@ -103,11 +106,13 @@ Based on verification AND code review results:
 8. Loop back to Phase 1
 
 **On FAIL (attempt 1):**
+
 1. Update plan status to `RETRY`
 2. Append retry instructions to the plan (what failed and how to fix it)
 3. Loop back to Phase 3 (re-implement with retry instructions)
 
 **On FAIL (attempt 2):**
+
 1. Update plan status to `BLOCKED`
 2. Add `workflow:manual` label to the Gitea issue
 3. Inform the user: "Story #NNN blocked after 2 attempts. Marked for manual review."
@@ -116,6 +121,7 @@ Based on verification AND code review results:
 ### Phase 7 — MILESTONE CHECK
 
 After each completed story, check if all issues in the story's milestone are now closed. If so:
+
 1. Trigger the release logic (`/project:release <milestone>`) in **milestone-triggered** mode
 2. The release PR is created but NOT merged — it awaits user approval
 3. Inform the user: "All issues in <milestone> completed. Release PR created for your approval."
@@ -124,6 +130,7 @@ After each completed story, check if all issues in the story's milestone are now
 ### Phase 8 — PERIODIC REFACTORING CHECK
 
 After every 5 completed stories (tracked by the `completed` counter):
+
 1. Run the refactoring review logic (`/project:refactor-review`)
 2. Create refactoring issues as needed
 3. Close resolved tech debt issues
@@ -133,11 +140,13 @@ After every 5 completed stories (tracked by the `completed` counter):
 ## Stop Conditions
 
 Stop the loop when any of these occur:
+
 - The user says "stop"
 - No eligible issues remain (all are completed, blocked, or have unmet dependencies)
 - 3 consecutive stories are BLOCKED
 
 When stopping, display a summary of work completed:
+
 - Stories completed (with PR links)
 - Stories auto-merged vs awaiting review
 - Stories blocked (with failure reasons)
@@ -149,6 +158,7 @@ When stopping, display a summary of work completed:
 ## Tracking
 
 Maintain a running tally during the session:
+
 - `completed`: list of issue numbers with PR links
 - `auto_merged`: list of issue numbers that were auto-merged
 - `awaiting_review`: list of issue numbers with PRs awaiting manual review

.claude/commands/code-review.md

@@ -26,6 +26,7 @@ git diff main --name-only
 ```
 
 Read every changed file in full. Also read the diff for context on what changed:
+
 ```bash
 git diff main
 ```
@@ -35,23 +36,27 @@ git diff main
 Evaluate each changed file against these dimensions:
 
 **Correctness:**
+
 - Does the code do what the issue and plan require?
 - Are edge cases handled?
 - Are error conditions properly managed?
 
 **Security:**
+
 - No XSS vulnerabilities
 - No credentials or API keys in client-side code
 - No sensitive data stored insecurely
 - Proper input sanitization
 
 **Architecture:**
+
 - Component boundaries respected
 - State management follows project patterns
 - API communication uses established patterns
 - Proper separation of concerns
 
 **Code Quality:**
+
 - Idiomatic TypeScript/framework patterns
 - Consistent error handling
 - Meaningful variable and function names
@@ -59,17 +64,20 @@ Evaluate each changed file against these dimensions:
 - No `any` types without justification
 
 **Testing:**
+
 - Sufficient test coverage
 - Meaningful test cases (not just happy path)
 - Component tests for UI behavior
 - Proper mocking of external dependencies
 
 **Accessibility:**
+
 - Semantic HTML elements used
 - ARIA attributes where needed
 - Keyboard navigation support
 
 **Performance:**
+
 - No unnecessary re-renders
 - Proper memoization where beneficial
 - No memory leaks
@@ -78,12 +86,12 @@ Evaluate each changed file against these dimensions:
 
 Each finding MUST be categorized:
 
-| Severity | Description | Blocks Merge? |
-|---|---|---|
-| **Critical** | Security vulnerability, data loss risk, major architectural violation | Yes |
-| **Major** | Bug, missing error handling, test gap, significant design issue | Yes |
-| **Minor** | Style issue, naming improvement, small optimization, documentation gap | No |
-| **Suggestion** | Optional improvement, alternative approach worth considering | No |
+| Severity       | Description                                                            | Blocks Merge? |
+| -------------- | ---------------------------------------------------------------------- | ------------- |
+| **Critical**   | Security vulnerability, data loss risk, major architectural violation  | Yes           |
+| **Major**      | Bug, missing error handling, test gap, significant design issue        | Yes           |
+| **Minor**      | Style issue, naming improvement, small optimization, documentation gap | No            |
+| **Suggestion** | Optional improvement, alternative approach worth considering           | No            |
 
 ### 5. Produce Review Report
 
@@ -117,6 +125,7 @@ Request Changes: one or more critical/major findings
 ### 6. Handle Minor Findings
 
 If the verdict is **APPROVE** but there are minor findings:
+
 1. Create a single Gitea issue titled: "Tech debt: minor findings from issue #$ARGUMENTS review"
 2. List all minor findings in the issue body as checklist items
 3. Apply labels: `type:refactor`, `priority:low`, `cat:tech-debt`
@@ -125,6 +134,7 @@ If the verdict is **APPROVE** but there are minor findings:
 ### 7. Post Review to PR
 
 If a pull request exists for the feature branch:
+
 - Add a review comment via `mcp__gitea__pull_request_review_write`
 - If APPROVE: approve the PR
 - If REQUEST_CHANGES: request changes with the critical/major findings listed

.claude/commands/implement-story.md

@@ -20,6 +20,7 @@ An implementation plan MUST exist at `implementation-plans/issue-$ARGUMENTS.md`
 ### 1. Read the Plan and Context
 
 Read these files:
+
 - `implementation-plans/issue-$ARGUMENTS.md` — the implementation plan
 - `CLAUDE.md` — coding standards (if it exists)
 - `package.json` — project dependencies and scripts
@@ -64,6 +65,7 @@ Follow the plan's implementation steps in order:
 ### 6. Log Deviations
 
 If you deviate from the plan (different approach, additional files, skipped steps), document each deviation in the plan's **Deviation Log** section with:
+
 - What changed
 - Why it changed
 
@@ -81,6 +83,7 @@ Adapt commands based on what's available in `package.json`. Fix any failures bef
 ### 8. Commit
 
 Stage all changed files and commit with a descriptive message:
+
 ```
 feat: <short description of what was implemented> (issue #$ARGUMENTS)
 ```
@@ -90,6 +93,7 @@ Use conventional commit prefixes: `feat:`, `fix:`, `chore:`, `refactor:`, `test:
 ### 9. Output Summary
 
 Display:
+
 - Files created and modified (with counts)
 - Tests added (count)
 - Deviations from plan (if any)

.claude/commands/plan-story.md

@@ -20,6 +20,7 @@ Use `mcp__gitea__issue_read` to get the full issue (title, body, labels, milesto
 ### 2. Read Project Context
 
 Read these files to understand the project:
+
 - `CLAUDE.md` — coding standards and workflow (if it exists)
 - `package.json` — project dependencies and scripts
 - `implementation-plans/_index.md` — existing plans index (if it exists)
@@ -27,6 +28,7 @@ Read these files to understand the project:
 ### 3. Determine Technology Stack
 
 From the project files, determine:
+
 - **Framework:** React, Vue, Svelte, etc. (check package.json)
 - **Language:** TypeScript or JavaScript
 - **Build tool:** Vite, Next.js, Webpack, etc.
@@ -37,6 +39,7 @@ From the project files, determine:
 ### 4. Find Related Plans
 
 From the index (if it exists), identify plans that share:
+
 - The same feature area or component
 - Overlapping affected files
 - Dependency relationships (blocked-by / blocks)
@@ -46,6 +49,7 @@ Read those related plan files to understand prior decisions and patterns.
 ### 5. Explore the Codebase
 
 Based on the issue's scope, explore relevant code:
+
 - Use Glob to find files in affected directories
 - Use Grep to find existing patterns, interfaces, types, and components
 - Use Read to examine specific files mentioned in the issue or related plans
@@ -56,6 +60,7 @@ Based on the issue's scope, explore relevant code:
 The plan MUST include:
 
 **Metadata:**
+
 - Issue link, number, title
 - Milestone and labels
 - Status: `PLANNED`
@@ -64,9 +69,11 @@ The plan MUST include:
 - Blocked-by references
 
 **Acceptance Criteria:**
+
 - Copy directly from the issue body
 
 **Architecture Analysis:**
+
 - Which components/pages are affected
 - Which API endpoints are involved
 - Which state/stores are affected
@@ -74,6 +81,7 @@ The plan MUST include:
 - Existing patterns to follow (with file references)
 
 **Implementation Steps (phase by phase):**
+
 1. **Types & Configuration** — TypeScript types/interfaces, config constants, API types
 2. **Core Logic** — Business logic, hooks, utilities, state management
 3. **Components** — UI components, layouts, pages
@@ -81,9 +89,11 @@ The plan MUST include:
 5. **Tests** — Unit tests, component tests, E2E tests
 
 **Files to Create/Modify:**
+
 - Explicit file paths with a one-line purpose for each
 
 **Risks and Edge Cases:**
+
 - Potential issues and mitigation strategies
 
 **Important:** Include type definitions, component signatures, and hook interfaces in the plan, but do NOT write actual implementation code.
@@ -95,6 +105,7 @@ Write the plan to `implementation-plans/issue-$ARGUMENTS.md`.
 ### 8. Update the Index
 
 Create or update `implementation-plans/_index.md`:
+
 - Add the new plan to the master table
 - Add cross-references in the appropriate feature area section
 

.claude/commands/refactor-review.md

@@ -10,6 +10,7 @@ You are the **Refactoring Reviewer** agent. Your job is to review the entire pro
 ## Trigger
 
 This command is triggered:
+
 - Periodically (every ~5 completed stories) by the auto-dev pipeline
 - Manually by the user via `/project:refactor-review`
 
@@ -24,6 +25,7 @@ This command is triggered:
 ### 2. Survey the Codebase
 
 Explore all source directories:
+
 - Use Glob to find all source files (`src/**/*.ts`, `src/**/*.tsx`, `src/**/*.css`, `src/**/*.vue`, `src/**/*.svelte`, etc.)
 - Use Grep to find patterns of concern (see checklist below)
 - Read key files to understand current state
@@ -33,17 +35,20 @@ Explore all source directories:
 Evaluate the project against these dimensions:
 
 **Code Duplication:**
+
 - Shared logic duplicated across components instead of extracted to hooks/utilities
 - Similar UI patterns that should be abstracted into shared components
 - Repeated API call patterns that should use a shared data fetching layer
 
 **Modularity:**
+
 - Components longer than ~100 lines that should be split
 - Components with too many responsibilities
 - Tight coupling between feature modules
 - Missing abstractions
 
 **Consistency:**
+
 - Inconsistent error handling patterns
 - Inconsistent state management approaches
 - Inconsistent API call patterns
@@ -51,21 +56,25 @@ Evaluate the project against these dimensions:
 - Inconsistent styling approaches
 
 **Architecture Drift:**
+
 - Components bypassing the established API layer
 - State management inconsistencies
 - Routing pattern violations
 
 **Dependency Health:**
+
 - Unused dependencies in package.json
 - Outdated dependencies with known vulnerabilities
 - Lock file hygiene
 
 **Test Quality:**
+
 - Tests that only test happy paths
 - Missing component tests for interactive features
 - Test code duplication
 
 **Accessibility:**
+
 - Missing ARIA attributes on interactive elements
 - Missing keyboard navigation
 - Missing alt text on images
@@ -74,11 +83,11 @@ Evaluate the project against these dimensions:
 
 Categorize each finding:
 
-| Priority | Description |
-|---|---|
-| **High** | Architecture drift, security concern, significant duplication, accessibility blockers |
-| **Medium** | Modularity issues, inconsistencies, test quality gaps |
-| **Low** | Style issues, minor duplication, documentation gaps |
+| Priority   | Description                                                                           |
+| ---------- | ------------------------------------------------------------------------------------- |
+| **High**   | Architecture drift, security concern, significant duplication, accessibility blockers |
+| **Medium** | Modularity issues, inconsistencies, test quality gaps                                 |
+| **Low**    | Style issues, minor duplication, documentation gaps                                   |
 
 ### 5. Create Refactoring Issues
 

.claude/commands/release.md

@@ -55,6 +55,7 @@ git checkout -b release/<milestone-slug> main
 ### 4. Create Release PR
 
 Push the release branch and create a Gitea PR:
+
 - **Title:** `Release: <milestone-name>`
 - **Head:** `release/<milestone-slug>`
 - **Base:** `main`
@@ -79,6 +80,7 @@ If **manually requested:** Proceed to merge.
 ### 6. Create Gitea Release
 
 Use `mcp__gitea__create_release`:
+
 - **tag_name:** `<milestone-slug>`
 - **target:** `main`
 - **title:** `<milestone-name>`
@@ -91,6 +93,7 @@ Use `mcp__gitea__milestone_write` to set the milestone state to `closed`.
 ### 8. Output Summary
 
 Display:
+
 - Milestone name and version
 - PR number and merge status
 - Tag created

.claude/commands/select-story.md

@@ -16,6 +16,7 @@ Use `mcp__gitea__list_issues` to fetch all open issues. Paginate with `perPage:
 ### 2. Filter Out Ineligible Issues
 
 Remove any issue that has:
+
 - Label `workflow:manual`
 - Label `workflow:blocked`
 
@@ -32,10 +33,12 @@ For each candidate issue, read its body and look for a "Blocked by" section. If
 Sort remaining issues using this priority order:
 
 **Milestone priority (earliest milestone first):**
+
 - Sort by milestone due date (earliest first)
 - Issues with no milestone come last
 
 **Within the same milestone, sort by priority label:**
+
 1. `priority:critical`
 2. `priority:high`
 3. `priority:medium`
@@ -45,6 +48,7 @@ Sort remaining issues using this priority order:
 ### 6. Present the Top Candidate
 
 Display the highest-priority issue with:
+
 - Issue number and title
 - Milestone name
 - All labels

.claude/commands/verify-story.md

@@ -27,26 +27,31 @@ Check `package.json` and the plan to know which quality gates to run.
 Run each gate and record pass/fail:
 
 Gate 1 — Build:
+
 ```bash
 npm run build
 ```
 
 Gate 2 — Lint:
+
 ```bash
 npm run lint
 ```
 
 Gate 3 — Type Check:
+
 ```bash
 npm run typecheck  # or npx tsc --noEmit
 ```
 
 Gate 4 — Tests:
+
 ```bash
 npm run test
 ```
 
 Gate 5 — Format (if available):
+
 ```bash
 npm run format:check  # or npx prettier --check .
 ```
@@ -58,23 +63,27 @@ Adapt commands based on what's available in `package.json`.
 Review all files changed in this branch (use `git diff main --name-only` to get the list). For each changed file, verify:
 
 **General:**
+
 - [ ] No hardcoded credentials, API keys, or secrets
 - [ ] No `TODO` or `FIXME` left unresolved (unless documented in plan)
 - [ ] Consistent error handling patterns
 - [ ] No `console.log` left in production code
 
 **TypeScript:**
+
 - [ ] No `any` types without justification
 - [ ] Proper type narrowing and null checks
 - [ ] Interfaces/types exported where needed
 
 **Components:**
+
 - [ ] Proper prop typing
 - [ ] Loading, error, and empty states handled
 - [ ] Accessible markup (semantic HTML, ARIA)
 - [ ] Responsive design considered
 
 **Security:**
+
 - [ ] No XSS vulnerabilities
 - [ ] User input properly sanitized
 - [ ] API tokens/secrets not in client-side code
@@ -82,6 +91,7 @@ Review all files changed in this branch (use `git diff main --name-only` to get
 ### 5. Acceptance Criteria Verification
 
 For each acceptance criterion from the issue:
+
 - Check the code to verify the criterion is met
 - Note which file(s) satisfy each criterion
 - Mark each criterion as PASS or FAIL with explanation
@@ -89,6 +99,7 @@ For each acceptance criterion from the issue:
 ### 6. Determine Result
 
 **PASS** if ALL of the following are true:
+
 - All quality gates pass
 - No architecture violations found (major/critical)
 - All acceptance criteria are met