wowdespacito/anthropics_skills
1
0
Fork 0
mirror of https://github.com/anthropics/skills.git synced 2026-08-02 13:05:28 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update claude-api skill: scheduled deployments, vault env-var credentials, system.message events (#1297)

Browse Source 
- Add Managed Agents scheduled deployments: new
  shared/managed-agents-scheduled-deployments.md (cron schedules, deployment
  runs, pause/auto-pause), Deployments and Deployment Runs API reference,
  beta-header coverage, and SKILL.md routing
- Vault environment_variable credentials: secrets substituted at egress with
  networking allowlists; secrets guidance in tools, client-patterns, and
  onboarding docs rewritten around them; self-hosted sandbox caveats noted
- Add system.message event for mid-session system prompt updates (Opus 4.8
  only) to the events guide and API reference
This commit is contained in:
Lance Martin
2026-06-09 13:35:16 -07:00
committed by GitHub
parent 2235be7c60
commit 5754626092
10 changed files with 279 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/claude-api/shared/managed-agents-client-patterns.md
+3 -1
View File
@@ -183,7 +183,9 @@ Delete the original via `files.delete(uploaded.id)`; the session-scoped copy is
## 9. Secrets for non-MCP APIs and CLIs — keep them host-side via custom tools
**Problem:** you want the agent to call a third-party API or run a CLI that needs a secret (API key, token, service-account credential), but there is currently no way to set environment variables inside the session container, and vaults currently hold MCP credentials only — they are not exposed to the container's shell. So `curl`, installed CLIs, or SDK clients running via the `bash` tool have no first-class place to read a secret from.
**Problem:** you want the agent to call a third-party API or run a CLI that needs a secret (API key, token, service-account credential), but you can't or don't want to hand the secret to a vault.
**First check:** for cloud environments, the first-class answer is now a vault `environment_variable` credential — the agent's shell sees an opaque placeholder and the real secret is substituted at egress. See `shared/managed-agents-tools.md` → Vaults. Use this pattern instead when that doesn't fit: **self-hosted sandboxes** (env-var credentials not yet supported there), clients that reject the placeholder via local format validation, secrets that must never leave your infrastructure, or calls that need host-side binaries.
**Solution:** move the authenticated call to your side. Declare a custom tool on the agent; when the agent emits `agent.custom_tool_use`, your orchestrator (the process reading the SSE stream) executes the call with its own credentials and responds with `user.custom_tool_result`. The container never sees the key.