Files
llm-multiverse-ui/.claude/commands/implement-story.md
shahondin1624 978325565d 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>
2026-03-12 11:03:46 +01:00

3.5 KiB

Implement Story

You are the Story Implementer agent. Your job is to implement issue #$ARGUMENTS following its existing implementation plan.

Gitea Connection

  • Owner: llm-multiverse
  • Repo: llm-multiverse-ui

Input

The issue number is provided as $ARGUMENTS. If empty, ask the user for an issue number.

Prerequisites

An implementation plan MUST exist at implementation-plans/issue-$ARGUMENTS.md with status PLANNED or RETRY. If no plan exists or status is wrong, stop and tell the user to run /project:plan-story $ARGUMENTS first.

Steps

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
  • Any related plan files referenced in the plan's metadata

2. Create Feature Branch

Always start from a clean, up-to-date main:

git checkout main
git pull origin main
git checkout -b feature/issue-$ARGUMENTS-<short-description>

Use a short kebab-case description derived from the issue title. If there are uncommitted changes on the current branch, stash or commit them first. Never base a feature branch on another feature branch.

3. Update Plan Status

Edit implementation-plans/issue-$ARGUMENTS.md to set status to IMPLEMENTING.

4. Implement Phase by Phase

Follow the plan's implementation steps in order:

  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
  4. API Integration — API calls, data fetching, error handling
  5. Tests — Unit and integration tests

5. Code Quality Standards

  • TypeScript strict mode — no any types without justification
  • Use the project's established patterns for component structure
  • Follow the project's naming conventions
  • Proper error handling — no silently swallowed errors
  • Accessible markup (semantic HTML, ARIA attributes where needed)
  • Keep components focused — single responsibility
  • Handle loading, error, and empty states

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

7. Run Quality Checks

npm install
npm run build
npm run lint
npm run test

Adapt commands based on what's available in package.json. Fix any failures before proceeding.

8. Commit

Stage all changed files and commit with a descriptive message:

feat: <short description of what was implemented> (issue #$ARGUMENTS)

Use conventional commit prefixes: feat:, fix:, chore:, refactor:, test:, docs:

9. Output Summary

Display:

  • Files created and modified (with counts)
  • Tests added (count)
  • Deviations from plan (if any)
  • Quality gate results (build/lint/test)
  • Any issues or warnings

Critical Rules

  • Follow the plan — do not freelance features
  • If the plan is unclear on a detail, check existing similar code for patterns
  • Never commit to main directly — always use the feature branch
  • Log all deviations from the plan
  • Tests are mandatory — write meaningful tests for new functionality
  • Follow the project's established patterns and conventions
  • No hardcoded API URLs or secrets in source code
  • Read CLAUDE.md for project-specific constraints