Agent skill

E2E Case Lifecycle

by zai-org in zai-org/ZCode

Plan, maintain, replay, and promote ZCode desktop E2E cases and their fixtures, coverage matrices, and CI admission evidence.

Apache-2.0Auto-check passedTesting & QA

Install E2E Case Lifecycle

skills CLI
$ npx skills add zai-org/ZCode --skill e2e-case-lifecycle -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install zai-org/ZCode e2e-case-lifecycle --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/zai-org/ZCode.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/e2e-case-lifecycle .claude/skills/e2e-case-lifecycle && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
e2e-case-lifecycle
GitHub stars
7.7k
Token cost
~2.1k tokens
SKILL.md length
822 words
Files
2
Skills in repo
5
Repo updated
First seen
Licence
Apache-2.0

At a glance

Plan, maintain, replay, and promote ZCode desktop E2E cases and their fixtures, coverage matrices, and CI admission evidence.

  • Works in 4 steps: Extract state dimensions from the… → Enumerate combinations, then prune… → Write accepted/undefined/pruned… → …
  • Tasks that involve End-to-end testing
  • SKILL.md covers Required Reading, Coverage Planning, Manual Review Case and Promotion, plus 2 more sections
  • Calls pnpm

What it does

E2E Case Lifecycle is an agent skill from zai-org/ZCode. Plan, maintain, replay, and promote ZCode desktop E2E cases and their fixtures, coverage matrices, and CI admission evidence.

Its SKILL.md is about 2.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files (for example `agents/openai.yaml`).

It sits in Testing & QA, covering End-to-end testing. The repository describes itself as: Z.ai's coding agent harness. Powerful, intelligent, extensible. The licence is Apache-2.0.

When your agent uses it

  • Tasks that involve End-to-end testing

Example prompts

  • “/e2e-case-lifecycle”

Requirements

  • Docker

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Extract state dimensions from the feature spec, catalog, and matrix.
  2. Enumerate combinations, then prune invalid or duplicate cases with the user.
  3. Write accepted/undefined/pruned decisions into catalog or matrix docs before code.
  4. Only generate E2E code for accepted semantics. If product behavior is undefined, stop at a question or doc update.

What it can do on your machine

Read from SKILL.md and the folder at commit aac4755. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • pnpm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use pnpm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

E2E Case Lifecycle loads about 2.1k tokens when it runs. Until then it costs about 36 tokens; SKILL.md has 822 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~36
When it runs · the whole SKILL.md, loaded when a task matches
~2.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from zai-org/ZCode at commit aac4755, republished under its Apache-2.0 licence (© zai-org). 822 words, ~2,107 tokens.

Download SKILL.mdSave it as .claude/skills/e2e-case-lifecycle/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
e2e-case-lifecycle
description
Plan, maintain, replay, and promote ZCode desktop E2E cases and their fixtures, coverage matrices, and CI admission evidence.
disable-model-invocation
true

E2E Case Lifecycle

Use this skill for the z-code E2E lifecycle: manual-review automation, capture/replay evidence, formal fixture promotion, Docker admission, and CI. It is intentionally domain-neutral: use it for conversation flows, SSH, provider settings, UI workflows, filesystem behavior, remote runtimes, auth/config, and similar product surfaces. Work from the z-code repo root.

Required Reading

Before writing or moving an E2E spec, read the relevant sections of the domain's case catalog, coverage matrix, and workflow docs. For conversation-session work, the default sources are:

  • docs/conversation-session-case-catalog.md
  • docs/testing/conversation-session-e2e-coverage-matrix.md
  • docs/testing/conversation-session-e2e-development-workflow.md

If the request involves SSH, provider settings, auth/config, fork, goal, fault, model switch, or remote/replayable semantics, also read the matching matrix/spec document under docs/testing/ or the nearest feature docs.

Coverage Planning

For open-ended feature changes or "what should we cover?" requests, use feature-boundary-planner first. Return here only after accepted cases exist in the catalog/matrix.

When asked what to test:

  1. Extract state dimensions from the feature spec, catalog, and matrix.
  2. Enumerate combinations, then prune invalid or duplicate cases with the user.
  3. Write accepted/undefined/pruned decisions into catalog or matrix docs before code.
  4. Only generate E2E code for accepted semantics. If product behavior is undefined, stop at a question or doc update.

Do not claim coverage from a path that merely passes through a state; each covered case needs setup, action, and assertion.

Manual Review Case

For a new candidate case:

  1. Put the spec under the domain's manual-review/pending/ directory. For conversation-session this is packages/desktop/test/e2e/conversation-session/manual-review/pending/.
  2. Use stable E2E_* markers in user prompts and provider matchers.
  3. Prefer existing helpers in packages/desktop/test/e2e/helpers/.
  4. Use buildReadonlyToolPrompt(...) for high/medium priority completed-history setup unless timing makes tool history counterproductive.
  5. Run manual/capture with:
bash
ZCODE_E2E_MANUAL_REVIEW=1 pnpm --filter @zcode/desktop test:e2e -- --spec './test/e2e/conversation-session/manual-review/pending/<case>.test.ts'

Manual/capture artifacts are review evidence, not the final test contract.

When a feedback reproduction run needs a video artifact, record the Electron window from inside the app instead of using OS screen recording. Import startElectronWindowRecording and ELECTRON_WINDOW_RECORDING_CAPTURE_MODE from ../../../helpers/electron-window-recorder.js in conversation manual-review/pending/ specs, start recording before the user-visible path, stop it in finally, and write video_capture_mode: ELECTRON_WINDOW_RECORDING_CAPTURE_MODE to the feedback manifest. Do not use macOS Screen Recording, screencapture, QuickTime, or screenshot-only videos as the normal evidence path.

Promotion

After the user confirms human review, run the promotion dry run first:

bash
pnpm --filter @zcode/desktop e2e:promote -- --spec ./test/e2e/conversation-session/manual-review/pending/<case>.test.ts --reviewed

Then apply:

bash
pnpm --filter @zcode/desktop e2e:promote -- --spec ./test/e2e/conversation-session/manual-review/pending/<case>.test.ts --reviewed --apply

The tool moves the spec, fixes common helper imports, creates fixture/manifest scaffolds, and updates the coverage matrix path. It does not decide request semantics.

On --apply, promotion treats those writes as one filesystem transaction and runs pnpm audit:conversation-session-coverage against the tentative formal state. It keeps the promotion only when the audit passes; audit failure or execution error restores the pending spec, fixtures, manifest, and coverage matrix, then exits nonzero. Therefore complete and validate the canonical fixture contract while the spec is still pending instead of relying on post-promotion scaffolds.

Show full SKILL.md (366 more words)Show less

Fixture Contract

Use case-local data by default:

  • packages/desktop/test/e2e/fixtures/upstream/common.json for truly shared helper responses.
  • packages/desktop/test/e2e/fixtures/upstream/<domain>/<case>.json for case-specific provider responses.
  • packages/desktop/test/e2e/fixtures/cases/<domain>/<case>.json for manifest metadata.
  • packages/desktop/test/e2e/fixtures/fs/<domain>/<case>/ for file-system fixtures.

Classify each request as main, common, ignore, or synthetic. Developers review uncertain classifications; tools handle mechanical checks. Do not add new case-specific responses to provider-basic.json.

For timing:

  • fast-text: ordinary functional assertions.
  • controlled-stream: stop, queue, interrupted, or running-window assertions.
  • recorded-stream: performance or stream cadence assertions.
  • fault-stream: socket, truncation, rate-limit, or error injection.

Every synthetic request needs a syntheticReason in fixture metadata and manifest requests.

Verification

After filling fixtures:

For a pending case, validate the current spec against its canonical formal-target fixture metadata before promotion:

bash
pnpm --filter @zcode/desktop e2e:fixture:check -- --spec ./test/e2e/conversation-session/manual-review/pending/<case>.test.ts

The spec field in both the case manifest and case-local provider fixture remains ./test/e2e/conversation-session/<case>.test.ts while the current spec is pending. It is the canonical formal target, not the current physical path. Pending replay remains explicit: pass E2E_PROVIDER_REPLAY_FIXTURE_PATH so a normal manual-review run still captures the live provider path.

After promotion:

bash
pnpm --filter @zcode/desktop e2e:fixture:check -- --spec ./test/e2e/conversation-session/<case>.test.ts

Prove the case does not depend on legacy shared fixtures:

bash
E2E_PROVIDER_REPLAY_FIXTURE_PATH=packages/desktop/test/e2e/fixtures/upstream/common.json,packages/desktop/test/e2e/fixtures/upstream/conversation-session/<case>.json \
  pnpm --filter @zcode/desktop exec wdio run wdio.conf.ts --spec './test/e2e/conversation-session/<case>.test.ts'

Then run default replay:

bash
pnpm --filter @zcode/desktop exec wdio run wdio.conf.ts --spec './test/e2e/conversation-session/<case>.test.ts'

Before adding the case to the Docker suite, prove the formal case in isolated replay:

bash
E2E_SPEC=./test/e2e/conversation-session/<case>.test.ts pnpm run test:e2e:container

After that passes, admit it to the Docker conversation preset:

bash
pnpm --filter @zcode/desktop e2e:docker:admit -- --spec ./test/e2e/conversation-session/<case>.test.ts --verified --artifact packages/desktop/.e2e-artifacts/<run-id> --apply
pnpm run test:e2e:container:conversation

Docker runs are suite-oriented after admission. Use one isolated single-spec Docker run only as the admission proof or for failure localization. Once a case is admitted, batch stable compatible specs through the matching preset such as pnpm run test:e2e:container:conversation; this reuses the image, container startup, WDIO entrypoint, desktop app build, and agent server build. Split a case into a separate preset or container only when it needs real capture, fault injection, performance/timing-sensitive replay, global-state pollution, or special network/file-system setup.

For E2E code changes, run the following required code checks once for the final change. Documentation-only edits use the documentation checks in AGENTS.md:

bash
pnpm --filter @zcode/desktop typecheck:e2e
pnpm typecheck
pnpm lint

After the applicable lifecycle checks and code checks pass, finish; repeat or expand only after new edits, failures, or unresolved risks. Keep human review and promotion/admission requirements above intact. If a required environment or check is blocked, finish the executable parts and report the remaining evidence; use the root AGENTS.md completion rules and do not automatically commit incomplete verification. Report existing warnings separately from new failures.

© zai-org, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in .agents/skills/e2e-case-lifecycle of zai-org/ZCode.

  • SKILL.md
  • agents/openai.yaml

Open the folder on GitHubat commit aac4755

Compare with similar skills

E2E Case Lifecycle next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

E2E Case Lifecycle compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
E2E Case Lifecycle this skillzai-org/ZCode7.7k—~2.1kAutomated safety check: PassApache-2.0
Web Application Testinganthropics/skills180k51 repos~966Automated safety check: PassApache-2.0
TDD WorkflowhellangleZ/burn-in-cceverywhere-ralph11211 repos~2.4kAutomated safety check: PassNone
Uloop Replay Inputkurotu/VRCQuestTools3733 repos~615Automated safety check: PassMIT
Ui4 Convert Testspayloadcms/payload45k—~3.5kAutomated safety check: PassMIT
E2Estackia/rtp2httpd2.2k—~517Automated safety check: PassGPL-2.0

Similar skills

  • Web Application Testing

    anthropics/skills

    Official

    Tests local web applications with Python Playwright scripts, checking frontend behavior, capturing screenshots and reading browser console logs.

    180k GitHub starsUsed in 51 repos~966 tokens
    Testing & QAAuto-check passed
  • TDD Workflow

    hellangleZ/burn-in-cceverywhere-ralph

    A skill your agent uses when writing new features, fixing bugs, or refactoring code.

    112 GitHub starsUsed in 11 repos~2.4k tokens
    Testing & QAAuto-check passed
  • Uloop Replay Input

    kurotu/VRCQuestTools

    Replay recorded PlayMode keyboard and mouse input. An agent skill from kurotu/VRCQuestTools.

    373 GitHub starsUsed in 3 repos~615 tokens
    Testing & QAAuto-check passed
  • Ui4 Convert Tests

    payloadcms/payload

    A skill your agent uses when UI changes are complete and e2e tests need updating.

    45k GitHub stars~3.5k tokensUpdated yesterday
    Testing & QAAuto-check passed
  • E2E

    stackia/rtp2httpd

    Write, run, review, or debug rtp2httpd E2E tests and their harness in e2e/ and scripts/run-e2e.sh.

    2.2k GitHub stars~517 tokensUpdated 9 days ago
    Testing & QAAuto-check passed
  • Moav E2E

    MotherofallVPNs/MoaV

    Run and debug MoaV's end-to-end tests — real protocol connectivity (client-test.sh) and the moav CLI smoke test — against a LIVE server, via the self-hosted e2e workflow or a local test VPS.

    449 GitHub stars~1.9k tokensUpdated 4 days ago
    Testing & QAAuto-check: notes

More from zai-org/ZCode

All 25 skills in this repo
  • DOCX

    zai-org/ZCode

    Complete DOCX document creation, editing, and analysis capabilities with support for revisions, comments, formatting preservation, and text extraction.

    7.7k GitHub stars~4.9k tokensUpdated yesterday
    Auto-check: notes
  • Visualize

    zai-org/ZCode

    Create visualizations and interactive tools directly in conversation.

    7.7k GitHub stars~8.7k tokensUpdated yesterday
    Auto-check passed
  • PDF

    zai-org/ZCode

    Professional PDF toolkit covering four production workflows: reports, creative visuals, academic LaTeX, and existing PDF processing.

    7.7k GitHub stars~18k tokensUpdated yesterday
    Auto-check: notes
  • A skill your agent uses when ZCode needs to inspect, plan, or execute restoration of old ACP-era ZCode sessions from ~/.zcode/v2/sessions into the new ZCode task/session stores.

    7.7k GitHub stars~1.2k tokensUpdated yesterday
    Auto-check passed
  • Generate, verify, or remove large synthetic ZCode task fixtures in local ~/.zcode persistence for UI/session performance testing.

    7.7k GitHub stars~698 tokensUpdated yesterday
    Auto-check passed
  • Check ZCode module and layer boundaries for code changes. An agent skill from zai-org/ZCode.

    7.7k GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed

Categories

Questions about E2E Case Lifecycle

What does E2E Case Lifecycle do?

Plan, maintain, replay, and promote ZCode desktop E2E cases and their fixtures, coverage matrices, and CI admission evidence. E2E Case Lifecycle is an agent skill from zai-org/ZCode. Plan, maintain, replay, and promote ZCode desktop E2E cases and their fixtures, coverage matrices, and CI admission evidence.

When should I use E2E Case Lifecycle?

E2E Case Lifecycle fits situations like: tasks that involve End-to-end testing.

How do I install E2E Case Lifecycle in Claude Code?

Run `npx skills add zai-org/ZCode --skill e2e-case-lifecycle -a claude-code`. Or copy the skill folder (.agents/skills/e2e-case-lifecycle in zai-org/ZCode) into .claude/skills/e2e-case-lifecycle in your project. Claude Code loads it when a task matches its description.

How do I install E2E Case Lifecycle in Codex?

Run `npx skills add zai-org/ZCode --skill e2e-case-lifecycle -a codex`. Or copy the skill folder (.agents/skills/e2e-case-lifecycle in zai-org/ZCode) into .agents/skills/e2e-case-lifecycle in your project. Codex loads it when a task matches its description.

Can I use E2E Case Lifecycle in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add zai-org/ZCode --skill e2e-case-lifecycle -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/e2e-case-lifecycle, .gemini/skills/e2e-case-lifecycle, .github/skills/e2e-case-lifecycle and .opencode/skills/e2e-case-lifecycle in your project.

What does E2E Case Lifecycle need to run?

Going by SKILL.md and its folder, E2E Case Lifecycle needs the command-line tools its instructions call (pnpm). Our summary lists: Docker.

Does E2E Case Lifecycle access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is E2E Case Lifecycle safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does E2E Case Lifecycle use?

E2E Case Lifecycle is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does E2E Case Lifecycle use?

About 2.1k tokens (SKILL.md is roughly 8.4k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to E2E Case Lifecycle?

Skills that share tags, products or a category with E2E Case Lifecycle: Web Application Testing (anthropics/skills, 180k stars), TDD Workflow (hellangleZ/burn-in-cceverywhere-ralph, 112 stars), Uloop Replay Input (kurotu/VRCQuestTools, 373 stars) and Ui4 Convert Tests (payloadcms/payload, 45k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains E2E Case Lifecycle?

zai-org (a GitHub organization) maintains it in zai-org/ZCode, which has 7,659 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on October 10, 2026.

Source: zai-org/ZCode on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.