48 lines
2.2 KiB
Markdown
48 lines
2.2 KiB
Markdown
## 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
|