Skip to content
cccskills
FreePublished on GitHubEnglish overview

writing-acceptance-tests

Use this skill to add or revise GitHub CLI acceptance tests, which exercise `gh` against live GitHub resources. It guides fixture selection, safe cleanup, API request budgeting, asynchronous waits, and focused validation.

OriginalShow the original description

Use when adding or changing GitHub CLI acceptance tests, txtar scripts, testdata groups, repository fixtures, or acceptance harness behavior.

cli/cli46,752 stars(GitHub 46,752 + cccskills 0)
Works withGitHub

Run score Not tested

See how to install

Good for

  • Adding a GitHub CLI acceptance test
  • Choosing shared or isolated repository fixtures
  • Testing workflow runs with bounded waits
  • Keeping live API requests within limits
  • Validating changed acceptance scripts

Overview

What it does

This skill helps add or change acceptance tests that run GitHub CLI (gh) against live GitHub resources. For each test, decide whether it needs user-level credentials and choose a shared, isolated, or no-repository fixture. It covers naming and state management to prevent interference in shared repositories, recording created resources and cleaning them up, and limiting API requests. For workflows or other resources registered asynchronously, wait for a condition instead of sleeping for a fixed duration. Validate changed tests with a focused run first.

When it helps

Use it when changing GitHub CLI features or acceptance-test scripts. It is intended for development in environments where tests may share repositories and API limits. The guidance helps check behavior while reducing test conflicts and unnecessary resource creation.

Example requests

  • “Choose a fixture mode for an acceptance test of this feature.”
  • “Change this workflow test to wait until its condition is met.”
  • “Validate the metadata in the test script I changed.”

Notes

Live tests operate on GitHub resources and require acceptance-test credentials. Check acceptance/README.md for the verification method and credential variables.

This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.

Document check

AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).

SafetyAre sending data, deleting files, and running commands disclosed?
BPartly lackingLive tests create and delete repositories; deferred cleanup is specified.
Easy setupDoes it need few tools or API keys, and are they documented?
BPartly lackingGo tests and GitHub credentials with variables from the README are required.

Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 26, 2026. Treat it as a guide and read the original before installing.

Disagree? Request a re-evaluation

Tell us which point is wrong and why. No login needed. We will check it against the SKILL.md, redo the evaluation, and show the result here.

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

Files included (1)

  • SKILL.md7.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Writing Acceptance Tests

Acceptance tests exercise gh against live GitHub resources. Minimize repository creation and cloning without allowing concurrent scripts to interfere.

Read acceptance/README.md and nearby scripts before editing.

Declare token capability

Every .txtar script must start with exactly one capability declaration:

# requires-user-capability: false

Set the declaration to true only when the script requires a user principal, such as account SSH/GPG keys, personal-account forks, or user membership APIs. Repository and organization operations supported by an installation token should use false.

Choose one repository mode

Every script must contain exactly one declaration:

ModeUse when
fixture-repo shared REPOOne initialized private repository is enough and every operation can coexist with concurrent and accumulated state.
fixture-repo isolated REPOOne initialized private repository is enough, but the test needs clean state, changes repository-global state, or performs multiple coordinated Git ref updates.
fixture-repo noneNo repository is needed, or the test needs multiple repositories, public visibility, special creation options, or repository lifecycle coverage.

Managed fixtures are initialized, have discussions enabled, and are deleted by the harness. Scripts using shared or isolated must not run gh repo create.

With none, create every required repository explicitly and immediately register deferred cleanup. Use defer gh repo delete --yes $ORG/$REPO when the repository should still exist under that name. Use defer cleanup-repo $REPO when testing deletion or renaming; it is scoped to $ORG and treats an already absent repository as success.

Repositories created with an initial commit can remain busy after gh repo create returns. Before renaming one, use wait-for-repository-ready $ORG/$REPO to wait for its default-branch commit. GitHub can retain the repository creation lock after that commit becomes readable, so keep the gh repo rename command inline and allow a 10-second stabilization delay between this readiness check and that command.

Shared fixture contract

Scripts within a group run concurrently. A shared script must remain correct when the repository already contains unrelated resources.

  • Never rename, transfer, archive, delete, or globally reconfigure the repository. Do not toggle features, change its description, or mutate its default branch.
  • Give resources unique, reasonably short names using $RANDOM_STRING, adding $SCRIPT_NAME only when useful. Width-constrained commands such as gh pr status truncate long titles.
  • Make commits unique across concurrent scripts. Unique branch names do not affect commit IDs, so include the script's $RANDOM_STRING in the commit contents or message when scripts could otherwise create the same tree from the same parent.
  • Consolidate related repository-scoped operations, such as merging pull requests, into one isolated script. Unique refs do not prevent concurrent Git pushes and merges in a shared repository from contending.
  • GitHub normalizes some identifiers. Use env2upper for Actions variables and secrets whose generated names are asserted later.
  • Capture the created resource's URL or ID. Filter and paginate list operations; never select the first, latest, or only result.
  • Target the fixture with --repo $ORG/$REPO or GH_REPO=$ORG/$REPO. Clone only when local Git behavior is part of the test.

If any operation violates this contract, use isolated; do not weaken assertions to make sharing appear safe.

API request budgets

Scripts share token-wide API rate limits. Count requests across the whole test process and combine compatible live assertions. Keep coverage for a narrowly limited endpoint in one script so concurrent scripts cannot burst the limit. For Code Search's 10 requests/minute bucket, use at most five HTTP requests in the entire acceptance process, even when they run sequentially. This reserves half the bucket for pagination, retries, and other token activity. Count the requests made by each command, keep representative live coverage, and move remaining variants to unit tests.

Use bounded condition-based waits for asynchronously registered resources. Fixed sleeps are both slower when registration is fast and unreliable when it is slow. Use wait-for-workflow after pushing a new workflow definition, then use wait-for-run before watching or inspecting a triggered workflow run. After gh workflow run, wait-for-run captures the returned run URL when the server provides one and falls back to polling for older servers. On timeout, wait-for-run captures the pushed commit and remote ref, workflow files, recent unfiltered runs, commit check suites, and an Actions API request ID. Use that evidence to distinguish event ingestion, run indexing, filtering, and push/setup failures before changing fixture isolation or timeout budgets. Cancellation tests must use a self-contained workflow with a deliberately long step so the run cannot finish before the cancellation request, plus a short job timeout so a failed cancellation cannot run for the full step. After registration, use wait-for-run-status RUN_ID in_progress before cancellation because the cancellation endpoint can reject a run that is still starting. Do not wait for GitHub to finish cancellation after the command confirms that the request was submitted; that tests Actions' eventual behavior rather than the CLI contract. Do not lengthen registration sleeps to compensate for a short or externally dependent job.

Organization safety

Every live mutation must resolve through $ORG/$REPO, a resource ID or URL captured from something created under $ORG, or fixture cleanup scoped to GH_ACCEPTANCE_ORG. Do not rely on ambient Git remotes or repository context.

Example

env2upper VAR_NAME=TESTSCRIPTS_${RANDOM_STRING}
fixture-repo shared REPO
env GH_REPO=$ORG/$REPO

exec gh variable set $VAR_NAME --body value
exec gh variable get $VAR_NAME
stdout '^value$'

Validate

Run metadata checks without live credentials:

go test -tags=acceptance \
  -run '^(TestSelectAcceptanceTestGroups|TestFilterAcceptanceScripts|TestTokenHasUserCapability|TestAcceptanceScriptsDeclareUserCapabilityRequirement|TestAcceptanceScriptsDeclareFixtureRepository|TestRequiresUserCapabilityForScript|TestValidateFixtureRepositoryDeclaration|TestFixtureRepositoryManager)$' \
  ./acceptance

Run a changed live script with GH_ACCEPTANCE_GROUP and GH_ACCEPTANCE_SCRIPT; see acceptance/README.md for the credential variables. Use -count=1 to bypass the Go test cache. Start with one script. If concurrency is required to reproduce the behavior, pass only the contending scripts as a comma-separated filter and repeat that focused set before widening the run.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

This dispatcher helps with GitHub Agentic Workflows by identifying whether a request is about design, creation, configuration, updates, debugging, or upgrades. It selects the matching workflow prompt or skill file so the agent can follow task-specific guidance.

  • Design a GitHub Agentic Workflow from scratch
  • Create or configure a workflow engine
  • Update or debug an existing workflow
cli/cli46.8KUpdated Oct 25, 2026

cli-exercise

FreeSummary

Exercise a real command-line program with specified cases or a stated goal, then capture and verify the observed behavior. It produces local media evidence such as a session video, helping reviewers see what the command did without treating the recording as proof of general correctness.

  • Record specified CLI test cases
  • Demonstrate a command’s behavior
  • Validate an interactive terminal workflow
cli/cli46.8KUpdated Oct 25, 2026

Verify CLI exercise expectations against recorded evidence, render requested media, inspect the results, and return local artifacts with case outcomes. The workflow keeps failures visible and does not publish evidence by default.

  • Verifying a recorded CLI exercise
  • Rendering and inspecting session evidence
  • Returning local artifacts without publishing
cli/cli46.8KUpdated Oct 25, 2026

Use this skill to execute supplied CLI test cases without changing their commands, inputs, ordering, or assertions. It guides preparation, exercise, and validation case by case, then classifies results as passed, failed, blocked, or observed based on actual evidence.

  • Run caller-supplied CLI cases in their specified order
  • Preserve literal inputs and expected assertions
  • Validate each case against observed output or state
cli/cli46.8KUpdated Oct 25, 2026

Use this skill to explore a CLI goal by choosing observable checks within an approved scope. It guides the agent through preparation, one exercise, and immediate validation for each case, then helps report what the evidence established and what remained unreachable.

  • Explore a CLI task with a clear goal and approved boundaries
  • Choose checks for an outcome such as uploading a file
  • Run and validate CLI cases one at a time
cli/cli46.8KUpdated Oct 25, 2026

This internal module checks whether cli-exercise can use its required build, terminal, and media tools. When a dependency is missing, it identifies a suitable setup path and requires approval before installation, then rechecks readiness. It does not authorize recordings or other actions.

  • Check cli-exercise tool readiness
  • Find missing recording or rendering dependencies
  • Prepare an approved dependency installation
cli/cli46.8KUpdated Oct 25, 2026

See all skills by cli

Report a problem with this skill