원클릭으로
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