ワンクリックで
cc-verify-serverapi-changes-example-for-verify-skill
Example workflow for verifying a server/API change, as part of the Verify skill.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Example workflow for verifying a server/API change, as part of the Verify skill.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Reference guide covering decision heuristics for building agents on the Claude API, including tool surface design, context management, caching strategies, and composing tool calls
Template for presenting language-specific reference documentation with quick task navigation
Guides Claude in building LLM-powered applications using the Anthropic SDK, covering language detection, API surface selection (Claude API vs Managed Agents), model defaults, thinking/effort configuration, and language-specific documentation reading
Skill definition for the /catch-up periodic heartbeat that scans current priorities, triages actionable changes, reports a short digest, and updates catch-up state
Instructions for using computer-use MCP tools including tool selection tiers, app access tiers, link safety, and financial action restrictions
Prompt for creating verifier skills for the Verify agent to automatically verify code changes
| name | cc-verify-serverapi-changes-example-for-verify-skill |
| description | Example workflow for verifying a server/API change, as part of the Verify skill. |
The handle is curl (or equivalent). The evidence is the response.
curl the route the diff touches, with inputs that hit the changed branchIf there's a run-skill it handles this. If not:
<start-command> &> /tmp/server.log &
SERVER_PID=$!
for i in {1..30}; do curl -sf localhost:PORT/health >/dev/null && break; sleep 1; done
# ... your curls ...
kill $SERVER_PID
No readiness endpoint? Poll the route you're about to test until it stops returning connection-refused, then add a beat.
Diff: adds a Retry-After header to 429 responses in rateLimit.ts.
Claim (PR body): "clients can now back off correctly."
Inference: hitting the rate limit should now return Retry-After: <n>
in the response headers. It didn't before.
Plan:
Retry-After headerExecute:
# trigger the limit — 10 fast requests, limit is 5/sec per the diff
for i in {1..10}; do curl -s -o /dev/null -w "%{http_code}\n" localhost:3000/api/thing; done
# → 200 200 200 200 200 429 429 429 429 429
# capture the 429 headers
curl -si localhost:3000/api/thing | head -20
# → HTTP/1.1 429 Too Many Requests
# → Retry-After: 12
# → ...
Verdict: PASS — Retry-After: 12 present, positive integer.
NaN / undefined / negative → the
logic is wrong