{"owner":"moeru-ai","repo":"airi","hasSkills":true,"totalSkillsCount":6,"totalTokensCount":5010,"categories":["root-instruction","copilot-instructions","mcp-config","marketplace","plugin-manifest","cursor-rule"],"hasMcp":true,"mcpConfig":{"mcpServers":{"airi":{"command":"npx","args":["-y","@modelcontextprotocol/server-airi"]}}},"found":["AGENTS.md",".github/copilot-instructions.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json",".cursorrules (code-pair-interviews.mdc)"],"skills":{"AGENTS.md":"# Project AIRI Agent Guide\n\nThis file gives the core rules for all work in the `moeru-ai/airi` monorepo. Skills and nested `AGENTS.md` files give the rules for specific tasks. Before you start a task, find it in [Task Routing](#task-routing) and read the listed file.\n\n## Project Map\n\nAll apps use Vue 3, Vite, TypeScript, Pinia, VueUse, UnoCSS, Vitest, and ESLint.\n\n| Path | Content |\n| --- | --- |\n| `apps/stage-web` | The web app. It uses Vue Router. |\n| `apps/stage-tamagotchi` | The Electron desktop app. |\n| `apps/stage-pocket` | The mobile app. It uses Vue Router, Capacitor, Kotlin, and Swift. |\n| `packages/stage-ui` | Business components, composables, and stores that stage-web and stage-tamagotchi share. |\n| `packages/stage-ui-three` | Three.js bindings and Vue components. |\n| `packages/stage-shared` | Logic that the stage packages and the stage apps share. |\n| `packages/stage-pages` | Shared page bases. |\n| `packages/stage-layouts` | Shared layouts, including the stage-web settings layout. |\n| `packages/ui` | Primitives built on reka-ui, such as inputs, buttons, and layout. They have minimal business logic. |\n| `packages/i18n` | All translations. |\n| `packages/server-runtime`, `packages/server-sdk`, `packages/server-shared` | The server channel that `services/` and `plugins/` use. |\n| `server/apps/api` | The hosted Hono resource API and its business domains. |\n| `server/apps/auth` | The standalone Better Auth and OIDC service. |\n| `server/packages` | Backend-only schema and Node infrastructure packages. |\n| `server/dev/caddy` | Local Auth and API edge routing. |\n| `server/docker-compose.yaml` | The complete local backend stack. |\n\nKey files and directories:\n\n- Pages are in `apps/stage-web/src/pages` and `apps/stage-tamagotchi/src/renderer/pages`. Devtools pages are in the `devtools` folder of each.\n- The router configuration is in `apps/stage-web/vite.config.ts` and `apps/stage-tamagotchi/electron.vite.config.ts`.\n- The settings layouts are `packages/stage-layouts/src/layouts/settings.vue` (stage-web) and `apps/stage-tamagotchi/src/renderer/layouts/settings.vue`.\n- A settings or devtools page needs `<route lang=\"yaml\"> meta: layout: settings </route>`. Register its route and icon in the settings layout.\n- In `packages/stage-ui/src`, provider definitions are in `stores/providers/` and orchestration modules are in `stores/modules/`.\n- Business composables are in `packages/stage-ui/src/composables/`. Business components are in `packages/stage-ui/src/components/`.\n- Put a component for one page or one use case in `packages/stage-ui/src/components/scenarios/`.\n- Stories are in `packages/stage-ui/stories`, with `packages/stage-ui/histoire.config.ts`. An example is `packages/stage-ui/src/components/misc/Button.story.vue`.\n- Eventa contracts are in `apps/stage-tamagotchi/src/shared`. Main and renderer usage examples are in `apps/stage-tamagotchi/src/main/services/electron`.\n- The dependency injection example is `apps/stage-tamagotchi/src/main/index.ts`.\n- Style configuration is in `uno.config.ts`. Existing animations are in `apps/stage-web/src/styles`.\n- CI pipelines are in `.github/workflows`. Lint rules are in `eslint.config.ts`.\n\n## Commands\n\nUse pnpm workspace filters to limit a command to one workspace. Replace `<package name>` with the `name` field in `package.json`, for example `@proj-airi/stage-tamagotchi`.\n\n- Typecheck one workspace: `pnpm -F <package name> typecheck`. For stage-tamagotchi, this command runs `tsc` and `vue-tsc`.\n- Test one file: `pnpm -F <package name> exec vitest run <path>`. Give `<path>` relative to the workspace.\n- Test one workspace: `pnpm -F <package name> exec vitest run`.\n- Test all workspaces: `pnpm test:run`. Turbo runs the `test:run` script of each workspace, with its browser projects.\n- Test the root scripts in `.github/scripts`: `pnpm test:root`. The root `vitest.config.ts` has only these tests.\n- Test the changes of a branch: run the `test:run` script of each changed workspace and of each workspace that depends on it.\n  Use the merge base with `origin/main` as the base.\n\n  ```sh\n  base=$(git merge-base origin/main HEAD)\n  TURBO_SCM_BASE=\"$base\" pnpm exec turbo run test:run --affected\n  ```\n\n  If the branch changes `.github/scripts`, also run `pnpm test:root`.\n\n- Lint: `pnpm lint`. ESLint also does the formatting. To fix lint and format errors, run `pnpm lint:fix`.\n- Build one workspace: `pnpm -F <package name> build`. For stage-tamagotchi, this command runs the typecheck and `electron-vite build`.\n\n## Scope and Checks\n\n- Keep each change inside the scope of the task.\n- In each function, component, or test that you change, correct the code that does not obey a current rule. Do not change other code only to improve it.\n- Do not add one-off patterns. Before you write a new utility or function, search for an existing internal implementation.\n- If new logic can become a shared utility, propose the shared approach to the user.\n- If a refactor is small, do it step by step.\n- After a task, run the typecheck and the related tests for each workspace that you changed.\n- Before you create a PR or push to one, run the tests of the branch changes. CI runs every project, including the browser projects.\n- If a change alters UI structure, layout, or interaction, review the related browser and end-to-end tests.\n- If intended behavior changes, update the affected assertions. Keep valid regression checks. Do not delete an assertion only to make a test pass.\n- After the final UI change, run the related tests on the final commit.\n- Before you report a CI success, make sure that CI tested the current PR head.\n- If you change a shared package or an exported type, also run the root `pnpm typecheck`.\n- Run `pnpm lint` before you finish.\n- Report only the checks that you ran. Give each command and its result.\n- At the end, summarize the changes, the commands that you ran, and the follow-up work.\n\n## Code Rules\n\n- Put shared logic in `packages/`. Keep module boundaries clear.\n- Use kebab-case for all file names.\n- Do not use `any`. Prefer type generics. Use `as unknown as <Type>` only when you cannot fix the type safely.\n- Omit TypeScript and JavaScript source extensions in relative imports, dynamic imports, and re-exports. Write `./module`, not `./module.ts` or `./module.js`. Keep an extension only when the runtime or asset format requires it.\n- Do not edit `tsconfig.json` to hide an import or type error. Find and fix the cause.\n- Treat a circular import as a design problem. First reconsider ownership and module boundaries. If you cannot resolve the cycle confidently, ask the user.\n- Use `@moeru/eventa` for all IPC, RPC, and cross-process events. Define the contracts in one central place, such as `apps/stage-tamagotchi/src/shared`.\n- Use dependency injection only at external boundaries: databases, model runtimes, queues, caches, filesystems, networks, clocks, environments, and feature gates. Use `injeca` for it.\n- Do not add dependency objects for internal functions that only call sibling helpers or forward parameters.\n- Prefer classes for runtime or browser APIs. Also prefer classes for substantial business modules that own state, lifecycle, or a stable domain boundary.\n- Prefer functions for pure transformations and local helpers.\n- Use Valibot for schema validation. Keep each schema near its consumers.\n- Use `errorMessageFrom(error)` from `@moeru/std` to get an error message. Add `?? 'fallback'` when you need a default. For other error handling, prefer the `@moeru/std` patterns.\n- Mark every workaround with a `// NOTICE:` comment in this format:\n\n  ```ts\n  // NOTICE:\n  // Why this workaround is needed.\n  // Root cause summary.\n  // Source/context (file, issue, URL, or node_modules reference).\n  // Removal condition (when it can be safely deleted).\n  ```\n\n### Backward Compatibility\n\n- Do not add backward-compatibility guards.\n- If old callers or old data need extended support, write a refactor document with the target shape. Then start another Codex or Claude Code session from the shell to do the refactor.\n- If a compatibility fallback must stay for a limited time, mark it with `// NOTICE:` and give its removal condition.\n- If a compatibility fallback is permanent, document it as supported policy. Do not call it legacy.\n- A nested `AGENTS.md` can override this rule for a public contract. It must name the root rule that it overrides.\n\n### Dependencies\n\n- Prefer `es-toolkit` for general utilities. Ask the user before you add another general utility library, such as a package from `unjs` or `tinylib`.\n- Some features use `node:*` built-in modules, DOM operations, Vue composables, React hooks, Vite plugins, or GitHub Actions workflows. For these features, research existing libraries first.\n- Before you choose a library, ask the user to choose. Help the user compare the options.\n- If the user works spec-driven, list the candidate libraries in a Markdown comparison table.\n- If the user asks you to use a specific tool or dependency, read its documentation in Context7 first. Then examine how this repository uses it.\n- If Context7 returns several names without a clear difference, ask the user to choose one.\n- If the documentation conflicts with the typecheck result, examine the dependency source in `node_modules` to find the cause.\n\n## Documentation\n\n- Put project-wide and client ADRs in `docs/ai/adr/`. Put hosted backend ADRs in `server/docs/ai/adr/`, and obey the ADR rules in `server/AGENTS.md`.\n- Put a documentation change in the same commit or PR as the code that it describes. This rule applies to ADRs, `README.md` files, and component references.\n- Put agent configuration changes in their own commit. Agent configuration includes `AGENTS.md`, `CLAUDE.md`, skills, and `.github/copilot-instructions.md`.\n- If the agent configuration describes the code of a PR, put its commit in that PR. Do not open a second PR for it.\n- Keep a structured `README.md` in each `packages/` and `apps/` entry. It tells what the entry does, how to use it, when to use it, and when not to use it.\n- Put all translations in `packages/i18n`. By default, edit only the English source locale and your own locale.\n- Do not edit other locales unless the user asks. Crowdin manages them, and the next Crowdin sync can replace local edits.\n- Do not use English text as a placeholder in other locales. Add only the locales you implement.\n- When you add a nested `AGENTS.md`, add a `CLAUDE.md` next to it that contains only `@AGENTS.md`. The root `CLAUDE.md` stops Claude Code from reading a nested `AGENTS.md` without this file.\n\n## Writing\n\n- For text, obey the [`simple-english`](.agents/skills/simple-english/SKILL.md) skill. Text includes documentation, code comments, commit messages, and PR and issue text.\n- Do not apply the skill to code, identifiers, commands, or quoted errors.\n- This repository breaks these rules most often:\n  - Do not write \"should\", \"may\", \"might\", \"could\", or \"would\". Write \"must\" or \"can\", or state the fact.\n  - Do not use semicolons. Write two sentences.\n  - Write \"for example\" and \"that is\". Do not write \"e.g.\", \"i.e.\", or \"etc.\".\n  - Write an instruction in 20 words or fewer. Write a description in 25 words or fewer.\n  - Put a condition before its command.\n\n## Git and Pull Requests\n\n- Use Conventional Commits, for example `feat(<package name>): add runner reconnect backoff`. Do not use gitmoji.\n- Name branches `username/feat/short-name`.\n- Rebase when you pull.\n- To create, open, publish, or prepare a pull request, use the [`create-pr`](.agents/skills/create-pr/SKILL.md) skill. It also covers visual evidence and review follow-up.\n\n## Task Routing\n\nSkills are in `.agents/skills/<name>/SKILL.md`. Read the listed file before you start the task.\n\n| Task | Read |\n| --- | --- |\n| Design, change, or review UI appearance and interaction | [AIRI Design Guide](DESIGN.md) |\n| Write, refactor, or review TypeScript or Vue code | [`enforce-rules-for-typescript`](.agents/skills/enforce-rules-for-typescript/SKILL.md) |\n| Write or debug tests, reproduce a bug, add mocks, or fix test import boundaries | [`enforce-rules-for-vitest`](.agents/skills/enforce-rules-for-vitest/SKILL.md) |\n| Change UnoCSS, Vue styles, UI components, animations, icons, or color mode | [`enforce-rules-for-unocss`](.agents/skills/enforce-rules-for-unocss/SKILL.md) |\n| Add `synced` to a Pinia store, or change a synced store | [`enforce-rules-for-pinia-synced`](.agents/skills/enforce-rules-for-pinia-synced/SKILL.md) |\n| Write or change a string that users see, or a glossary term | [`packages/i18n/AGENTS.md`](packages/i18n/AGENTS.md) |\n| Review pending Crowdin translations, or find why approved translations did not reach the repository | [`enforce-rules-for-i18n`](.agents/skills/enforce-rules-for-i18n/SKILL.md) |\n| Work under `server/` | [`server/AGENTS.md`](server/AGENTS.md). For `server/apps/api`, also read [`server/apps/api/AGENTS.md`](server/apps/api/AGENTS.md). |\n| Write documentation, code comments, commit messages, or PR and issue text | [`simple-english`](.agents/skills/simple-english/SKILL.md) |\n| Analyze why a chat, speech, or audio turn was slow or failed, using saved IO traces | [`analyze-io-traces`](.agents/skills/analyze-io-traces/SKILL.md) |\n| Create or prepare a pull request | [`create-pr`](.agents/skills/create-pr/SKILL.md) |\n| Upload a local file through a file input or a file chooser in a web or Electron app | [`use-agent-browser-with-input-file`](.agents/skills/use-agent-browser-with-input-file/SKILL.md) and [`agent-browser`](.agents/skills/agent-browser/SKILL.md). For Electron, also read [`agent-browser-electron`](.agents/skills/agent-browser-electron/SKILL.md). |\n| Test Live2D, VRM, or MMD import and rendering in stage-web, stage-tamagotchi, or stage-pocket | [`use-agent-browser-for-airi`](.agents/skills/use-agent-browser-for-airi/SKILL.md) |\n\nThese directories also have their own `AGENTS.md`. Read it before you work in the directory:\n\n- `packages/model-driver-mediapipe/`\n- `services/computer-use-mcp/`\n",".github/copilot-instructions.md":"# Copilot repository instructions\n\nThis is the `moeru-ai/airi` pnpm monorepo. Prefer the smallest safe change and keep every task inside its stated scope.\n\n## General rules\n\n- Follow the root `AGENTS.md` instructions.\n- Do not modify unrelated files.\n- Do not mix agent configuration changes and runtime logic changes in one commit. They can share one PR. Put documentation that describes the changed code in the same commit.\n- Do not change package files, lockfiles, or workspace configuration unless the task explicitly requires it.\n- Preserve existing test style and helpers.\n- Do not claim tests passed unless you actually ran them.\n- Report exact commands, exit codes, and relevant pass/fail output.\n\n## Validation\n\n- Use package-scoped pnpm commands where possible.\n- Run the narrowest relevant test first.\n- Run typecheck if runtime contracts or exported types changed.\n- Run affected package tests if shared logic changed.\n- Run `git diff --check` before finalizing when possible.\n\n## Output format\n\n1. Confirmed facts\n2. Files changed\n3. Commands run\n4. Test results\n5. Remaining risks\n6. Keep / revert / split recommendation\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.claude-plugin/plugin.json)",".cursorrules (code-pair-interviews.mdc)":"---\ndescription: \"Cursor rules for code pair interviews development with integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert software developer focused on producing clean, well-structured, and professional-quality code, suitable for a code pair programming interview.\n\nCode Structure and Organization\n\n-   Organize code logically with a clear separation of concerns.\n-   Break down problems into smaller, self-contained units using functions and classes.\n-   Ensure modularity and reusability of code components.\n-   Adhere to the Single Responsibility Principle: each function/class should have one specific job.\n-   When tackling complex problems, begin by outlining a high-level plan before writing code.\n-   Start with a simple, straightforward solution to the core problem, optimizing later if time allows.\n-   Select appropriate data structures and algorithms with a focus on clarity and efficiency.\n    -   Example: Use a hash map for quick lookups when appropriate.\n\nCoding Style\n\n-   Maintain consistent indentation using 2 spaces (prefer spaces over tabs).\n-   Use meaningful and descriptive names for variables, functions, and classes.\n    -   Avoid single-letter or cryptic abbreviations.\n    -   Example: Use `calculate_total_cost` instead of `calc`.\n-   Employ comments judiciously to explain non-obvious logic or provide high-level overviews.\n    -   Use docstrings for functions and methods to describe purpose, parameters, and return values.\n    -   Avoid over-commenting self-explanatory code.\n-   Keep lines of code within a reasonable length (80-100 characters) to enhance readability.\n-   Use blank lines to separate logical blocks of code and improve visual organization.\n\nCoding Best Practices\n\n-   Write clean and readable code.\n-   Prioritize clarity in code structure and style.\n-   Consider edge cases and implement error handling.\n-   Strive for efficient solutions.\n-   Test code thoroughly with various inputs, including edge cases.\n-   Start simple and optimize later.\n"},"files":{"AGENTS.md":"# Project AIRI Agent Guide\n\nThis file gives the core rules for all work in the `moeru-ai/airi` monorepo. Skills and nested `AGENTS.md` files give the rules for specific tasks. Before you start a task, find it in [Task Routing](#task-routing) and read the listed file.\n\n## Project Map\n\nAll apps use Vue 3, Vite, TypeScript, Pinia, VueUse, UnoCSS, Vitest, and ESLint.\n\n| Path | Content |\n| --- | --- |\n| `apps/stage-web` | The web app. It uses Vue Router. |\n| `apps/stage-tamagotchi` | The Electron desktop app. |\n| `apps/stage-pocket` | The mobile app. It uses Vue Router, Capacitor, Kotlin, and Swift. |\n| `packages/stage-ui` | Business components, composables, and stores that stage-web and stage-tamagotchi share. |\n| `packages/stage-ui-three` | Three.js bindings and Vue components. |\n| `packages/stage-shared` | Logic that the stage packages and the stage apps share. |\n| `packages/stage-pages` | Shared page bases. |\n| `packages/stage-layouts` | Shared layouts, including the stage-web settings layout. |\n| `packages/ui` | Primitives built on reka-ui, such as inputs, buttons, and layout. They have minimal business logic. |\n| `packages/i18n` | All translations. |\n| `packages/server-runtime`, `packages/server-sdk`, `packages/server-shared` | The server channel that `services/` and `plugins/` use. |\n| `server/apps/api` | The hosted Hono resource API and its business domains. |\n| `server/apps/auth` | The standalone Better Auth and OIDC service. |\n| `server/packages` | Backend-only schema and Node infrastructure packages. |\n| `server/dev/caddy` | Local Auth and API edge routing. |\n| `server/docker-compose.yaml` | The complete local backend stack. |\n\nKey files and directories:\n\n- Pages are in `apps/stage-web/src/pages` and `apps/stage-tamagotchi/src/renderer/pages`. Devtools pages are in the `devtools` folder of each.\n- The router configuration is in `apps/stage-web/vite.config.ts` and `apps/stage-tamagotchi/electron.vite.config.ts`.\n- The settings layouts are `packages/stage-layouts/src/layouts/settings.vue` (stage-web) and `apps/stage-tamagotchi/src/renderer/layouts/settings.vue`.\n- A settings or devtools page needs `<route lang=\"yaml\"> meta: layout: settings </route>`. Register its route and icon in the settings layout.\n- In `packages/stage-ui/src`, provider definitions are in `stores/providers/` and orchestration modules are in `stores/modules/`.\n- Business composables are in `packages/stage-ui/src/composables/`. Business components are in `packages/stage-ui/src/components/`.\n- Put a component for one page or one use case in `packages/stage-ui/src/components/scenarios/`.\n- Stories are in `packages/stage-ui/stories`, with `packages/stage-ui/histoire.config.ts`. An example is `packages/stage-ui/src/components/misc/Button.story.vue`.\n- Eventa contracts are in `apps/stage-tamagotchi/src/shared`. Main and renderer usage examples are in `apps/stage-tamagotchi/src/main/services/electron`.\n- The dependency injection example is `apps/stage-tamagotchi/src/main/index.ts`.\n- Style configuration is in `uno.config.ts`. Existing animations are in `apps/stage-web/src/styles`.\n- CI pipelines are in `.github/workflows`. Lint rules are in `eslint.config.ts`.\n\n## Commands\n\nUse pnpm workspace filters to limit a command to one workspace. Replace `<package name>` with the `name` field in `package.json`, for example `@proj-airi/stage-tamagotchi`.\n\n- Typecheck one workspace: `pnpm -F <package name> typecheck`. For stage-tamagotchi, this command runs `tsc` and `vue-tsc`.\n- Test one file: `pnpm -F <package name> exec vitest run <path>`. Give `<path>` relative to the workspace.\n- Test one workspace: `pnpm -F <package name> exec vitest run`.\n- Test all workspaces: `pnpm test:run`. Turbo runs the `test:run` script of each workspace, with its browser projects.\n- Test the root scripts in `.github/scripts`: `pnpm test:root`. The root `vitest.config.ts` has only these tests.\n- Test the changes of a branch: run the `test:run` script of each changed workspace and of each workspace that depends on it.\n  Use the merge base with `origin/main` as the base.\n\n  ```sh\n  base=$(git merge-base origin/main HEAD)\n  TURBO_SCM_BASE=\"$base\" pnpm exec turbo run test:run --affected\n  ```\n\n  If the branch changes `.github/scripts`, also run `pnpm test:root`.\n\n- Lint: `pnpm lint`. ESLint also does the formatting. To fix lint and format errors, run `pnpm lint:fix`.\n- Build one workspace: `pnpm -F <package name> build`. For stage-tamagotchi, this command runs the typecheck and `electron-vite build`.\n\n## Scope and Checks\n\n- Keep each change inside the scope of the task.\n- In each function, component, or test that you change, correct the code that does not obey a current rule. Do not change other code only to improve it.\n- Do not add one-off patterns. Before you write a new utility or function, search for an existing internal implementation.\n- If new logic can become a shared utility, propose the shared approach to the user.\n- If a refactor is small, do it step by step.\n- After a task, run the typecheck and the related tests for each workspace that you changed.\n- Before you create a PR or push to one, run the tests of the branch changes. CI runs every project, including the browser projects.\n- If a change alters UI structure, layout, or interaction, review the related browser and end-to-end tests.\n- If intended behavior changes, update the affected assertions. Keep valid regression checks. Do not delete an assertion only to make a test pass.\n- After the final UI change, run the related tests on the final commit.\n- Before you report a CI success, make sure that CI tested the current PR head.\n- If you change a shared package or an exported type, also run the root `pnpm typecheck`.\n- Run `pnpm lint` before you finish.\n- Report only the checks that you ran. Give each command and its result.\n- At the end, summarize the changes, the commands that you ran, and the follow-up work.\n\n## Code Rules\n\n- Put shared logic in `packages/`. Keep module boundaries clear.\n- Use kebab-case for all file names.\n- Do not use `any`. Prefer type generics. Use `as unknown as <Type>` only when you cannot fix the type safely.\n- Omit TypeScript and JavaScript source extensions in relative imports, dynamic imports, and re-exports. Write `./module`, not `./module.ts` or `./module.js`. Keep an extension only when the runtime or asset format requires it.\n- Do not edit `tsconfig.json` to hide an import or type error. Find and fix the cause.\n- Treat a circular import as a design problem. First reconsider ownership and module boundaries. If you cannot resolve the cycle confidently, ask the user.\n- Use `@moeru/eventa` for all IPC, RPC, and cross-process events. Define the contracts in one central place, such as `apps/stage-tamagotchi/src/shared`.\n- Use dependency injection only at external boundaries: databases, model runtimes, queues, caches, filesystems, networks, clocks, environments, and feature gates. Use `injeca` for it.\n- Do not add dependency objects for internal functions that only call sibling helpers or forward parameters.\n- Prefer classes for runtime or browser APIs. Also prefer classes for substantial business modules that own state, lifecycle, or a stable domain boundary.\n- Prefer functions for pure transformations and local helpers.\n- Use Valibot for schema validation. Keep each schema near its consumers.\n- Use `errorMessageFrom(error)` from `@moeru/std` to get an error message. Add `?? 'fallback'` when you need a default. For other error handling, prefer the `@moeru/std` patterns.\n- Mark every workaround with a `// NOTICE:` comment in this format:\n\n  ```ts\n  // NOTICE:\n  // Why this workaround is needed.\n  // Root cause summary.\n  // Source/context (file, issue, URL, or node_modules reference).\n  // Removal condition (when it can be safely deleted).\n  ```\n\n### Backward Compatibility\n\n- Do not add backward-compatibility guards.\n- If old callers or old data need extended support, write a refactor document with the target shape. Then start another Codex or Claude Code session from the shell to do the refactor.\n- If a compatibility fallback must stay for a limited time, mark it with `// NOTICE:` and give its removal condition.\n- If a compatibility fallback is permanent, document it as supported policy. Do not call it legacy.\n- A nested `AGENTS.md` can override this rule for a public contract. It must name the root rule that it overrides.\n\n### Dependencies\n\n- Prefer `es-toolkit` for general utilities. Ask the user before you add another general utility library, such as a package from `unjs` or `tinylib`.\n- Some features use `node:*` built-in modules, DOM operations, Vue composables, React hooks, Vite plugins, or GitHub Actions workflows. For these features, research existing libraries first.\n- Before you choose a library, ask the user to choose. Help the user compare the options.\n- If the user works spec-driven, list the candidate libraries in a Markdown comparison table.\n- If the user asks you to use a specific tool or dependency, read its documentation in Context7 first. Then examine how this repository uses it.\n- If Context7 returns several names without a clear difference, ask the user to choose one.\n- If the documentation conflicts with the typecheck result, examine the dependency source in `node_modules` to find the cause.\n\n## Documentation\n\n- Put project-wide and client ADRs in `docs/ai/adr/`. Put hosted backend ADRs in `server/docs/ai/adr/`, and obey the ADR rules in `server/AGENTS.md`.\n- Put a documentation change in the same commit or PR as the code that it describes. This rule applies to ADRs, `README.md` files, and component references.\n- Put agent configuration changes in their own commit. Agent configuration includes `AGENTS.md`, `CLAUDE.md`, skills, and `.github/copilot-instructions.md`.\n- If the agent configuration describes the code of a PR, put its commit in that PR. Do not open a second PR for it.\n- Keep a structured `README.md` in each `packages/` and `apps/` entry. It tells what the entry does, how to use it, when to use it, and when not to use it.\n- Put all translations in `packages/i18n`. By default, edit only the English source locale and your own locale.\n- Do not edit other locales unless the user asks. Crowdin manages them, and the next Crowdin sync can replace local edits.\n- Do not use English text as a placeholder in other locales. Add only the locales you implement.\n- When you add a nested `AGENTS.md`, add a `CLAUDE.md` next to it that contains only `@AGENTS.md`. The root `CLAUDE.md` stops Claude Code from reading a nested `AGENTS.md` without this file.\n\n## Writing\n\n- For text, obey the [`simple-english`](.agents/skills/simple-english/SKILL.md) skill. Text includes documentation, code comments, commit messages, and PR and issue text.\n- Do not apply the skill to code, identifiers, commands, or quoted errors.\n- This repository breaks these rules most often:\n  - Do not write \"should\", \"may\", \"might\", \"could\", or \"would\". Write \"must\" or \"can\", or state the fact.\n  - Do not use semicolons. Write two sentences.\n  - Write \"for example\" and \"that is\". Do not write \"e.g.\", \"i.e.\", or \"etc.\".\n  - Write an instruction in 20 words or fewer. Write a description in 25 words or fewer.\n  - Put a condition before its command.\n\n## Git and Pull Requests\n\n- Use Conventional Commits, for example `feat(<package name>): add runner reconnect backoff`. Do not use gitmoji.\n- Name branches `username/feat/short-name`.\n- Rebase when you pull.\n- To create, open, publish, or prepare a pull request, use the [`create-pr`](.agents/skills/create-pr/SKILL.md) skill. It also covers visual evidence and review follow-up.\n\n## Task Routing\n\nSkills are in `.agents/skills/<name>/SKILL.md`. Read the listed file before you start the task.\n\n| Task | Read |\n| --- | --- |\n| Design, change, or review UI appearance and interaction | [AIRI Design Guide](DESIGN.md) |\n| Write, refactor, or review TypeScript or Vue code | [`enforce-rules-for-typescript`](.agents/skills/enforce-rules-for-typescript/SKILL.md) |\n| Write or debug tests, reproduce a bug, add mocks, or fix test import boundaries | [`enforce-rules-for-vitest`](.agents/skills/enforce-rules-for-vitest/SKILL.md) |\n| Change UnoCSS, Vue styles, UI components, animations, icons, or color mode | [`enforce-rules-for-unocss`](.agents/skills/enforce-rules-for-unocss/SKILL.md) |\n| Add `synced` to a Pinia store, or change a synced store | [`enforce-rules-for-pinia-synced`](.agents/skills/enforce-rules-for-pinia-synced/SKILL.md) |\n| Write or change a string that users see, or a glossary term | [`packages/i18n/AGENTS.md`](packages/i18n/AGENTS.md) |\n| Review pending Crowdin translations, or find why approved translations did not reach the repository | [`enforce-rules-for-i18n`](.agents/skills/enforce-rules-for-i18n/SKILL.md) |\n| Work under `server/` | [`server/AGENTS.md`](server/AGENTS.md). For `server/apps/api`, also read [`server/apps/api/AGENTS.md`](server/apps/api/AGENTS.md). |\n| Write documentation, code comments, commit messages, or PR and issue text | [`simple-english`](.agents/skills/simple-english/SKILL.md) |\n| Analyze why a chat, speech, or audio turn was slow or failed, using saved IO traces | [`analyze-io-traces`](.agents/skills/analyze-io-traces/SKILL.md) |\n| Create or prepare a pull request | [`create-pr`](.agents/skills/create-pr/SKILL.md) |\n| Upload a local file through a file input or a file chooser in a web or Electron app | [`use-agent-browser-with-input-file`](.agents/skills/use-agent-browser-with-input-file/SKILL.md) and [`agent-browser`](.agents/skills/agent-browser/SKILL.md). For Electron, also read [`agent-browser-electron`](.agents/skills/agent-browser-electron/SKILL.md). |\n| Test Live2D, VRM, or MMD import and rendering in stage-web, stage-tamagotchi, or stage-pocket | [`use-agent-browser-for-airi`](.agents/skills/use-agent-browser-for-airi/SKILL.md) |\n\nThese directories also have their own `AGENTS.md`. Read it before you work in the directory:\n\n- `packages/model-driver-mediapipe/`\n- `services/computer-use-mcp/`\n",".github/copilot-instructions.md":"# Copilot repository instructions\n\nThis is the `moeru-ai/airi` pnpm monorepo. Prefer the smallest safe change and keep every task inside its stated scope.\n\n## General rules\n\n- Follow the root `AGENTS.md` instructions.\n- Do not modify unrelated files.\n- Do not mix agent configuration changes and runtime logic changes in one commit. They can share one PR. Put documentation that describes the changed code in the same commit.\n- Do not change package files, lockfiles, or workspace configuration unless the task explicitly requires it.\n- Preserve existing test style and helpers.\n- Do not claim tests passed unless you actually ran them.\n- Report exact commands, exit codes, and relevant pass/fail output.\n\n## Validation\n\n- Use package-scoped pnpm commands where possible.\n- Run the narrowest relevant test first.\n- Run typecheck if runtime contracts or exported types changed.\n- Run affected package tests if shared logic changed.\n- Run `git diff --check` before finalizing when possible.\n\n## Output format\n\n1. Confirmed facts\n2. Files changed\n3. Commands run\n4. Test results\n5. Remaining risks\n6. Keep / revert / split recommendation\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.claude-plugin/plugin.json)",".cursorrules (code-pair-interviews.mdc)":"---\ndescription: \"Cursor rules for code pair interviews development with integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert software developer focused on producing clean, well-structured, and professional-quality code, suitable for a code pair programming interview.\n\nCode Structure and Organization\n\n-   Organize code logically with a clear separation of concerns.\n-   Break down problems into smaller, self-contained units using functions and classes.\n-   Ensure modularity and reusability of code components.\n-   Adhere to the Single Responsibility Principle: each function/class should have one specific job.\n-   When tackling complex problems, begin by outlining a high-level plan before writing code.\n-   Start with a simple, straightforward solution to the core problem, optimizing later if time allows.\n-   Select appropriate data structures and algorithms with a focus on clarity and efficiency.\n    -   Example: Use a hash map for quick lookups when appropriate.\n\nCoding Style\n\n-   Maintain consistent indentation using 2 spaces (prefer spaces over tabs).\n-   Use meaningful and descriptive names for variables, functions, and classes.\n    -   Avoid single-letter or cryptic abbreviations.\n    -   Example: Use `calculate_total_cost` instead of `calc`.\n-   Employ comments judiciously to explain non-obvious logic or provide high-level overviews.\n    -   Use docstrings for functions and methods to describe purpose, parameters, and return values.\n    -   Avoid over-commenting self-explanatory code.\n-   Keep lines of code within a reasonable length (80-100 characters) to enhance readability.\n-   Use blank lines to separate logical blocks of code and improve visual organization.\n\nCoding Best Practices\n\n-   Write clean and readable code.\n-   Prioritize clarity in code structure and style.\n-   Consider edge cases and implement error handling.\n-   Strive for efficient solutions.\n-   Test code thoroughly with various inputs, including edge cases.\n-   Start simple and optimize later.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/moeru-ai/airi/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Project AIRI Agent Guide\n\nThis file gives the core rules for all work in the `moeru-ai/airi` monorepo. Skills and nested `AGENTS.md` files give the rules for specific tasks. Before you start a task, find it in [Task Routing](#task-routing) and read the listed file.\n\n## Project Map\n\nAll apps use Vue 3, Vite, TypeScript, Pinia, VueUse, UnoCSS, Vitest, and ESLint.\n\n| Path | Content |\n| --- | --- |\n| `apps/stage-web` | The web app. It uses Vue Router. |\n| `apps/stage-tamagotchi` | The Electron desktop app. |\n| `apps/stage-pocket` | The mobile app. It uses Vue Router, Capacitor, Kotlin, and Swift. |\n| `packages/stage-ui` | Business components, composables, and stores that stage-web and stage-tamagotchi share. |\n| `packages/stage-ui-three` | Three.js bindings and Vue components. |\n| `packages/stage-shared` | Logic that the stage packages and the stage apps share. |\n| `packages/stage-pages` | Shared page bases. |\n| `packages/stage-layouts` | Shared layouts, including the stage-web settings layout. |\n| `packages/ui` | Primitives built on reka-ui, such as inputs, buttons, and layout. They have minimal business logic. |\n| `packages/i18n` | All translations. |\n| `packages/server-runtime`, `packages/server-sdk`, `packages/server-shared` | The server channel that `services/` and `plugins/` use. |\n| `server/apps/api` | The hosted Hono resource API and its business domains. |\n| `server/apps/auth` | The standalone Better Auth and OIDC service. |\n| `server/packages` | Backend-only schema and Node infrastructure packages. |\n| `server/dev/caddy` | Local Auth and API edge routing. |\n| `server/docker-compose.yaml` | The complete local backend stack. |\n\nKey files and directories:\n\n- Pages are in `apps/stage-web/src/pages` and `apps/stage-tamagotchi/src/renderer/pages`. Devtools pages are in the `devtools` folder of each.\n- The router configuration is in `apps/stage-web/vite.config.ts` and `apps/stage-tamagotchi/electron.vite.config.ts`.\n- The settings layouts are `packages/stage-layouts/src/layouts/settings.vue` (stage-web) and `apps/stage-tamagotchi/src/renderer/layouts/settings.vue`.\n- A settings or devtools page needs `<route lang=\"yaml\"> meta: layout: settings </route>`. Register its route and icon in the settings layout.\n- In `packages/stage-ui/src`, provider definitions are in `stores/providers/` and orchestration modules are in `stores/modules/`.\n- Business composables are in `packages/stage-ui/src/composables/`. Business components are in `packages/stage-ui/src/components/`.\n- Put a component for one page or one use case in `packages/stage-ui/src/components/scenarios/`.\n- Stories are in `packages/stage-ui/stories`, with `packages/stage-ui/histoire.config.ts`. An example is `packages/stage-ui/src/components/misc/Button.story.vue`.\n- Eventa contracts are in `apps/stage-tamagotchi/src/shared`. Main and renderer usage examples are in `apps/stage-tamagotchi/src/main/services/electron`.\n- The dependency injection example is `apps/stage-tamagotchi/src/main/index.ts`.\n- Style configuration is in `uno.config.ts`. Existing animations are in `apps/stage-web/src/styles`.\n- CI pipelines are in `.github/workflows`. Lint rules are in `eslint.config.ts`.\n\n## Commands\n\nUse pnpm workspace filters to limit a command to one workspace. Replace `<package name>` with the `name` field in `package.json`, for example `@proj-airi/stage-tamagotchi`.\n\n- Typecheck one workspace: `pnpm -F <package name> typecheck`. For stage-tamagotchi, this command runs `tsc` and `vue-tsc`.\n- Test one file: `pnpm -F <package name> exec vitest run <path>`. Give `<path>` relative to the workspace.\n- Test one workspace: `pnpm -F <package name> exec vitest run`.\n- Test all workspaces: `pnpm test:run`. Turbo runs the `test:run` script of each workspace, with its browser projects.\n- Test the root scripts in `.github/scripts`: `pnpm test:root`. The root `vitest.config.ts` has only these tests.\n- Test the changes of a branch: run the `test:run` script of each changed workspace and of each workspace that depends on it.\n  Use the merge base with `origin/main` as the base.\n\n  ```sh\n  base=$(git merge-base origin/main HEAD)\n  TURBO_SCM_BASE=\"$base\" pnpm exec turbo run test:run --affected\n  ```\n\n  If the branch changes `.github/scripts`, also run `pnpm test:root`.\n\n- Lint: `pnpm lint`. ESLint also does the formatting. To fix lint and format errors, run `pnpm lint:fix`.\n- Build one workspace: `pnpm -F <package name> build`. For stage-tamagotchi, this command runs the typecheck and `electron-vite build`.\n\n## Scope and Checks\n\n- Keep each change inside the scope of the task.\n- In each function, component, or test that you change, correct the code that does not obey a current rule. Do not change other code only to improve it.\n- Do not add one-off patterns. Before you write a new utility or function, search for an existing internal implementation.\n- If new logic can become a shared utility, propose the shared approach to the user.\n- If a refactor is small, do it step by step.\n- After a task, run the typecheck and the related tests for each workspace that you changed.\n- Before you create a PR or push to one, run the tests of the branch changes. CI runs every project, including the browser projects.\n- If a change alters UI structure, layout, or interaction, review the related browser and end-to-end tests.\n- If intended behavior changes, update the affected assertions. Keep valid regression checks. Do not delete an assertion only to make a test pass.\n- After the final UI change, run the related tests on the final commit.\n- Before you report a CI success, make sure that CI tested the current PR head.\n- If you change a shared package or an exported type, also run the root `pnpm typecheck`.\n- Run `pnpm lint` before you finish.\n- Report only the checks that you ran. Give each command and its result.\n- At the end, summarize the changes, the commands that you ran, and the follow-up work.\n\n## Code Rules\n\n- Put shared logic in `packages/`. Keep module boundaries clear.\n- Use kebab-case for all file names.\n- Do not use `any`. Prefer type generics. Use `as unknown as <Type>` only when you cannot fix the type safely.\n- Omit TypeScript and JavaScript source extensions in relative imports, dynamic imports, and re-exports. Write `./module`, not `./module.ts` or `./module.js`. Keep an extension only when the runtime or asset format requires it.\n- Do not edit `tsconfig.json` to hide an import or type error. Find and fix the cause.\n- Treat a circular import as a design problem. First reconsider ownership and module boundaries. If you cannot resolve the cycle confidently, ask the user.\n- Use `@moeru/eventa` for all IPC, RPC, and cross-process events. Define the contracts in one central place, such as `apps/stage-tamagotchi/src/shared`.\n- Use dependency injection only at external boundaries: databases, model runtimes, queues, caches, filesystems, networks, clocks, environments, and feature gates. Use `injeca` for it.\n- Do not add dependency objects for internal functions that only call sibling helpers or forward parameters.\n- Prefer classes for runtime or browser APIs. Also prefer classes for substantial business modules that own state, lifecycle, or a stable domain boundary.\n- Prefer functions for pure transformations and local helpers.\n- Use Valibot for schema validation. Keep each schema near its consumers.\n- Use `errorMessageFrom(error)` from `@moeru/std` to get an error message. Add `?? 'fallback'` when you need a default. For other error handling, prefer the `@moeru/std` patterns.\n- Mark every workaround with a `// NOTICE:` comment in this format:\n\n  ```ts\n  // NOTICE:\n  // Why this workaround is needed.\n  // Root cause summary.\n  // Source/context (file, issue, URL, or node_modules reference).\n  // Removal condition (when it can be safely deleted).\n  ```\n\n### Backward Compatibility\n\n- Do not add backward-compatibility guards.\n- If old callers or old data need extended support, write a refactor document with the target shape. Then start another Codex or Claude Code session from the shell to do the refactor.\n- If a compatibility fallback must stay for a limited time, mark it with `// NOTICE:` and give its removal condition.\n- If a compatibility fallback is permanent, document it as supported policy. Do not call it legacy.\n- A nested `AGENTS.md` can override this rule for a public contract. It must name the root rule that it overrides.\n\n### Dependencies\n\n- Prefer `es-toolkit` for general utilities. Ask the user before you add another general utility library, such as a package from `unjs` or `tinylib`.\n- Some features use `node:*` built-in modules, DOM operations, Vue composables, React hooks, Vite plugins, or GitHub Actions workflows. For these features, research existing libraries first.\n- Before you choose a library, ask the user to choose. Help the user compare the options.\n- If the user works spec-driven, list the candidate libraries in a Markdown comparison table.\n- If the user asks you to use a specific tool or dependency, read its documentation in Context7 first. Then examine how this repository uses it.\n- If Context7 returns several names without a clear difference, ask the user to choose one.\n- If the documentation conflicts with the typecheck result, examine the dependency source in `node_modules` to find the cause.\n\n## Documentation\n\n- Put project-wide and client ADRs in `docs/ai/adr/`. Put hosted backend ADRs in `server/docs/ai/adr/`, and obey the ADR rules in `server/AGENTS.md`.\n- Put a documentation change in the same commit or PR as the code that it describes. This rule applies to ADRs, `README.md` files, and component references.\n- Put agent configuration changes in their own commit. Agent configuration includes `AGENTS.md`, `CLAUDE.md`, skills, and `.github/copilot-instructions.md`.\n- If the agent configuration describes the code of a PR, put its commit in that PR. Do not open a second PR for it.\n- Keep a structured `README.md` in each `packages/` and `apps/` entry. It tells what the entry does, how to use it, when to use it, and when not to use it.\n- Put all translations in `packages/i18n`. By default, edit only the English source locale and your own locale.\n- Do not edit other locales unless the user asks. Crowdin manages them, and the next Crowdin sync can replace local edits.\n- Do not use English text as a placeholder in other locales. Add only the locales you implement.\n- When you add a nested `AGENTS.md`, add a `CLAUDE.md` next to it that contains only `@AGENTS.md`. The root `CLAUDE.md` stops Claude Code from reading a nested `AGENTS.md` without this file.\n\n## Writing\n\n- For text, obey the [`simple-english`](.agents/skills/simple-english/SKILL.md) skill. Text includes documentation, code comments, commit messages, and PR and issue text.\n- Do not apply the skill to code, identifiers, commands, or quoted errors.\n- This repository breaks these rules most often:\n  - Do not write \"should\", \"may\", \"might\", \"could\", or \"would\". Write \"must\" or \"can\", or state the fact.\n  - Do not use semicolons. Write two sentences.\n  - Write \"for example\" and \"that is\". Do not write \"e.g.\", \"i.e.\", or \"etc.\".\n  - Write an instruction in 20 words or fewer. Write a description in 25 words or fewer.\n  - Put a condition before its command.\n\n## Git and Pull Requests\n\n- Use Conventional Commits, for example `feat(<package name>): add runner reconnect backoff`. Do not use gitmoji.\n- Name branches `username/feat/short-name`.\n- Rebase when you pull.\n- To create, open, publish, or prepare a pull request, use the [`create-pr`](.agents/skills/create-pr/SKILL.md) skill. It also covers visual evidence and review follow-up.\n\n## Task Routing\n\nSkills are in `.agents/skills/<name>/SKILL.md`. Read the listed file before you start the task.\n\n| Task | Read |\n| --- | --- |\n| Design, change, or review UI appearance and interaction | [AIRI Design Guide](DESIGN.md) |\n| Write, refactor, or review TypeScript or Vue code | [`enforce-rules-for-typescript`](.agents/skills/enforce-rules-for-typescript/SKILL.md) |\n| Write or debug tests, reproduce a bug, add mocks, or fix test import boundaries | [`enforce-rules-for-vitest`](.agents/skills/enforce-rules-for-vitest/SKILL.md) |\n| Change UnoCSS, Vue styles, UI components, animations, icons, or color mode | [`enforce-rules-for-unocss`](.agents/skills/enforce-rules-for-unocss/SKILL.md) |\n| Add `synced` to a Pinia store, or change a synced store | [`enforce-rules-for-pinia-synced`](.agents/skills/enforce-rules-for-pinia-synced/SKILL.md) |\n| Write or change a string that users see, or a glossary term | [`packages/i18n/AGENTS.md`](packages/i18n/AGENTS.md) |\n| Review pending Crowdin translations, or find why approved translations did not reach the repository | [`enforce-rules-for-i18n`](.agents/skills/enforce-rules-for-i18n/SKILL.md) |\n| Work under `server/` | [`server/AGENTS.md`](server/AGENTS.md). For `server/apps/api`, also read [`server/apps/api/AGENTS.md`](server/apps/api/AGENTS.md). |\n| Write documentation, code comments, commit messages, or PR and issue text | [`simple-english`](.agents/skills/simple-english/SKILL.md) |\n| Analyze why a chat, speech, or audio turn was slow or failed, using saved IO traces | [`analyze-io-traces`](.agents/skills/analyze-io-traces/SKILL.md) |\n| Create or prepare a pull request | [`create-pr`](.agents/skills/create-pr/SKILL.md) |\n| Upload a local file through a file input or a file chooser in a web or Electron app | [`use-agent-browser-with-input-file`](.agents/skills/use-agent-browser-with-input-file/SKILL.md) and [`agent-browser`](.agents/skills/agent-browser/SKILL.md). For Electron, also read [`agent-browser-electron`](.agents/skills/agent-browser-electron/SKILL.md). |\n| Test Live2D, VRM, or MMD import and rendering in stage-web, stage-tamagotchi, or stage-pocket | [`use-agent-browser-for-airi`](.agents/skills/use-agent-browser-for-airi/SKILL.md) |\n\nThese directories also have their own `AGENTS.md`. Read it before you work in the directory:\n\n- `packages/model-driver-mediapipe/`\n- `services/computer-use-mcp/`\n","isInternal":false,"tokens":3462,"sizeBytes":14034},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Copilot repository instructions\n\nThis is the `moeru-ai/airi` pnpm monorepo. Prefer the smallest safe change and keep every task inside its stated scope.\n\n## General rules\n\n- Follow the root `AGENTS.md` instructions.\n- Do not modify unrelated files.\n- Do not mix agent configuration changes and runtime logic changes in one commit. They can share one PR. Put documentation that describes the changed code in the same commit.\n- Do not change package files, lockfiles, or workspace configuration unless the task explicitly requires it.\n- Preserve existing test style and helpers.\n- Do not claim tests passed unless you actually ran them.\n- Report exact commands, exit codes, and relevant pass/fail output.\n\n## Validation\n\n- Use package-scoped pnpm commands where possible.\n- Run the narrowest relevant test first.\n- Run typecheck if runtime contracts or exported types changed.\n- Run affected package tests if shared logic changed.\n- Run `git diff --check` before finalizing when possible.\n\n## Output format\n\n1. Confirmed facts\n2. Files changed\n3. Commands run\n4. Test results\n5. Remaining risks\n6. Keep / revert / split recommendation\n","isInternal":false,"tokens":247,"sizeBytes":1135},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":192},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":178},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":171},{"name":".cursorrules","path":".cursorrules (code-pair-interviews.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/code-pair-interviews.mdc","title":"Awesome Cursorrules: code pair interviews","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for code pair interviews development with integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert software developer focused on producing clean, well-structured, and professional-quality code, suitable for a code pair programming interview.\n\nCode Structure and Organization\n\n-   Organize code logically with a clear separation of concerns.\n-   Break down problems into smaller, self-contained units using functions and classes.\n-   Ensure modularity and reusability of code components.\n-   Adhere to the Single Responsibility Principle: each function/class should have one specific job.\n-   When tackling complex problems, begin by outlining a high-level plan before writing code.\n-   Start with a simple, straightforward solution to the core problem, optimizing later if time allows.\n-   Select appropriate data structures and algorithms with a focus on clarity and efficiency.\n    -   Example: Use a hash map for quick lookups when appropriate.\n\nCoding Style\n\n-   Maintain consistent indentation using 2 spaces (prefer spaces over tabs).\n-   Use meaningful and descriptive names for variables, functions, and classes.\n    -   Avoid single-letter or cryptic abbreviations.\n    -   Example: Use `calculate_total_cost` instead of `calc`.\n-   Employ comments judiciously to explain non-obvious logic or provide high-level overviews.\n    -   Use docstrings for functions and methods to describe purpose, parameters, and return values.\n    -   Avoid over-commenting self-explanatory code.\n-   Keep lines of code within a reasonable length (80-100 characters) to enhance readability.\n-   Use blank lines to separate logical blocks of code and improve visual organization.\n\nCoding Best Practices\n\n-   Write clean and readable code.\n-   Prioritize clarity in code structure and style.\n-   Consider edge cases and implement error handling.\n-   Strive for efficient solutions.\n-   Test code thoroughly with various inputs, including edge cases.\n-   Start simple and optimize later.\n","tokens":401,"sizeBytes":2015}],"systemPromptSnippet":"<yakaai_skills repo=\"moeru-ai/airi\">\n<!-- File: AGENTS.md (Tokens: ~3462 | Category: root-instruction) -->\n# Project AIRI Agent Guide\n\nThis file gives the core rules for all work in the `moeru-ai/airi` monorepo. Skills and nested `AGENTS.md` files give the rules for specific tasks. Before you start a task, find it in [Task Routing](#task-routing) and read the listed file.\n\n## Project Map\n\nAll apps use Vue 3, Vite, TypeScript, Pinia, VueUse, UnoCSS, Vitest, and ESLint.\n\n| Path | Content |\n| --- | --- |\n| `apps/stage-web` | The web app. It uses Vue Router. |\n| `apps/stage-tamagotchi` | The Electron desktop app. |\n| `apps/stage-pocket` | The mobile app. It uses Vue Router, Capacitor, Kotlin, and Swift. |\n| `packages/stage-ui` | Business components, composables, and stores that stage-web and stage-tamagotchi share. |\n| `packages/stage-ui-three` | Three.js bindings and Vue components. |\n| `packages/stage-shared` | Logic that the stage packages and the stage apps share. |\n| `packages/stage-pages` | Shared page bases. |\n| `packages/stage-layouts` | Shared layouts, including the stage-web settings layout. |\n| `packages/ui` | Primitives built on reka-ui, such as inputs, buttons, and layout. They have minimal business logic. |\n| `packages/i18n` | All translations. |\n| `packages/server-runtime`, `packages/server-sdk`, `packages/server-shared` | The server channel that `services/` and `plugins/` use. |\n| `server/apps/api` | The hosted Hono resource API and its business domains. |\n| `server/apps/auth` | The standalone Better Auth and OIDC service. |\n| `server/packages` | Backend-only schema and Node infrastructure packages. |\n| `server/dev/caddy` | Local Auth and API edge routing. |\n| `server/docker-compose.yaml` | The complete local backend stack. |\n\nKey files and directories:\n\n- Pages are in `apps/stage-web/src/pages` and `apps/stage-tamagotchi/src/renderer/pages`. Devtools pages are in the `devtools` folder of each.\n- The router configuration is in `apps/stage-web/vite.config.ts` and `apps/stage-tamagotchi/electron.vite.config.ts`.\n- The settings layouts are `packages/stage-layouts/src/layouts/settings.vue` (stage-web) and `apps/stage-tamagotchi/src/renderer/layouts/settings.vue`.\n- A settings or devtools page needs `<route lang=\"yaml\"> meta: layout: settings </route>`. Register its route and icon in the settings layout.\n- In `packages/stage-ui/src`, provider definitions are in `stores/providers/` and orchestration modules are in `stores/modules/`.\n- Business composables are in `packages/stage-ui/src/composables/`. Business components are in `packages/stage-ui/src/components/`.\n- Put a component for one page or one use case in `packages/stage-ui/src/components/scenarios/`.\n- Stories are in `packages/stage-ui/stories`, with `packages/stage-ui/histoire.config.ts`. An example is `packages/stage-ui/src/components/misc/Button.story.vue`.\n- Eventa contracts are in `apps/stage-tamagotchi/src/shared`. Main and renderer usage examples are in `apps/stage-tamagotchi/src/main/services/electron`.\n- The dependency injection example is `apps/stage-tamagotchi/src/main/index.ts`.\n- Style configuration is in `uno.config.ts`. Existing animations are in `apps/stage-web/src/styles`.\n- CI pipelines are in `.github/workflows`. Lint rules are in `eslint.config.ts`.\n\n## Commands\n\nUse pnpm workspace filters to limit a command to one workspace. Replace `<package name>` with the `name` field in `package.json`, for example `@proj-airi/stage-tamagotchi`.\n\n- Typecheck one workspace: `pnpm -F <package name> typecheck`. For stage-tamagotchi, this command runs `tsc` and `vue-tsc`.\n- Test one file: `pnpm -F <package name> exec vitest run <path>`. Give `<path>` relative to the workspace.\n- Test one workspace: `pnpm -F <package name> exec vitest run`.\n- Test all workspaces: `pnpm test:run`. Turbo runs the `test:run` script of each workspace, with its browser projects.\n- Test the root scripts in `.github/scripts`: `pnpm test:root`. The root `vitest.config.ts` has only these tests.\n- Test the changes of a branch: run the `test:run` script of each changed workspace and of each workspace that depends on it.\n  Use the merge base with `origin/main` as the base.\n\n  ```sh\n  base=$(git merge-base origin/main HEAD)\n  TURBO_SCM_BASE=\"$base\" pnpm exec turbo run test:run --affected\n  ```\n\n  If the branch changes `.github/scripts`, also run `pnpm test:root`.\n\n- Lint: `pnpm lint`. ESLint also does the formatting. To fix lint and format errors, run `pnpm lint:fix`.\n- Build one workspace: `pnpm -F <package name> build`. For stage-tamagotchi, this command runs the typecheck and `electron-vite build`.\n\n## Scope and Checks\n\n- Keep each change inside the scope of the task.\n- In each function, component, or test that you change, correct the code that does not obey a current rule. Do not change other code only to improve it.\n- Do not add one-off patterns. Before you write a new utility or function, search for an existing internal implementation.\n- If new logic can become a shared utility, propose the shared approach to the user.\n- If a refactor is small, do it step by step.\n- After a task, run the typecheck and the related tests for each workspace that you changed.\n- Before you create a PR or push to one, run the tests of the branch changes. CI runs every project, including the browser projects.\n- If a change alters UI structure, layout, or interaction, review the related browser and end-to-end tests.\n- If intended behavior changes, update the affected assertions. Keep valid regression checks. Do not delete an assertion only to make a test pass.\n- After the final UI change, run the related tests on the final commit.\n- Before you report a CI success, make sure that CI tested the current PR head.\n- If you change a shared package or an exported type, also run the root `pnpm typecheck`.\n- Run `pnpm lint` before you finish.\n- Report only the checks that you ran. Give each command and its result.\n- At the end, summarize the changes, the commands that you ran, and the follow-up work.\n\n## Code Rules\n\n- Put shared logic in `packages/`. Keep module boundaries clear.\n- Use kebab-case for all file names.\n- Do not use `any`. Prefer type generics. Use `as unknown as <Type>` only when you cannot fix the type safely.\n- Omit TypeScript and JavaScript source extensions in relative imports, dynamic imports, and re-exports. Write `./module`, not `./module.ts` or `./module.js`. Keep an extension only when the runtime or asset format requires it.\n- Do not edit `tsconfig.json` to hide an import or type error. Find and fix the cause.\n- Treat a circular import as a design problem. First reconsider ownership and module boundaries. If you cannot resolve the cycle confidently, ask the user.\n- Use `@moeru/eventa` for all IPC, RPC, and cross-process events. Define the contracts in one central place, such as `apps/stage-tamagotchi/src/shared`.\n- Use dependency injection only at external boundaries: databases, model runtimes, queues, caches, filesystems, networks, clocks, environments, and feature gates. Use `injeca` for it.\n- Do not add dependency objects for internal functions that only call sibling helpers or forward parameters.\n- Prefer classes for runtime or browser APIs. Also prefer classes for substantial business modules that own state, lifecycle, or a stable domain boundary.\n- Prefer functions for pure transformations and local helpers.\n- Use Valibot for schema validation. Keep each schema near its consumers.\n- Use `errorMessageFrom(error)` from `@moeru/std` to get an error message. Add `?? 'fallback'` when you need a default. For other error handling, prefer the `@moeru/std` patterns.\n- Mark every workaround with a `// NOTICE:` comment in this format:\n\n  ```ts\n  // NOTICE:\n  // Why this workaround is needed.\n  // Root cause summary.\n  // Source/context (file, issue, URL, or node_modules reference).\n  // Removal condition (when it can be safely deleted).\n  ```\n\n### Backward Compatibility\n\n- Do not add backward-compatibility guards.\n- If old callers or old data need extended support, write a refactor document with the target shape. Then start another Codex or Claude Code session from the shell to do the refactor.\n- If a compatibility fallback must stay for a limited time, mark it with `// NOTICE:` and give its removal condition.\n- If a compatibility fallback is permanent, document it as supported policy. Do not call it legacy.\n- A nested `AGENTS.md` can override this rule for a public contract. It must name the root rule that it overrides.\n\n### Dependencies\n\n- Prefer `es-toolkit` for general utilities. Ask the user before you add another general utility library, such as a package from `unjs` or `tinylib`.\n- Some features use `node:*` built-in modules, DOM operations, Vue composables, React hooks, Vite plugins, or GitHub Actions workflows. For these features, research existing libraries first.\n- Before you choose a library, ask the user to choose. Help the user compare the options.\n- If the user works spec-driven, list the candidate libraries in a Markdown comparison table.\n- If the user asks you to use a specific tool or dependency, read its documentation in Context7 first. Then examine how this repository uses it.\n- If Context7 returns several names without a clear difference, ask the user to choose one.\n- If the documentation conflicts with the typecheck result, examine the dependency source in `node_modules` to find the cause.\n\n## Documentation\n\n- Put project-wide and client ADRs in `docs/ai/adr/`. Put hosted backend ADRs in `server/docs/ai/adr/`, and obey the ADR rules in `server/AGENTS.md`.\n- Put a documentation change in the same commit or PR as the code that it describes. This rule applies to ADRs, `README.md` files, and component references.\n- Put agent configuration changes in their own commit. Agent configuration includes `AGENTS.md`, `CLAUDE.md`, skills, and `.github/copilot-instructions.md`.\n- If the agent configuration describes the code of a PR, put its commit in that PR. Do not open a second PR for it.\n- Keep a structured `README.md` in each `packages/` and `apps/` entry. It tells what the entry does, how to use it, when to use it, and when not to use it.\n- Put all translations in `packages/i18n`. By default, edit only the English source locale and your own locale.\n- Do not edit other locales unless the user asks. Crowdin manages them, and the next Crowdin sync can replace local edits.\n- Do not use English text as a placeholder in other locales. Add only the locales you implement.\n- When you add a nested `AGENTS.md`, add a `CLAUDE.md` next to it that contains only `@AGENTS.md`. The root `CLAUDE.md` stops Claude Code from reading a nested `AGENTS.md` without this file.\n\n## Writing\n\n- For text, obey the [`simple-english`](.agents/skills/simple-english/SKILL.md) skill. Text includes documentation, code comments, commit messages, and PR and issue text.\n- Do not apply the skill to code, identifiers, commands, or quoted errors.\n- This repository breaks these rules most often:\n  - Do not write \"should\", \"may\", \"might\", \"could\", or \"would\". Write \"must\" or \"can\", or state the fact.\n  - Do not use semicolons. Write two sentences.\n  - Write \"for example\" and \"that is\". Do not write \"e.g.\", \"i.e.\", or \"etc.\".\n  - Write an instruction in 20 words or fewer. Write a description in 25 words or fewer.\n  - Put a condition before its command.\n\n## Git and Pull Requests\n\n- Use Conventional Commits, for example `feat(<package name>): add runner reconnect backoff`. Do not use gitmoji.\n- Name branches `username/feat/short-name`.\n- Rebase when you pull.\n- To create, open, publish, or prepare a pull request, use the [`create-pr`](.agents/skills/create-pr/SKILL.md) skill. It also covers visual evidence and review follow-up.\n\n## Task Routing\n\nSkills are in `.agents/skills/<name>/SKILL.md`. Read the listed file before you start the task.\n\n| Task | Read |\n| --- | --- |\n| Design, change, or review UI appearance and interaction | [AIRI Design Guide](DESIGN.md) |\n| Write, refactor, or review TypeScript or Vue code | [`enforce-rules-for-typescript`](.agents/skills/enforce-rules-for-typescript/SKILL.md) |\n| Write or debug tests, reproduce a bug, add mocks, or fix test import boundaries | [`enforce-rules-for-vitest`](.agents/skills/enforce-rules-for-vitest/SKILL.md) |\n| Change UnoCSS, Vue styles, UI components, animations, icons, or color mode | [`enforce-rules-for-unocss`](.agents/skills/enforce-rules-for-unocss/SKILL.md) |\n| Add `synced` to a Pinia store, or change a synced store | [`enforce-rules-for-pinia-synced`](.agents/skills/enforce-rules-for-pinia-synced/SKILL.md) |\n| Write or change a string that users see, or a glossary term | [`packages/i18n/AGENTS.md`](packages/i18n/AGENTS.md) |\n| Review pending Crowdin translations, or find why approved translations did not reach the repository | [`enforce-rules-for-i18n`](.agents/skills/enforce-rules-for-i18n/SKILL.md) |\n| Work under `server/` | [`server/AGENTS.md`](server/AGENTS.md). For `server/apps/api`, also read [`server/apps/api/AGENTS.md`](server/apps/api/AGENTS.md). |\n| Write documentation, code comments, commit messages, or PR and issue text | [`simple-english`](.agents/skills/simple-english/SKILL.md) |\n| Analyze why a chat, speech, or audio turn was slow or failed, using saved IO traces | [`analyze-io-traces`](.agents/skills/analyze-io-traces/SKILL.md) |\n| Create or prepare a pull request | [`create-pr`](.agents/skills/create-pr/SKILL.md) |\n| Upload a local file through a file input or a file chooser in a web or Electron app | [`use-agent-browser-with-input-file`](.agents/skills/use-agent-browser-with-input-file/SKILL.md) and [`agent-browser`](.agents/skills/agent-browser/SKILL.md). For Electron, also read [`agent-browser-electron`](.agents/skills/agent-browser-electron/SKILL.md). |\n| Test Live2D, VRM, or MMD import and rendering in stage-web, stage-tamagotchi, or stage-pocket | [`use-agent-browser-for-airi`](.agents/skills/use-agent-browser-for-airi/SKILL.md) |\n\nThese directories also have their own `AGENTS.md`. Read it before you work in the directory:\n\n- `packages/model-driver-mediapipe/`\n- `services/computer-use-mcp/`\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~247 | Category: copilot-instructions) -->\n# Copilot repository instructions\n\nThis is the `moeru-ai/airi` pnpm monorepo. Prefer the smallest safe change and keep every task inside its stated scope.\n\n## General rules\n\n- Follow the root `AGENTS.md` instructions.\n- Do not modify unrelated files.\n- Do not mix agent configuration changes and runtime logic changes in one commit. They can share one PR. Put documentation that describes the changed code in the same commit.\n- Do not change package files, lockfiles, or workspace configuration unless the task explicitly requires it.\n- Preserve existing test style and helpers.\n- Do not claim tests passed unless you actually ran them.\n- Report exact commands, exit codes, and relevant pass/fail output.\n\n## Validation\n\n- Use package-scoped pnpm commands where possible.\n- Run the narrowest relevant test first.\n- Run typecheck if runtime contracts or exported types changed.\n- Run affected package tests if shared logic changed.\n- Run `git diff --check` before finalizing when possible.\n\n## Output format\n\n1. Confirmed facts\n2. Files changed\n3. Commands run\n4. Test results\n5. Remaining risks\n6. Keep / revert / split recommendation\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/moeru-ai/airi/HEAD/.cursor/mcp.json)\n\n<!-- File: .cursorrules (code-pair-interviews.mdc) (Tokens: ~401 | Category: cursor-rule) -->\n---\ndescription: \"Cursor rules for code pair interviews development with integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are an expert software developer focused on producing clean, well-structured, and professional-quality code, suitable for a code pair programming interview.\n\nCode Structure and Organization\n\n-   Organize code logically with a clear separation of concerns.\n-   Break down problems into smaller, self-contained units using functions and classes.\n-   Ensure modularity and reusability of code components.\n-   Adhere to the Single Responsibility Principle: each function/class should have one specific job.\n-   When tackling complex problems, begin by outlining a high-level plan before writing code.\n-   Start with a simple, straightforward solution to the core problem, optimizing later if time allows.\n-   Select appropriate data structures and algorithms with a focus on clarity and efficiency.\n    -   Example: Use a hash map for quick lookups when appropriate.\n\nCoding Style\n\n-   Maintain consistent indentation using 2 spaces (prefer spaces over tabs).\n-   Use meaningful and descriptive names for variables, functions, and classes.\n    -   Avoid single-letter or cryptic abbreviations.\n    -   Example: Use `calculate_total_cost` instead of `calc`.\n-   Employ comments judiciously to explain non-obvious logic or provide high-level overviews.\n    -   Use docstrings for functions and methods to describe purpose, parameters, and return values.\n    -   Avoid over-commenting self-explanatory code.\n-   Keep lines of code within a reasonable length (80-100 characters) to enhance readability.\n-   Use blank lines to separate logical blocks of code and improve visual organization.\n\nCoding Best Practices\n\n-   Write clean and readable code.\n-   Prioritize clarity in code structure and style.\n-   Consider edge cases and implement error handling.\n-   Strive for efficient solutions.\n-   Test code thoroughly with various inputs, including edge cases.\n-   Start simple and optimize later.\n</yakaai_skills>"}