How do I install the Sdk E2e Cases skill?

Run npx skillmds@latest add kunpengcompute/sdk-e2e-cases in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Sdk E2e Cases safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Sdk E2e Cases?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Sdk E2e Cases free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Sdk E2e Cases?

kunpengcompute (@kunpengcompute) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Sdk E2e Cases by kunpengcompute — Agent Skill

Name: Sdk E2e Cases
Author: kunpengcompute

Sdk E2e Cases

Write, review, and execute CubeSandbox SDK compatibility E2E pytest cases. Use when the user asks to add, design, review, debug, or run SDK E2E cases under tests/e2e/sdk_compat, or mentions lifecycle, network policy, sandbox templates, backend compatibility, pytest markers, or live E2E validation.

kunpengcompute e9fd959 2 files · 7.3 KB Updated Sep 17, 2026

File contents

SDK E2E Cases

Use this skill for CubeSandbox SDK compatibility E2E work in tests/e2e/sdk_compat.

Required First Steps

Read the relevant local docs before changing tests:
- tests/e2e/sdk_compat/README.md
- tests/e2e/sdk_compat/docs/case-authoring.md
- tests/e2e/sdk_compat/docs/test-coverage.md
- tests/e2e/sdk_compat/docs/framework-design.md
Inspect nearby cases in the same domain directory before writing a new case.
Decide whether the request is case authoring, review, execution, or debugging, then follow the matching workflow below.

Authoring Workflow

Classify the behavior domain: commands, filesystem, host-mount, lifecycle, network, run_code, or concurrency.
Decide whether the behavior is a shared SDK contract or backend-specific behavior.
Use capability and environment markers for unsupported prerequisites. Do not hide backend differences with loose assertions.
Prefer existing fixtures and helpers over new abstractions:
- sdk_sandbox
- sdk_e2e_config
- sdk_backend
- sandbox_create_options
- sandbox_template_id
Keep assertions contract-focused and diagnostics useful. Include IDs, states, URLs, status codes, and short response snippets where helpful, but do not log secrets or traffic access token values.
Add or update docs only when the case introduces a new pattern, marker, environment variable, template requirement, or coverage category.

Review Workflow

Review SDK E2E changes for:

Correctness: the test asserts product/SDK contracts, not incidental implementation details.
Backend compatibility: shared cases run across selected backends, and unsupported behavior uses capability markers.
Lifecycle semantics: running means the sandbox data plane should be usable; do not mask backend bugs with broad retries.
Resource cleanup: created sandboxes are cleaned with existing fixtures/helpers unless intentionally preserved by framework behavior.
Security: do not print API keys, traffic access tokens, machine IPs, or sensitive headers.
Stability: avoid fixed sleeps, public internet assumptions without markers, and unbounded polling.
Maintainability: prefer existing helpers, readable markers, and focused tests.

Execution Workflow

From tests/e2e/sdk_compat, use the smallest command that validates the change:

pytest --collect-only -q
pytest --run-e2e -m "p0 and not slow"
pytest --run-e2e cases/lifecycle/test_create.py -q
pytest --run-e2e cases/network/test_policy.py -q

For live runs, check that required environment variables are documented and intentionally set. Use SDK_E2E_KEEP_SANDBOX_ON_FAILURE=true only when debugging failures.

Additional Reference

For concrete marker templates, review checklists, and command patterns, read REFERENCE.md.

---name: sdk-e2e-casesdescription: Write, review, and execute CubeSandbox SDK compatibility E2E pytest cases. Use when the user asks to add, design, review, debug, or run SDK E2E cases under tests/e2e/sdk_compat, or mentions lifecycle, network policy, sandbox templates, backend compatibility, pytest markers, or live E2E validation.---# SDK E2E CasesUse this skill for CubeSandbox SDK compatibility E2E work in `tests/e2e/sdk_compat`.## Required First Steps1. Read the relevant local docs before changing tests: - `tests/e2e/sdk_compat/README.md` - `tests/e2e/sdk_compat/docs/case-authoring.md` - `tests/e2e/sdk_compat/docs/test-coverage.md` - `tests/e2e/sdk_compat/docs/framework-design.md`2. Inspect nearby cases in the same domain directory before writing a new case.3. Decide whether the request is case authoring, review, execution, or debugging, then follow the matching workflow below.## Authoring Workflow1. Classify the behavior domain: `commands`, `filesystem`, `host-mount`, `lifecycle`, `network`, `run_code`, or `concurrency`.2. Decide whether the behavior is a shared SDK contract or backend-specific behavior.3. Use capability and environment markers for unsupported prerequisites. Do not hide backend differences with loose assertions.4. Prefer existing fixtures and helpers over new abstractions: - `sdk_sandbox` - `sdk_e2e_config` - `sdk_backend` - `sandbox_create_options` - `sandbox_template_id`5. Keep assertions contract-focused and diagnostics useful. Include IDs, states, URLs, status codes, and short response snippets where helpful, but do not log secrets or traffic access token values.6. Add or update docs only when the case introduces a new pattern, marker, environment variable, template requirement, or coverage category.## Review WorkflowReview SDK E2E changes for:- Correctness: the test asserts product/SDK contracts, not incidental implementation details.- Backend compatibility: shared cases run across selected backends, and unsupported behavior uses capability markers.- Lifecycle semantics: `running` means the sandbox data plane should be usable; do not mask backend bugs with broad retries.- Resource cleanup: created sandboxes are cleaned with existing fixtures/helpers unless intentionally preserved by framework behavior.- Security: do not print API keys, traffic access tokens, machine IPs, or sensitive headers.- Stability: avoid fixed sleeps, public internet assumptions without markers, and unbounded polling.- Maintainability: prefer existing helpers, readable markers, and focused tests.## Execution WorkflowFrom `tests/e2e/sdk_compat`, use the smallest command that validates the change:```bashpytest --collect-only -qpytest --run-e2e -m "p0 and not slow"pytest --run-e2e cases/lifecycle/test_create.py -qpytest --run-e2e cases/network/test_policy.py -q```For live runs, check that required environment variables are documented and intentionally set. Use `SDK_E2E_KEEP_SANDBOX_ON_FAILURE=true` only when debugging failures.## Additional ReferenceFor concrete marker templates, review checklists, and command patterns, read `REFERENCE.md`.

Frequently asked questions