GreptimeDB Fuzz CI Failure Investigation
GreptimeTeam/greptimedb
Diagnoses a failed GreptimeDB fuzz CI job by pulling its GitHub Actions logs and fuzz artifacts, then matching the evidence to the local source code.
A skill your agent uses when CI tests fail on main branch after PR merge, when investigating flaky test failures, or when user provides a PR URL/number to aggregate all failing tests
$ npx skills add payloadcms/payload --skill triage-ci-flake -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install payloadcms/payload triage-ci-flake --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/payloadcms/payload.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/triage-ci-flake .claude/skills/triage-ci-flake && 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 "triage-ci-flake" agent skill from https://github.com/payloadcms/payload/tree/main/.agents/skills/triage-ci-flake into .claude/skills/triage-ci-flake/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "triage-ci-flake", 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/payloadcms/payload/tree/main/.agents/skills/triage-ci-flakeType 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 payloadcms/payload --skill triage-ci-flake -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install payloadcms/payload triage-ci-flake --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/payloadcms/payload.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.agents/skills/triage-ci-flake .agents/skills/triage-ci-flake && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "triage-ci-flake" agent skill from https://github.com/payloadcms/payload/tree/main/.agents/skills/triage-ci-flake into .agents/skills/triage-ci-flake/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "triage-ci-flake", 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 payloadcms/payload --skill triage-ci-flake -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install payloadcms/payload triage-ci-flake --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/payloadcms/payload.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.agents/skills/triage-ci-flake .cursor/skills/triage-ci-flake && 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 "triage-ci-flake" agent skill from https://github.com/payloadcms/payload/tree/main/.agents/skills/triage-ci-flake into .cursor/skills/triage-ci-flake/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "triage-ci-flake", 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/payloadcms/payload.git --path .agents/skills/triage-ci-flake--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 payloadcms/payload --skill triage-ci-flake -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install payloadcms/payload triage-ci-flake --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/payloadcms/payload.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.agents/skills/triage-ci-flake .gemini/skills/triage-ci-flake && 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 "triage-ci-flake" agent skill from https://github.com/payloadcms/payload/tree/main/.agents/skills/triage-ci-flake into .gemini/skills/triage-ci-flake/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "triage-ci-flake", 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 payloadcms/payload triage-ci-flakeInstalls 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 payloadcms/payload --skill triage-ci-flake -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/payloadcms/payload.git skills-src && mkdir -p .github/skills && cp -r skills-src/.agents/skills/triage-ci-flake .github/skills/triage-ci-flake && 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 "triage-ci-flake" agent skill from https://github.com/payloadcms/payload/tree/main/.agents/skills/triage-ci-flake into .github/skills/triage-ci-flake/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "triage-ci-flake", 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 payloadcms/payload --skill triage-ci-flake -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install payloadcms/payload triage-ci-flake --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/payloadcms/payload.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.agents/skills/triage-ci-flake .opencode/skills/triage-ci-flake && 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 "triage-ci-flake" agent skill from https://github.com/payloadcms/payload/tree/main/.agents/skills/triage-ci-flake into .opencode/skills/triage-ci-flake/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "triage-ci-flake", 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.
triage-ci-flakeA skill your agent uses when CI tests fail on main branch after PR merge, when investigating flaky test failures, or when user provides a PR URL/number to aggregate all failing tests
Triage CI Flake is an agent skill from payloadcms/payload. Use when CI tests fail on main branch after PR merge, when investigating flaky test failures, or when user provides a PR URL/number to aggregate all failing tests
Its SKILL.md is about 4.4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Testing & QA, covering Failing and flaky tests. It works with Payload CMS and GitHub. The repository describes itself as: Payload is the open-source, fullstack Next.js framework, giving you instant backend superpowers. Get a full TypeScript backend and admin panel instantly. Use Payload as a… The licence is MIT.
9 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit c66a7be. It shows what the files ask for, not the result of running them.
Pre-approves these tools, so the agent can use them without asking each time:
WriteBash(date:*)Bash(mkdir -p *)From allowed-tools in the SKILL.md frontmatter.
Shell commands in SKILL.md call:
pnpmFrom the folder's file list and the shell code blocks in SKILL.md.
Hosts in commands or code, which the agent is likely to contact:
github.comFrom 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.
Triage CI Flake loads about 4.4k tokens when it runs. Until then it costs about 45 tokens; SKILL.md has 1,323 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 payloadcms/payload at commit c66a7be, republished under its MIT licence (© payloadcms). 1,323 words, ~4,400 tokens.
.claude/skills/triage-ci-flake/SKILL.md (or your agent's skills folder).Systematic workflow designed specifically for triaging and fixing end-to-end (e2e) test failures in CI, especially flaky Playwright tests that pass locally but fail in CI. E2E tests that made it to main are usually flaky due to timing, bundling, or environment differences.
CRITICAL RULE: You MUST run the reproduction workflow before proposing any fixes. No exceptions.
main branch after PR was mergedWhen the user provides a PR URL (e.g., https://github.com/payloadcms/payload/pull/16701) or PR number:
First, use tool_search with query "github pull request status checks" to load the GitHub tools.
Then use the github-pull-request_pullRequestStatusChecks tool to get all failing checks:
Tool: github-pull-request_pullRequestStatusChecks
Parameters:
pullRequestNumber: <extracted from URL or provided>
repo: { owner: "payloadcms", name: "payload" }Parse the status checks response and create a summary table:
| Suite | Check Status | Target URL |
|---|---|---|
| admine2elist-view | failed | [link] |
| plugin-import-export | failed | [link] |
For each failing check, the context field contains the test suite name (e.g., admin__e2e__list-view).
For each failing check:
targetUrl to get detailed failure logsPresent a consolidated summary:
## Failing Tests Summary
### 1. admin**e2e**list-view (3/4)
- **Test**: "should use custom pagination limit"
- **Error**: Locator `.per-page__button` not found
- **File**: test/admin/e2e/list-view/e2e.spec.ts:1495
### 2. plugin-import-export
- **Test**: "should inherit limit from list view URL"
- **Error**: Locator `.per-page__button` not found
- **File**: test/plugin-import-export/e2e.spec.ts:150Look for patterns across failures:
For each unique failure, follow the standard reproduction workflow below.
YOU MUST EXECUTE THESE COMMANDS. Reading code or analyzing logs does NOT count as reproduction.
pnpm dev $SUITE_NAME (use run_in_background=true)pnpm prepare-run-test-against-prodpnpm dev:prod $SUITE_NAME and run test againOnly after EXECUTING these commands and seeing their output can you proceed to analysis and fixes.
"Analysis from logs" is NOT reproduction. You must RUN the commands.
digraph triage_ci {
"CI failure reported" [shape=box];
"Extract details from CI logs" [shape=box];
"Identify suite and test name" [shape=box];
"Run dev server: pnpm dev $SUITE" [shape=box];
"Run specific test by name" [shape=box];
"Did test fail?" [shape=diamond];
"Debug with dev code" [shape=box];
"Run prepare-run-test-against-prod" [shape=box];
"Run: pnpm dev:prod $SUITE" [shape=box];
"Run specific test again" [shape=box];
"Did test fail now?" [shape=diamond];
"Debug bundling issue" [shape=box];
"Unable to reproduce - check logs" [shape=box];
"Fix and verify" [shape=box];
"CI failure reported" -> "Extract details from CI logs";
"Extract details from CI logs" -> "Identify suite and test name";
"Identify suite and test name" -> "Run dev server: pnpm dev $SUITE";
"Run dev server: pnpm dev $SUITE" -> "Run specific test by name";
"Run specific test by name" -> "Did test fail?";
"Did test fail?" -> "Debug with dev code" [label="yes"];
"Did test fail?" -> "Run prepare-run-test-against-prod" [label="no"];
"Run prepare-run-test-against-prod" -> "Run: pnpm dev:prod $SUITE";
"Run: pnpm dev:prod $SUITE" -> "Run specific test again";
"Run specific test again" -> "Did test fail now?";
"Did test fail now?" -> "Debug bundling issue" [label="yes"];
"Did test fail now?" -> "Unable to reproduce - check logs" [label="no"];
"Debug with dev code" -> "Fix and verify";
"Debug bundling issue" -> "Fix and verify";
}From CI logs or GitHub Actions URL, identify:
i18n, fields, lexical)test/i18n/e2e.spec.ts)CRITICAL: Always run the specific test by name, not the full suite.
SERVER MANAGEMENT RULES:
# ========================================
# STEP 2A: STOP ALL SERVERS
# ========================================
lsof -ti:3000 | xargs kill -9 2>/dev/null || echo "Port 3000 clear"
# ========================================
# STEP 2B: START DEV SERVER
# ========================================
# Start dev server with the suite (in background with run_in_background=true)
pnpm dev $SUITE_NAME
# ========================================
# STEP 2C: WAIT FOR SERVER READY
# ========================================
# Wait for server to be ready (REQUIRED - do not skip)
until curl -s http://localhost:3000/admin > /dev/null 2>&1; do sleep 1; done && echo "Server ready"
# ========================================
# STEP 2D: RUN SPECIFIC TEST
# ========================================
# Run ONLY the specific failing test using Playwright directly
# For E2E tests (DO NOT use pnpm test:e2e as it spawns its own server):
pnpm exec playwright test test/$SUITE_NAME/e2e.spec.ts -g "exact test name"
Did the test fail?
If test passed with dev code, the issue is likely in bundled/production code.
IMPORTANT: You MUST stop the dev server before starting prod server.
# ========================================
# STEP 3A: STOP ALL SERVERS (INCLUDING DEV SERVER FROM STEP 2)
# ========================================
lsof -ti:3000 | xargs kill -9 2>/dev/null || echo "Port 3000 clear"
# ========================================
# STEP 3B: BUILD AND PACK FOR PROD
# ========================================
# Build all packages and pack them (this takes time - be patient)
pnpm prepare-run-test-against-prod
# ========================================
# STEP 3C: START PROD SERVER
# ========================================
# Start prod dev server (in background with run_in_background=true)
pnpm dev:prod $SUITE_NAME
# ========================================
# STEP 3D: WAIT FOR SERVER READY
# ========================================
# Wait for server to be ready (REQUIRED - do not skip)
until curl -s http://localhost:3000/admin > /dev/null 2>&1; do sleep 1; done && echo "Server ready"
# ========================================
# STEP 3E: RUN SPECIFIC TEST
# ========================================
# Run the specific test again using Playwright directly
pnpm exec playwright test test/$SUITE_NAME/e2e.spec.ts -g "exact test name"Did the test fail now?
If you cannot reproduce locally after both attempts:
for i in {1..10}; do pnpm test:e2e...; done)Fix patterns:
toBeVisible(), toHaveText())waitForFunction() with condition checksafterEachFix patterns:
afterEachdeleteAll that affects other testssetTimeout/sleep instead of condition-based waitingFix patterns:
waitForPageStability() helperWhen fixing e2e tests, be aware of these eslint rules:
playwright/no-networkidle - Avoid waitForLoadState('networkidle') (use condition-based waiting instead)payload/no-wait-function - Avoid custom wait() functions (use Playwright's built-in waits)payload/no-flaky-assertions - Avoid non-retryable assertionsplaywright/prefer-web-first-assertions - Use built-in Playwright assertionsExisting code may violate these rules - when adding new code, follow the rules even if existing code doesn't.
After fixing:
# Ensure dev server is running on port 3000
# Run test multiple times to confirm stability
for i in {1..10}; do
pnpm exec playwright test test/$SUITE_NAME/e2e.spec.ts -g "exact test name" || break
done
# Run full suite
pnpm exec playwright test test/$SUITE_NAME/e2e.spec.ts
# If you modified bundled code, test with prod build
lsof -ti:3000 | xargs kill -9 2>/dev/null
pnpm prepare-run-test-against-prod
pnpm dev:prod $SUITE_NAME
until curl -s http://localhost:3000/admin > /dev/null; do sleep 1; done
pnpm exec playwright test test/$SUITE_NAME/e2e.spec.tsNO FIX WITHOUT REPRODUCTION FIRST
If you propose a fix before completing steps 1-3 of the workflow, you've violated this skill.
This applies even when:
No exceptions. Run the reproduction workflow first.
Every excuse for skipping reproduction, and why it's wrong:
| Rationalization | Reality |
|---|---|
| "The logs show the exact error" | Logs show symptoms, not root cause. Reproduce. |
| "I can see the problem in the code" | You're guessing. Reproduce to confirm. |
| "This is obviously a race condition" | Maybe. Reproduce to be sure. |
| "I've seen this error before" | This might be different. Reproduce. |
| "The stack trace is clear" | Stack trace shows where, not why. Reproduce. |
| "Time pressure - need to fix fast" | Reproducing IS fast. Guessing wastes time. |
| "The test file shows the issue" | Reading ≠ running. Execute the commands. |
| "I'll analyze the code first" | Code analysis comes AFTER reproduction. |
| "Let me investigate the root cause" | Reproduction IS the investigation. |
| "I need to understand the error" | Understanding comes from seeing it fail. |
These thoughts mean you're about to violate the skill:
All of these mean: Stop immediately. Execute the reproduction commands. No analysis without execution.
CORRECT approach - executes commands first:
User: CI failed on i18n suite - https://github.com/.../actions/runs/XXX
Agent:
1. Extracted details from CI logs:
- Suite: i18n
- Test: "ensure translations update correctly when switching language"
- File: test/i18n/e2e.spec.ts:124
- Error: "Error loading language: en" TypeError: network error
2. Executing reproduction workflow:
[Uses Bash tool to kill ports]
$ lsof -ti:3000 | xargs kill -9 2>/dev/null || echo "Port 3000 clear"
[Uses Bash tool with run_in_background=true]
$ pnpm dev i18n
[Waits for server to start with curl check]
$ until curl -s http://localhost:3000/admin > /dev/null; do sleep 1; done && echo "Server ready"
[Uses Bash tool to run Playwright directly]
$ pnpm exec playwright test test/i18n/e2e.spec.ts -g "ensure translations update correctly when switching language"
Output shows: Test PASSED locally
3. Test passed with dev code, trying bundled code:
[Kills ports again]
$ lsof -ti:3000 | xargs kill -9 2>/dev/null
[Uses Bash tool]
$ pnpm prepare-run-test-against-prod
[Uses Bash tool with run_in_background=true]
$ pnpm dev:prod i18n
[Waits for server]
$ until curl -s http://localhost:3000/admin > /dev/null; do sleep 1; done
[Uses Bash tool]
$ pnpm exec playwright test test/i18n/e2e.spec.ts -g "ensure translations update correctly when switching language"
Output shows: Test FAILED - reproduced!
4. Now that I've reproduced it, analyzing the failure...
[Code analysis, root cause identification]
5. Implementing fix: [specific changes]
6. Verification:
[Uses Bash tool]
$ for i in {1..10}; do pnpm test:e2e i18n -g "exact test"; done
All 10 runs passed!INCORRECT approach - analyzes without executing:
User: CI failed on i18n suite
Agent: Looking at the error logs, I can see this is a race condition...
[Analyzes code, proposes fix without running any commands]
❌ WRONG - This violates the skill. Must execute reproduction commands first.| Mistake | Fix |
|---|---|
| Running full test suite first | Run specific test by name |
| Skipping dev code reproduction | Always try dev code first |
| Not testing with bundled code | If dev passes, test with prepare-run-test-against-prod |
| Proposing fix without reproducing | Follow the workflow - reproduce first |
Using networkidle in new code | Use condition-based waiting with waitForFunction() |
Adding arbitrary wait() calls | Use Playwright's built-in assertions and waits |
After you have:
You MUST prompt the user to create a PR:
The fix has been verified and is ready for review. Would you like me to create a PR with these changes?
Summary of changes:
- [List files modified]
- [Brief description of the fix]
- [Verification results]IMPORTANT:
This ensures the user has visibility and control over what gets submitted for review.
© payloadcms, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Just SKILL.md in .agents/skills/triage-ci-flake of payloadcms/payload.
Open the folder on GitHubat commit c66a7be
Triage CI Flake 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 |
|---|---|---|---|---|---|---|
| Triage CI Flake this skillpayloadcms/payload | 45k | — | ~4.4k | Automated safety check: Pass | MIT | |
| GreptimeDB Fuzz CI Failure InvestigationGreptimeTeam/greptimedb | 6.7k | — | ~4.4k | Automated safety check: Pass | Apache-2.0 | |
| Fix Issueremix-run/remix | 33k | — | ~1.8k | Automated safety check: Pass | MIT | |
| Issue To Regression Testbrunosabot/streamline-card | 269 | — | ~529 | Automated safety check: Pass | MIT | |
| Detect Flaky Testsagent-substrate/substrate | 4.5k | — | ~3k | Automated safety check: Pass | Apache-2.0 | |
| Fix Random CI Test Failuredotnet/macios | 2.9k | — | ~1.3k | Automated safety check: Pass | Custom licence |
GreptimeTeam/greptimedb
Diagnoses a failed GreptimeDB fuzz CI job by pulling its GitHub Actions logs and fuzz artifacts, then matching the evidence to the local source code.
remix-run/remix
Fix a reported issue in Remix from a GitHub issue. An agent skill from remix-run/remix.
brunosabot/streamline-card
A skill your agent uses when the user asks to fix a bug, references a GitHub issue number, or describes an issue and wants a fix.
agent-substrate/substrate
Detects flaky Go tests by analyzing GitHub Actions workflow runs across the last 7 days and all PRs — covering both the run-tests job (unit/integration) and the e2e-test job (gVisor and microVM…
dotnet/macios
Investigate and fix flaky/random CI test failures in dotnet/macios.
dotnet/maui
Adds dotnet/maui-specific context for investigating failing PR checks and broken nightly builds: pipelines, Helix logs, binlogs and merge-readiness verdicts.
payloadcms/payload
A skill your agent uses when a Payload pull request needs a concise visual walkthrough for reviewers.
payloadcms/payload
A skill your agent uses when working with Payload projects (payload.config.ts, collections, fields, hooks, access control, Payload API).
payloadcms/payload
A skill your agent uses when fixing dependency vulnerabilities, running pnpm audit, or when the audit-dependencies CI check fails
payloadcms/payload
A skill your agent uses when new translation keys are added to packages to generate new translations strings
payloadcms/payload
A skill your agent uses when UI changes are complete and e2e tests need updating.
payloadcms/payload
A skill your agent uses when changing or reviewing rendered Payload UI, interaction or focus behavior, semantic markup, accessibility tests, or WCAG/VPAT evidence.
Works with
Categories
A skill your agent uses when CI tests fail on main branch after PR merge, when investigating flaky test failures, or when user provides a PR URL/number to aggregate all failing tests. Triage CI Flake is an agent skill from payloadcms/payload.
Triage CI Flake fits situations like: CI tests fail on main branch after PR merge; investigating flaky test failures; user provides a PR URL/number to aggregate all failing tests.
Run `npx skills add payloadcms/payload --skill triage-ci-flake -a claude-code`. Or copy the skill folder (.agents/skills/triage-ci-flake in payloadcms/payload) into .claude/skills/triage-ci-flake in your project. Claude Code loads it when a task matches its description.
Run `npx skills add payloadcms/payload --skill triage-ci-flake -a codex`. Or copy the skill folder (.agents/skills/triage-ci-flake in payloadcms/payload) into .agents/skills/triage-ci-flake 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 payloadcms/payload --skill triage-ci-flake -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/triage-ci-flake, .gemini/skills/triage-ci-flake, .github/skills/triage-ci-flake and .opencode/skills/triage-ci-flake in your project.
Going by SKILL.md and its folder, Triage CI Flake needs the command-line tools its instructions call (pnpm). Our summary lists: Node.js. Its frontmatter pre-approves these tools: Write, Bash(date:*), Bash(mkdir -p *).
SKILL.md names 1 domain. In commands or code: github.com; the agent is likely to contact it when it follows the instructions. 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.
Triage CI Flake is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 4.4k tokens (SKILL.md is roughly 18k 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 Triage CI Flake: GreptimeDB Fuzz CI Failure Investigation (GreptimeTeam/greptimedb, 6.7k stars), Fix Issue (remix-run/remix, 33k stars), Issue To Regression Test (brunosabot/streamline-card, 269 stars) and Detect Flaky Tests (agent-substrate/substrate, 4.5k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
payloadcms (a GitHub organization) maintains it in payloadcms/payload, which has 45,140 GitHub stars. The repository holds 9 skills in this directory. The repository was last updated on October 8, 2026.
Source: payloadcms/payload on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.