agentleFS
openclawopenclaw/openclaw-enterprise/.agents/skills/enterprise-testing/SKILL.md

enterprise-testing

Skill454 starsChanged 8 days agoMITView on GitHub

Select proportional Enterprise validation and diagnose exact CI runs, distinguishing product, harness, infrastructure, and credential failures.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read the touched scope's AGENTS.md and the selected testing guide.

    line 13
  2. Very specific:

    Run pnpm check:workspace and applicable pnpm format:check with the installed graph.

    line 33
  3. Very specific:

    Use the local checks guide for formatting and generated-artifact procedures.

    line 36
  4. Distinctive:

    Use only owned disposable resources and authorized credentials.

    line 44
  5. Distinctive:

    Follow repository integration requirements and each suite's guide for images, model selection, database roles, credential placement, …

    line 50
  6. Distinctive:

    Do not infer a category solely from a check name.

    line 82

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Enterprise Testing

Prove the changed contract with the smallest meaningful check, complete required checks, then stop. Broaden or repeat for new changes, failures, or unresolved risks. Use test-audit when authoring or reviewing tests; do not create tests that merely mirror a reversible documentation or style edit.

Read the touched scope's AGENTS.md and the selected testing guide. Run commands from the repository root. Use Node.js 24 or newer and repository-pinned pnpm with matching installed dependencies. Report missing prerequisites; dependency-independent checks prove only their own scope. Never run npm run precommit.

Select proof

Changed contractStarting proof and owner
Domain or Driver behaviornode --test tests/conformance/<name>.test.mjs; broaden to pnpm test:conformance when relevant.
API or controller behaviornode --test tests/integration/<name>.test.mjs; broaden to pnpm test:integration. See local checks.
PostgreSQL persistencepnpm test:postgres after the database prerequisites; use the actual database for persisted invariants.
Docker runtimepnpm docker:test with explicit selectors, images, and credentials from Docker testing.
KubernetesSelect the exact fixture or runtime file from Kubernetes testing, with its disposable cluster and database prerequisites.
Console UIpnpm test:console-browser with the prepared browser described in browser testing.
Types, package boundaries, generated APIpnpm typecheck (builds packages and checks test types); pnpm openapi:check for API changes.
Documentation or skillspnpm docs:check, relevant links, and git diff --check; no runtime tests solely for prose changes.
CI or test selectionnode scripts/ci/run-tests.mjs audit; inspect CI ownership, and use actionlint for workflow edits when available.

Run pnpm check:workspace and applicable pnpm format:check with the installed graph. The root formatter does not include .agents/skills/**/*.md; inspect adapted skill Markdown separately. Keep autoreview implementation and test changes in openclaw/agent-skills. Use the local checks guide for formatting and generated-artifact procedures. Resolve <name> to existing owner/sibling tests; do not run placeholder commands. When all conformance and integration contracts need proof, pnpm test selects both; browser and credentialed coverage still depend on their documented selection and prerequisites.

Real-runtime boundaries

Use only owned disposable resources and authorized credentials. Scope selection variables to the chosen process; preserve shared dependencies, services, databases, kubeconfig, and unrelated clusters. Do not run untrusted contributor tooling against a credentialed local environment; use an approved isolated CI environment. Setup and credentialed execution need their existing authorization.

Follow repository integration requirements and each suite's guide for images, model selection, database roles, credential placement, networking, and cleanup. Do not bypass missing credentials, disable isolation, or substitute a fake for requested runtime proof. Selected required cluster/runtime cases must pass without skips. Fixture or in-memory success does not prove genuine gateway, Codex WebSocket, model execution, or production deployment. A green PR aggregate does not prove manual credentialed lanes ran.

Diagnose CI

gh pr view <pr> --json headRefOid,statusCheckRollup
gh run view <run-id> --json status,conclusion,headSha,url,jobs
gh run view <run-id> --job <job-id> --log

Bind evidence to the PR head, actual run SHA, run ID, and job ID. A pull-request run may test a merge commit: record that relation rather than assuming its SHA equals the branch head. Inspect the latest attempt for that source; confirm whether a newer run superseded a cancellation. Fetch relevant leaf logs and result artifacts, not just the rollup status. Use CI result accounting and coverage to interpret selected lanes and skips.

  • Product: supported behavior fails with valid setup; reproduce narrowly, repair the owning implementation, and rerun that proof.
  • Harness: selection, setup, assertions, or result accounting are wrong; repair the harness without weakening required outcomes.
  • Infrastructure: provisioning, image availability, networking, or capacity fails; retain evidence and retry the affected job only when justified.
  • Credentials: approved credentials, access, or protected-environment approval is missing; report the gap without exposing values or substituting mock proof.

Do not infer a category solely from a check name. State uncertainty when logs are unavailable. Route unrelated failures with evidence instead of expanding the task; never rerun a broad workflow merely to erase a failure. Report commands, source/run/job identity, pass/fail/skip counts, proof limits, and remaining blockers.

Provenance

Adapted from OpenClaw; see source and intentional adaptations.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.