diff --git a/.github/tigent.yml b/.github/tigent.yml index 9602696..480637d 100644 --- a/.github/tigent.yml +++ b/.github/tigent.yml @@ -1,5 +1,4 @@ confidence: 0.6 - users: - gr2m - dancer @@ -7,66 +6,33 @@ users: - lgrammel - nicoalbanese - felixarntz +prompt: >- + - area labeling: ai/core covers core APIs (generateText, generateObject, + streamText, streamObject, tool calling, structured output, steps, middleware, + telemetry hooks) and any OpenAI Responses API structured outputs; ai/ui, + ai/ui-vue, ai/rsc, ai/provider, ai/mcp, ai/gateway, ai/telemetry, ai/codemod, + expo, tools-registry, codex as before. -prompt: | - this bot labels issues and prs for the vercel ai sdk monorepo. the ai sdk provides a unified api for working with large language models across providers. - - area labels (assign one or more based on which package is affected): - ai/core is for the core generateText, generateObject, streamText, streamObject apis, tool calling, structured output, steps, middleware, telemetry hooks, and anything in the ai package that isn't ui-related. - ai/ui is for useChat, useCompletion, useAssistant, UIMessage, ui message streaming, react hooks, and frontend integration. also covers angular and svelte ui bindings. - ai/ui-vue is specifically for vue.js ui bindings. - ai/rsc is for react server components integration, createStreamableUI, createStreamableValue, and server action streaming. - ai/provider is for the provider interface, provider registry, model specifications, and shared provider utilities. use this when the issue is about how providers implement the ai sdk interface. - ai/mcp is for model context protocol integration, mcp client, mcp server tools, and @ai-sdk/mcp. - ai/gateway is for the ai gateway (@ai-sdk/gateway), provider routing, oidc auth, and the vercel ai gateway service. - ai/telemetry is for opentelemetry integration, tracing, span attributes, and observability. - ai/codemod is for codemods, migration scripts, and automated code transformations between sdk versions. - expo is for react native and expo-specific issues, metro bundler compatibility, and mobile platform concerns. - tools-registry is for the tools registry, tool packages, and shared tool definitions. - codex is for codex-related functionality. + - provider labeling: assign ai/provider plus the specific provider label + (e.g., provider/openai) for provider-specific issues; also keep + provider/openai-compatible, provider/community, and the audio/speech provider + labels as defined. - provider labels (assign when the issue is specific to a provider): - provider/openai for openai and gpt models. provider/anthropic for anthropic and claude models. provider/google for google ai and gemini models. provider/google-vertex for google vertex ai. provider/azure for azure openai. provider/amazon-bedrock for aws bedrock. provider/xai for xai/grok. provider/mistral for mistral. provider/cohere for cohere. provider/groq for groq. provider/deepseek for deepseek. provider/fireworks for fireworks. provider/togetherai for together ai. provider/perplexity for perplexity. provider/replicate for replicate. provider/huggingface for hugging face. provider/cerebras for cerebras. provider/deepinfra for deepinfra. provider/baseten for baseten. provider/fal for fal. provider/luma for luma. provider/black-forest-labs for bfl/flux image models. provider/gateway for the gateway provider specifically. provider/vercel for the vercel provider. - provider/openai-compatible is for issues with providers using the openai-compatible base layer. - provider/community is for community-maintained providers not officially supported. - provider labels for audio/speech: provider/elevenlabs, provider/lmnt, provider/hume, provider/deepgram, provider/assemblyai, provider/gladia, provider/revai. + - type labeling: bug, feature, documentation, maintenance, support, wontfix, + deprecation as defined. - type labels: - bug is for defects, regressions, unexpected errors, incorrect behavior. look for phrases like "doesn't work", "error", "crash", "regression", "broke", "unexpected". - feature is for new capabilities that don't exist yet. look for "feature request", "would be nice", "support for", "add ability to". - documentation is for docs improvements, typos, missing guides, incorrect examples, broken links, outdated references. - maintenance is for dependency updates, refactoring, ci/cd, tooling, code cleanup, test improvements, normalizing patterns across packages. - support is for general questions, help requests, usage guidance, and "how do i" questions. most user-filed issues that aren't clear bugs get support. - wontfix should never be assigned by the bot. - deprecation is for marking apis, features, or patterns as deprecated in favor of newer alternatives. + - triage labels: reproduce-needed, reproduce-provided, pull-request-welcome, + good-first-issue, external, resumability as defined. - triage labels: - reproduction needed means the bug report lacks a minimal reproduction. assign this when someone reports a bug but doesn't include steps to reproduce, a code snippet, or a repo link. - reproduction provided means a reproduction has been supplied (code, repo link, or clear steps). - pull request welcome marks issues where the team would appreciate community prs. similar to good first issue but can be more complex. - good first issue is for small, well-scoped tasks suitable for new contributors. - external means the issue is caused by something outside the ai sdk (a provider api change, a framework bug, a user's environment). - resumability is for issues related to resumable streams and recovery. + - version labels: major, minor, backport as defined. - version labels: - major marks prs that include breaking changes requiring a major version bump. - minor marks prs that add new features requiring a minor version bump. - backport marks prs that should be backported to older release branches. + - workflow labels: type:batch, type:epic as defined. - workflow labels: - type:batch is for coordinated changes across multiple packages. - type:epic is for large tracked initiatives spanning multiple prs. + - labeling patterns: when the issue concerns core API functionality or OpenAI + Responses API structured outputs, include ai/core; if it also concerns a + provider, include ai/provider and the provider/ label. For example: “Add + support for OpenAI Responses API structured outputs” should be ai/core, + ai/provider, provider/openai. - labeling patterns observed in this repo: - most issues get an area label (ai/core, ai/ui, ai/provider) plus support. bugs also get bug. provider-specific issues get both ai/provider and the specific provider label (e.g., provider/anthropic). - prs typically get area labels matching what they change, plus bug or feature or documentation as the type. - issues mentioning streaming, generateText, generateObject, streamText, streamObject, tool calling, structured output, steps, or middleware are ai/core. - issues mentioning useChat, useCompletion, hooks, or frontend are ai/ui. - issues about a specific provider's behavior (model responses, api compatibility, token counting) get both ai/provider and the provider label. - issues about the gateway, routing, or oidc get ai/gateway. - issues about mcp servers, mcp tools, or model context protocol get ai/mcp. - docs prs that only touch documentation files get documentation alone. - dependency update prs get maintenance. - if an issue mentions both a bug and a provider, assign bug + ai/provider + the provider label. - if someone asks "how do i" or "is it possible to", that's support plus the relevant area. - do not assign labels you are not confident about. under-labeling is better than mislabeling. + - do not assign labels you are not confident about; under-labeling is better + than mislabeling.