{"owner":"the1812","repo":"Bilibili-Evolved","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":3595,"categories":["anthropic-skill","root-instruction","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/bilibili-evolved-dev-server/SKILL.md",".agents/skills/bilibili-evolved-dev-server/agents/openai.yaml","AGENTS.md","dev-tools/dev-server/README.md"],"skills":{".agents/skills/bilibili-evolved-dev-server/SKILL.md":"---\nname: bilibili-evolved-dev-server\ndescription: Bilibili-Evolved local dev server workflow. Use when working in the Bilibili-Evolved repository and needing to start the dev server, compile or watch one registry component/plugin, create a component/plugin scaffold through the dev server, reason about HTTP build-on-request versus WebSocket commands, or use DevClient during local feature development.\n---\n\n# Bilibili Evolved Dev Server\n\n## Core Model\n\n- Read `AGENTS.md` and `CONTRIBUTING.md` before making repo changes.\n- Use PowerShell syntax on Windows.\n- Use `pnpm`; do not use npm.\n- Start the local dev server with:\n\n```powershell\npnpm tsx dev-tools/dev-server/index.ts\n```\n\n- HTTP serves static resources only, but requesting `/registry/dist/components/<id>.js` or `/registry/dist/plugins/<id>.js` may trigger build-on-request before serving the file.\n- WebSocket is the control plane for explicit commands such as build, watch, stop, create, session query, and graceful server shutdown.\n- `dist/`, `registry/dist/`, and generated feature docs are not normal development changes.\n\n## Feature Commands\n\nUse these commands when the dev server is already running:\n\n```powershell\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts build component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts build plugin video/player/speed\npnpm tsx dev-tools/dev-server/command.ts watch component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts stop component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\n- `build` compiles one feature once without creating a watcher.\n- `watch` starts or reuses one feature watcher.\n- `stop` stops one watcher.\n- `sessions` prints active watched feature paths.\n- `shutdown` gracefully exits the dev server and its core and feature watchers. Prefer it over terminating the process tree externally.\n- Prefer these commands over full registry builds when validating one component or plugin.\n\n## Creating Features\n\nCreate new registry component/plugin scaffolds through the dev server command:\n\n```powershell\n$authorName = gh api user --jq \".login\"\n$authorLink = gh api user --jq \".html_url\"\npnpm tsx dev-tools/dev-server/command.ts create component style/my-feature myFeature \"My Feature\" $authorName $authorLink \"Feature description.\"\npnpm tsx dev-tools/dev-server/command.ts create plugin video/player/my-plugin myPlugin \"My Plugin\" $authorName $authorLink \"Plugin description.\"\n```\n\nBefore creating a feature, get the current GitHub user from `gh` with `gh api user --jq \".login\"` and use that as `authorName`; get the profile URL with `gh api user --jq \".html_url\"` and use that as `authorLink`. If `gh` is unavailable, not authenticated, or returns a blank value, ask the user for the GitHub username/profile link before running `create`. Do not use the code agent name, local OS username, or local Git `user.name` / `user.email` for author metadata.\n\nAfter creation, inspect and edit the generated `index.ts` and `index.md`. Keep component/plugin names specific and camelCase, include author metadata for contributor-created features, and keep descriptions in `index.md`.\n\n## DevClient\n\n- DevClient connects to `ws://localhost:<port>`.\n- Starting debug from the settings panel rewrites the feature update URL to the local `/registry/dist/...` URL and relies on HTTP build-on-request.\n- Stopping debug, losing the dev server, or seeing a feature session disappear should restore the original update URL.\n- If debugging state looks wrong, query sessions first, then inspect DevClient `devRecords` and auto-update URLs.\n\n## Browser Checks\n\n- Bilibili Evolved depends on a userscript manager extension such as Tampermonkey. The built-in browser and Playwright do not provide that extension environment and are not reliable for runtime behavior checks.\n- If real browser validation is useful and available, try controlling the user's Chrome browser because it can use the installed userscript manager, extension permissions, login state, and real Bilibili pages.\n- Browser validation is optional for this skill. If Chrome, the userscript manager, account state, or the target page is unavailable, continue the dev server workflow and report that browser validation was not performed.\n\n## Validation\n\n- For TypeScript changes, run `pnpm run type`.\n- For lint-sensitive changes, run `pnpm run lint-check`.\n- For core userscript changes, use the dev server's core watcher, which automatically compiles the development build.\n- For registry feature changes, run `pnpm tsx dev-tools/dev-server/command.ts build <component|plugin> <id>` while the dev server is running; the compiled output is served from memory.\n- `pnpm run build-core` and `pnpm run build-features` are production CI or release validations. Run them locally only when explicitly requested, reproducing a CI failure, changing shared build infrastructure, or preparing a release.\n",".agents/skills/bilibili-evolved-dev-server/agents/openai.yaml":"interface:\n  display_name: \"Bilibili Evolved Dev Server\"\n  short_description: \"Use the local dev server and feature commands.\"\n  default_prompt: \"Use $bilibili-evolved-dev-server to compile or watch one Bilibili Evolved feature with the local dev server.\"\n","AGENTS.md":"# AGENTS.md\n\nThis file gives coding agents repository-specific guidance for working on Bilibili Evolved. Read `CONTRIBUTING.md` first, then use this file as the practical checklist for implementation and verification.\n\nFollow the [feature scope and restrictions](CONTRIBUTING.md#功能范围与限制) in `CONTRIBUTING.md` when proposing, implementing, or reviewing changes, including the prohibition on computing API signatures directly in the project.\n\n## Project Structure\n\n- `src/` contains the userscript core, built-in components, shared runtime APIs, settings UI, and other code shipped with the main script.\n- `registry/lib/components/` contains installable components. New components should be placed under the appropriate category directory and use `index.ts` as the webpack entry.\n- `registry/lib/plugins/` contains plugins. Use a plugin when the feature only makes sense as an extension of another component.\n- Third-party components that are meant to remain outside the main repository should be added through `registry/lib/docs/third-party.ts` instead of mixing external component registration with in-repo source changes.\n- `dist/` and `registry/dist/` are build outputs. Development branches should not keep generated dist files; release output branches such as `preview`, `master`, and `master-cdn` get them from CI builds.\n- Feature documentation outputs under `doc/features/` are generated from metadata. Update them only when the task is explicitly about generated docs or release preparation.\n\n## Development Setup\n\n- The package manager is `pnpm`.\n- Install root dependencies with `pnpm install`.\n- Install registry dependencies from `registry/` when building registry features.\n- Use the VS Code tasks from `.vscode/tasks.json` as the source of truth for local task commands when in doubt.\n\nCommon commands:\n\n```sh\npnpm run type\npnpm run lint-check\npnpm tsx dev-tools/dev-server/index.ts\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\nThe dev server starts and watches the development core build, serves the local userscript, and provides registry feature URLs for browser testing. Registry feature URLs are virtual build-on-request outputs served from memory. WebSocket is the command and event control plane; use `dev-tools/dev-server/command.ts` for single-feature build, watch, stop, start-debug, stop-debug, scaffold, and graceful server shutdown commands. See `dev-tools/dev-server/README.md` for protocol details and `CONTRIBUTING.md` for Tampermonkey setup details.\n\n## Component And Plugin Guidelines\n\n- Define components with `defineComponentMetadata`.\n- Follow existing plugin definitions for code under `registry/lib/plugins/`.\n- New components should include `author` metadata.\n- Component `name` values should be specific and camelCase. Display names and option names should clearly describe the feature instead of using generic labels.\n- If a component has an `index.md`, do not duplicate the same description in metadata unless the existing pattern for that component requires it.\n- Use `urlInclude` and `urlExclude` for page matching instead of manually repeating page checks in `entry`.\n- Keep `entry` focused on the work that must happen when the component starts.\n- Do not rely on the return value of `entry` for cleanup. Put teardown logic in `unload`; use `reload` together with `unload` when a component must support disable and re-enable behavior.\n- Use existing shared core APIs, component APIs, and plugin APIs before adding new infrastructure. Do not add new uses of `styledComponentEntry` or `toggleStyle` from `@/components/styled-component`; declare fixed component styles through metadata `instantStyles` instead.\n- Use the observer APIs from `core/observer`, such as `mutationObserve`, `childList`, `visible`, `sizeChange`, `urlChange`, and `videoChange`, instead of directly constructing native `MutationObserver`, `IntersectionObserver`, or `ResizeObserver` instances when the project API covers the required behavior.\n- Put fixed component styles in SCSS files and load them through metadata `instantStyles`. Do not embed fixed CSS in TypeScript strings, HTML `style` attributes constructed in TypeScript, `style.cssText`, or individual DOM style assignments. For styles that require a different loading lifecycle, use the existing style APIs to load SCSS and handle cleanup explicitly.\n- When writing SCSS, check shared Sass files before adding local helpers. For example, `ui/_common.scss` is available through `@import \"common\"` and provides common mixins such as fullscreen and centering helpers.\n- For options, follow existing `defineOptionsMetadata` and `options` patterns so defaults, labels, and validators stay close to metadata.\n- Model exclusive choices as one option, usually with an enum or dropdown, instead of multiple mutually exclusive boolean options.\n- For dynamic style switching, keep the style rules in SCSS and toggle a state class on `html` so CSS responds to that state. Prefer this over manually adding and removing stylesheets in TypeScript.\n- Runtime style writes are allowed for computed positions and dimensions, CSS custom properties, and restoring existing inline styles. Keep fixed declarations in SCSS even when the same element also needs dynamic values.\n\n## Code Style\n\n- Follow the repository ESLint and Prettier configuration.\n- Use named exports except in files covered by the existing ESLint overrides, such as Vue single-file components and build-related files.\n- Keep control-flow bodies braced.\n- Preserve the existing TypeScript, Vue 2, and SCSS conventions around the code being changed.\n- Avoid unnecessary defensive branches, empty error handling, duplicated state, and one-off abstractions.\n- Prefer existing Bilibili API wrappers, request helpers, settings helpers, observer utilities, style utilities, and UI components over reimplementing equivalent behavior.\n- Prefer stable Bilibili APIs and existing wrappers over reading page-internal globals or framework internals when the data is available from an API.\n- Scope DOM selectors to the nearest stable parent class or page region. Avoid broad selectors that can match unrelated Bilibili UI.\n- Keep names and types aligned with behavior. If a function starts returning a broader shape, update the type and name instead of overloading a misleading contract.\n- Be careful with data units and API failure states. Do not cache a failed request as if it were a successful value, and keep byte, bit, count, id, and URL semantics explicit.\n\n## Generated Files\n\n- Do not manually edit generated docs or dist outputs as part of ordinary feature or bug-fix work.\n- If generated files must be updated, use the project’s existing build or docs generation workflow and include only the intended generated changes.\n- Do not commit unrelated cache, profile, local debug, or package-manager output files.\n\n## Validation\n\nChoose validation based on the risk and scope of the change.\n\n- Run `pnpm run type` for TypeScript type checking.\n- Run `pnpm run lint-check` for lint validation.\n- For core userscript changes, use the dev server's core watcher, which automatically compiles the development build.\n- For registry feature changes, run `pnpm tsx dev-tools/dev-server/command.ts build <component|plugin> <id>` while the dev server is running.\n- Run `pnpm exec tsc -p dev-tools/dev-server/tsconfig.json` for dev server TypeScript changes.\n- For browser-facing behavior, verify the changed feature in a real browser with the local userscript installed.\n- For API-shape or Bilibili-rollout-dependent changes, record what page or account state was actually self-tested.\n\nThe pull request CI workflow runs the following checks and builds. Do not repeat `build-core` or the full `build-features` build as routine local validation; run them locally only when explicitly requested, reproducing a CI failure, changing shared build infrastructure, or preparing a release.\n\n1. `pnpm run type`\n2. `pnpm run lint-check`\n3. `pnpm run build-core`\n4. install dependencies in `registry/`\n5. `pnpm run build-features`\n\nWhen a change affects page behavior, also check the browser console for new runtime errors and test the relevant Bilibili page type, such as video, bangumi, live, feeds, space, settings panel, or the affected component area.\n\n## Branches And Commits\n\n- Use `preview-features` as the base for new features.\n- Use `preview-fixes` as the base for bug fixes.\n- Commit messages only need to clearly describe the change; the repository does not require a strict conventional commit format.\n- Do not create release tags, push release branches, or perform release steps unless the task is explicitly about releasing.\n","dev-tools/dev-server/README.md":"# Bilibili Evolved Dev Server\n\n## HTTP\n\nThe HTTP server serves static files from the repository root only for core outputs.\n\n- `dist/*` -> core userscript outputs\n\nRequests to `registry/dist/components/<id>.js` and `registry/dist/plugins/<id>.js` are virtual output URLs. They trigger build-on-request when the memory output is missing, then return the compiled output from memory. Other `/registry/*` URLs are not served from disk. HTTP does not expose control APIs.\n\n## WebSocket\n\nDev server WebSocket: `ws://localhost:23333` by default.\n\nWebSocket is the command and event control plane.\n\nClient commands:\n\n```json\n{ \"type\": \"queryFeatureSessions\" }\n```\n\n```json\n{ \"type\": \"shutdownServer\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"buildFeature\", \"kind\": \"component\", \"id\": \"style/hide/banner\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"startFeatureSession\", \"kind\": \"plugin\", \"id\": \"video/player/speed\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"stopFeatureSession\", \"kind\": \"component\", \"id\": \"style/hide/banner\", \"requestId\": \"...\" }\n```\n\n```json\n{\n  \"type\": \"startDebugFeature\",\n  \"kind\": \"component\",\n  \"id\": \"style/hide/banner\",\n  \"targetClientId\": \"dev-client-1\",\n  \"requestId\": \"...\"\n}\n```\n\n```json\n{\n  \"type\": \"createFeature\",\n  \"kind\": \"component\",\n  \"id\": \"style/my-feature\",\n  \"name\": \"myFeature\",\n  \"displayName\": \"My Feature\",\n  \"authorName\": \"Author Name\",\n  \"authorLink\": \"https://example.com\",\n  \"description\": \"Feature description.\",\n  \"requestId\": \"...\"\n}\n```\n\nServer events:\n\n- `serverReady`: initial connection event with `clientId` and active `featureSessions`.\n- `featureSessionsChanged`: active watched feature paths changed.\n- `itemUpdate`: watched feature compiled and DevClient should update.\n- `featureBuilt`: explicit feature build or watched build completed.\n- `featureBuildFailed`: explicit feature build failed.\n- `serverStop`: server is shutting down; DevClient should restore dev URLs and close the socket.\n- `commandResult`: response for commands with `requestId`.\n\n## CLI\n\nUse the command client while the dev server is running:\n\n```powershell\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts build component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts watch plugin video/player/speed\npnpm tsx dev-tools/dev-server/command.ts stop component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts start-debug component style/hide/banner dev-client-1\npnpm tsx dev-tools/dev-server/command.ts stop-debug component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\n`shutdown` responds to the command client, broadcasts `serverStop`, and then gracefully closes core and feature watchers, WebSocket connections, and the HTTP server.\n"},"files":{".agents/skills/bilibili-evolved-dev-server/SKILL.md":"---\nname: bilibili-evolved-dev-server\ndescription: Bilibili-Evolved local dev server workflow. Use when working in the Bilibili-Evolved repository and needing to start the dev server, compile or watch one registry component/plugin, create a component/plugin scaffold through the dev server, reason about HTTP build-on-request versus WebSocket commands, or use DevClient during local feature development.\n---\n\n# Bilibili Evolved Dev Server\n\n## Core Model\n\n- Read `AGENTS.md` and `CONTRIBUTING.md` before making repo changes.\n- Use PowerShell syntax on Windows.\n- Use `pnpm`; do not use npm.\n- Start the local dev server with:\n\n```powershell\npnpm tsx dev-tools/dev-server/index.ts\n```\n\n- HTTP serves static resources only, but requesting `/registry/dist/components/<id>.js` or `/registry/dist/plugins/<id>.js` may trigger build-on-request before serving the file.\n- WebSocket is the control plane for explicit commands such as build, watch, stop, create, session query, and graceful server shutdown.\n- `dist/`, `registry/dist/`, and generated feature docs are not normal development changes.\n\n## Feature Commands\n\nUse these commands when the dev server is already running:\n\n```powershell\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts build component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts build plugin video/player/speed\npnpm tsx dev-tools/dev-server/command.ts watch component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts stop component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\n- `build` compiles one feature once without creating a watcher.\n- `watch` starts or reuses one feature watcher.\n- `stop` stops one watcher.\n- `sessions` prints active watched feature paths.\n- `shutdown` gracefully exits the dev server and its core and feature watchers. Prefer it over terminating the process tree externally.\n- Prefer these commands over full registry builds when validating one component or plugin.\n\n## Creating Features\n\nCreate new registry component/plugin scaffolds through the dev server command:\n\n```powershell\n$authorName = gh api user --jq \".login\"\n$authorLink = gh api user --jq \".html_url\"\npnpm tsx dev-tools/dev-server/command.ts create component style/my-feature myFeature \"My Feature\" $authorName $authorLink \"Feature description.\"\npnpm tsx dev-tools/dev-server/command.ts create plugin video/player/my-plugin myPlugin \"My Plugin\" $authorName $authorLink \"Plugin description.\"\n```\n\nBefore creating a feature, get the current GitHub user from `gh` with `gh api user --jq \".login\"` and use that as `authorName`; get the profile URL with `gh api user --jq \".html_url\"` and use that as `authorLink`. If `gh` is unavailable, not authenticated, or returns a blank value, ask the user for the GitHub username/profile link before running `create`. Do not use the code agent name, local OS username, or local Git `user.name` / `user.email` for author metadata.\n\nAfter creation, inspect and edit the generated `index.ts` and `index.md`. Keep component/plugin names specific and camelCase, include author metadata for contributor-created features, and keep descriptions in `index.md`.\n\n## DevClient\n\n- DevClient connects to `ws://localhost:<port>`.\n- Starting debug from the settings panel rewrites the feature update URL to the local `/registry/dist/...` URL and relies on HTTP build-on-request.\n- Stopping debug, losing the dev server, or seeing a feature session disappear should restore the original update URL.\n- If debugging state looks wrong, query sessions first, then inspect DevClient `devRecords` and auto-update URLs.\n\n## Browser Checks\n\n- Bilibili Evolved depends on a userscript manager extension such as Tampermonkey. The built-in browser and Playwright do not provide that extension environment and are not reliable for runtime behavior checks.\n- If real browser validation is useful and available, try controlling the user's Chrome browser because it can use the installed userscript manager, extension permissions, login state, and real Bilibili pages.\n- Browser validation is optional for this skill. If Chrome, the userscript manager, account state, or the target page is unavailable, continue the dev server workflow and report that browser validation was not performed.\n\n## Validation\n\n- For TypeScript changes, run `pnpm run type`.\n- For lint-sensitive changes, run `pnpm run lint-check`.\n- For core userscript changes, use the dev server's core watcher, which automatically compiles the development build.\n- For registry feature changes, run `pnpm tsx dev-tools/dev-server/command.ts build <component|plugin> <id>` while the dev server is running; the compiled output is served from memory.\n- `pnpm run build-core` and `pnpm run build-features` are production CI or release validations. Run them locally only when explicitly requested, reproducing a CI failure, changing shared build infrastructure, or preparing a release.\n",".agents/skills/bilibili-evolved-dev-server/agents/openai.yaml":"interface:\n  display_name: \"Bilibili Evolved Dev Server\"\n  short_description: \"Use the local dev server and feature commands.\"\n  default_prompt: \"Use $bilibili-evolved-dev-server to compile or watch one Bilibili Evolved feature with the local dev server.\"\n","AGENTS.md":"# AGENTS.md\n\nThis file gives coding agents repository-specific guidance for working on Bilibili Evolved. Read `CONTRIBUTING.md` first, then use this file as the practical checklist for implementation and verification.\n\nFollow the [feature scope and restrictions](CONTRIBUTING.md#功能范围与限制) in `CONTRIBUTING.md` when proposing, implementing, or reviewing changes, including the prohibition on computing API signatures directly in the project.\n\n## Project Structure\n\n- `src/` contains the userscript core, built-in components, shared runtime APIs, settings UI, and other code shipped with the main script.\n- `registry/lib/components/` contains installable components. New components should be placed under the appropriate category directory and use `index.ts` as the webpack entry.\n- `registry/lib/plugins/` contains plugins. Use a plugin when the feature only makes sense as an extension of another component.\n- Third-party components that are meant to remain outside the main repository should be added through `registry/lib/docs/third-party.ts` instead of mixing external component registration with in-repo source changes.\n- `dist/` and `registry/dist/` are build outputs. Development branches should not keep generated dist files; release output branches such as `preview`, `master`, and `master-cdn` get them from CI builds.\n- Feature documentation outputs under `doc/features/` are generated from metadata. Update them only when the task is explicitly about generated docs or release preparation.\n\n## Development Setup\n\n- The package manager is `pnpm`.\n- Install root dependencies with `pnpm install`.\n- Install registry dependencies from `registry/` when building registry features.\n- Use the VS Code tasks from `.vscode/tasks.json` as the source of truth for local task commands when in doubt.\n\nCommon commands:\n\n```sh\npnpm run type\npnpm run lint-check\npnpm tsx dev-tools/dev-server/index.ts\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\nThe dev server starts and watches the development core build, serves the local userscript, and provides registry feature URLs for browser testing. Registry feature URLs are virtual build-on-request outputs served from memory. WebSocket is the command and event control plane; use `dev-tools/dev-server/command.ts` for single-feature build, watch, stop, start-debug, stop-debug, scaffold, and graceful server shutdown commands. See `dev-tools/dev-server/README.md` for protocol details and `CONTRIBUTING.md` for Tampermonkey setup details.\n\n## Component And Plugin Guidelines\n\n- Define components with `defineComponentMetadata`.\n- Follow existing plugin definitions for code under `registry/lib/plugins/`.\n- New components should include `author` metadata.\n- Component `name` values should be specific and camelCase. Display names and option names should clearly describe the feature instead of using generic labels.\n- If a component has an `index.md`, do not duplicate the same description in metadata unless the existing pattern for that component requires it.\n- Use `urlInclude` and `urlExclude` for page matching instead of manually repeating page checks in `entry`.\n- Keep `entry` focused on the work that must happen when the component starts.\n- Do not rely on the return value of `entry` for cleanup. Put teardown logic in `unload`; use `reload` together with `unload` when a component must support disable and re-enable behavior.\n- Use existing shared core APIs, component APIs, and plugin APIs before adding new infrastructure. Do not add new uses of `styledComponentEntry` or `toggleStyle` from `@/components/styled-component`; declare fixed component styles through metadata `instantStyles` instead.\n- Use the observer APIs from `core/observer`, such as `mutationObserve`, `childList`, `visible`, `sizeChange`, `urlChange`, and `videoChange`, instead of directly constructing native `MutationObserver`, `IntersectionObserver`, or `ResizeObserver` instances when the project API covers the required behavior.\n- Put fixed component styles in SCSS files and load them through metadata `instantStyles`. Do not embed fixed CSS in TypeScript strings, HTML `style` attributes constructed in TypeScript, `style.cssText`, or individual DOM style assignments. For styles that require a different loading lifecycle, use the existing style APIs to load SCSS and handle cleanup explicitly.\n- When writing SCSS, check shared Sass files before adding local helpers. For example, `ui/_common.scss` is available through `@import \"common\"` and provides common mixins such as fullscreen and centering helpers.\n- For options, follow existing `defineOptionsMetadata` and `options` patterns so defaults, labels, and validators stay close to metadata.\n- Model exclusive choices as one option, usually with an enum or dropdown, instead of multiple mutually exclusive boolean options.\n- For dynamic style switching, keep the style rules in SCSS and toggle a state class on `html` so CSS responds to that state. Prefer this over manually adding and removing stylesheets in TypeScript.\n- Runtime style writes are allowed for computed positions and dimensions, CSS custom properties, and restoring existing inline styles. Keep fixed declarations in SCSS even when the same element also needs dynamic values.\n\n## Code Style\n\n- Follow the repository ESLint and Prettier configuration.\n- Use named exports except in files covered by the existing ESLint overrides, such as Vue single-file components and build-related files.\n- Keep control-flow bodies braced.\n- Preserve the existing TypeScript, Vue 2, and SCSS conventions around the code being changed.\n- Avoid unnecessary defensive branches, empty error handling, duplicated state, and one-off abstractions.\n- Prefer existing Bilibili API wrappers, request helpers, settings helpers, observer utilities, style utilities, and UI components over reimplementing equivalent behavior.\n- Prefer stable Bilibili APIs and existing wrappers over reading page-internal globals or framework internals when the data is available from an API.\n- Scope DOM selectors to the nearest stable parent class or page region. Avoid broad selectors that can match unrelated Bilibili UI.\n- Keep names and types aligned with behavior. If a function starts returning a broader shape, update the type and name instead of overloading a misleading contract.\n- Be careful with data units and API failure states. Do not cache a failed request as if it were a successful value, and keep byte, bit, count, id, and URL semantics explicit.\n\n## Generated Files\n\n- Do not manually edit generated docs or dist outputs as part of ordinary feature or bug-fix work.\n- If generated files must be updated, use the project’s existing build or docs generation workflow and include only the intended generated changes.\n- Do not commit unrelated cache, profile, local debug, or package-manager output files.\n\n## Validation\n\nChoose validation based on the risk and scope of the change.\n\n- Run `pnpm run type` for TypeScript type checking.\n- Run `pnpm run lint-check` for lint validation.\n- For core userscript changes, use the dev server's core watcher, which automatically compiles the development build.\n- For registry feature changes, run `pnpm tsx dev-tools/dev-server/command.ts build <component|plugin> <id>` while the dev server is running.\n- Run `pnpm exec tsc -p dev-tools/dev-server/tsconfig.json` for dev server TypeScript changes.\n- For browser-facing behavior, verify the changed feature in a real browser with the local userscript installed.\n- For API-shape or Bilibili-rollout-dependent changes, record what page or account state was actually self-tested.\n\nThe pull request CI workflow runs the following checks and builds. Do not repeat `build-core` or the full `build-features` build as routine local validation; run them locally only when explicitly requested, reproducing a CI failure, changing shared build infrastructure, or preparing a release.\n\n1. `pnpm run type`\n2. `pnpm run lint-check`\n3. `pnpm run build-core`\n4. install dependencies in `registry/`\n5. `pnpm run build-features`\n\nWhen a change affects page behavior, also check the browser console for new runtime errors and test the relevant Bilibili page type, such as video, bangumi, live, feeds, space, settings panel, or the affected component area.\n\n## Branches And Commits\n\n- Use `preview-features` as the base for new features.\n- Use `preview-fixes` as the base for bug fixes.\n- Commit messages only need to clearly describe the change; the repository does not require a strict conventional commit format.\n- Do not create release tags, push release branches, or perform release steps unless the task is explicitly about releasing.\n","dev-tools/dev-server/README.md":"# Bilibili Evolved Dev Server\n\n## HTTP\n\nThe HTTP server serves static files from the repository root only for core outputs.\n\n- `dist/*` -> core userscript outputs\n\nRequests to `registry/dist/components/<id>.js` and `registry/dist/plugins/<id>.js` are virtual output URLs. They trigger build-on-request when the memory output is missing, then return the compiled output from memory. Other `/registry/*` URLs are not served from disk. HTTP does not expose control APIs.\n\n## WebSocket\n\nDev server WebSocket: `ws://localhost:23333` by default.\n\nWebSocket is the command and event control plane.\n\nClient commands:\n\n```json\n{ \"type\": \"queryFeatureSessions\" }\n```\n\n```json\n{ \"type\": \"shutdownServer\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"buildFeature\", \"kind\": \"component\", \"id\": \"style/hide/banner\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"startFeatureSession\", \"kind\": \"plugin\", \"id\": \"video/player/speed\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"stopFeatureSession\", \"kind\": \"component\", \"id\": \"style/hide/banner\", \"requestId\": \"...\" }\n```\n\n```json\n{\n  \"type\": \"startDebugFeature\",\n  \"kind\": \"component\",\n  \"id\": \"style/hide/banner\",\n  \"targetClientId\": \"dev-client-1\",\n  \"requestId\": \"...\"\n}\n```\n\n```json\n{\n  \"type\": \"createFeature\",\n  \"kind\": \"component\",\n  \"id\": \"style/my-feature\",\n  \"name\": \"myFeature\",\n  \"displayName\": \"My Feature\",\n  \"authorName\": \"Author Name\",\n  \"authorLink\": \"https://example.com\",\n  \"description\": \"Feature description.\",\n  \"requestId\": \"...\"\n}\n```\n\nServer events:\n\n- `serverReady`: initial connection event with `clientId` and active `featureSessions`.\n- `featureSessionsChanged`: active watched feature paths changed.\n- `itemUpdate`: watched feature compiled and DevClient should update.\n- `featureBuilt`: explicit feature build or watched build completed.\n- `featureBuildFailed`: explicit feature build failed.\n- `serverStop`: server is shutting down; DevClient should restore dev URLs and close the socket.\n- `commandResult`: response for commands with `requestId`.\n\n## CLI\n\nUse the command client while the dev server is running:\n\n```powershell\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts build component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts watch plugin video/player/speed\npnpm tsx dev-tools/dev-server/command.ts stop component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts start-debug component style/hide/banner dev-client-1\npnpm tsx dev-tools/dev-server/command.ts stop-debug component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\n`shutdown` responds to the command client, broadcasts `serverStop`, and then gracefully closes core and feature watchers, WebSocket connections, and the HTTP server.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/the1812/Bilibili-Evolved/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nThis file gives coding agents repository-specific guidance for working on Bilibili Evolved. Read `CONTRIBUTING.md` first, then use this file as the practical checklist for implementation and verification.\n\nFollow the [feature scope and restrictions](CONTRIBUTING.md#功能范围与限制) in `CONTRIBUTING.md` when proposing, implementing, or reviewing changes, including the prohibition on computing API signatures directly in the project.\n\n## Project Structure\n\n- `src/` contains the userscript core, built-in components, shared runtime APIs, settings UI, and other code shipped with the main script.\n- `registry/lib/components/` contains installable components. New components should be placed under the appropriate category directory and use `index.ts` as the webpack entry.\n- `registry/lib/plugins/` contains plugins. Use a plugin when the feature only makes sense as an extension of another component.\n- Third-party components that are meant to remain outside the main repository should be added through `registry/lib/docs/third-party.ts` instead of mixing external component registration with in-repo source changes.\n- `dist/` and `registry/dist/` are build outputs. Development branches should not keep generated dist files; release output branches such as `preview`, `master`, and `master-cdn` get them from CI builds.\n- Feature documentation outputs under `doc/features/` are generated from metadata. Update them only when the task is explicitly about generated docs or release preparation.\n\n## Development Setup\n\n- The package manager is `pnpm`.\n- Install root dependencies with `pnpm install`.\n- Install registry dependencies from `registry/` when building registry features.\n- Use the VS Code tasks from `.vscode/tasks.json` as the source of truth for local task commands when in doubt.\n\nCommon commands:\n\n```sh\npnpm run type\npnpm run lint-check\npnpm tsx dev-tools/dev-server/index.ts\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\nThe dev server starts and watches the development core build, serves the local userscript, and provides registry feature URLs for browser testing. Registry feature URLs are virtual build-on-request outputs served from memory. WebSocket is the command and event control plane; use `dev-tools/dev-server/command.ts` for single-feature build, watch, stop, start-debug, stop-debug, scaffold, and graceful server shutdown commands. See `dev-tools/dev-server/README.md` for protocol details and `CONTRIBUTING.md` for Tampermonkey setup details.\n\n## Component And Plugin Guidelines\n\n- Define components with `defineComponentMetadata`.\n- Follow existing plugin definitions for code under `registry/lib/plugins/`.\n- New components should include `author` metadata.\n- Component `name` values should be specific and camelCase. Display names and option names should clearly describe the feature instead of using generic labels.\n- If a component has an `index.md`, do not duplicate the same description in metadata unless the existing pattern for that component requires it.\n- Use `urlInclude` and `urlExclude` for page matching instead of manually repeating page checks in `entry`.\n- Keep `entry` focused on the work that must happen when the component starts.\n- Do not rely on the return value of `entry` for cleanup. Put teardown logic in `unload`; use `reload` together with `unload` when a component must support disable and re-enable behavior.\n- Use existing shared core APIs, component APIs, and plugin APIs before adding new infrastructure. Do not add new uses of `styledComponentEntry` or `toggleStyle` from `@/components/styled-component`; declare fixed component styles through metadata `instantStyles` instead.\n- Use the observer APIs from `core/observer`, such as `mutationObserve`, `childList`, `visible`, `sizeChange`, `urlChange`, and `videoChange`, instead of directly constructing native `MutationObserver`, `IntersectionObserver`, or `ResizeObserver` instances when the project API covers the required behavior.\n- Put fixed component styles in SCSS files and load them through metadata `instantStyles`. Do not embed fixed CSS in TypeScript strings, HTML `style` attributes constructed in TypeScript, `style.cssText`, or individual DOM style assignments. For styles that require a different loading lifecycle, use the existing style APIs to load SCSS and handle cleanup explicitly.\n- When writing SCSS, check shared Sass files before adding local helpers. For example, `ui/_common.scss` is available through `@import \"common\"` and provides common mixins such as fullscreen and centering helpers.\n- For options, follow existing `defineOptionsMetadata` and `options` patterns so defaults, labels, and validators stay close to metadata.\n- Model exclusive choices as one option, usually with an enum or dropdown, instead of multiple mutually exclusive boolean options.\n- For dynamic style switching, keep the style rules in SCSS and toggle a state class on `html` so CSS responds to that state. Prefer this over manually adding and removing stylesheets in TypeScript.\n- Runtime style writes are allowed for computed positions and dimensions, CSS custom properties, and restoring existing inline styles. Keep fixed declarations in SCSS even when the same element also needs dynamic values.\n\n## Code Style\n\n- Follow the repository ESLint and Prettier configuration.\n- Use named exports except in files covered by the existing ESLint overrides, such as Vue single-file components and build-related files.\n- Keep control-flow bodies braced.\n- Preserve the existing TypeScript, Vue 2, and SCSS conventions around the code being changed.\n- Avoid unnecessary defensive branches, empty error handling, duplicated state, and one-off abstractions.\n- Prefer existing Bilibili API wrappers, request helpers, settings helpers, observer utilities, style utilities, and UI components over reimplementing equivalent behavior.\n- Prefer stable Bilibili APIs and existing wrappers over reading page-internal globals or framework internals when the data is available from an API.\n- Scope DOM selectors to the nearest stable parent class or page region. Avoid broad selectors that can match unrelated Bilibili UI.\n- Keep names and types aligned with behavior. If a function starts returning a broader shape, update the type and name instead of overloading a misleading contract.\n- Be careful with data units and API failure states. Do not cache a failed request as if it were a successful value, and keep byte, bit, count, id, and URL semantics explicit.\n\n## Generated Files\n\n- Do not manually edit generated docs or dist outputs as part of ordinary feature or bug-fix work.\n- If generated files must be updated, use the project’s existing build or docs generation workflow and include only the intended generated changes.\n- Do not commit unrelated cache, profile, local debug, or package-manager output files.\n\n## Validation\n\nChoose validation based on the risk and scope of the change.\n\n- Run `pnpm run type` for TypeScript type checking.\n- Run `pnpm run lint-check` for lint validation.\n- For core userscript changes, use the dev server's core watcher, which automatically compiles the development build.\n- For registry feature changes, run `pnpm tsx dev-tools/dev-server/command.ts build <component|plugin> <id>` while the dev server is running.\n- Run `pnpm exec tsc -p dev-tools/dev-server/tsconfig.json` for dev server TypeScript changes.\n- For browser-facing behavior, verify the changed feature in a real browser with the local userscript installed.\n- For API-shape or Bilibili-rollout-dependent changes, record what page or account state was actually self-tested.\n\nThe pull request CI workflow runs the following checks and builds. Do not repeat `build-core` or the full `build-features` build as routine local validation; run them locally only when explicitly requested, reproducing a CI failure, changing shared build infrastructure, or preparing a release.\n\n1. `pnpm run type`\n2. `pnpm run lint-check`\n3. `pnpm run build-core`\n4. install dependencies in `registry/`\n5. `pnpm run build-features`\n\nWhen a change affects page behavior, also check the browser console for new runtime errors and test the relevant Bilibili page type, such as video, bangumi, live, feeds, space, settings panel, or the affected component area.\n\n## Branches And Commits\n\n- Use `preview-features` as the base for new features.\n- Use `preview-fixes` as the base for bug fixes.\n- Commit messages only need to clearly describe the change; the repository does not require a strict conventional commit format.\n- Do not create release tags, push release branches, or perform release steps unless the task is explicitly about releasing.\n","isInternal":false,"tokens":1788,"sizeBytes":8715},{"name":"openai.yaml","path":".agents/skills/bilibili-evolved-dev-server/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/the1812/Bilibili-Evolved/HEAD/.agents/skills/bilibili-evolved-dev-server/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n  display_name: \"Bilibili Evolved Dev Server\"\n  short_description: \"Use the local dev server and feature commands.\"\n  default_prompt: \"Use $bilibili-evolved-dev-server to compile or watch one Bilibili Evolved feature with the local dev server.\"\n","isInternal":false,"tokens":60,"sizeBytes":256},{"name":"SKILL.md","path":".agents/skills/bilibili-evolved-dev-server/SKILL.md","rawUrl":"https://raw.githubusercontent.com/the1812/Bilibili-Evolved/HEAD/.agents/skills/bilibili-evolved-dev-server/SKILL.md","title":"bilibili-evolved-dev-server","category":"anthropic-skill","format":"markdown","content":"---\nname: bilibili-evolved-dev-server\ndescription: Bilibili-Evolved local dev server workflow. Use when working in the Bilibili-Evolved repository and needing to start the dev server, compile or watch one registry component/plugin, create a component/plugin scaffold through the dev server, reason about HTTP build-on-request versus WebSocket commands, or use DevClient during local feature development.\n---\n\n# Bilibili Evolved Dev Server\n\n## Core Model\n\n- Read `AGENTS.md` and `CONTRIBUTING.md` before making repo changes.\n- Use PowerShell syntax on Windows.\n- Use `pnpm`; do not use npm.\n- Start the local dev server with:\n\n```powershell\npnpm tsx dev-tools/dev-server/index.ts\n```\n\n- HTTP serves static resources only, but requesting `/registry/dist/components/<id>.js` or `/registry/dist/plugins/<id>.js` may trigger build-on-request before serving the file.\n- WebSocket is the control plane for explicit commands such as build, watch, stop, create, session query, and graceful server shutdown.\n- `dist/`, `registry/dist/`, and generated feature docs are not normal development changes.\n\n## Feature Commands\n\nUse these commands when the dev server is already running:\n\n```powershell\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts build component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts build plugin video/player/speed\npnpm tsx dev-tools/dev-server/command.ts watch component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts stop component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\n- `build` compiles one feature once without creating a watcher.\n- `watch` starts or reuses one feature watcher.\n- `stop` stops one watcher.\n- `sessions` prints active watched feature paths.\n- `shutdown` gracefully exits the dev server and its core and feature watchers. Prefer it over terminating the process tree externally.\n- Prefer these commands over full registry builds when validating one component or plugin.\n\n## Creating Features\n\nCreate new registry component/plugin scaffolds through the dev server command:\n\n```powershell\n$authorName = gh api user --jq \".login\"\n$authorLink = gh api user --jq \".html_url\"\npnpm tsx dev-tools/dev-server/command.ts create component style/my-feature myFeature \"My Feature\" $authorName $authorLink \"Feature description.\"\npnpm tsx dev-tools/dev-server/command.ts create plugin video/player/my-plugin myPlugin \"My Plugin\" $authorName $authorLink \"Plugin description.\"\n```\n\nBefore creating a feature, get the current GitHub user from `gh` with `gh api user --jq \".login\"` and use that as `authorName`; get the profile URL with `gh api user --jq \".html_url\"` and use that as `authorLink`. If `gh` is unavailable, not authenticated, or returns a blank value, ask the user for the GitHub username/profile link before running `create`. Do not use the code agent name, local OS username, or local Git `user.name` / `user.email` for author metadata.\n\nAfter creation, inspect and edit the generated `index.ts` and `index.md`. Keep component/plugin names specific and camelCase, include author metadata for contributor-created features, and keep descriptions in `index.md`.\n\n## DevClient\n\n- DevClient connects to `ws://localhost:<port>`.\n- Starting debug from the settings panel rewrites the feature update URL to the local `/registry/dist/...` URL and relies on HTTP build-on-request.\n- Stopping debug, losing the dev server, or seeing a feature session disappear should restore the original update URL.\n- If debugging state looks wrong, query sessions first, then inspect DevClient `devRecords` and auto-update URLs.\n\n## Browser Checks\n\n- Bilibili Evolved depends on a userscript manager extension such as Tampermonkey. The built-in browser and Playwright do not provide that extension environment and are not reliable for runtime behavior checks.\n- If real browser validation is useful and available, try controlling the user's Chrome browser because it can use the installed userscript manager, extension permissions, login state, and real Bilibili pages.\n- Browser validation is optional for this skill. If Chrome, the userscript manager, account state, or the target page is unavailable, continue the dev server workflow and report that browser validation was not performed.\n\n## Validation\n\n- For TypeScript changes, run `pnpm run type`.\n- For lint-sensitive changes, run `pnpm run lint-check`.\n- For core userscript changes, use the dev server's core watcher, which automatically compiles the development build.\n- For registry feature changes, run `pnpm tsx dev-tools/dev-server/command.ts build <component|plugin> <id>` while the dev server is running; the compiled output is served from memory.\n- `pnpm run build-core` and `pnpm run build-features` are production CI or release validations. Run them locally only when explicitly requested, reproducing a CI failure, changing shared build infrastructure, or preparing a release.\n","frontmatter":{"name":"bilibili-evolved-dev-server","description":"Bilibili-Evolved local dev server workflow. Use when working in the Bilibili-Evolved repository and needing to start the dev server, compile or watch one registry component/plugin, create a component/plugin scaffold through the dev server, reason about HTTP build-on-request versus WebSocket commands, or use DevClient during local feature development."},"isInternal":false,"tokens":1068,"sizeBytes":4955},{"name":"README.md","path":"dev-tools/dev-server/README.md","rawUrl":"https://raw.githubusercontent.com/the1812/Bilibili-Evolved/HEAD/dev-tools/dev-server/README.md","title":"dev-server Documentation","category":"plugin-manifest","format":"markdown","content":"# Bilibili Evolved Dev Server\n\n## HTTP\n\nThe HTTP server serves static files from the repository root only for core outputs.\n\n- `dist/*` -> core userscript outputs\n\nRequests to `registry/dist/components/<id>.js` and `registry/dist/plugins/<id>.js` are virtual output URLs. They trigger build-on-request when the memory output is missing, then return the compiled output from memory. Other `/registry/*` URLs are not served from disk. HTTP does not expose control APIs.\n\n## WebSocket\n\nDev server WebSocket: `ws://localhost:23333` by default.\n\nWebSocket is the command and event control plane.\n\nClient commands:\n\n```json\n{ \"type\": \"queryFeatureSessions\" }\n```\n\n```json\n{ \"type\": \"shutdownServer\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"buildFeature\", \"kind\": \"component\", \"id\": \"style/hide/banner\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"startFeatureSession\", \"kind\": \"plugin\", \"id\": \"video/player/speed\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"stopFeatureSession\", \"kind\": \"component\", \"id\": \"style/hide/banner\", \"requestId\": \"...\" }\n```\n\n```json\n{\n  \"type\": \"startDebugFeature\",\n  \"kind\": \"component\",\n  \"id\": \"style/hide/banner\",\n  \"targetClientId\": \"dev-client-1\",\n  \"requestId\": \"...\"\n}\n```\n\n```json\n{\n  \"type\": \"createFeature\",\n  \"kind\": \"component\",\n  \"id\": \"style/my-feature\",\n  \"name\": \"myFeature\",\n  \"displayName\": \"My Feature\",\n  \"authorName\": \"Author Name\",\n  \"authorLink\": \"https://example.com\",\n  \"description\": \"Feature description.\",\n  \"requestId\": \"...\"\n}\n```\n\nServer events:\n\n- `serverReady`: initial connection event with `clientId` and active `featureSessions`.\n- `featureSessionsChanged`: active watched feature paths changed.\n- `itemUpdate`: watched feature compiled and DevClient should update.\n- `featureBuilt`: explicit feature build or watched build completed.\n- `featureBuildFailed`: explicit feature build failed.\n- `serverStop`: server is shutting down; DevClient should restore dev URLs and close the socket.\n- `commandResult`: response for commands with `requestId`.\n\n## CLI\n\nUse the command client while the dev server is running:\n\n```powershell\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts build component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts watch plugin video/player/speed\npnpm tsx dev-tools/dev-server/command.ts stop component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts start-debug component style/hide/banner dev-client-1\npnpm tsx dev-tools/dev-server/command.ts stop-debug component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\n`shutdown` responds to the command client, broadcasts `serverStop`, and then gracefully closes core and feature watchers, WebSocket connections, and the HTTP server.\n","isInternal":false,"tokens":679,"sizeBytes":2760}],"systemPromptSnippet":"<yakaai_skills repo=\"the1812/Bilibili-Evolved\">\n<!-- File: AGENTS.md (Tokens: ~1788 | Category: root-instruction) -->\n# AGENTS.md\n\nThis file gives coding agents repository-specific guidance for working on Bilibili Evolved. Read `CONTRIBUTING.md` first, then use this file as the practical checklist for implementation and verification.\n\nFollow the [feature scope and restrictions](CONTRIBUTING.md#功能范围与限制) in `CONTRIBUTING.md` when proposing, implementing, or reviewing changes, including the prohibition on computing API signatures directly in the project.\n\n## Project Structure\n\n- `src/` contains the userscript core, built-in components, shared runtime APIs, settings UI, and other code shipped with the main script.\n- `registry/lib/components/` contains installable components. New components should be placed under the appropriate category directory and use `index.ts` as the webpack entry.\n- `registry/lib/plugins/` contains plugins. Use a plugin when the feature only makes sense as an extension of another component.\n- Third-party components that are meant to remain outside the main repository should be added through `registry/lib/docs/third-party.ts` instead of mixing external component registration with in-repo source changes.\n- `dist/` and `registry/dist/` are build outputs. Development branches should not keep generated dist files; release output branches such as `preview`, `master`, and `master-cdn` get them from CI builds.\n- Feature documentation outputs under `doc/features/` are generated from metadata. Update them only when the task is explicitly about generated docs or release preparation.\n\n## Development Setup\n\n- The package manager is `pnpm`.\n- Install root dependencies with `pnpm install`.\n- Install registry dependencies from `registry/` when building registry features.\n- Use the VS Code tasks from `.vscode/tasks.json` as the source of truth for local task commands when in doubt.\n\nCommon commands:\n\n```sh\npnpm run type\npnpm run lint-check\npnpm tsx dev-tools/dev-server/index.ts\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\nThe dev server starts and watches the development core build, serves the local userscript, and provides registry feature URLs for browser testing. Registry feature URLs are virtual build-on-request outputs served from memory. WebSocket is the command and event control plane; use `dev-tools/dev-server/command.ts` for single-feature build, watch, stop, start-debug, stop-debug, scaffold, and graceful server shutdown commands. See `dev-tools/dev-server/README.md` for protocol details and `CONTRIBUTING.md` for Tampermonkey setup details.\n\n## Component And Plugin Guidelines\n\n- Define components with `defineComponentMetadata`.\n- Follow existing plugin definitions for code under `registry/lib/plugins/`.\n- New components should include `author` metadata.\n- Component `name` values should be specific and camelCase. Display names and option names should clearly describe the feature instead of using generic labels.\n- If a component has an `index.md`, do not duplicate the same description in metadata unless the existing pattern for that component requires it.\n- Use `urlInclude` and `urlExclude` for page matching instead of manually repeating page checks in `entry`.\n- Keep `entry` focused on the work that must happen when the component starts.\n- Do not rely on the return value of `entry` for cleanup. Put teardown logic in `unload`; use `reload` together with `unload` when a component must support disable and re-enable behavior.\n- Use existing shared core APIs, component APIs, and plugin APIs before adding new infrastructure. Do not add new uses of `styledComponentEntry` or `toggleStyle` from `@/components/styled-component`; declare fixed component styles through metadata `instantStyles` instead.\n- Use the observer APIs from `core/observer`, such as `mutationObserve`, `childList`, `visible`, `sizeChange`, `urlChange`, and `videoChange`, instead of directly constructing native `MutationObserver`, `IntersectionObserver`, or `ResizeObserver` instances when the project API covers the required behavior.\n- Put fixed component styles in SCSS files and load them through metadata `instantStyles`. Do not embed fixed CSS in TypeScript strings, HTML `style` attributes constructed in TypeScript, `style.cssText`, or individual DOM style assignments. For styles that require a different loading lifecycle, use the existing style APIs to load SCSS and handle cleanup explicitly.\n- When writing SCSS, check shared Sass files before adding local helpers. For example, `ui/_common.scss` is available through `@import \"common\"` and provides common mixins such as fullscreen and centering helpers.\n- For options, follow existing `defineOptionsMetadata` and `options` patterns so defaults, labels, and validators stay close to metadata.\n- Model exclusive choices as one option, usually with an enum or dropdown, instead of multiple mutually exclusive boolean options.\n- For dynamic style switching, keep the style rules in SCSS and toggle a state class on `html` so CSS responds to that state. Prefer this over manually adding and removing stylesheets in TypeScript.\n- Runtime style writes are allowed for computed positions and dimensions, CSS custom properties, and restoring existing inline styles. Keep fixed declarations in SCSS even when the same element also needs dynamic values.\n\n## Code Style\n\n- Follow the repository ESLint and Prettier configuration.\n- Use named exports except in files covered by the existing ESLint overrides, such as Vue single-file components and build-related files.\n- Keep control-flow bodies braced.\n- Preserve the existing TypeScript, Vue 2, and SCSS conventions around the code being changed.\n- Avoid unnecessary defensive branches, empty error handling, duplicated state, and one-off abstractions.\n- Prefer existing Bilibili API wrappers, request helpers, settings helpers, observer utilities, style utilities, and UI components over reimplementing equivalent behavior.\n- Prefer stable Bilibili APIs and existing wrappers over reading page-internal globals or framework internals when the data is available from an API.\n- Scope DOM selectors to the nearest stable parent class or page region. Avoid broad selectors that can match unrelated Bilibili UI.\n- Keep names and types aligned with behavior. If a function starts returning a broader shape, update the type and name instead of overloading a misleading contract.\n- Be careful with data units and API failure states. Do not cache a failed request as if it were a successful value, and keep byte, bit, count, id, and URL semantics explicit.\n\n## Generated Files\n\n- Do not manually edit generated docs or dist outputs as part of ordinary feature or bug-fix work.\n- If generated files must be updated, use the project’s existing build or docs generation workflow and include only the intended generated changes.\n- Do not commit unrelated cache, profile, local debug, or package-manager output files.\n\n## Validation\n\nChoose validation based on the risk and scope of the change.\n\n- Run `pnpm run type` for TypeScript type checking.\n- Run `pnpm run lint-check` for lint validation.\n- For core userscript changes, use the dev server's core watcher, which automatically compiles the development build.\n- For registry feature changes, run `pnpm tsx dev-tools/dev-server/command.ts build <component|plugin> <id>` while the dev server is running.\n- Run `pnpm exec tsc -p dev-tools/dev-server/tsconfig.json` for dev server TypeScript changes.\n- For browser-facing behavior, verify the changed feature in a real browser with the local userscript installed.\n- For API-shape or Bilibili-rollout-dependent changes, record what page or account state was actually self-tested.\n\nThe pull request CI workflow runs the following checks and builds. Do not repeat `build-core` or the full `build-features` build as routine local validation; run them locally only when explicitly requested, reproducing a CI failure, changing shared build infrastructure, or preparing a release.\n\n1. `pnpm run type`\n2. `pnpm run lint-check`\n3. `pnpm run build-core`\n4. install dependencies in `registry/`\n5. `pnpm run build-features`\n\nWhen a change affects page behavior, also check the browser console for new runtime errors and test the relevant Bilibili page type, such as video, bangumi, live, feeds, space, settings panel, or the affected component area.\n\n## Branches And Commits\n\n- Use `preview-features` as the base for new features.\n- Use `preview-fixes` as the base for bug fixes.\n- Commit messages only need to clearly describe the change; the repository does not require a strict conventional commit format.\n- Do not create release tags, push release branches, or perform release steps unless the task is explicitly about releasing.\n\n<!-- File: .agents/skills/bilibili-evolved-dev-server/agents/openai.yaml (Tokens: ~60 | Category: anthropic-skill) -->\ninterface:\n  display_name: \"Bilibili Evolved Dev Server\"\n  short_description: \"Use the local dev server and feature commands.\"\n  default_prompt: \"Use $bilibili-evolved-dev-server to compile or watch one Bilibili Evolved feature with the local dev server.\"\n\n<!-- File: .agents/skills/bilibili-evolved-dev-server/SKILL.md (Tokens: ~1068 | Category: anthropic-skill) -->\n---\nname: bilibili-evolved-dev-server\ndescription: Bilibili-Evolved local dev server workflow. Use when working in the Bilibili-Evolved repository and needing to start the dev server, compile or watch one registry component/plugin, create a component/plugin scaffold through the dev server, reason about HTTP build-on-request versus WebSocket commands, or use DevClient during local feature development.\n---\n\n# Bilibili Evolved Dev Server\n\n## Core Model\n\n- Read `AGENTS.md` and `CONTRIBUTING.md` before making repo changes.\n- Use PowerShell syntax on Windows.\n- Use `pnpm`; do not use npm.\n- Start the local dev server with:\n\n```powershell\npnpm tsx dev-tools/dev-server/index.ts\n```\n\n- HTTP serves static resources only, but requesting `/registry/dist/components/<id>.js` or `/registry/dist/plugins/<id>.js` may trigger build-on-request before serving the file.\n- WebSocket is the control plane for explicit commands such as build, watch, stop, create, session query, and graceful server shutdown.\n- `dist/`, `registry/dist/`, and generated feature docs are not normal development changes.\n\n## Feature Commands\n\nUse these commands when the dev server is already running:\n\n```powershell\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts build component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts build plugin video/player/speed\npnpm tsx dev-tools/dev-server/command.ts watch component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts stop component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\n- `build` compiles one feature once without creating a watcher.\n- `watch` starts or reuses one feature watcher.\n- `stop` stops one watcher.\n- `sessions` prints active watched feature paths.\n- `shutdown` gracefully exits the dev server and its core and feature watchers. Prefer it over terminating the process tree externally.\n- Prefer these commands over full registry builds when validating one component or plugin.\n\n## Creating Features\n\nCreate new registry component/plugin scaffolds through the dev server command:\n\n```powershell\n$authorName = gh api user --jq \".login\"\n$authorLink = gh api user --jq \".html_url\"\npnpm tsx dev-tools/dev-server/command.ts create component style/my-feature myFeature \"My Feature\" $authorName $authorLink \"Feature description.\"\npnpm tsx dev-tools/dev-server/command.ts create plugin video/player/my-plugin myPlugin \"My Plugin\" $authorName $authorLink \"Plugin description.\"\n```\n\nBefore creating a feature, get the current GitHub user from `gh` with `gh api user --jq \".login\"` and use that as `authorName`; get the profile URL with `gh api user --jq \".html_url\"` and use that as `authorLink`. If `gh` is unavailable, not authenticated, or returns a blank value, ask the user for the GitHub username/profile link before running `create`. Do not use the code agent name, local OS username, or local Git `user.name` / `user.email` for author metadata.\n\nAfter creation, inspect and edit the generated `index.ts` and `index.md`. Keep component/plugin names specific and camelCase, include author metadata for contributor-created features, and keep descriptions in `index.md`.\n\n## DevClient\n\n- DevClient connects to `ws://localhost:<port>`.\n- Starting debug from the settings panel rewrites the feature update URL to the local `/registry/dist/...` URL and relies on HTTP build-on-request.\n- Stopping debug, losing the dev server, or seeing a feature session disappear should restore the original update URL.\n- If debugging state looks wrong, query sessions first, then inspect DevClient `devRecords` and auto-update URLs.\n\n## Browser Checks\n\n- Bilibili Evolved depends on a userscript manager extension such as Tampermonkey. The built-in browser and Playwright do not provide that extension environment and are not reliable for runtime behavior checks.\n- If real browser validation is useful and available, try controlling the user's Chrome browser because it can use the installed userscript manager, extension permissions, login state, and real Bilibili pages.\n- Browser validation is optional for this skill. If Chrome, the userscript manager, account state, or the target page is unavailable, continue the dev server workflow and report that browser validation was not performed.\n\n## Validation\n\n- For TypeScript changes, run `pnpm run type`.\n- For lint-sensitive changes, run `pnpm run lint-check`.\n- For core userscript changes, use the dev server's core watcher, which automatically compiles the development build.\n- For registry feature changes, run `pnpm tsx dev-tools/dev-server/command.ts build <component|plugin> <id>` while the dev server is running; the compiled output is served from memory.\n- `pnpm run build-core` and `pnpm run build-features` are production CI or release validations. Run them locally only when explicitly requested, reproducing a CI failure, changing shared build infrastructure, or preparing a release.\n\n<!-- File: dev-tools/dev-server/README.md (Tokens: ~679 | Category: plugin-manifest) -->\n# Bilibili Evolved Dev Server\n\n## HTTP\n\nThe HTTP server serves static files from the repository root only for core outputs.\n\n- `dist/*` -> core userscript outputs\n\nRequests to `registry/dist/components/<id>.js` and `registry/dist/plugins/<id>.js` are virtual output URLs. They trigger build-on-request when the memory output is missing, then return the compiled output from memory. Other `/registry/*` URLs are not served from disk. HTTP does not expose control APIs.\n\n## WebSocket\n\nDev server WebSocket: `ws://localhost:23333` by default.\n\nWebSocket is the command and event control plane.\n\nClient commands:\n\n```json\n{ \"type\": \"queryFeatureSessions\" }\n```\n\n```json\n{ \"type\": \"shutdownServer\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"buildFeature\", \"kind\": \"component\", \"id\": \"style/hide/banner\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"startFeatureSession\", \"kind\": \"plugin\", \"id\": \"video/player/speed\", \"requestId\": \"...\" }\n```\n\n```json\n{ \"type\": \"stopFeatureSession\", \"kind\": \"component\", \"id\": \"style/hide/banner\", \"requestId\": \"...\" }\n```\n\n```json\n{\n  \"type\": \"startDebugFeature\",\n  \"kind\": \"component\",\n  \"id\": \"style/hide/banner\",\n  \"targetClientId\": \"dev-client-1\",\n  \"requestId\": \"...\"\n}\n```\n\n```json\n{\n  \"type\": \"createFeature\",\n  \"kind\": \"component\",\n  \"id\": \"style/my-feature\",\n  \"name\": \"myFeature\",\n  \"displayName\": \"My Feature\",\n  \"authorName\": \"Author Name\",\n  \"authorLink\": \"https://example.com\",\n  \"description\": \"Feature description.\",\n  \"requestId\": \"...\"\n}\n```\n\nServer events:\n\n- `serverReady`: initial connection event with `clientId` and active `featureSessions`.\n- `featureSessionsChanged`: active watched feature paths changed.\n- `itemUpdate`: watched feature compiled and DevClient should update.\n- `featureBuilt`: explicit feature build or watched build completed.\n- `featureBuildFailed`: explicit feature build failed.\n- `serverStop`: server is shutting down; DevClient should restore dev URLs and close the socket.\n- `commandResult`: response for commands with `requestId`.\n\n## CLI\n\nUse the command client while the dev server is running:\n\n```powershell\npnpm tsx dev-tools/dev-server/command.ts sessions\npnpm tsx dev-tools/dev-server/command.ts build component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts watch plugin video/player/speed\npnpm tsx dev-tools/dev-server/command.ts stop component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts start-debug component style/hide/banner dev-client-1\npnpm tsx dev-tools/dev-server/command.ts stop-debug component style/hide/banner\npnpm tsx dev-tools/dev-server/command.ts shutdown\n```\n\n`shutdown` responds to the command client, broadcasts `serverStop`, and then gracefully closes core and feature watchers, WebSocket connections, and the HTTP server.\n</yakaai_skills>"}