Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions .agents/skills/api-module/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
---
name: api-module
description: Add an API endpoint module to packages/api-client from an OpenAPI schema. Use for new backend endpoints, API client modules, or tasks that provide an OpenAPI schema.
---

# Add an API Module

Read the applicable `AGENTS.md` files before you edit code.

Read [the API module standard](../../../standards/frontend/ADDING_API_MODULES.md) in full.

1. Identify the OpenAPI schema from the request. If more than one schema is possible, ask the user to select one.
2. Read the schema. Identify each endpoint, HTTP method, request type, response type, and path parameter.
3. Get the service and version from the URL prefix. For example, map `/v3/projects` to `labrinth/v3/`.
4. Define the API types in `types.ts`. Make each type match the schema exactly.
5. Do not change, rename, or remove API fields.
6. Make a module class that extends `AbstractModule`. Implement each endpoint with `this.client.request()` or `this.client.upload()`.
7. Use the request-option pattern from the standard. Do not call `$fetch`, `fetch`, or another HTTP client directly.
8. Add the module to `MODULE_REGISTRY` so the client can instantiate it.
9. Export new service types from the applicable barrel `index.ts`.
10. Check the module paths, registry key, public type exports, and endpoint types.

Run only the checks that the user or the applicable `AGENTS.md` permits.
4 changes: 4 additions & 0 deletions .agents/skills/api-module/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Add API Module"
short_description: "Add typed API client modules from OpenAPI"
default_prompt: "Use $api-module to add an API client module from this OpenAPI schema."
38 changes: 38 additions & 0 deletions .agents/skills/cross-platform-pages/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
---
name: cross-platform-pages
description: Convert a page to the shared Modrinth page system for the website and desktop app. Use for shared layouts, wrapped layouts, or platform dependency-injection contracts.
---

# Convert a Cross-Platform Page

Read the applicable `AGENTS.md` files before you edit code.

Read these standards in full:

- [Cross-platform pages](../../../standards/frontend/CROSS_PLATFORM_PAGES.md)
- [Dependency injection](../../../standards/frontend/DEPENDENCY_INJECTION.md)

1. Identify the target page from the request.
2. Read the page and its route shell. Identify data sources, mutations, navigation, and platform APIs.
3. Use a wrapped layout when both platforms use the same API source and page logic.
4. Use a shared layout when platform data or operations have different implementations.

For a shared layout:

1. Define a provider contract for all platform operations.
2. Put common UI and state logic in the shared layout.
3. Put reusable search, filter, and selection logic in local composables.
4. Implement the contract in `apps/frontend/` and `apps/app-frontend/`.
5. Use optional contract fields only for capabilities that are not available on both platforms.

For a wrapped layout:

1. Move the page to `packages/ui/src/layouts/wrapped/` and preserve its route structure.
2. Replace platform-only imports with common utilities or provider calls.
3. Make each frontend route shell render the wrapped component.
4. Match primary query options in both route shells when the layout uses `ReadyTransition` and `useReadyState`.
5. Prefetch these queries with `ensureQueryData`, as the standard specifies.

Check that both route shells resolve their imports. Check that all required provider fields have implementations.

Run only the checks that the user or the applicable `AGENTS.md` permits.
4 changes: 4 additions & 0 deletions .agents/skills/cross-platform-pages/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Convert Cross-Platform Page"
short_description: "Share pages across the web and desktop app"
default_prompt: "Use $cross-platform-pages to convert this page for the website and desktop app."
28 changes: 28 additions & 0 deletions .agents/skills/figma-mcp/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
---
name: figma-mcp
description: Convert a Figma design into a Modrinth Vue page or component. Use when a request provides a Figma URL or asks to implement a Figma layout.
---

# Implement a Figma Design

Read the applicable `AGENTS.md` files before you edit code.

Read these files in full:

- [Figma MCP usage](../../../standards/frontend/FIGMA_MCP_USAGE.md)
- `packages/ui/AGENTS.md`

1. Get the Figma URL from the request.
2. Extract the `fileKey` and `nodeId`. Replace each `-` in the node ID with `:`.
3. Load any available Figma design-to-code instructions before you call `get_design_context`.
4. Call `get_design_context` first. Use `clientLanguages: "typescript,html,css"` and `clientFrameworks: "vue"`.
5. Map Figma color variables to the applicable `surface-*` and `text-*` tokens.
6. Do not use aliased Figma names directly.
7. Search `packages/ui/src/components/` for applicable components before you make new components.
8. Read `packages/assets/styles/variables.scss` when Figma does not supply a required token.
9. Use exact spacing values from the design.
10. Use `get_screenshot` for more visual detail when necessary.
11. Use `get_variable_defs` when a token is not clear.
12. Implement the result as a Vue SFC with Tailwind classes and the existing component library.

Run only the checks that the user or the applicable `AGENTS.md` permits.
4 changes: 4 additions & 0 deletions .agents/skills/figma-mcp/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Implement Figma Design"
short_description: "Build Modrinth Vue UI from Figma designs"
default_prompt: "Use $figma-mcp to implement this Figma design as a Modrinth Vue component."
32 changes: 32 additions & 0 deletions .agents/skills/i18n-pass/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
name: i18n-pass
description: Convert hard-coded English text in changed Vue components to the @modrinth/ui localization system. Use for an i18n pass, untranslated-string review, pull request, or component migration.
---

# Do an Internationalization Pass

Read the applicable `AGENTS.md` files before you edit code.

Read [the internationalization standard](../../../standards/frontend/INTERNATIONALIZATION.md) in full.

1. Identify the scope from the request.
2. For a pull request, use `gh pr diff <number>` to identify changed files.
3. For a file path, inspect that file.
4. When the request gives no scope, inspect the current uncommitted diff.
5. Limit the pass to changed `.vue` files.
6. Find user-visible text in templates and scripts.

Check inner text, `alt`, `placeholder`, `aria-label`, buttons, tooltips, notifications, dropdown labels, and error messages.

Do not change dynamic expressions, HTML tag names, CSS classes, internal identifiers, or log messages.

1. Define stable message IDs with `defineMessage` or `defineMessages`.
2. Replace simple text with `formatMessage()` calls.
3. Use `<IntlFormatted>` for text that contains links or markup.
4. Use ICU selections and plurals when grammar depends on a value.
5. Add a space before `}}` when an ICU placeholder ends at the Vue delimiter.
6. Do not change component logic, layout, or reactivity.
7. Do not edit localization JSON files. The user maintains those files.
8. Check the changed templates again for hard-coded English text.

Run only the checks that the user or the applicable `AGENTS.md` permits.
4 changes: 4 additions & 0 deletions .agents/skills/i18n-pass/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Run Internationalization Pass"
short_description: "Localize user-visible text in Vue files"
default_prompt: "Use $i18n-pass to localize the user-visible text in these changed Vue files."
40 changes: 40 additions & 0 deletions .agents/skills/review-changelog/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
---
name: review-changelog
description: Review the latest packages/blog/changelog.ts entry against the Modrinth changelog standard. Use before a pull request or when asked to review or lint a changelog entry.
---

# Review a Changelog Entry

Read [the changelog standard](../../../standards/maintaining/CHANGELOG.md) in full before the review.

1. Open `packages/blog/changelog.ts`.
2. Find the first entry in the `VERSIONS` array.
3. If the request names `web`, `hosting`, or `app`, review the latest entry for that product.
4. Otherwise, review the latest entry and all adjacent entries with the same date.

Check the entry structure:

- `date` contains a valid ISO 8601 timestamp.
- `product` is `web`, `hosting`, or `app`.
- An `app` entry has a `version` value.
- A `web` or `hosting` entry does not have a `version` value.
- Standard headings are `## Added`, `## Changed`, `## Fixed`, and `## Security`.
- A featured release can use a linked heading.
- Flag the legacy `## Improvements` heading.

Check each bullet:

- The voice and tense agree with the section.
- The first verb agrees with the section.
- The bullet describes user-visible behavior, not implementation.
- The bullet identifies the applicable page, tab, modal, or feature.
- The bullet contains one sentence, uses sentence case, and ends with a period.
- Product and UI names use the public labels.
- The bullet does not contain filler, vague intensifiers, apologies, or internal references.
- The bullet is not a duplicate detail of a larger listed change.

Group findings by entry. For each finding, show the original bullet and a proposed replacement.

If the entry has no findings, state this result. Do not edit the changelog unless the user asks you to apply fixes.

When the user asks for fixes, preserve tab indentation and template-literal formatting.
4 changes: 4 additions & 0 deletions .agents/skills/review-changelog/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Review Changelog"
short_description: "Review changelog entries for style problems"
default_prompt: "Use $review-changelog to review the latest changelog entry."
39 changes: 39 additions & 0 deletions .agents/skills/tanstack-query/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
name: tanstack-query
description: Convert Vue server-state code to TanStack Query. Use for useQuery, useMutation, cache invalidation, optimistic updates, or replacement of useAsyncData and manual ref patterns.
---

# Convert Data Code to TanStack Query

Read the applicable `AGENTS.md` files before you edit code.

Read [the TanStack Query standard](../../../standards/frontend/FETCHING_DATA.md) in full.

1. Identify the target file from the request.
2. Find `useAsyncData`, `useFetch`, manual API refs, and fetch calls in `onMounted`.
3. Identify mutations that use manual loading, error, or result refs.

For queries:

1. Replace manual fetch logic with `useQuery`.
2. Get `api-client` with `injectModrinthClient()`.
3. Use a hierarchical query key with the resource, qualifier, and parameters.
4. Use a computed query key for reactive parameters.
5. Use a computed `enabled` option when the query depends on other data.
6. Use a shared query-option factory when multiple components use the query.

For mutations:

1. Replace manual mutation state with `useMutation`.
2. Invalidate or update related query data after success.
3. Use an optimistic update only when the UI needs an immediate response.
4. Cancel the applicable query and save its prior data before an optimistic update.
5. Restore the prior data after an error. Invalidate the query after settlement.

Remove manual loading and error refs that TanStack Query replaces. Remove obsolete `onMounted` fetch calls.

Keep Nuxt SSR behavior. Match route-shell prefetch options when `ReadyTransition` and `useReadyState` depend on the query.

Check query keys, invalidation prefixes, reactive values, and rollback data.

Run only the checks that the user or the applicable `AGENTS.md` permits.
4 changes: 4 additions & 0 deletions .agents/skills/tanstack-query/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Migrate to TanStack Query"
short_description: "Migrate Vue server state to TanStack Query"
default_prompt: "Use $tanstack-query to migrate this Vue component to TanStack Query."
18 changes: 0 additions & 18 deletions .claude/skills/api-module/SKILL.md

This file was deleted.

26 changes: 0 additions & 26 deletions .claude/skills/cross-platform-pages/SKILL.md

This file was deleted.

22 changes: 0 additions & 22 deletions .claude/skills/figma-mcp/SKILL.md

This file was deleted.

24 changes: 0 additions & 24 deletions .claude/skills/i18n-pass/SKILL.md

This file was deleted.

Loading
Loading