此技能识别 GitHub Agentic Workflows 相关请求的类型,并引导代理读取对应提示或技能文件,涵盖设计、创建、配置、更新、调试和升级。
- 设计或创建新工作流
- 更新现有工作流
- 调查工作流错误
编写或修改 GitHub CLI 验收测试时,帮助选择仓库夹具、安排资源清理、控制 API 请求量,并为异步工作流设置条件等待,再先集中验证改动的测试。
Use when adding or changing GitHub CLI acceptance tests, txtar scripts, testdata groups, repository fixtures, or acceptance harness behavior.
实测评分 未实测
查看安装方法此技能帮助编写或修改针对真实 GitHub 资源运行 GitHub CLI(gh)的验收测试。每项测试都要确定是否需要用户权限凭据,并选择共享、隔离或不使用仓库的夹具方式。内容还包括如何为共享仓库中的资源命名和管理状态,以避免测试互相干扰;如何记录创建的资源并在结束时清理;以及如何控制 API 请求量。对于异步注册的工作流等资源,应等待条件满足,而不是固定等待一段时间。修改测试后,先集中运行相关测试进行验证。
修改 GitHub CLI 功能或验收测试脚本时,可以参考此技能。它适用于多个测试共用仓库或 API 限额的开发环境,帮助在检查功能行为时减少测试冲突和不必要的资源创建。
实时测试会操作 GitHub 上的资源,并且需要验收测试凭据。验证方法和凭据变量请查阅 acceptance/README.md。
本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。
AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果(实测对比)。
不计入评分。 由 AI(OpenAI Codex)于 2026年10月26日 评估。仅供参考,安装前请同时查看原文。
安装前可以查看交给 AI 代理的指令内容。
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.
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.
Every script must contain exactly one declaration:
| Mode | Use when |
|---|---|
fixture-repo shared REPO | One initialized private repository is enough and every operation can coexist with concurrent and accumulated state. |
fixture-repo isolated REPO | One initialized private repository is enough, but the test needs clean state, changes repository-global state, or performs multiple coordinated Git ref updates. |
fixture-repo none | No 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.
Scripts within a group run concurrently. A shared script must remain correct when the repository already contains unrelated resources.
$RANDOM_STRING, adding
$SCRIPT_NAME only when useful. Width-constrained commands such as
gh pr status truncate long titles.$RANDOM_STRING in the commit
contents or message when scripts could otherwise create the same tree from the
same parent.isolated script. Unique refs do not prevent concurrent
Git pushes and merges in a shared repository from contending.env2upper for Actions variables and
secrets whose generated names are asserted later.--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.
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.
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.
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$'
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.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
此技能识别 GitHub Agentic Workflows 相关请求的类型,并引导代理读取对应提示或技能文件,涵盖设计、创建、配置、更新、调试和升级。
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.
中文简介正在准备中。当前显示英语简介。
将命令行练习的预期与记录证据逐项核对,按需渲染并检查媒体,返回各案例结果和本地成果文件路径;默认不发布证据。
此技能按原样执行指定的命令行测试,保留命令、输入、顺序和预期条件;逐项准备、操作并验证,再依据实际证据标记通过、失败、受阻或仅作观察。
此技能根据目标和已批准的范围选择可观察的命令行检查,逐项完成准备、操作和即时验证,并整理证据、尚未达到的行为及检查结果。
这是供 `cli-exercise` 内部使用的准备检查模块,用于核验构建、终端和媒体工具是否可用;缺少依赖时先征得安装同意,安装后重新检查。