본문으로 건너뛰기
cccskills
무료GitHub에 공개한국어 소개

writing-acceptance-tests

GitHub CLI의 실제 리소스를 사용하는 인수 테스트를 추가하거나 수정할 때 저장소 픽스처, 리소스 정리, API 요청량, 비동기 대기 방식을 정하도록 돕습니다. 변경한 테스트를 먼저 좁은 범위로 검증합니다.

원문원문 설명 보기

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

cli/cli스타 46,748(GitHub 46,748 + cccskills 0)
연동 도구GitHub

실행 점수 미검증

설치 방법 보기

이럴 때 유용합니다

  • GitHub CLI 인수 테스트 추가하기
  • 테스트용 저장소 픽스처 방식 고르기
  • 워크플로 준비 상태를 확인하며 기다리기
  • API 요청량을 제한해 테스트하기

한국어 소개

할 수 있는 일

이 기술은 실제 GitHub 리소스를 대상으로 GitHub CLI(gh)를 실행하는 인수 테스트를 추가하거나 수정하도록 돕습니다. 각 테스트마다 사용자 권한이 필요한지 판단하고, 공유, 격리 또는 저장소 없음 중 픽스처 방식을 정합니다. 공유 저장소에서 다른 테스트와 충돌하지 않도록 이름과 상태를 관리하고, 생성한 리소스를 기록해 정리하는 방법과 API 요청량을 줄이는 방법도 다룹니다. 비동기적으로 등록되는 워크플로 같은 리소스는 고정 시간 동안 기다리는 대신 조건을 확인하며 기다립니다. 변경한 테스트는 먼저 대상 범위를 좁혀 검증합니다.

이럴 때 유용합니다

GitHub CLI 기능이나 인수 테스트 스크립트를 수정할 때 사용할 수 있습니다. 여러 테스트가 저장소나 API 제한을 공유하는 환경에서 충돌이나 불필요한 리소스 생성을 줄이며 동작을 확인하는 데 도움이 됩니다.

사용 예시

  • “이 기능의 인수 테스트에 적합한 픽스처 방식을 골라 주세요.”
  • “워크플로 테스트가 조건을 확인하며 기다리도록 바꿔 주세요.”
  • “수정한 테스트 스크립트의 메타데이터를 검증해 주세요.”

주의 사항

실시간 테스트는 GitHub의 리소스를 조작합니다. 실행하려면 인수 테스트용 인증 정보가 필요합니다. 검증 방법과 인증 변수는 acceptance/README.md에서 확인합니다.

이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.

문서 점검

AI가 SKILL.md의 내용에서 주의가 필요한 작업과 도입 전제를 확인했습니다. 점수는 실제로 실행한 결과(실행 검증)만으로 매깁니다.

안전성전송·삭제·명령 실행 등을 명시하고 있는가
B일부 부족실시간 테스트에서 저장소를 만들고 삭제하며 지연 정리를 지정합니다.
도입의 용이성필요한 도구나 API 키가 적고 적혀 있는가
B일부 부족Go 테스트와 GitHub 인증 정보가 필요하며 변수는 README에 안내되어 있습니다.

점수에는 넣지 않았습니다. 2026년 10월 26일 기준으로 AI(OpenAI Codex)가 판정했습니다. 참고용이므로 설치 전에 원문도 확인해 주세요.

평가가 다르다고 생각되면 재검토를 요청하기

어느 항목이 왜 다르다고 생각하는지 적어 주세요. 로그인은 필요 없습니다. SKILL.md와 대조해 평가를 다시 만들고 이곳에 반영합니다.

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

포함된 파일(1)

  • SKILL.md7.0 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

agentic-workflows

무료요약 있음

GitHub Agentic Workflows 요청이 설계, 생성, 설정, 수정, 디버깅, 업그레이드 중 무엇인지 구분해 알맞은 프롬프트나 스킬 파일로 안내합니다.

  • 새 워크플로 설계 또는 생성
  • 기존 워크플로 수정
  • 워크플로 오류 조사
cli/cli4.7만2026년 10월 25일 업데이트

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/cli4.7만2026년 10월 25일 업데이트

cli-exercise-evidence

무료요약 있음

명령줄 연습의 기대 결과를 기록된 증거와 대조하고, 요청된 미디어를 렌더링해 점검한 뒤 사례별 결과와 로컬 산출물 경로를 제공합니다. 기본적으로 증거를 공개하지 않습니다.

  • 명령줄 연습의 기대 결과를 검증할 때
  • 기록에서 동영상 증거를 만들 때
  • 동영상이나 화면 내용을 점검할 때
cli/cli4.7만2026년 10월 25일 업데이트

cli-exercise-exact

무료요약 있음

지정된 CLI 테스트의 명령, 입력, 순서, 기대 조건을 바꾸지 않고 실행하도록 안내합니다. 사례별 준비·실행·검증 후 실제 증거에 따라 통과, 실패, 차단 또는 관찰로 분류합니다.

  • 지정된 그대로 CLI 테스트 실행
  • 입력과 사례 순서 보존
  • 기대 결과를 실제 출력과 대조
cli/cli4.7만2026년 10월 25일 업데이트

cli-exercise-explore

무료요약 있음

승인된 범위 안에서 목표에 맞는 CLI 확인 항목을 정하고, 각 항목의 준비·실행·즉시 검증을 차례로 진행합니다. 증거로 확인된 결과와 도달하지 못한 동작을 구분해 정리합니다.

  • 목표에 맞춰 CLI 작업 확인
  • 업로드 완료 조건 정리
  • 작업마다 준비와 검증 수행
cli/cli4.7만2026년 10월 25일 업데이트

cli-exercise-preflight

무료요약 있음

`cli-exercise` 내부 모듈로 빌드, 터미널, 미디어 도구의 사용 가능 여부를 확인합니다. 의존 항목이 없으면 설치 경로를 제안하고 승인을 받은 뒤 설치하며, 완료 후 준비 상태를 다시 확인합니다. 녹화나 다른 작업 권한을 부여하지는 않습니다.

  • 녹화 전 필요한 도구 확인
  • 동영상 또는 GIF 출력 지원 확인
  • 누락된 의존 항목의 설치 절차 확인
cli/cli4.7만2026년 10월 25일 업데이트

cli의 스킬 모두 보기

이 스킬의 문제 신고