Azure Pipelines Log Downloader
ansible/ansible
Downloads Azure Pipelines CI logs for an Ansible pull request or build so the agent can analyze test failures, after asking you first.
Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension.
$ npx skills add ansible/vscode-ansible --skill wdio-testing -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install ansible/vscode-ansible wdio-testing --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/ansible/vscode-ansible.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.cursor/skills/wdio-testing .claude/skills/wdio-testing && rm -rf skills-srcUse ~/.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/
Install the "wdio-testing" agent skill from https://github.com/ansible/vscode-ansible/tree/main/.cursor/skills/wdio-testing into .claude/skills/wdio-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wdio-testing", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/ansible/vscode-ansible/tree/main/.cursor/skills/wdio-testingType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add ansible/vscode-ansible --skill wdio-testing -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install ansible/vscode-ansible wdio-testing --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ansible/vscode-ansible.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.cursor/skills/wdio-testing .agents/skills/wdio-testing && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "wdio-testing" agent skill from https://github.com/ansible/vscode-ansible/tree/main/.cursor/skills/wdio-testing into .agents/skills/wdio-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wdio-testing", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add ansible/vscode-ansible --skill wdio-testing -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install ansible/vscode-ansible wdio-testing --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ansible/vscode-ansible.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.cursor/skills/wdio-testing .cursor/skills/wdio-testing && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "wdio-testing" agent skill from https://github.com/ansible/vscode-ansible/tree/main/.cursor/skills/wdio-testing into .cursor/skills/wdio-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wdio-testing", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/ansible/vscode-ansible.git --path .cursor/skills/wdio-testing--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add ansible/vscode-ansible --skill wdio-testing -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install ansible/vscode-ansible wdio-testing --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ansible/vscode-ansible.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.cursor/skills/wdio-testing .gemini/skills/wdio-testing && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "wdio-testing" agent skill from https://github.com/ansible/vscode-ansible/tree/main/.cursor/skills/wdio-testing into .gemini/skills/wdio-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wdio-testing", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install ansible/vscode-ansible wdio-testingInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add ansible/vscode-ansible --skill wdio-testing -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/ansible/vscode-ansible.git skills-src && mkdir -p .github/skills && cp -r skills-src/.cursor/skills/wdio-testing .github/skills/wdio-testing && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "wdio-testing" agent skill from https://github.com/ansible/vscode-ansible/tree/main/.cursor/skills/wdio-testing into .github/skills/wdio-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wdio-testing", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add ansible/vscode-ansible --skill wdio-testing -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install ansible/vscode-ansible wdio-testing --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ansible/vscode-ansible.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.cursor/skills/wdio-testing .opencode/skills/wdio-testing && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "wdio-testing" agent skill from https://github.com/ansible/vscode-ansible/tree/main/.cursor/skills/wdio-testing into .opencode/skills/wdio-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "wdio-testing", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
wdio-testingWrite, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension.
Wdio Testing is an agent skill from ansible/vscode-ansible. Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension. Use when creating new WDIO specs, fixing test failures, adding webview or Lightspeed tests, or troubleshooting headless/CI execution.
Its SKILL.md is about 2.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `patterns.md`).
It sits in DevOps & Cloud, covering Infrastructure as code and Failing and flaky tests. It works with Ansible and Visual Studio Code. The repository describes itself as: Ansible IDE extension: auto-completion and integrating quality assurance tools like ansible-lint, ansible syntax check, yamllint, molecule and ansible-test. The licence is MIT.
2 steps, taken from the first numbered list in SKILL.md.
Read from SKILL.md and the folder at commit 98024ea. It shows what the files ask for, not the result of running them.
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.
Shell commands in SKILL.md call:
npxFrom the folder's file list and the shell code blocks in SKILL.md.
Links to these hosts (documentation or services it may open):
webdriver.ioFrom URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Wdio Testing loads about 2.2k tokens when it runs. Until then it costs about 58 tokens; SKILL.md has 649 words of instructions outside code blocks.
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.
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.
The full file from ansible/vscode-ansible at commit 98024ea, republished under its MIT licence (© ansible). 649 words, ~2,218 tokens.
.claude/skills/wdio-testing/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.Each spec file (test/wdio/*.spec.ts) gets its own VS Code Electron instance.
The runner is configured in wdio.conf.ts, which uses wdio-vscode-service to
download, launch, and drive VS Code via ChromeDriver.
Key paths:
| Path | Purpose |
|---|---|
wdio.conf.ts | Runner config: capabilities, extensions dir, user settings |
test/wdio/*.spec.ts | Test specs (Mocha BDD) |
test/wdio/tsconfig.json | TypeScript config for WDIO tests (CommonJS target) |
test/wdio/fixtures/ | Ansible fixture files opened during tests |
test/wdio/mock-server.ts | Express mock for Lightspeed API |
scripts/install-test-extensions.mjs | Installs dependency extensions into .wdio-vscode/extensions/ |
.wdio-vscode/ | VS Code binary cache + installed extensions (gitignored) |
task wdio # full suite via Taskfile
npx pnpm test:wdio # full suite via npm script
TS_NODE_PROJECT=test/wdio/tsconfig.json npx wdio run wdio.conf.ts --spec test/wdio/smoke.spec.ts # single specThe TS_NODE_PROJECT env var is required when invoking wdio directly; the
Taskfile and npm script set it automatically.
The Ansible extension activates on onLanguage:ansible. In a fresh VS Code
session, the extension is not active until an Ansible file is opened.
Every spec that uses extension commands MUST:
isActive before proceeding// In the before() hook:
await browser.executeWorkbench(async (vscode, fixture: string) => {
const folder = vscode.workspace.workspaceFolders?.[0];
if (!folder) throw new Error("workspace missing");
const uri = vscode.Uri.joinPath(folder.uri, fixture);
const doc = await vscode.workspace.openTextDocument(uri);
await vscode.window.showTextDocument(doc, { preview: false });
}, "playbook.ansible.yml");
await browser.waitUntil(
async () => {
const active = await browser.executeWorkbench(async (vscode) => {
const ext = vscode.extensions.getExtension("redhat.ansible");
return ext?.isActive === true;
});
return active === true;
},
{ timeout: 60_000, interval: 2000 },
);See smoke.spec.ts for the canonical waitForExtensionActive() helper.
executeWorkbench Closure Rulesbrowser.executeWorkbench(callback, ...args) serializes the callback and runs
it inside the VS Code extension host process. Outer-scope variables are NOT
available inside the callback. This is the single most common source of
confusing "X is not defined" errors.
// BAD -- MOCK_URL is a module-level const; will throw "MOCK_URL is not defined"
const MOCK_URL = "http://localhost:3001";
await browser.executeWorkbench(async (vscode) => {
const config = vscode.workspace.getConfiguration("ansible");
await config.update("lightspeed.apiEndpoint", MOCK_URL, vscode.ConfigurationTarget.Global);
});
// GOOD -- pass as an argument after the callback
const url = MOCK_URL;
await browser.executeWorkbench(
async (vscode, endpoint: string) => {
const config = vscode.workspace.getConfiguration("ansible");
await config.update("lightspeed.apiEndpoint", endpoint, vscode.ConfigurationTarget.Global);
},
url,
);Rules:
vscode (the VS Code API).countTabs(vscode)) are
also NOT available inside the callback. Inline the logic or wrap the entire
executeWorkbench call in a helper that returns a serializable result.require() is not available in the workbench context. Use the vscode
API or run Node utilities from the test runner process directly.Webviews render inside nested iframes. After webview.open(), selectors like
$("h1") target the webview's DOM. Always call webview.close() when done
(use try/finally).
Vue-based webviews render asynchronously. Elements may exist in the DOM but have
empty text until the Vue app hydrates. Use waitUntil to poll for rendered
content:
async function waitForWebviewText(
titlePattern: RegExp,
textCheck: (text: string) => boolean,
timeout = 30_000,
): Promise<string> {
const workbench = await browser.getWorkbench();
let lastText = "";
await browser.waitUntil(
async () => {
try {
const webview = await workbench.getWebviewByTitle(titlePattern);
await webview.open();
const body = await $("body");
if (await body.isExisting()) lastText = await body.getText();
await webview.close();
return textCheck(lastText);
} catch { return false; }
},
{ timeout, interval: 2000 },
);
return lastText;
}Open webview commands via executeWorkbench (not workbench.executeCommand)
to avoid command palette timing issues:
await browser.executeWorkbench(
async (vscode, cmd: string) => {
await vscode.commands.executeCommand(cmd);
},
"ansible.content-creator.menu",
);test/wdio/mock-server.ts is a standalone Express server with canned responses
for Lightspeed API endpoints.
Usage in a spec:
import * as mockServer from "./mock-server";
before(async () => {
await mockServer.start(3001);
// point the extension at the mock
await browser.executeWorkbench(
async (vscode, endpoint: string) => { /* update setting */ },
"http://localhost:3001",
);
await injectMockSession();
});
after(async () => {
// restore original setting, then stop
await mockServer.stop();
});mockServer.setResponse(endpoint, status, body, delay?) -- override a
specific endpoint per test.mockServer.resetResponses() -- revert to defaults (call in afterEach).injectMockSession() -- calls the ansible.lightspeed.mockSession command
to fake an authenticated user. Uses waitUntil because the command is only
available after the extension finishes activating.If the extension under test gains new extensionDependencies, add them to the
DEPENDENCY_EXTENSIONS array in scripts/install-test-extensions.mjs:
const DEPENDENCY_EXTENSIONS = [
"ms-python.python",
"ms-python.vscode-python-envs",
"redhat.vscode-yaml",
// add new entries here
];Run npx pnpm pretest:wdio to install them into .wdio-vscode/extensions/.
The Taskfile wraps the test command with xvfb-run on Linux:
cmds:
- "{{.XVFB}}npx pnpm test:wdio"XVFB is set to xvfb-run --auto-servernum when Xvfb is available.
--disable-gpuAlways set in wdio.conf.ts under vscodeArgs. Prevents GPU-related crashes
in headless environments. Safe on all platforms.
--no-sandboxThis flag causes SIGSEGV crashes on many Linux systems (Fedora, newer kernels). Electron's sandbox is required for stable operation under Xvfb.
On Wayland desktops, the VS Code window will be visible during local test runs.
This is expected; xvfb-run on CI handles headless. Do NOT set
WAYLAND_DISPLAY="" as it can trigger Xvfb/Electron crashes.
| Pitfall | Cause | Fix |
|---|---|---|
"X is not defined" inside executeWorkbench | Closure variable captured | Pass as argument (see above) |
| Extension commands not found | Extension not activated | Open fixture + waitUntil(isActive) |
getCommands() misses some commands | registerTextEditorCommand isn't listed | Use getCommands() without true filter, or just execute the command and catch errors |
| Notification check throws | .monaco-list-row not displayed | Wrap getNotifications() in try/catch |
| Webview text is empty | Vue hasn't rendered yet | Use waitUntil to poll for text content |
| SIGSEGV under Xvfb | --no-sandbox flag | Remove it; keep only --disable-gpu |
workbench.executeCommand timeout | Command palette focus race | Use executeWorkbench + vscode.commands.executeCommand instead |
© ansible, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 1 other file in .cursor/skills/wdio-testing of ansible/vscode-ansible.
Open the folder on GitHubat commit 98024ea
Wdio Testing 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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Wdio Testing this skillansible/vscode-ansible | 487 | — | ~2.2k | Automated safety check: Pass | MIT | |
| Azure Pipelines Log Downloaderansible/ansible | 71k | — | ~825 | Automated safety check: Pass | GPL-3.0 | |
| Spa Create Configsplunk/splunk-platform-automator | 137 | — | ~3.5k | Automated safety check: Pass | Proprietary | |
| Spa Add Test Scenariosplunk/splunk-platform-automator | 137 | — | ~2.2k | Automated safety check: Pass | Proprietary | |
| Frontend Overlayansible/ansible-ui | 113 | — | ~2.5k | Automated safety check: Notes | Apache-2.0 | |
| Run Testsansible-collections/ansible.mysql | 134 | — | ~1.2k | Automated safety check: Pass | Custom licence |
ansible/ansible
Downloads Azure Pipelines CI logs for an Ansible pull request or build so the agent can analyze test failures, after asking you first.
splunk/splunk-platform-automator
A skill your agent uses when creating or updating splunkconfig.yml, designing Splunk Enterprise lab topology, multisite IDXC, SHC layout, architecture plan before config, or AWS Terraform block for…
splunk/splunk-platform-automator
A skill your agent uses when adding app scope/routing test coverage (deployer, CM, DS, direct).
ansible/ansible-ui
Product-specific frontend wrappers, API clients, and paths for ansible-ui.
ansible-collections/ansible.mysql
Runs and writes tests (sanity, unit, integration) for the ansible.mysql Ansible collection using ansible-test.
ansible-collections/community.postgresql
Runs and writes tests (sanity, unit, integration) for the community.postgresql Ansible collection using ansible-test.
Works with
Categories
Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension. Wdio Testing is an agent skill from ansible/vscode-ansible. Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension.
Wdio Testing fits situations like: creating new WDIO specs; fixing test failures; lightspeed tests; troubleshooting headless/CI execution.
Run `npx skills add ansible/vscode-ansible --skill wdio-testing -a claude-code`. Or copy the skill folder (.cursor/skills/wdio-testing in ansible/vscode-ansible) into .claude/skills/wdio-testing in your project. Claude Code loads it when a task matches its description.
Run `npx skills add ansible/vscode-ansible --skill wdio-testing -a codex`. Or copy the skill folder (.cursor/skills/wdio-testing in ansible/vscode-ansible) into .agents/skills/wdio-testing in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ansible/vscode-ansible --skill wdio-testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/wdio-testing, .gemini/skills/wdio-testing, .github/skills/wdio-testing and .opencode/skills/wdio-testing in your project.
Going by SKILL.md and its folder, Wdio Testing needs the command-line tools its instructions call (npx). Our summary lists: Node.js.
SKILL.md names 1 domain. As links in the text: webdriver.io. This is read from the text; nothing was executed.
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.
Wdio Testing is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 2.2k tokens (SKILL.md is roughly 8.9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with Wdio Testing: Azure Pipelines Log Downloader (ansible/ansible, 71k stars), Spa Create Config (splunk/splunk-platform-automator, 137 stars), Spa Add Test Scenario (splunk/splunk-platform-automator, 137 stars) and Frontend Overlay (ansible/ansible-ui, 113 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
ansible (a GitHub organization) maintains it in ansible/vscode-ansible, which has 487 GitHub stars. The repository was last updated on October 7, 2026.
Source: ansible/vscode-ansible on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.