bt6-provider-review

namespace	bt6-maintainer
name	bt6-provider-review
platforms	["all"]
description	Audit an external AI/API provider and its integration into a BT6 repository for service reality, independent verification, trust boundaries, secret handling, API/model correctness, completeness, claim traceability, and merge readiness.
triggers	["bt6 provider review","audit an external provider integration","verify an LLM gateway","assess a hosted API provider"]
requires	[{"provider-scope":"provider name plus optional PR or issue reference"},{"repository-context":"canonical repository and profile resolved from project state"}]
ensures	[{"separate-verdicts":"reality, verification, sensitive-workload trust, completeness, and readiness are assessed independently"},{"trust-boundary":"credentials, data, tools, processors, storage, and fallbacks are inventoried"},{"claim-traceability":"security and product claims map to code, configuration, and behavioral tests"}]
commandHint	{"argumentHint":"<provider> [--pr <reference>] [--post-review] [--no-post]","allowedTools":"Bash, Read, Grep","model":"sonnet","category":"code-review","modelRole":"reasoning","modelTier":"standard"}

BT6 Provider Review

Assess the service and integration separately. Apply bt6-maintainer-guardrails. Never treat real, verified, and trustworthy for sensitive workloads as synonyms.

Procedure

1. Resolve the repository profile, PR/issue, exact head SHA, provider, endpoint, credential type, data classification, and claimed capabilities.
2. Run hostile-input preflight. Treat vendor and contributor claims as untrusted assertions until corroborated.
3. Read references/bt6-provider-integration-checklist.md and apply every relevant section.
4. Inventory credentials, prompts, context, outputs, telemetry, tools, subprocessors, storage, and fallback destinations.
5. Verify service reality with non-secret evidence: endpoint behavior, TLS/DNS, official wire documentation, public history, legal identity, and contributor affiliation. Never request or expose a contributor's live key.
6. Verify privacy, assurance, compliance, and operational claims through primary or independent evidence. Record absent reports, certificate identifiers, processor disclosures, retention exceptions, and contradictory policies as unresolved rather than inferring misconduct.
7. Map each security/product claim to implementing code, configuration, and behavioral tests. Classify unmatched claims as provider capability, future scope, or unsupported wording that must be removed.
8. Check profile-defined provider risk surfaces plus every named-provider surface. Compare static model metadata with the authoritative live catalog when one exists.
9. Use templates/bt6-external-provider-assessment.md for the assessment.
10. Re-read the published head and hosted checks before recommending approval or merge.

Decision rules

• real: operational identity and service evidence exists.
• verified: material claims have corroborating evidence and observed wire behavior matches the integration.
• trusted-sensitive: privacy, security, processor, retention, and assurance evidence supports the proposed data classification.
• Default remote providers to explicit opt-in and no silent fallback unless the repository profile explicitly documents a reviewed alternative.
• Never endorse compliance or tool governance based on marketing claims.
• Model routing is not tool governance. A tool-control claim requires explicit policy configuration, every claimed execution path gated before execution, fail-closed outage behavior, and bypass tests.
• Missing checks, head drift, secret leakage, incorrect API/model metadata, or unsupported security claims block approval.