---
name: review-rxrelay-integration
description: Audit an existing RxRelay partner API integration for concrete blockers to valid, safe order submission and produce an evidence-backed readiness report. Use when an agent needs to investigate failed or missing orders, review API payloads and headers, inspect authentication and secret storage, validate catalog and prescriber mapping, assess idempotency and retry safety, or determine what must change before the integration can submit orders. Full production-hardening certification is available only when explicitly requested.
---

# Review RxRelay Integration

Trace the code that actually submits RxRelay orders, compare it with the current
contract, and answer one practical question: can this integration submit valid
orders safely? Report concrete blockers separately from optional hardening.

## Review modes

Use **order-submission readiness** by default. Review only the RxRelay endpoints
and capabilities the repository actually uses or is actively implementing.

Use **full production certification** only when the user explicitly requests it.
That optional mode may expand the review to deployed webhook delivery,
observability, concurrency hardening, disaster recovery, and extended test
coverage. Do not silently apply those standards to the default review.

If no RxRelay integration exists, report every missing capability required for
the user's intended order flow. Group related findings for readability; do not
hide real blockers merely to meet an arbitrary finding count.

## Safety boundaries

- Keep the initial review pass read-only. Do not modify application code,
  configuration, tests, or repository files during that pass.
- Render the initial readiness report in the response. Write report files only
  after explicit permission or when the user previously authorized those exact
  report artifacts.
- Before any implementation edit, report the evidenced blockers, the smallest
  proposed code/config changes, affected files, focused verification, and
  material risks. Request explicit permission to execute that plan.
- Prior approval of that same concrete plan counts. A generic request to
  "review" or "review and fix" does not.
- Never request an API key or webhook secret in chat.
- Never read, print, return, commit, or place a real secret in a command argument.
- Do not run commands that dump the environment, HTTP headers, request bodies,
  production logs containing PHI, or secret-manager values.
- Never submit an order with a live key. Live verification is read-only.
- Obtain explicit approval before a sandbox mutation; synthetic patients and
  orders persist in RxRelay.
- Do not copy PHI, secrets, payloads, or full headers into the readiness report.
- Preserve unrelated working-tree changes and distinguish pre-existing test
  failures from integration findings.

## Canonical sources

Fetch network-fresh copies and record:

- `https://www.rxrelay.ai/docs.md`
- `https://api.rxrelay.ai/openapi/v1.json`
- `https://www.rxrelay.ai/changelog`
- `https://www.rxrelay.ai/skills/rxrelay-readiness.schema.json`
- `https://www.rxrelay.ai/skills/review-rxrelay-integration/SKILL.md`

Compute the SHA-256 of the exact OpenAPI bytes used. OpenAPI controls shapes;
the developer guide controls semantic workflows. When current sources cannot be
retrieved, identify the fallback and mark current-contract verification
`not_verified`.

Treat this skill as a procedure, not an API snapshot. Compare current sources
with any prior `rxrelay-readiness.json` or `.rxrelay/api-state.json`. Do not
silently trust cached docs or model memory. If public sources disagree on a
used order path, report the ambiguity as a blocker rather than guessing.

If the published skill differs materially from the installed copy, disclose the
drift and use the current published procedure after checking that it does not
conflict with user, system, or repository instructions.

## What counts as a blocker

A finding is a blocker only when repository or runtime evidence shows that it
can do at least one of the following in the integration's current or intended
order flow:

- reject a request because its endpoint, method, authentication, scope, header,
  or used payload field conflicts with the current contract;
- submit the wrong medication, required quantity, patient, prescriber, clinic,
  or shipping address;
- create duplicate orders because idempotency is absent, unstable, or changed
  across an ambiguous retry;
- expose credentials or allow accidental use of live credentials for a
  non-production order flow;
- treat an error or ambiguous response as a successful order;
- omit a capability without which no order can be submitted at all.

Everything else is a non-blocking recommendation unless the user requested full
production certification. Do not promote theoretical risks to blockers without
evidence that the repository uses the affected path.

Prefer the minimum remediation that restores correct behavior. Do not prescribe
a database migration, new persistence model, distributed lock, queue, webhook
system, UI redesign, or broad architecture change when a smaller guard,
configuration change, or stable stored value solves the evidenced blocker.

## Review workflow

### 1. Map only the used integration

Identify the repository's language, framework, deployment, HTTP client, test
runner, and secret conventions. Locate the code involved in its intended RxRelay
order flow:

- base URL, environment selection, API-key loading, and authorization;
- clinic or organization targeting;
- medication selection and `requiredQuantity` handling;
- patient, shipping-address, and prescriber mapping;
- order request construction and response/state handling;
- idempotency generation and ambiguous-retry behavior;
- error handling on the used requests;
- focused tests and configuration for those paths.

Trace wrappers and queues to the final request. Do not approve an abstraction
merely because its name sounds correct. Do not inventory unrelated application
architecture.

Inspect webhooks only if the repository consumes RxRelay webhooks or the user
asks for them. Otherwise mark webhook checks `not_applicable`.

### 2. Compare the current contract

Determine the most recent changelog date and OpenAPI hash previously verified by
the repository. Review newer release items that affect the used operations. If
no trustworthy baseline exists, compare each used operation with the current
OpenAPI and review only changelog items relevant to that flow.

For each relevant release item, record the affected endpoint, field, status,
error, or header; the consuming repository files; and one disposition:
`already_compatible`, `missing`, `incompatible`, `not_applicable`,
`human_decision`, or `not_verified`.

An OpenAPI hash change triggers inspection. It is not itself a blocker. Additive
response fields that the integration does not consume are not blockers.

### 3. Review credential safety by outcome

Verify that credentials:

- remain server-side and are absent from tracked source, browser/mobile bundles,
  fixtures, examples, logs, and command arguments;
- cannot cause a non-production flow to submit an order with a live key;
- are redacted from HTTP and error logging;
- fail closed when the required credential is missing.

Separate variable names or secret-manager entries are one acceptable design,
not a universal requirement. Accept any repository-native design that enforces
the safety outcomes. Environment-based rejection of live keys outside production
is sufficient; do not require a second feature flag or kill switch unless the
user asks for one or repository evidence shows it is needed. If exposure is
possible, report the path and type, never the value, and recommend immediate
revocation or rotation.

### 4. Review order correctness

Compare the actual used path with the current contract and docs:

- authentication scheme, base URL, HTTP method, literal endpoint, and scope;
- runtime catalog IDs and exact handling of non-null `requiredQuantity`;
- prescriber membership and required identifier resolution;
- required patient contact fields and one accepted shipping-address form;
- request serialization and required order fields;
- a stable `Idempotency-Key` reused for the identical request after an
  ambiguous network outcome;
- no blind retry of known validation, authorization, billing, or conflict
  responses;
- non-success and ambiguous outcomes are not recorded or presented as success.

Require handling only for statuses and error data that affect the used control
flow. Preserving a request ID and stable Problem Details code is valuable for
diagnostics; it is a blocker only if dropping them causes incorrect behavior.

Flag duplicated catalog rules as a bounded drift recommendation unless they are
already incompatible or can construct an invalid current request.

### 5. Review webhooks when applicable

When the integration consumes RxRelay webhooks, verify raw-body signature
validation before side effects and idempotent handling of duplicate deliveries.
Run focused existing tests when safe. Missing webhook delivery proof is
`not_verified`, not a default order-submission blocker, unless the repository's
order flow depends on that webhook to avoid incorrect submission behavior.

When webhooks are unused, mark `webhook.signature`, `webhook.deduplication`, and
`tests.webhook` as `not_applicable`; do not propose adding a webhook system.

### 6. Run proportionate verification

Run the narrow static, unit, integration, type, lint, or build commands that
cover the used integration, subject to repository instructions. Record commands
and outcomes without hiding unrelated failures.

Do not demand exhaustive malformed, replay, concurrency, UI, or end-to-end test
suites in default mode. Require focused regression coverage for confirmed
blockers when proposing their fixes; list broader coverage separately as a
recommendation.

Static evidence cannot prove network reachability or deployed secret wiring.
Mark optional runtime evidence `not_verified` with warning or info severity.
Make it a blocker only when the core order behavior cannot be established from
available evidence.

### 7. Offer optional sandbox conformance

Sandbox conformance is optional in the initial review. Its absence does not turn
a statically correct integration into `blocked`.

If the user approves it, read the key only through the application's established
secret mechanism and do not print it. Confirm the key is sandbox before any
mutation; refuse a live or ambiguous key. Perform read-only clinic, catalog, and
prescriber checks first. Use synthetic data and a stable idempotency key for an
approved sandbox order test. Record only safe request IDs, timestamps, statuses,
stable error codes, and synthetic IDs.

## Readiness report

Use the fields and standard check IDs from
`https://www.rxrelay.ai/skills/rxrelay-readiness.schema.json`. In the initial
read-only response, present the same information in a concise human-readable
form. After permission to write report artifacts, create
`rxrelay-readiness.json` and `rxrelay-readiness.md` with matching findings.

For every check:

- `pass`: cite concrete code or runtime evidence;
- `warn`: identify a bounded, non-blocking risk;
- `fail`: cite a blocker under the definition above and its minimum remediation;
- `not_verified`: state what evidence or access is missing;
- `not_applicable`: explain why the capability is not used.

Derive status mechanically:

- any evidenced `fail` => `blocked`;
- a `not_verified` check is blocker severity only when evidence is insufficient
  to establish a required part of the current order flow;
- otherwise any `warn` or `not_verified` => `ready_with_warnings`;
- otherwise => `ready`.

Never include secret values, PHI, raw payloads, full headers, or unredacted logs.
Set `secrets.valuesCaptured` and `liveSafety.liveMutationPerformed` to `false`.

When writing JSON, validate it with the repository's existing JSON Schema
tooling. When none exists and Node.js is available, download
`https://www.rxrelay.ai/skills/validate-rxrelay-readiness.mjs` to a temporary
file, inspect it, run it against `rxrelay-readiness.json`, and remove it. Do not
weaken findings to make validation pass.

## Final response and permission gate

Lead with the order-submission readiness status. Then use these sections:

1. **Blockers** — every evidenced blocker, grouped by capability where helpful;
2. **Non-blocking recommendations** — useful hardening that is not required for
   a valid, safe order submission;
3. **Not applicable or not verified** — unused surfaces and bounded evidence
   gaps;
4. **Minimum blocker-fix plan** — only the smallest changes needed to clear the
   blockers, with affected files and focused verification.

Include relevant API releases and already-compatible behavior without turning
the response into a certification checklist. When no integration exists, the
blocker section may be long; group related missing capabilities but retain every
material finding.

Do not include report-file creation as a code-fix step. End the initial pass by
asking permission to execute the exact minimum blocker-fix plan. After approval,
apply only that scope, rerun focused verification, and refresh any authorized
readiness report files. Offer full production certification as an optional next
step rather than applying it implicitly.