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.

## Output

Lead with findings. State separate service-reality, independent-verification,
sensitive-workload-trust, integration-completeness, and merge-readiness
verdicts. Link evidence and label assumptions.