Add Flow Vault API coverage to call-rest-apis skill

[jstjoe]

Summary

Adds coverage for Skyflow's new Flow Vault API to the call-rest-apis skill, so it sits alongside the existing Data, Detect, and Management API coverage. Source content came from the skyflow-fern-config repo (used read-only as a source — no changes were made there).

Changes

• flow-vault.openapi.json (new) — the complete Flow Vault OpenAPI 3.0 spec, copied verbatim from the source repo. Covers 43 paths: V2 vault management, records, query, and tokens; V1 policies, roles, service accounts, users, workspaces, accounts, token exchange (STS), and authentication.
• flow-vault-api.md (new) — a task-oriented guide following the same format as the other *-api.md guides. Includes endpoints, operationIds, copy-pastable curl examples, request/response bodies, and parameters for the key operations, plus sections on base URLs, authentication, redaction levels, token groups, hashings, and partial-success error handling.
• SKILL.md — added Flow Vault rows to the API quick reference table, listed the new spec under OpenAPI Specifications, noted Flow Vault's required X-SKYFLOW-ACCOUNT-ID header and distinct base URLs, and extended the usage instructions.
• CONTRIBUTING.md — added the flow-vault-api.md → flow-vault.openapi.json mapping (and corrected the stale vault-api.md entry to data-api.md).
• README.md (plugin) — updated the call-rest-apis description to mention the Flow Vault API.

Notes on Flow Vault specifics captured in the guide

• Two base domains: skyvault.skyflowapis.com for records/query/tokens, skyflowapis.com for management/governance.
• X-SKYFLOW-ACCOUNT-ID is required on every request.
• Redaction values are lowercase (plain_text, redacted) unlike the classic Data API.
• Batch record/token operations support partial success (per-item httpCode/error, HTTP 207).

Verification

• flow-vault.openapi.json is byte-identical to the source spec and parses as valid JSON (title "Flow Vault API", 43 paths).
• All operationIds cited in the guide were cross-checked against the spec.
• The source skyflow-fern-config working tree is unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JJ6x5iN7BXYFd6XNqh8yGb

---

Generated by Claude Code

[jstjoe]

Hey @claude code review please?

[jstjoe]

Code review (requested by @jstjoe)

Reviewed the diff on claude/flow-vault-api-skyflow-wjl6w8. Overall it's accurate and consistent with the existing API guides. Checks run against the bundled flow-vault.openapi.json:

• ✅ All 22 endpoints and 20 operationIds cited in flow-vault-api.md exist in the spec, with matching methods/paths.
• ✅ Nested request/response field names verified against the spec schemas — columnRedactions (columnName/redaction), tokenGroupRedactions (tokenGroupName/redaction), getTokens records (value/tokenGroupName), secrets (hashName/secret), policy ruleParams, service-account response, etc.
• ✅ flow-vault.openapi.json is a byte-identical copy of the source spec (valid JSON, 43 paths).
• ✅ Internal anchor (#get-bearer-token) and the relative spec link resolve.
• ✅ SKILL.md / CONTRIBUTING.md / README.md edits are consistent (also corrects a stale vault-api.md → data-api.md mapping in CONTRIBUTING).

One thing to be aware of (non-blocking):

• updateType isn't modeled in the bundled spec. The guide documents updateType (UPDATE/REPLACE) as a top-level field on POST /v2/records/update, plus upsert.updateType on insert — which matches Skyflow's published Flow Vault how-to docs and their contract-test annotations. However, updateType appears 0 times in flow-vault.openapi.json (UpdateRequest = vaultID/tableName/records; Upsert = uniqueColumns only). This reads as a gap in the upstream spec rather than a guide error, so I'd keep the guide as-is (it reflects real API behavior) and, if worth it, flag the spec upstream in skyflow-fern-config.

Nothing else stood out. LGTM 🟢

---

Generated by Claude Code