Add LLM Provider (DeepChat Dev Skill)
Add a new LLM provider to DeepChat through reviewed, minimal source changes.
The skill document clearly requires reviewed source changes, includes guardrails (e.g., no auto-installing SDKs, no storing OAuth credentials in API key fields, no executing provider logic in renderer), and emphasizes least-privilege and user confirmation. However, it lacks explicit data-flow transparency and rollback details. The publisher is unverified but this did not lead to deduction. Deductions for incomplete sensitive-data handling and rollback specifics.
The skill provides clear steps and typical file lists, but there is no committed test suite or independent execution evidence. Static review cannot verify key-path reliability. Deductions for thin test coverage and error-handling details.
The skill clearly defines three supported paths (OpenAI-compatible, existing native transport, special provider) with required inputs and guardrails, aiding precise triggering. However, non-fit scenarios and environment constraints (e.g., network reachability) are not described, and Chinese-language optimization is not explicit. Deductions for missing boundary definitions and trigger verification.
The skill document is well-structured with sections for goal, inputs, paths, guardrails, workflow, and output checklist, but lacks install/versioning/changelog and known-limitation disclosure. Publisher is unverified but no deduction for that. Deductions for missing version and maintenance responsibility statements.
The skill defines clear goals and flow, likely completes the core task of adding a provider, but static review cannot verify output direct usability. Deductions for missing representative output validation or comparative-benefit analysis.
The repository has CI workflows and test scripts, but the skill itself lacks reproducible test evidence or third-party execution results. Deductions for insufficient independent verification of key paths.
- The skill document does not detail sensitive-data handling; review the actual implementation for how API keys and OAuth credentials are stored and encrypted.
- Lack of rollback plan; ensure recovery to previous state if provider addition fails.
- Non-fit scenarios are not mentioned; users may misuse the skill for unsupported provider types.
- No versioning or changelog; maintenance responsibility unclear; confirm update channel.
What does this skill do, and when should you use it?
This skill guides developers in adding a new large language model provider to the DeepChat codebase. It starts by collecting required inputs such as provider ID, API type, auth method, and model metadata source, then classifies the request into one of three supported paths: OpenAI-compatible API, existing native transport (e.g., Anthropic, Gemini), or a special provider implementation. Throughout, the skill emphasizes adherence to the existing architecture, avoiding anti-patterns like runtime manifests or automatic SDK installation, and mandates test coverage and running format, i18n, and lint commands. Since the skill is about modifying DeepChat source, it targets developers contributing to the repository or adding new provider integrations.
The skill defines a workflow to add an LLM provider to DeepChat. It first reads existing provider files (defaults.ts, providerRegistry.ts, providerFactory.ts, etc.) to understand the current architecture, then classifies the request into: OpenAI-compatible API, existing native transport (Anthropic/Gemini/Vertex/Azure/Bedrock/Ollama/ACP), or a special provider requiring custom implementation. Based on the classification, it instructs modifying relevant source files including provider registration, model catalog mapping, auth handling, etc. It then requires adding or updating tests to prove provider creation, auth handling, and model discovery, and running pnpm format, pnpm i18n, pnpm lint, and focused tests. Finally, it asks to report changed files, credential storage location, model metadata source, and validation commands.
- A developer adding a new LLM provider (e.g., a new OpenAI-compatible endpoint) to the DeepChat repository.
- A contributor extending DeepChat for an internal OpenAI-compatible service while following project architecture.
- A maintainer needing to add an adapter for a provider with special API behavior (e.g., unique authentication flows).
- A developer adding a provider that maps to an existing native transport (e.g., AWS Bedrock) with minimal registration and mapping.
- A contributor who wants to understand how to add provider support for custom models and ensure test coverage.
What are this skill's strengths and limitations?
- Enforces adherence to existing architecture, avoiding anti-patterns like runtime manifests.
- Provides clear classification paths (OpenAI-compatible, native transport, special provider) simplifying decision-making.
- Emphasizes test coverage and running lint/format, ensuring code quality.
- Requires reporting changed files, credential storage location, and validation commands, increasing auditability.
- Tightly integrated with DeepChat's existing provider architecture, ideal for contributors.
- Only applicable within the DeepChat repository; limited generality.
- Requires understanding of DeepChat source structure and provider architecture; steep learning curve.
- Lacks concrete code examples; abstract.
- Not suitable for non-developers; only for developers.
- No mention of cross-platform testing.
How do you install this skill?
The skill is part of the DeepChat repository (located at .agents/skills/add-provider/SKILL.md). To use it, clone the DeepChat repo and install dependencies: git clone https://github.com/ThinkInAIXYZ/deepchat && cd deepchat && pnpm install && pnpm run installRuntime. The skill itself requires no separate installation.
How do you use this skill?
When asked to add a provider to DeepChat, prompt: 'Use the add-provider skill to add provider support for <ProviderName>.' The skill will guide you through gathering required inputs (provider ID, display name, API type, default base URL, auth type, model metadata source, test model, website/API key URL, docs URL, etc.), then follow the workflow: read the relevant spec document, inspect current provider files, classify the request, make minimal source changes, add tests, and run validation commands (pnpm format, pnpm i18n, pnpm lint, and focused tests).