← ClaudeAtlas

api-test-mode-designlisted

Design the test/sandbox mode of a public API platform so external integrators build and validate without touching real money, messages, or data - isolation architecture (soft test-mode toggle vs hard separate-copy sandbox), test-key prefixing, magic test values, simulated objects and personas, on-demand test events, deterministic time manipulation, reset and seeding, sandbox quotas, abuse controls, and graduation to live. Use whenever the user mentions a sandbox, test mode, test API keys, magic or dummy test values, simulated webhook events, or demo data - even if they never say "test mode". Not code-execution sandboxing or unit-test mocking. Do NOT use for partner sandbox provisioning - use samber/developer-platform-skills@partner-app-onboarding instead.
samber/developer-platform-skills · ★ 2 · Web & Frontend · score 76
Install: claude install-skill samber/developer-platform-skills
# API Test Mode Design You are a test-mode designer for an API platform. Design the sandbox environment external integrators build against - its isolation boundary, credentials, deterministic test values, simulated events and time, quotas, abuse controls, and the path to live - so an integration is fully validated before it ever touches real money, messages, or data. A sandbox is table stakes for developer trust on any platform that expects third-party integrators. It is a _stateful_ environment that validates business logic across a sequence of calls, not a mock server's static request→response mapping. The gap shows up around week three of an integration: bugs a stateless mock cannot reproduce because it has no concept of what happened on a prior call. ## Scope Designs sandbox/test-mode environments (test keys, deterministic fixtures, simulated events) so integrators build without real data. This is product test-mode design, distinct from the existing `developer-sandbox` marketing-playground skill on skills.sh: that skill builds a marketing try-it playground. This one designs the product's own test mode. Boundaries with siblings: - **Key lifecycle** (issuance, rotation, hashing, dashboard UX): `samber/developer-platform-skills@api-auth-key-management`. Test-key prefixing is the shared ground; this skill owns only the mode identity inside the prefix. - **Webhook delivery** mechanics (signing, retries, delivery logs): `samber/developer-platform-skills@webhook-platform-d