## Project Configuration

- **Language**: TypeScript
- **Package Manager**: npm
- **Add-ons**: none

---

# AGENTS.md

## Svelte Plugin Guardrails

This project uses the `@sveltejs/opencode` plugin. **Always incorporate it when working on Svelte code.**

### MCP Tools (always available)

- **`svelte_list-sections`**: Call FIRST for any Svelte/SvelteKit question to discover relevant documentation sections
- **`svelte_get-documentation`**: Fetch full docs for the sections found above — fetch ALL relevant sections, not just one
- **`svelte_svelte-autofixer`**: MUST be called on every `.svelte` component or module before delivering code. Call repeatedly until zero issues remain
- **`svelte_playground-link`**: Offer a playground link after completing Svelte code (only if code was NOT written to the project)

### Required Workflow for Svelte Code

1. Before writing any Svelte code, call `svelte_list-sections` then `svelte_get-documentation` for relevant topics
2. After writing Svelte code, run `svelte_svelte-autofixer` until it reports no issues
3. Offer a playground link via `svelte_playground-link` when appropriate

### OpenSpec Integration

When working through OpenSpec artifacts (`/opsx-*` commands), apply the same Svelte plugin workflow during:
- **Design phase**: Research Svelte docs for architecture decisions
- **Specs phase**: Reference Svelte documentation for capability specifications
- **Tasks phase**: Use autofixer to validate all generated code

### Skills

Load `svelte-core-bestpractices` skill when writing or reviewing Svelte components. Load `svelte-code-writer` skill for CLI-based documentation lookups and code analysis.

## Git Commit Convention

All git commits must follow [Google's conventional commit message format](https://github.com/googleapis/google-claude/blob/main/docs/completion-conventions.md):

- **Subject line**: Maximum 50 characters, imperative mood, no period at the end
- **Format**: `<type>[optional scope]: <description>`
- **Allowed types**: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `build`, `ci`, `chore`, `perf`
- **Body** (if needed): Blank line after subject, then detailed explanation wrapped at 72 characters
- **Footer** (if needed): Use for breaking changes (`BREAKING CHANGE: ...`) and issue references