{"owner":"onejs","repo":"one","hasSkills":true,"totalSkillsCount":6,"totalTokensCount":2060,"categories":["root-instruction","copilot-instructions","mcp-config","marketplace","plugin-manifest","cursor-rule"],"hasMcp":true,"mcpConfig":{"mcpServers":{"one":{"command":"npx","args":["-y","@modelcontextprotocol/server-one"]}}},"found":["AGENTS.md",".github/copilot-instructions.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json",".cursorrules (react-components-creation-cursorrules-prompt-file.mdc)"],"skills":{"AGENTS.md":"---\napplyTo: \"**\"\n---\n\n# Project Overview\n\nOne is a framework that aims to make web and native development with React and React Native much simpler and faster.\n\nOne builds on Vite to serve both React web and React Native, it also provides file system–based routing, render modes, loaders, middleware, a CLI, Hono, and more.\n\nTo understand more about One, you should search for documentation (`apps/onestack.dev/**/*.mdx`) under the site (`apps/onestack.dev`). This site contains guides, API references, and examples to help you grasp the framework's capabilities and practices.\n\n## Monorepo Structure\n\n- `packages/one/` - Main framework package & Vite plugin\n- `packages/vxrn/` - A Vite plugin that makes Vite support React Native\n- `packages/vite-plugin-metro/` - Another Vite plugin that makes Vite support React Native\n- `apps/onestack.dev/` - Documentation website\n- `examples/` - Template projects and demos\n- `tests/` - Test suite and some test related stuff for the framework\n- `packages/create-vxrn/` - CLI scaffolding tool (`npx one`)\n\n## Operations\n\n- Publish beta versions from branches without asking. Require explicit user permission for stable releases.\n- Create worktrees only under `~/.worktrees/one-<slug>`, from a freshly fetched `origin/main`. Never in `/tmp`, a scratchpad, or inside the repo.\n- The session that creates a worktree owns it. When the task ends, either\n  `git worktree remove <path>` from the primary checkout, or leave it clean with\n  every commit pushed to its branch, and say which in your final report.\n- Uncommitted work in a worktree at session end is lost work. Commit it to the\n  branch and push, as a `wip:` commit if unfinished, before you stop.\n- Managers prune without asking: any worktree with no live owner, a clean tree,\n  and a HEAD reachable from `origin` is removed. `tm drift` is the audit.\n\n## Commit Messages\n\n- Keep commit messages short and simple\n- NO attribution lines (no \"Generated with Claude Code\", no \"Co-Authored-By\")\n- NO wordy descriptions - just state what was changed\n\n## Fast upstream releases\n\n- Run `bun release --into ~/<downstream>` in an isolated worktree to build the installed package family and replace downstream `node_modules` immediately. No commit, push, publish, CI, or tests are required. Use `--skip-build` only for outputs already built from your current source.\n- Branch work off `main`; `v2-beta` is retired. Main pushes do not publish stable packages.\n- Keep unreleased features together on one release branch and in one minor release PR. Test branch canaries and downstream consumers, prepare the minor version in that PR, and wait for owner review before merging and explicitly publishing it.\n- Use patch releases only for reviewed bug fixes with no unreleased features. Dependency and documentation maintenance do not require a library release when published runtime bytes are unchanged.\n- Publish a canary from any branch with `gh workflow run release.yml --ref <branch> -f release=canary`, independently of full CI. Canaries build and publish without test gates.\n- Use any canary, including your own, without waiting for an official beta. Pin the printed version because the shared `canary` tag moves. Record the source branch.\n- Verify content by packing the exact npm version and inspecting changed dist or source files and `releaseSourceCommit` in its manifest. A matching version string alone proves nothing.\n- State the validation actually performed in each commit message body. Write `Validation: none` when no checks were run. Do not imply a canary has passed tests.\n",".github/copilot-instructions.md":"instructions/general.instructions.md",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/onejs/one/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/onejs/one/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/onejs/one/HEAD/.claude-plugin/plugin.json)",".cursorrules (react-components-creation-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for React component creation and development.\"\nglobs: **/*\nalwaysApply: false\n---\n# Cursor Rules\n\n## Whenever you need a React component\n\n1. Carefully consider the component's purpose, functionality, and design\n\n2. Think slowly, step by step, and outline your reasoning\n\n3. Check if a similar component already exists in any of the following locations\n   1. packages/ui/src/components\n   2. apps/spa/src/components\n\n4. If it doesn't exist, generate a detailed prompt for the component, including:\n   - Component name and purpose\n   - Desired props and their types\n   - Any specific styling or behavior requirements\n   - Mention of using Tailwind CSS for styling\n   - Request for TypeScript usage\n\n5. URL encode the prompt.\n\n6. Create a clickable link in this format:\n   [ComponentName](https://v0.dev/chat?q={encoded_prompt})\n\n7. After generating, adapt the component to fit our project structure:\n   - Import\n     - common shadcn/ui components from <ui_package_alias>@repo/ui/components/ui/</ui_package_alias>\n     - app specific components from <app_package_alias>@/components</app_package_alias>\n   - Ensure it follows our existing component patterns\n   - Add any necessary custom logic or state management\n\nExample prompt template:\n\"Create a React component named {ComponentName} using TypeScript and Tailwind CSS. It should {description of functionality}. Props should include {list of props with types}. The component should {any specific styling or behavior notes}. Please provide the full component code.\"\n\nRemember to replace placeholders like <ui_package_path> and <app_package_alias> with the actual values used in your project.\n"},"files":{"AGENTS.md":"---\napplyTo: \"**\"\n---\n\n# Project Overview\n\nOne is a framework that aims to make web and native development with React and React Native much simpler and faster.\n\nOne builds on Vite to serve both React web and React Native, it also provides file system–based routing, render modes, loaders, middleware, a CLI, Hono, and more.\n\nTo understand more about One, you should search for documentation (`apps/onestack.dev/**/*.mdx`) under the site (`apps/onestack.dev`). This site contains guides, API references, and examples to help you grasp the framework's capabilities and practices.\n\n## Monorepo Structure\n\n- `packages/one/` - Main framework package & Vite plugin\n- `packages/vxrn/` - A Vite plugin that makes Vite support React Native\n- `packages/vite-plugin-metro/` - Another Vite plugin that makes Vite support React Native\n- `apps/onestack.dev/` - Documentation website\n- `examples/` - Template projects and demos\n- `tests/` - Test suite and some test related stuff for the framework\n- `packages/create-vxrn/` - CLI scaffolding tool (`npx one`)\n\n## Operations\n\n- Publish beta versions from branches without asking. Require explicit user permission for stable releases.\n- Create worktrees only under `~/.worktrees/one-<slug>`, from a freshly fetched `origin/main`. Never in `/tmp`, a scratchpad, or inside the repo.\n- The session that creates a worktree owns it. When the task ends, either\n  `git worktree remove <path>` from the primary checkout, or leave it clean with\n  every commit pushed to its branch, and say which in your final report.\n- Uncommitted work in a worktree at session end is lost work. Commit it to the\n  branch and push, as a `wip:` commit if unfinished, before you stop.\n- Managers prune without asking: any worktree with no live owner, a clean tree,\n  and a HEAD reachable from `origin` is removed. `tm drift` is the audit.\n\n## Commit Messages\n\n- Keep commit messages short and simple\n- NO attribution lines (no \"Generated with Claude Code\", no \"Co-Authored-By\")\n- NO wordy descriptions - just state what was changed\n\n## Fast upstream releases\n\n- Run `bun release --into ~/<downstream>` in an isolated worktree to build the installed package family and replace downstream `node_modules` immediately. No commit, push, publish, CI, or tests are required. Use `--skip-build` only for outputs already built from your current source.\n- Branch work off `main`; `v2-beta` is retired. Main pushes do not publish stable packages.\n- Keep unreleased features together on one release branch and in one minor release PR. Test branch canaries and downstream consumers, prepare the minor version in that PR, and wait for owner review before merging and explicitly publishing it.\n- Use patch releases only for reviewed bug fixes with no unreleased features. Dependency and documentation maintenance do not require a library release when published runtime bytes are unchanged.\n- Publish a canary from any branch with `gh workflow run release.yml --ref <branch> -f release=canary`, independently of full CI. Canaries build and publish without test gates.\n- Use any canary, including your own, without waiting for an official beta. Pin the printed version because the shared `canary` tag moves. Record the source branch.\n- Verify content by packing the exact npm version and inspecting changed dist or source files and `releaseSourceCommit` in its manifest. A matching version string alone proves nothing.\n- State the validation actually performed in each commit message body. Write `Validation: none` when no checks were run. Do not imply a canary has passed tests.\n",".github/copilot-instructions.md":"instructions/general.instructions.md",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/onejs/one/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/onejs/one/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/onejs/one/HEAD/.claude-plugin/plugin.json)",".cursorrules (react-components-creation-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for React component creation and development.\"\nglobs: **/*\nalwaysApply: false\n---\n# Cursor Rules\n\n## Whenever you need a React component\n\n1. Carefully consider the component's purpose, functionality, and design\n\n2. Think slowly, step by step, and outline your reasoning\n\n3. Check if a similar component already exists in any of the following locations\n   1. packages/ui/src/components\n   2. apps/spa/src/components\n\n4. If it doesn't exist, generate a detailed prompt for the component, including:\n   - Component name and purpose\n   - Desired props and their types\n   - Any specific styling or behavior requirements\n   - Mention of using Tailwind CSS for styling\n   - Request for TypeScript usage\n\n5. URL encode the prompt.\n\n6. Create a clickable link in this format:\n   [ComponentName](https://v0.dev/chat?q={encoded_prompt})\n\n7. After generating, adapt the component to fit our project structure:\n   - Import\n     - common shadcn/ui components from <ui_package_alias>@repo/ui/components/ui/</ui_package_alias>\n     - app specific components from <app_package_alias>@/components</app_package_alias>\n   - Ensure it follows our existing component patterns\n   - Add any necessary custom logic or state management\n\nExample prompt template:\n\"Create a React component named {ComponentName} using TypeScript and Tailwind CSS. It should {description of functionality}. Props should include {list of props with types}. The component should {any specific styling or behavior notes}. Please provide the full component code.\"\n\nRemember to replace placeholders like <ui_package_path> and <app_package_alias> with the actual values used in your project.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/onejs/one/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"---\napplyTo: \"**\"\n---\n\n# Project Overview\n\nOne is a framework that aims to make web and native development with React and React Native much simpler and faster.\n\nOne builds on Vite to serve both React web and React Native, it also provides file system–based routing, render modes, loaders, middleware, a CLI, Hono, and more.\n\nTo understand more about One, you should search for documentation (`apps/onestack.dev/**/*.mdx`) under the site (`apps/onestack.dev`). This site contains guides, API references, and examples to help you grasp the framework's capabilities and practices.\n\n## Monorepo Structure\n\n- `packages/one/` - Main framework package & Vite plugin\n- `packages/vxrn/` - A Vite plugin that makes Vite support React Native\n- `packages/vite-plugin-metro/` - Another Vite plugin that makes Vite support React Native\n- `apps/onestack.dev/` - Documentation website\n- `examples/` - Template projects and demos\n- `tests/` - Test suite and some test related stuff for the framework\n- `packages/create-vxrn/` - CLI scaffolding tool (`npx one`)\n\n## Operations\n\n- Publish beta versions from branches without asking. Require explicit user permission for stable releases.\n- Create worktrees only under `~/.worktrees/one-<slug>`, from a freshly fetched `origin/main`. Never in `/tmp`, a scratchpad, or inside the repo.\n- The session that creates a worktree owns it. When the task ends, either\n  `git worktree remove <path>` from the primary checkout, or leave it clean with\n  every commit pushed to its branch, and say which in your final report.\n- Uncommitted work in a worktree at session end is lost work. Commit it to the\n  branch and push, as a `wip:` commit if unfinished, before you stop.\n- Managers prune without asking: any worktree with no live owner, a clean tree,\n  and a HEAD reachable from `origin` is removed. `tm drift` is the audit.\n\n## Commit Messages\n\n- Keep commit messages short and simple\n- NO attribution lines (no \"Generated with Claude Code\", no \"Co-Authored-By\")\n- NO wordy descriptions - just state what was changed\n\n## Fast upstream releases\n\n- Run `bun release --into ~/<downstream>` in an isolated worktree to build the installed package family and replace downstream `node_modules` immediately. No commit, push, publish, CI, or tests are required. Use `--skip-build` only for outputs already built from your current source.\n- Branch work off `main`; `v2-beta` is retired. Main pushes do not publish stable packages.\n- Keep unreleased features together on one release branch and in one minor release PR. Test branch canaries and downstream consumers, prepare the minor version in that PR, and wait for owner review before merging and explicitly publishing it.\n- Use patch releases only for reviewed bug fixes with no unreleased features. Dependency and documentation maintenance do not require a library release when published runtime bytes are unchanged.\n- Publish a canary from any branch with `gh workflow run release.yml --ref <branch> -f release=canary`, independently of full CI. Canaries build and publish without test gates.\n- Use any canary, including your own, without waiting for an official beta. Pin the printed version because the shared `canary` tag moves. Record the source branch.\n- Verify content by packing the exact npm version and inspecting changed dist or source files and `releaseSourceCommit` in its manifest. A matching version string alone proves nothing.\n- State the validation actually performed in each commit message body. Write `Validation: none` when no checks were run. Do not imply a canary has passed tests.\n","frontmatter":{"applyTo":"**"},"isInternal":false,"tokens":801,"sizeBytes":3571},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/onejs/one/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"instructions/general.instructions.md","isInternal":false,"tokens":4,"sizeBytes":36},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/onejs/one/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/onejs/one/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":188},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/onejs/one/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/onejs/one/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":174},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/onejs/one/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/onejs/one/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":167},{"name":".cursorrules","path":".cursorrules (react-components-creation-cursorrules-prompt-file.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/react-components-creation-cursorrules-prompt-file.mdc","title":"Awesome Cursorrules: react components creation","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for React component creation and development.\"\nglobs: **/*\nalwaysApply: false\n---\n# Cursor Rules\n\n## Whenever you need a React component\n\n1. Carefully consider the component's purpose, functionality, and design\n\n2. Think slowly, step by step, and outline your reasoning\n\n3. Check if a similar component already exists in any of the following locations\n   1. packages/ui/src/components\n   2. apps/spa/src/components\n\n4. If it doesn't exist, generate a detailed prompt for the component, including:\n   - Component name and purpose\n   - Desired props and their types\n   - Any specific styling or behavior requirements\n   - Mention of using Tailwind CSS for styling\n   - Request for TypeScript usage\n\n5. URL encode the prompt.\n\n6. Create a clickable link in this format:\n   [ComponentName](https://v0.dev/chat?q={encoded_prompt})\n\n7. After generating, adapt the component to fit our project structure:\n   - Import\n     - common shadcn/ui components from <ui_package_alias>@repo/ui/components/ui/</ui_package_alias>\n     - app specific components from <app_package_alias>@/components</app_package_alias>\n   - Ensure it follows our existing component patterns\n   - Add any necessary custom logic or state management\n\nExample prompt template:\n\"Create a React component named {ComponentName} using TypeScript and Tailwind CSS. It should {description of functionality}. Props should include {list of props with types}. The component should {any specific styling or behavior notes}. Please provide the full component code.\"\n\nRemember to replace placeholders like <ui_package_path> and <app_package_alias> with the actual values used in your project.\n","tokens":355,"sizeBytes":1671}],"systemPromptSnippet":"<yakaai_skills repo=\"onejs/one\">\n<!-- File: AGENTS.md (Tokens: ~801 | Category: root-instruction) -->\n---\napplyTo: \"**\"\n---\n\n# Project Overview\n\nOne is a framework that aims to make web and native development with React and React Native much simpler and faster.\n\nOne builds on Vite to serve both React web and React Native, it also provides file system–based routing, render modes, loaders, middleware, a CLI, Hono, and more.\n\nTo understand more about One, you should search for documentation (`apps/onestack.dev/**/*.mdx`) under the site (`apps/onestack.dev`). This site contains guides, API references, and examples to help you grasp the framework's capabilities and practices.\n\n## Monorepo Structure\n\n- `packages/one/` - Main framework package & Vite plugin\n- `packages/vxrn/` - A Vite plugin that makes Vite support React Native\n- `packages/vite-plugin-metro/` - Another Vite plugin that makes Vite support React Native\n- `apps/onestack.dev/` - Documentation website\n- `examples/` - Template projects and demos\n- `tests/` - Test suite and some test related stuff for the framework\n- `packages/create-vxrn/` - CLI scaffolding tool (`npx one`)\n\n## Operations\n\n- Publish beta versions from branches without asking. Require explicit user permission for stable releases.\n- Create worktrees only under `~/.worktrees/one-<slug>`, from a freshly fetched `origin/main`. Never in `/tmp`, a scratchpad, or inside the repo.\n- The session that creates a worktree owns it. When the task ends, either\n  `git worktree remove <path>` from the primary checkout, or leave it clean with\n  every commit pushed to its branch, and say which in your final report.\n- Uncommitted work in a worktree at session end is lost work. Commit it to the\n  branch and push, as a `wip:` commit if unfinished, before you stop.\n- Managers prune without asking: any worktree with no live owner, a clean tree,\n  and a HEAD reachable from `origin` is removed. `tm drift` is the audit.\n\n## Commit Messages\n\n- Keep commit messages short and simple\n- NO attribution lines (no \"Generated with Claude Code\", no \"Co-Authored-By\")\n- NO wordy descriptions - just state what was changed\n\n## Fast upstream releases\n\n- Run `bun release --into ~/<downstream>` in an isolated worktree to build the installed package family and replace downstream `node_modules` immediately. No commit, push, publish, CI, or tests are required. Use `--skip-build` only for outputs already built from your current source.\n- Branch work off `main`; `v2-beta` is retired. Main pushes do not publish stable packages.\n- Keep unreleased features together on one release branch and in one minor release PR. Test branch canaries and downstream consumers, prepare the minor version in that PR, and wait for owner review before merging and explicitly publishing it.\n- Use patch releases only for reviewed bug fixes with no unreleased features. Dependency and documentation maintenance do not require a library release when published runtime bytes are unchanged.\n- Publish a canary from any branch with `gh workflow run release.yml --ref <branch> -f release=canary`, independently of full CI. Canaries build and publish without test gates.\n- Use any canary, including your own, without waiting for an official beta. Pin the printed version because the shared `canary` tag moves. Record the source branch.\n- Verify content by packing the exact npm version and inspecting changed dist or source files and `releaseSourceCommit` in its manifest. A matching version string alone proves nothing.\n- State the validation actually performed in each commit message body. Write `Validation: none` when no checks were run. Do not imply a canary has passed tests.\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~4 | Category: copilot-instructions) -->\ninstructions/general.instructions.md\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/onejs/one/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/onejs/one/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/onejs/one/HEAD/.cursor/mcp.json)\n\n<!-- File: .cursorrules (react-components-creation-cursorrules-prompt-file.mdc) (Tokens: ~355 | Category: cursor-rule) -->\n---\ndescription: \"Cursor rules for React component creation and development.\"\nglobs: **/*\nalwaysApply: false\n---\n# Cursor Rules\n\n## Whenever you need a React component\n\n1. Carefully consider the component's purpose, functionality, and design\n\n2. Think slowly, step by step, and outline your reasoning\n\n3. Check if a similar component already exists in any of the following locations\n   1. packages/ui/src/components\n   2. apps/spa/src/components\n\n4. If it doesn't exist, generate a detailed prompt for the component, including:\n   - Component name and purpose\n   - Desired props and their types\n   - Any specific styling or behavior requirements\n   - Mention of using Tailwind CSS for styling\n   - Request for TypeScript usage\n\n5. URL encode the prompt.\n\n6. Create a clickable link in this format:\n   [ComponentName](https://v0.dev/chat?q={encoded_prompt})\n\n7. After generating, adapt the component to fit our project structure:\n   - Import\n     - common shadcn/ui components from <ui_package_alias>@repo/ui/components/ui/</ui_package_alias>\n     - app specific components from <app_package_alias>@/components</app_package_alias>\n   - Ensure it follows our existing component patterns\n   - Add any necessary custom logic or state management\n\nExample prompt template:\n\"Create a React component named {ComponentName} using TypeScript and Tailwind CSS. It should {description of functionality}. Props should include {list of props with types}. The component should {any specific styling or behavior notes}. Please provide the full component code.\"\n\nRemember to replace placeholders like <ui_package_path> and <app_package_alias> with the actual values used in your project.\n</yakaai_skills>"}