Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/payloadcms/payload/ui4-convert-testsnpx skills add payloadcms/payload --skill ui4-convert-testsgit clone --depth 1 https://github.com/payloadcms/payloadWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00036 | $0.03414 |
| Opus 5 | $0.00018 | $0.01707 |
| Sonnet 5 | $0.00007 | $0.00683 |
| Haiku 4.5 | $0.00004 | $0.00341 |
Grade A, and why
ui4-convert-tests scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 453 lines — stays where its author put it; the contents beside it link to each section on GitHub.
UI4 Convert Tests
Overview
After completing UI changes, this skill systematically identifies and fixes affected e2e tests. It analyzes the diff to understand what kind of changes were made (not just which files), then finds tests that need updates.
When to Use
- UI changes are finalized and ready for test fixes
- CI is failing on tests due to your UI changes
- Before opening a PR to ensure tests pass
Process
Step 1: Analyze What Changed
Goal: Understand the nature of your changes to predict test impact.
# Get changed UI files
git diff main --name-only -- 'packages/ui/src/**/*.tsx' 'packages/ui/src/**/*.css'
For each changed file, categorize the changes:
A. Selector Changes (IDs, classes)
git diff main -- <file> | grep -E '^\-.*className|^\-.*id=|^\+.*className|^\+.*id='
B. Structural Changes (elements moved)
Look for components being:
- Moved INTO a popup, drawer, or dropdown
- Wrapped in new parent elements
- Made conditional
git diff main -- <file> | grep -E 'Popup|PopupList|Drawer|Dropdown'
C. Text/Label Changes
# Translation keys
git diff main -- <file> | grep -E "t\('|i18n\.t\("
# Hardcoded text
git diff main -- <file> | grep -E 'placeholder=|aria-label='
Build a change summary:
| Change Type | What Changed | Test Impact |
|---|---|---|
| Selector | .btn:has-text("Create") → #create-new-doc |
Update locators |
| Structure | Button moved into popup | Add popup open step |
| Text | "Search by ID" → "Search" | Update assertions |
Step 2: Find Affected Tests
Search strategy: Cast a wide net, then narrow down.
# Search for component name references (not just selectors)
grep -rn "QueryPreset\|query-preset\|preset" test/**/*.ts --include="*.spec.ts" --include="*.ts"
# Search for specific selectors from Step 1
grep -rn "\.list-header\|Create New\|#create-new" test/**/*.ts
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 453 lines · 36 tokens per session scan A 547ea3c63c8d
ui4-convert-tests is a skill published in the GitHub repository payloadcms/payload (44,499 stars, last pushed 4d ago), licensed MIT. It adds 36 tokens to every session and 3,414 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
wordclaw-cms
Use when Codex is connected to a WordClaw MCP server or WordClaw-backed REST runtime. Start with system://capabilities, system://deployment-status, system://current-actor, and system://workspace-context, then use guidetask or resolveworkspacetarget before writing. Covers schema-bound authoring, review workflows, asset…
wordclaw-cms
Use when OpenClaw is connected to a WordClaw MCP server or WordClaw-backed REST runtime. Start with system://capabilities, system://deployment-status, system://current-actor, and system://workspace-context, then use guidetask or resolveworkspacetarget before writing. Covers schema-bound authoring, review workflows…
agent-browser
Browser automation for testing and verification. Use when you need to interact with web UIs, verify visual changes, fill forms, or capture screenshots.
instatic-user-e2e
Run user-facing Instatic E2E audits with a real browser and disposable local data. Use when asked to test the app as a user, run an agent-browser pass, perform a fresh-install smoke test, audit UX friction, verify setup/login/edit/publish/public-page flows, retest E2E issues, or update the Instatic E2E protocol and…
run-example-test
Run a single distribution example or tutorial integration test (IT) fast, instead of the whole 6 min example suite. Use when asked to run, verify, or check one example/tutorial test in the api-gateway distribution module.
gsd-integration-checker
Verifies that integrations work correctly by checking endpoints, responses, and data flow. Spawned by /gsd:complete-milestone orchestrator.