メニュー
Curl-based API smoke testing for backend work. No browser required. Use when building or editing API routes, serverless functions, express endpoints, database layer, or any work where the deliverable is a callable endpoint rather than a UI. Complements web-testing — do not replace it for UI work.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | backend-testing |
| description | Curl-based API smoke testing for backend work. No browser required. Use when building or editing API routes, serverless functions, express endpoints, database layer, or any work where the deliverable is a callable endpoint rather than a UI. Complements web-testing — do not replace it for UI work. |
| user-invocable | false |
| metadata | {"category":"skill"} |
This skill exists because the v2.1.6 run shipped 83 UI components against
hardcoded mock data. Every GET /api/health returned 500 in production and
nobody noticed because nothing tested the endpoint. Workers in backend steps
MUST exercise each endpoint they create before calling the step complete.
Before writing any new endpoint, probe the current state:
cd {{PROJECT_PATH}}
# Start the dev server in the background
npm run dev > /tmp/backend-dev.log 2>&1 &
DEV_PID=$!
# Wait for it to be ready (max 30s)
for i in {1..30}; do
if curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/ >/dev/null 2>&1; then
break
fi
sleep 1
done
# Hit the health endpoint. If it doesn't exist yet, that's fine — the
# absence tells you what to build next.
curl -sS -w '\nHTTP %{http_code}\n' http://localhost:3000/api/health || echo 'no /api/health'
If /api/health already returns non-200, FIX THAT before adding new endpoints.
Building on a failing foundation is the #1 reason v2.1.6 shipped unusable.
For each endpoint you created or modified, record three things in your structured handoff:
POST /api/shipments)Example — creating POST /api/shipments:
curl -sS -w '\nHTTP %{http_code}\n' -X POST http://localhost:3000/api/shipments \
-H 'Content-Type: application/json' \
-d '{"origin":{"line1":"1 test st"},"destination":{"line1":"2 test st"}}'
Expected shape:
{"id":"ship_…","origin":{"line1":"1 test st"},"destination":{"line1":"2 test st"}}
HTTP 201
If the response is 500 or HTML, STOP — do not paper over with a catch that returns mock data. Debug the handler, fix the underlying cause, repeat the curl. You are not done until the endpoint returns the shape you documented.
The v2.1.6 failure had /api/quote expecting { origin: { line1 } } but
the form posted { originLine1 }. Both sides shipped, neither talked to
the other, and the system appeared to work because the UI fell through to
mock data. Avoid this:
[PREREQUISITE-1] breakdown step exists specifically to enforce this —
don't skip it when you are inside a prerequisite step.If the endpoint writes to a database, curl-verify the round-trip. Create → read back → confirm what you created is what you read.
# Create
RESP=$(curl -sS -X POST http://localhost:3000/api/shipments \
-H 'Content-Type: application/json' \
-d '{"origin":{"line1":"A"},"destination":{"line1":"B"}}')
ID=$(echo "$RESP" | jq -r .id)
# Read back
curl -sS -w '\nHTTP %{http_code}\n' "http://localhost:3000/api/shipments/$ID"
If the GET returns 404 or different data, the write did not persist. Do not declare the endpoint working.
Your structured handoff YAML block must include, verbatim, the endpoints you exercised. Keep it tight — list method + path + one-line notes:
what_i_built: "POST /api/shipments persists to Supabase; returns shipment.id"
what_connects: "reads {origin,destination}; writes shipments table"
what_i_verified: "curl -X POST returned 201 with id; GET /api/shipments/:id returned the same record"
known_gaps: "no rate-limiting; no auth check on GET"
Always kill the dev server you started:
kill $DEV_PID 2>/dev/null || true
| Step intent | Skill |
|---|---|
| New or modified API route, serverless function, DB access | backend-testing |
| New or modified UI surface, journey gate, visual verification | web-testing (playwright-cli) |
| Full-stack step that does both | Run backend-testing first, then web-testing |
The executive's Phase 5 integration validator will fail a fullstack gate that claims "UI works" without the backend round-trip being documented in the handoff.
The SOLE WRITER to the V3.0 mem0 second brain. Invoked agentically by the executive at write moments — post-run, post-retro, post-spec-merge, manual /harvest. Decides which facts to classify into which memory type (principle/semantic/procedural/episodic/reflective), validates against the schema, and calls the deterministic plumbing in references/ via Bash. Blocks until writes are durable (poll event endpoint for SUCCEEDED). Never invoked from worker code.
Consult the V3.0 mem0 second brain agentically during executive planning, work selection, pre-spawn memory pack building, and failure diagnosis. Use this skill whenever the executive needs to remember prior runs, retros, or learned principles. Read-only — never writes. Drives the unified `mem0` CLI via Bash, orchestrating multiple iterative search queries (mem0 does not do multi-hop graph traversal natively, so iterative search IS the multi-hop).
Hook D — Failure-Diagnosis memory consultation. Runs at executive Phase 7 (after 3+ consecutive failures on a work item) BEFORE the failure-diagnosis skill itself runs. Consults the second brain for similar prior failures and successful retry strategies, then hands enriched context to the failure-diagnosis skill. Read-only. Invokes the memory-reader skill.
Hook E — Post-Retrospective Harvest. Runs after a retrospective markdown doc completes (per-run or weekly). Reads the retro fully and decides which durable lessons (reflective, semantic, procedural memories) to write to the second brain. Typically 3–8 writes per weekly retro, 0–3 per per-run retro. Invokes the memory-harvester skill for the actual writes.
Hook C — Post-Run Harvest. Runs after a worker completes (executive Phase 6 success path). Decides agentically which facts from the run to write to the second brain — typically 0–3 memory writes per run (one episodic, optionally a semantic or procedural). Invokes the memory-harvester skill to do the actual writes (with event-polling for durability).
Hook B — Pre-Spawn Memory Pack build. Runs before each worker spawn (executive Phase 4 prep). Reads the second brain for project-specific memories and produces a Memory Pack markdown block that worker-spawner injects into the worker's generated CLAUDE.md. Workers consume this as static markdown — they never call mem0 themselves. Read-only. Invokes the memory-reader skill.