fix: learn from #105 correction

.github/tigent.yml

@@ -1,72 +1,38 @@
 confidence: 0.6
-
 users:
   - gr2m
   - dancer
   - aayush-kapoor
   - 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/<name> 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.