[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C6FQEB1W6A3CWNYP5SW5MZ":3,"skill-same:01M6C6FQEB1W6A3CWNYP5SW5MZ":102},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6C6FQEB1W6A3CWNYP5SW5MZ","add-provider",null,"Add or extend an open-source OOMOL Connect provider under src\u002Fproviders\u002F\u003Cservice>, including provider definition, action schemas, local executors, credential validation, examples, and generated catalog updates.","Allternit\u002Fallternit-platform","Allternit","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F250397232?v=4","01M6C67T2SPVP033M7REAAHYHX","01M6C67T7CXM1DKVQY8DFAFRB2",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FAllternit\u002Fallternit-platform\u002Fblob\u002Fmain\u002Fservices\u002Fopen-connector\u002F.codex\u002Fskills\u002Fadd-provider\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"add","add provider","provider","extend","connect","definition","source","updates","action","open-source","service","local","credential","catalog","generated","src","open","Providers","examples","validation","2026-11-10 10:12:30",false,"---\nname: add-provider\ndescription: Add or extend an open-source OOMOL Connect provider under src\u002Fproviders\u002F\u003Cservice>, including provider definition, action schemas, local executors, credential validation, examples, and generated catalog updates.\n---\n\n# Add Provider\n\nUse this skill when adding or updating a provider in this repository. The goal is to produce provider code that looks native to this project, is locally runnable when execution is supported, and keeps the public catalog accurate for agents and users.\n\nThis is the agent-oriented workflow for [CONTRIBUTING.md](..\u002F..\u002F..\u002FCONTRIBUTING.md#adding-providers). Follow [AGENTS.md](..\u002F..\u002F..\u002FAGENTS.md) for repository-wide style and verification rules.\n\n## Public Boundary\n\nKeep the repository focused on open-source local execution:\n\n- Do not describe non-public products, non-public migration sources, unreleased SDK behavior, deployment operations, or organization-specific workflows in provider code, docs, examples, or skill text.\n- Do not expose compatibility fields, storage placeholders, or implementation details that have no clear public source and consumer.\n- Do not add provider-local generated schema modules such as `generated.ts` from OpenAPI\u002Ftool output. If the upstream surface is large, choose a small runnable subset and maintain schemas as source.\n- Do not copy third-party logos, screenshots, API specs, documentation excerpts, generated schemas, or brand assets unless the project has the right to distribute them.\n- Prefer official public URLs for `homepageUrl`, API documentation references in comments when truly needed, and credential help text.\n- If you use a reference implementation, treat it only as behavioral evidence. Re-express the provider in this repository's architecture and remove non-public assumptions before finishing.\n\n## Required Context\n\nBefore editing, read:\n\n- `AGENTS.md`.\n- `CONTRIBUTING.md`.\n- `docs\u002Fcatalog-format.md`.\n- Existing providers with similar auth and runtime shape under `src\u002Fproviders`.\n- Shared provider helpers in `src\u002Fcore\u002Fjson-schema.ts`, `src\u002Fcore\u002Fcast.ts`, `src\u002Fcore\u002Frequest.ts`, `src\u002Fcore\u002Ftypes.ts`, and `src\u002Fproviders\u002Fprovider-runtime.ts`.\n\nWhen the provider has official API documentation, use it as the source of truth for endpoints, auth, pagination, request bodies, response envelopes, limits, and error behavior. If you also have a reference implementation, compare it against the official docs instead of copying it blindly.\n\n## Pattern Picker\n\nBefore writing code, pick the closest current provider and follow its current imports and file shape:\n\n- `src\u002Fproviders\u002Fhackernews` or `src\u002Fproviders\u002Fnasa`: no-auth public APIs.\n- `src\u002Fproviders\u002Favoma` or `src\u002Fproviders\u002Fattention`: API key provider with `executors.ts` as credential wiring and provider logic in `runtime.ts`.\n- `src\u002Fproviders\u002Fgithub`: provider supporting both OAuth and API key through one bearer-token runtime context.\n- `src\u002Fproviders\u002Fgmail`: OAuth-only provider with credential validation and resource-specific runtime helpers.\n- `src\u002Fproviders\u002Fbenchmark_email`, `src\u002Fproviders\u002Fclickhouse`, or `src\u002Fproviders\u002Fdataforseo`: custom credentials or user-configured API base URLs.\n- `src\u002Fproviders\u002Fbaselinker`, `src\u002Fproviders\u002Fiqair_airvisual`, or `src\u002Fproviders\u002Fautotask`: provider proxy support and endpoint guards.\n- `src\u002Fproviders\u002Fhttp-json-runtime.ts`: shared helper for simple JSON HTTP providers when the provider does not need a richer local protocol.\n\nDo not copy these examples mechanically. Use them to discover the current helper APIs and module boundaries, then keep only the pieces that match the provider being added.\n\n## Target Shape\n\nProvider code normally lives under:\n\n```text\nsrc\u002Fproviders\u002F\u003Cservice>\u002F\n  definition.ts\n  actions.ts       # Optional, but preferred once the provider has several actions.\n  executors.ts\n  scopes.ts        # Only for non-trivial provider-native scopes or permissions.\n  runtime-*.ts     # Only for real API-family or resource boundaries.\n```\n\nRules:\n\n- Do not create `index.ts` or barrel files.\n- Do not hand-edit generated registry or catalog files. Run generation.\n- Keep definitions importable without network, credentials, or executor code.\n- Keep executor modules lazy. `definition.ts` must not import `executors.ts`, and executor modules should not import `definition.ts` just to reuse catalog metadata.\n- Keep provider-local helpers for provider-specific URLs, signing, pagination, envelopes, error extraction, and response normalization. Put generic casts, reads, query building, request helpers, and credential wiring in shared helpers when they are useful across providers.\n\n## Provider Definition\n\nCreate or update `definition.ts` as catalog source code:\n\n- Export `provider: ProviderDefinition`.\n- Use a stable lowercase service id, usually the product slug.\n- Declare `displayName`, `categories`, `authTypes`, `auth`, optional `homepageUrl` or `iconUrl`, and `actions`.\n- Use `defineProviderAction(service, action)` from `src\u002Fcore\u002Fprovider-definition.ts` so action ids stay stable as `\u003Cservice>.\u003Cname>`.\n- Use provider-native `requiredScopes` and `providerPermissions`; do not invent private aliases.\n- Keep action descriptions and schema descriptions useful for agents. They should describe the business operation and field meaning, not the implementation.\n\nBuild `inputSchema` and `outputSchema` with `s` from `src\u002Fcore\u002Fjson-schema.ts`:\n\n- Prefer existing `s` helpers; read `src\u002Fcore\u002Fjson-schema.ts` for the current helper names instead of inventing provider-local schema wrappers.\n- Drop to plain JSON Schema only for a provider-specific edge case that the shared helper cannot express clearly.\n- Preserve meaningful required fields, enums, formats, min\u002Fmax values, defaults, pagination cursors, follow-up actions, and async lifecycle metadata.\n- Do not copy generated catalog JSON into source.\n- Do not preserve generated safe-integer limits or converter artifacts unless they represent a real provider constraint.\n- Do not hide stable top-level outputs behind `unknown` or overly loose objects when the provider returns a documented shape.\n\n## Auth\n\nMap provider auth to this repository's public credential types:\n\n- `no_auth`: use `authTypes: [\"no_auth\"]` and `auth: [{ type: \"no_auth\" }]`.\n- `api_key`: provide a user-facing label, placeholder, and useful description.\n- `custom_credential`: define explicit fields with labels and descriptions.\n- `oauth2`: configure public authorization URL, token URL, scopes, redirect path behavior if required by current types, token auth method, and static authorization params.\n\nOpen-source users bring their own credentials and OAuth applications. Provider code should validate and use those credentials through the shared runtime interfaces instead of assuming an external credential service.\n\nAdd `credentialValidators` in `executors.ts` when the provider can cheaply verify credentials and return a useful `CredentialProfile`. Use a stable account id and readable display name when the provider exposes them.\n\n## Executors\n\nCreate or update `executors.ts` with `ProviderExecutors`:\n\n- Use `defineProviderExecutors` from `src\u002Fproviders\u002Fprovider-runtime.ts`.\n- Prefer `defineApiKeyProviderExecutors`, `defineOAuthProviderExecutors`, or `defineBearerProviderExecutors` when their context shape fits.\n- Resolve credentials through `ExecutionContext` or the shared credential helpers.\n- Keep action handlers keyed by provider action names.\n- Preserve provider request semantics: endpoint paths, methods, auth headers, request bodies, query params, pagination, status handling, error mapping, and output normalization.\n- Use `ProviderRequestError` for provider API failures that should become stable execution errors.\n- Use shared request helpers such as `setSearchParams`, `readProviderJson`, and `readProviderText` when they fit existing patterns.\n- Pass `context.signal` and transit file support through provider contexts when the provider needs cancellation or file output.\n\nProvider-local runtime files are appropriate when a provider has multiple API areas or a meaningful shared protocol. Do not add local mini-frameworks, schema facades, or action adapter layers just to reduce edit size.\n\n## Historical Failure Modes\n\nPrevious provider batches needed cleanup for these issues. Check them explicitly:\n\n- Do not add catalog-only placeholders or empty `executors`. Add a provider when it has a runnable local executor.\n- Do not commit generated action schema modules. Hand-maintained provider source should own action schemas.\n- If a credential field contains a user-configured base URL, host, workspace URL, or region-derived URL, normalize and validate it with the current public URL helper from `src\u002Fcore\u002Frequest.ts` before any fetch or proxy call. Reject credentials in URLs and unsafe network targets according to that helper.\n- If runtime downloads or uploads files, use existing transit-file and bounded-response helpers. Avoid unbounded `arrayBuffer()` or `text()` reads for file-sized responses.\n- If the upstream API supports streaming, multipart uploads, or very large local files but this runtime only supports JSON-friendly calls, expose the JSON-friendly shape and reject unsupported flags deliberately.\n- Do not add tests that only prove schema validation already rejects malformed fields. Add tests only when provider or shared runtime behavior would otherwise be unprotected.\n\n## Examples And Tests\n\nExamples should be concrete scripts users can run with `node examples\u002F...`. If credentials are required, read them from environment variables and print a clear skip message when missing. Do not add package scripts for every provider example.\n\nProvider tests are not required for simple request\u002Fresponse mapping already covered by centralized provider loader tests. Add targeted tests only when the change introduces non-trivial local logic, shared helper behavior, proxy endpoint guards, credential validation branches, pagination normalization, or a confirmed regression risk.\n\nDo not add tests that only mirror static declarations such as provider labels, auth type arrays, action names, icon URLs, or generated catalog shape.\n\n## Implementation Flow\n\n1. Identify the provider id and the smallest useful runnable action set. Prefer a runnable provider over a catalog-only placeholder.\n2. Read official docs and one or two nearby providers from the pattern picker.\n3. Add or update `definition.ts`, `actions.ts`, `executors.ts`, and provider-local runtime files.\n4. Move genuinely generic helper behavior to shared helper modules only after checking existing APIs and downstream call sites.\n5. Run `npm run generate:catalog`.\n6. Run `npm run fix-check`.\n7. Run targeted tests when you changed shared helpers or added provider logic that is not covered by existing loader tests.\n8. Run `npm run build` when you need CI-parity no-fix typechecking or when the task asks for it.\n9. Review diffs for generated noise, non-public wording, copied assets, placeholder fields, and non-lazy imports.\n\n## Quality Gate\n\nBefore finishing, inspect the result against these checks:\n\n- The provider reads like native open-source code for this repository.\n- Definitions are pure catalog data and executor code is lazy-loaded.\n- Runtime fields have a clear public source and consumer.\n- Auth is locally configurable by users.\n- Schemas are useful public contracts for agents, not loose reflections of unknown JSON.\n- Generic helper code has a single owner.\n- Provider-local helper code has provider-specific meaning.\n- No generated files were hand-edited.\n- No third-party rights issue was introduced.\n- No non-public product behavior is mentioned.\n\n## Final Handoff\n\nState:\n\n- Which provider and actions were added or updated.\n- Whether each action is locally executable or catalog-only.\n- Main files changed.\n- Any shared helpers changed and why the behavior belongs there.\n- Tests intentionally omitted or added, with the reason.\n- Exact validation commands run and their result.\n- Whether full tests were not run.\n","# Add Provider\n\nUse this skill when adding or updating a provider in this repository. The goal is to produce provider code that looks native to this project, is locally runnable when execution is supported, and keeps the public catalog accurate for agents and users.\n\nThis is the agent-oriented workflow for [CONTRIBUTING.md](..\u002F..\u002F..\u002FCONTRIBUTING.md#adding-providers). Follow [AGENTS.md](..\u002F..\u002F..\u002FAGENTS.md) for repository-wide style and verification rules.\n\n## Public Boundary\n\nKeep the repository focused on open-source local execution:\n\n- Do not describe non-public products, non-public migration sources, unreleased SDK behavior, deployment operations, or organization-specific workflows in provider code, docs, examples, or skill text.\n- Do not expose compatibility fields, storage placeholders, or implementation details that have no clear public source and consumer.\n- Do not add provider-local generated schema modules such as `generated.ts` from OpenAPI\u002Ftool output. If the upstream surface is large, choose a small runnable subset and maintain schemas as source.\n- Do not copy third-party logos, screenshots, API specs, documentation excerpts, generated schemas, or brand assets unless the project has the right to distribute them.\n- Prefer official public URLs for `homepageUrl`, API documentation references in comments when truly needed, and credential help text.\n- If you use a reference implementation, treat it only as behavioral evidence. Re-express the provider in this repository's architecture and remove non-public assumptions before finishing.\n\n## Required Context\n\nBefore editing, read:\n\n- `AGENTS.md`.\n- `CONTRIBUTING.md`.\n- `docs\u002Fcatalog-format.md`.\n- Existing providers with similar auth and runtime shape under `src\u002Fproviders`.\n- Shared provider helpers in `src\u002Fcore\u002Fjson-schema.ts`, `src\u002Fcore\u002Fcast.ts`, `src\u002Fcore\u002Frequest.ts`, `src\u002Fcore\u002Ftypes.ts`, and `src\u002Fproviders\u002Fprovider-runtime.ts`.\n\nWhen the provider has official API documentation, use it as the source of truth for endpoints, auth, pagination, request bodies, response envelopes, limits, and error behavior. If you also have a reference implementation, compare it against the official docs instead of copying it blindly.\n\n## Pattern Picker\n\nBefore writing code, pick the closest current provider and follow its current imports and file shape:\n\n- `src\u002Fproviders\u002Fhackernews` or `src\u002Fproviders\u002Fnasa`: no-auth public APIs.\n- `src\u002Fproviders\u002Favoma` or `src\u002Fproviders\u002Fattention`: API key provider with `executors.ts` as credential wiring and provider logic in `runtime.ts`.\n- `src\u002Fproviders\u002Fgithub`: provider supporting both OAuth and API key through one bearer-token runtime context.\n- `src\u002Fproviders\u002Fgmail`: OAuth-only provider with credential validation and resource-specific runtime helpers.\n- `src\u002Fproviders\u002Fbenchmark_email`, `src\u002Fproviders\u002Fclickhouse`, or `src\u002Fproviders\u002Fdataforseo`: custom credentials or user-configured API base URLs.\n- `src\u002Fproviders\u002Fbaselinker`, `src\u002Fproviders\u002Fiqair_airvisual`, or `src\u002Fproviders\u002Fautotask`: provider proxy support and endpoint guards.\n- `src\u002Fproviders\u002Fhttp-json-runtime.ts`: shared helper for simple JSON HTTP providers when the provider does not need a richer local protocol.\n\nDo not copy these examples mechanically. Use them to discover the current helper APIs and module boundaries, then keep only the pieces that match the provider being added.\n\n## Target Shape\n\nProvider code normally lives under:\n\n```text\nsrc\u002Fproviders\u002F\u003Cservice>\u002F\n  definition.ts\n  actions.ts       # Optional, but preferred once the provider has several actions.\n  executors.ts\n  scopes.ts        # Only for non-trivial provider-native scopes or permissions.\n  runtime-*.ts     # Only for real API-family or resource boundaries.\n```\n\nRules:\n\n- Do not create `index.ts` or barrel files.\n- Do not hand-edit generated registry or catalog files. Run generation.\n- Keep definitions importable without network, credentials, or executor code.\n- Keep executor modules lazy. `definition.ts` must not import `executors.ts`, and executor modules should not import `definition.ts` just to reuse catalog metadata.\n- Keep provider-local helpers for provider-specific URLs, signing, pagination, envelopes, error extraction, and response normalization. Put generic casts, reads, query building, request helpers, and credential wiring in shared helpers when they are useful across providers.\n\n## Provider Definition\n\nCreate or update `definition.ts` as catalog source code:\n\n- Export `provider: ProviderDefinition`.\n- Use a stable lowercase service id, usually the product slug.\n- Declare `displayName`, `categories`, `authTypes`, `auth`, optional `homepageUrl` or `iconUrl`, and `actions`.\n- Use `defineProviderAction(service, action)` from `src\u002Fcore\u002Fprovider-definition.ts` so action ids stay stable as `\u003Cservice>.\u003Cname>`.\n- Use provider-native `requiredScopes` and `providerPermissions`; do not invent private aliases.\n- Keep action descriptions and schema descriptions useful for agents. They should describe the business operation and field meaning, not the implementation.\n\nBuild `inputSchema` and `outputSchema` with `s` from `src\u002Fcore\u002Fjson-schema.ts`:\n\n- Prefer existing `s` helpers; read `src\u002Fcore\u002Fjson-schema.ts` for the current helper names instead of inventing provider-local schema wrappers.\n- Drop to plain JSON Schema only for a provider-specific edge case that the shared helper cannot express clearly.\n- Preserve meaningful required fields, enums, formats, min\u002Fmax values, defaults, pagination cursors, follow-up actions, and async lifecycle metadata.\n- Do not copy generated catalog JSON into source.\n- Do not preserve generated safe-integer limits or converter artifacts unless they represent a real provider constraint.\n- Do not hide stable top-level outputs behind `unknown` or overly loose objects when the provider returns a documented shape.\n\n## Auth\n\nMap provider auth to this repository's public credential types:\n\n- `no_auth`: use `authTypes: [\"no_auth\"]` and `auth: [{ type: \"no_auth\" }]`.\n- `api_key`: provide a user-facing label, placeholder, and useful description.\n- `custom_credential`: define explicit fields with labels and descriptions.\n- `oauth2`: configure public authorization URL, token URL, scopes, redirect path behavior if required by current types, token auth method, and static authorization params.\n\nOpen-source users bring their own credentials and OAuth applications. Provider code should validate and use those credentials through the shared runtime interfaces instead of assuming an external credential service.\n\nAdd `credentialValidators` in `executors.ts` when the provider can cheaply verify credentials and return a useful `CredentialProfile`. Use a stable account id and readable display name when the provider exposes them.\n\n## Executors\n\nCreate or update `executors.ts` with `ProviderExecutors`:\n\n- Use `defineProviderExecutors` from `src\u002Fproviders\u002Fprovider-runtime.ts`.\n- Prefer `defineApiKeyProviderExecutors`, `defineOAuthProviderExecutors`, or `defineBearerProviderExecutors` when their context shape fits.\n- Resolve credentials through `ExecutionContext` or the shared credential helpers.\n- Keep action handlers keyed by provider action names.\n- Preserve provider request semantics: endpoint paths, methods, auth headers, request bodies, query params, pagination, status handling, error mapping, and output normalization.\n- Use `ProviderRequestError` for provider API failures that should become stable execution errors.\n- Use shared request helpers such as `setSearchParams`, `readProviderJson`, and `readProviderText` when they fit existing patterns.\n- Pass `context.signal` and transit file support through provider contexts when the provider needs cancellation or file output.\n\nProvider-local runtime files are appropriate when a provider has multiple API areas or a meaningful shared protocol. Do not add local mini-frameworks, schema facades, or action adapter layers just to reduce edit size.\n\n## Historical Failure Modes\n\nPrevious provider batches needed cleanup for these issues. Check them explicitly:\n\n- Do not add catalog-only placeholders or empty `executors`. Add a provider when it has a runnable local executor.\n- Do not commit generated action schema modules. Hand-maintained provider source should own action schemas.\n- If a credential field contains a user-configured base URL, host, workspace URL, or region-derived URL, normalize and validate it with the current public URL helper from `src\u002Fcore\u002Frequest.ts` before any fetch or proxy call. Reject credentials in URLs and unsafe network targets according to that helper.\n- If runtime downloads or uploads files, use existing transit-file and bounded-response helpers. Avoid unbounded `arrayBuffer()` or `text()` reads for file-sized responses.\n- If the upstream API supports streaming, multipart uploads, or very large local files but this runtime only supports JSON-friendly calls, expose the JSON-friendly shape and reject unsupported flags deliberately.\n- Do not add tests that only prove schema validation already rejects malformed fields. Add tests only when provider or shared runtime behavior would otherwise be unprotected.\n\n## Examples And Tests\n\nExamples should be concrete scripts users can run with `node examples\u002F...`. If credentials are required, read them from environment variables and print a clear skip message when missing. Do not add package scripts for every provider example.\n\nProvider tests are not required for simple request\u002Fresponse mapping already covered by centralized provider loader tests. Add targeted tests only when the change introduces non-trivial local logic, shared helper behavior, proxy endpoint guards, credential validation branches, pagination normalization, or a confirmed regression risk.\n\nDo not add tests that only mirror static declarations such as provider labels, auth type arrays, action names, icon URLs, or generated catalog shape.\n\n## Implementation Flow\n\n1. Identify the provider id and the smallest useful runnable action set. Prefer a runnable provider over a catalog-only placeholder.\n2. Read official docs and one or two nearby providers from the pattern picker.\n3. Add or update `definition.ts`, `actions.ts`, `executors.ts`, and provider-local runtime files.\n4. Move genuinely generic helper behavior to shared helper modules only after checking existing APIs and downstream call sites.\n5. Run `npm run generate:catalog`.\n6. Run `npm run fix-check`.\n7. Run targeted tests when you changed shared helpers or added provider logic that is not covered by existing loader tests.\n8. Run `npm run build` when you need CI-parity no-fix typechecking or when the task asks for it.\n9. Review diffs for generated noise, non-public wording, copied assets, placeholder fields, and non-lazy imports.\n\n## Quality Gate\n\nBefore finishing, inspect the result against these checks:\n\n- The provider reads like native open-source code for this repository.\n- Definitions are pure catalog data and executor code is lazy-loaded.\n- Runtime fields have a clear public source and consumer.\n- Auth is locally configurable by users.\n- Schemas are useful public contracts for agents, not loose reflections of unknown JSON.\n- Generic helper code has a single owner.\n- Provider-local helper code has provider-specific meaning.\n- No generated files were hand-edited.\n- No third-party rights issue was introduced.\n- No non-public product behavior is mentioned.\n\n## Final Handoff\n\nState:\n\n- Which provider and actions were added or updated.\n- Whether each action is locally executable or catalog-only.\n- Main files changed.\n- Any shared helpers changed and why the behavior belongs there.\n- Tests intentionally omitted or added, with the reason.\n- Exact validation commands run and their result.\n- Whether full tests were not run.\n",{"name":5,"description":7},"main","7db7c6f88fb96b6792195dacabdb088419b7a9fa","services\u002Fopen-connector\u002F.codex\u002Fskills\u002Fadd-provider",0,"https:\u002F\u002Fgithub.com\u002FAllternit\u002Fallternit-platform","https:\u002F\u002Fgithub.com\u002FAllternit","https:\u002F\u002Fallternit.com","Allternit builds AI agents that work on your computer, in the cloud, and from your phone. Home of Allternit Desktop and Gizzi Code.","2026-11-13 03:03:58",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add Allternit\u002Fallternit-platform --skill add-provider",{"tool":58,"command":59},"bunx","bunx skills add Allternit\u002Fallternit-platform --skill add-provider",{"tool":61,"command":62},"pnpm","pnpm dlx skills add Allternit\u002Fallternit-platform --skill add-provider","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAllternit\u002Fallternit-platform\u002Fblob\u002Fmain\u002Fservices\u002Fopen-connector\u002F.codex\u002Fskills\u002Fadd-provider\u002FSKILL.md",true,[66,72,76,80,84,88,94,98],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"_meta.json","REFERENCE","参考文档",127,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fvirtuals\u002F_meta.json",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":74,"sourceHtmlUrl":75},"package-lock.json",15813,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fvirtuals\u002Fpackage-lock.json",{"path":77,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":78,"sourceHtmlUrl":79},"package.json",600,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fvirtuals\u002Fpackage.json",{"path":81,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":82,"sourceHtmlUrl":83},"skill-card.md",2490,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fvirtuals\u002Fskill-card.md",{"path":85,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":86,"sourceHtmlUrl":87},"SOURCE.md",248,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fvirtuals\u002FSOURCE.md",{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"src\u002Fcli.ts","SCRIPT","脚本",12326,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fvirtuals\u002Fsrc\u002Fcli.ts",{"path":95,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":96,"sourceHtmlUrl":97},"TRUST.auto.yaml",2053,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fvirtuals\u002FTRUST.auto.yaml",{"path":99,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":100,"sourceHtmlUrl":101},"tsconfig.json",417,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fvirtuals\u002Ftsconfig.json",[103,129,148,171,195,224],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":38},"01M6C6GBWRCJNWQP5S16PKXB77","jev","Ask typed System One judgments (noul \u002F choice \u002F score) against Allternit's LOCAL System One server instead of prompting a chat model to \"return JSON\". Use when classifying, routing, scoring, or screening something and code needs a probability it can branch on, or when the user runs \u002Fjev. Official TypeSafe Jev is an optional, explicit remote lane.","https:\u002F\u002Fgithub.com\u002FAllternit\u002Fallternit-platform\u002Fblob\u002Fmain\u002Ftools\u002Fsystem-one-local\u002Fskills\u002Fjev\u002FSKILL.md",[],[105,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,29,125,126,127,128],"official","routing","code","server","lane","system","json","model","choice","branch","ask","user","use","scoring","chat","probability","remote","can","when",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":38},"01M6C6G9CGB9MX47NSQ31QNNB7","jev-route","Route with local System One answers — map Choice + confidence to act \u002F confirm \u002F human lanes, or pick a model tier by Choice label. Also documents the separate `route-model` helper for OpenRouter's typesafe\u002Fjev-router (a chat-model router, NOT System One). Use for confidence routing, model-tier routing, or when the user runs \u002Fjev-route.","https:\u002F\u002Fgithub.com\u002FAllternit\u002Fallternit-platform\u002Fblob\u002Fmain\u002Ftools\u002Fsystem-one-local\u002Fskills\u002Fjev-route\u002FSKILL.md",[],[105,136,137,138,111,115,117,139,118,140,121,122,141,142,124,143,29,144,145,146,147,128],"jev route","route","documents","pick","openrouter","router","model router","map","helper","with","for","model-tier",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":38},"01M6C6G6JZE0RC50QWWE6HG320","jev-guardrail","Screen text or agent tool calls with a battery of local System One Noul hazards plus a Score, with policy in code — and the Claude Code PreToolUse guard (hooks\u002Fpretooluse-guard) that puts deterministic hard rules first and lets Jev only raise friction. Use for injection\u002Fsecret\u002Fdestructive-action screening or when the user runs \u002Fjev-guardrail.","https:\u002F\u002Fgithub.com\u002FAllternit\u002Fallternit-platform\u002Fblob\u002Fmain\u002Ftools\u002Fsystem-one-local\u002Fskills\u002Fjev-guardrail\u002FSKILL.md",[],[105,155,156,157,112,158,159,160,115,161,162,163,121,122,164,165,166,167,29,168,169,146,170,128],"jev guardrail","guardrail","policy","injection","first","guard","tool","text","Rules","friction","only","hooks","deterministic","battery","calls","agent tool",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":182,"publishedAt":38},"01M6C6G426P7Q5J3F98HVYDCB2","jev-fanout","Ask every independent System One question over the same state in ONE POST \u002Fv1\u002Fsystemone to the local server (speculative fan-out). Use for parallel judgments, compound commands, one-call turn assessment, or when the user runs \u002Fjev-fanout. Do not fire one HTTP call per question.","https:\u002F\u002Fgithub.com\u002FAllternit\u002Fallternit-platform\u002Fblob\u002Fmain\u002Ftools\u002Fsystem-one-local\u002Fskills\u002Fjev-fanout\u002FSKILL.md",[177],{"categoryNo":178,"categoryName":179,"taxonomyType":180,"taxonomyTypeDesc":181},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",[105,183,184,185,186,187,113,115,188,120,189,121,122,190,191,29,192,193,146,194,128],"fanout","jev fanout","http","assessment","state","parallel","question","do","call","post","v1","local server",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":38},"01M6C6G13D7JK869Q3DHMQ9542","memory-drive","Read and write the user's Allternit Memory Drive, a git repo of markdown memories in the open Agent Memory Repo format. Use at the start of a session to load what the user's agents remember (MEMORY.md), when the user says \"remember this\", when you learn a durable fact about the user or their work, and before answering questions that depend on past sessions.","https:\u002F\u002Fgithub.com\u002FAllternit\u002Fallternit-platform\u002Fblob\u002Fmain\u002Ftools\u002Fmemory-drive-plugin\u002Fskills\u002Fmemory-drive\u002FSKILL.md",[],[202,203,204,205,206,207,208,209,210,34,211,212,213,214,215,216,121,217,122,218,219,220,221,222,223,128],"memory","drive","memory drive","sessions","remember","learn","git","agent memory","start","markdown","format","work","repo","read","write","session","what the","memories","about","questions","you","load",{"skillNo":225,"name":226,"nameZh":6,"description":227,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":228,"categories":229,"keywords":233,"publishedAt":38},"01M6C6FX778N1047QAJ39Y582H","agent-orchestrator","Orchestrate external CLI agents (kimi, codex, agy, claude, grok, gizzi) through the Allternit Factory (gizzi agents \u002F orchestration \u002F workspace \u002F workflows). Use when the user asks to delegate, offload, or farm out implementation work to another CLI agent \u002F terminal session, or to run work outside this session to save tokens. Part of Allternit Agents \u002F Bot Agents — not a separate product.","https:\u002F\u002Fgithub.com\u002FAllternit\u002Fallternit-platform\u002Fblob\u002Fmain\u002Ftools\u002Fagent-orchestrator\u002FSKILL.md",[230],{"categoryNo":231,"categoryName":232,"taxonomyType":180,"taxonomyTypeDesc":181},"01JBSEEDCAT000000000000023","Skill与智能体开发",[234,235,236,237,238,239,240,241,242,243,244,245,246,213,247,248,217,122,249,250,251,252,253,254,255,256,128],"orchestrator","agent orchestrator","bot","cli","terminal","codex","orchestration","workflows","run","product","orchestrate","save","workspace","delegate","factory","grok","kimi","implementation","offload","tokens","cli agents","farm","terminal session"]