Agent skill

Alego CI Test Reliability

by singula-ai in singula-ai/alego

Design, review, and diagnose Alego tests and fixtures that can fail nondeterministically under CI concurrency, shared host resources, clocks, process-global state, subprocesses, network listeners…

MITAuto-check passedFrontend & Design

Install Alego CI Test Reliability

skills CLI
$ npx skills add singula-ai/alego --skill alego-ci-test-reliability -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install singula-ai/alego alego-ci-test-reliability --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/singula-ai/alego.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/alego-ci-test-reliability .claude/skills/alego-ci-test-reliability && rm -rf skills-src

Use ~/.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/

Facts

Skill name
alego-ci-test-reliability
GitHub stars
109
Token cost
~2.4k tokens
SKILL.md length
1,291 words
Files
2 (incl. references)
Skills in repo
20
Repo updated
First seen
Licence
MIT

At a glance

Design, review, and diagnose Alego tests and fixtures that can fail nondeterministically under CI concurrency, shared host resources, clocks, process-global state, subprocesses, network listeners…

  • Works in 4 steps: Tests in one Vitest file. → Separate Vitest files or worker processes. → Independent Vitest or repository-gate… → …
  • Changing tests with those risks
  • SKILL.md covers Read the owning rules, Model the execution topology, Allocate resources atomically and Contain process-global state, plus 8 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Alego CI Test Reliability is an agent skill from singula-ai/alego. Design, review, and diagnose Alego tests and fixtures that can fail nondeterministically under CI concurrency, shared host resources, clocks, process-global state, subprocesses, network listeners, or asynchronous teardown. Use when adding or changing tests with those risks, investigating flaky CI, or reviewing test isolation; use alego-pre-push-checks separately to select outgoing commands.

Its SKILL.md is about 2.4k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/ci-flake-diagnosis.md`).

It sits in Frontend & Design, covering State management, Async programming and Design review and critique. It works with Vitest. The repository describes itself as: Build AI Agents like playing LEGOs. Everything is a Plugin. The licence is MIT.

When your agent uses it

  • Changing tests with those risks
  • Investigating flaky CI
  • Reviewing test isolation
  • Use alego-pre-push-checks separately to select outgoing commands

Example prompts

  • “/alego-ci-test-reliability”

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Tests in one Vitest file.
  2. Separate Vitest files or worker processes.
  3. Independent Vitest or repository-gate processes in one job.
  4. Different Actions jobs whose runners share one host.

What it can do on your machine

Read from SKILL.md and the folder at commit a79fe9a. It shows what the files ask for, not the result of running them.

  • Tool permissions

    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.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Alego CI Test Reliability loads about 2.4k tokens when it runs, and up to ~3.7k if it reads all its reference files. Until then it costs about 105 tokens; SKILL.md has 1,291 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~105
When it runs · the whole SKILL.md, loaded when a task matches
~2.4k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~3.7k

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.

Safety

Auto-check passed

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.

SKILL.md

The full file from singula-ai/alego at commit a79fe9a, republished under its MIT licence (© singula-ai). 1,291 words, ~2,359 tokens.

Download SKILL.mdSave it as .claude/skills/alego-ci-test-reliability/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
alego-ci-test-reliability
description
Design, review, and diagnose Alego tests and fixtures that can fail nondeterministically under CI concurrency, shared host resources, clocks, process-global state, subprocesses, network listeners, or asynchronous teardown. Use when adding or changing tests with those risks, investigating flaky CI, or reviewing test isolation; use alego-pre-push-checks separately to select outgoing commands.

Reliable ALEGO CI tests

Build tests that remain correct under the repository's real CI topology, not only when run alone on a quiet workstation. This skill owns isolation and reliability decisions; it does not replace the repository's test-tier policy or select every command for a push.

Read the owning rules

  • Use the testing policy to select unit, coverage, expected-output, snapshot, browser, or real-API evidence.
  • Use the defensive patterns for lifecycle, subprocess, cancellation, and teardown behavior.
  • Read the active Vitest config and GitHub workflow when their worker or job topology affects the test.
  • For recorded-session scenarios, also follow the snapshot instructions.
  • Use alego-pre-push-checks after the test design is sound to select outgoing validation.

Model the execution topology

Assume these layers can overlap unless the active configuration proves otherwise:

  1. Tests in one Vitest file.
  2. Separate Vitest files or worker processes.
  3. Independent Vitest or repository-gate processes in one job.
  4. Different Actions jobs whose runners share one host.

Process isolation does not isolate host ports, predictable filesystem paths, external services, databases, sockets, or inherited child processes. For every acquired resource, identify its owner, atomic allocation mechanism, observable readiness signal, registered cleanup, and quiescent completion signal.

Do not serialize an entire suite merely because one fixture lacks isolation. Narrow the exclusive scope or change the resource allocation first. A sequential Vitest block cannot protect a host resource from another file, process, job, or runner.

Allocate resources atomically

Use the resource owner's allocator instead of checking availability and claiming it later.

  • Network fixtures bind loopback with listen(0) and read the assigned address only after the server reports that it is listening. Never scan for a free port and bind it later.
  • Create private per-test temporary roots with mkdtemp; do not acquire predictable shared paths.
  • Give shared databases, sockets, sessions, and output locations unique per-test namespaces.
  • Use exclusive creation where a path must not already exist.
  • Keep stable recorded identifiers separate from ephemeral transport addresses. Translate inside the fixture instead of forcing the live resource to use the recorded value.

Literal paths and URLs used only as parser inputs or expected values are not acquired resources. Do not rewrite them merely because they look fixed.

Contain process-global state

Treat process.env, cwd, fake timers, locale and timezone, module mocks, registries, console hooks, globalThis, and global fetch interception as exclusive mutable resources.

Prefer an injected dependency or instance-local adapter. When mutation is required:

  • capture whether the original value was absent or present;
  • restore that exact state;
  • register restoration immediately;
  • use try/finally around the smallest mutation scope;
  • keep an afterEach fallback when failure before the local finally is plausible;
  • intercept the narrowest exact request or call that the fixture owns.

Respect platform-owned semantics

CI runs the same suite on Windows and on POSIX hosts, and a value the operating system owns does not always come back the way a test wrote it.

  • Writing a value back is safe only when the assertion tolerates the write-back failing. Restoring a file's mtime to prove that a fingerprint invalidates anyway holds everywhere; restoring it to prove that a record stays valid assumes a lossless round trip, which NTFS's 100-nanosecond ticks do not give a fractional millisecond. When the assertion depends on the restoration, take the expected value from a fresh read rather than from the remembered one.
  • Windows matches environment variable names case-insensitively, so a fixture seeding http_proxy and HTTP_PROXY as separate keys holds one entry there.
  • Windows releases file handles asynchronously, so a rename or removal that completes at once on a POSIX host needs a bounded retry sized to the observed contention.
  • Windows has no POSIX permission or signal semantics. A case that depends on them takes an explicit platform skip naming the reason, rather than an assertion weakened everywhere.

Prefer an observation that holds on every platform. When a case genuinely cannot, exclude it on that platform explicitly.

Budget timeouts against the lane

A describe or case timeout overrides the runner's --testTimeout instead of yielding to it, so a value below the lane's budget lowers what CI already granted — and the same literal reads as a widening on a host whose default is smaller. A suite bound by process creation takes the lane budget; a tighter value carries the reason it is tighter.

Raise the hook budget with the test budget. Setup and teardown pay the same contention, so lifting only the case budget moves a contended failure into afterEach.

Where a timeout is the subject, keep the outer wait far larger than the timeout under test. A case proving that a 20 ms deadline fires must not race the harness's own wait, or load decides which deadline reports first.

Show full SKILL.md (517 more words)Show less

Synchronize on state

A fixed sleep is not evidence that setup completed or cleanup settled.

  • Wait for an explicit readiness event, handshake, state transition, owned promise, or externally observable condition.
  • Use deferred promises or barriers to place a race at a deterministic point and prove the relevant operations overlap.
  • Use a timeout only to bound a wait, never as the condition that makes the assertion correct.
  • Do not assert scheduler-dependent ordering unless that ordering is the product behavior under test.
  • When time itself is the subject, inject or fake the clock and always restore real timers.

Dispose to quiescence

Register cleanup immediately after acquisition so assertion failures also release the resource. Cleanup stops new callbacks or requests, detaches listeners, restores global hooks, terminates owned work, and awaits child exit, server close, worker termination, or the equivalent completion signal.

Calling abort(), close(), or kill() without awaiting the owned completion signal is incomplete teardown. When late completion is possible, prove that disposal prevents it from mutating another test.

Prove the intended regression

  • Observe an ordinary regression fail before the fix when practical.
  • For a new static or corpus guard, temporarily introduce the rejected case and observe the intended failure.
  • For a race, use barriers to prove overlap; repeated execution alone is not a race test.
  • For ports, sockets, shared paths, subprocesses, or other host resources, run independent test processes concurrently when cross-process isolation is part of the fix.
  • Where a fixture spawns with its own deadline, assert that no signal or timeout ended the child before asserting its exit status, so a killed child reports as a timeout instead of as a status mismatch.
  • Verify external state, events, files, logs, exits, or disposal instead of trusting the component's self-report.

Stress runs supplement a deterministic regression; they do not replace one.

Reject flake-masking fixes

Do not present these as root-cause fixes for deterministic local tests:

  • increasing a timeout without identifying the awaited state;
  • adding retries;
  • making all files serial;
  • swallowing an error or unhandled rejection;
  • weakening an assertion;
  • normalizing away unstable behavior;
  • adding a sleep before cleanup or assertion.

Retries remain valid for documented transient external-provider tests under the real-API policy. Keep that exception at the external boundary.

Restoring a budget is not masking. Raising a suite to the lane budget it already had, or sizing a bounded retry to the contention actually measured on the runner, names the awaited work and returns what the lane granted; neither invents headroom around an unexamined wait.

Diagnose existing flakes

For an existing probabilistic CI failure, read the CI flake diagnosis workflow. A diagnosis-only request remains read-only: report the cause and evidence unless the user also asks for a fix.

Validate and report

Run the smallest focused regression for the affected behavior. Add topology-specific evidence only when the change owns that risk:

  • global mutation needs restoration evidence;
  • lifecycle or subprocess work needs quiescent teardown evidence;
  • ports, sockets, or shared paths need concurrent independent-process evidence;
  • a new guard needs a negative control.

Before a push, use alego-pre-push-checks. Report exact commands and observed results; do not describe retries, skipped tests, or pending CI as passing.

© singula-ai, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in .agents/skills/alego-ci-test-reliability of singula-ai/alego.

  • SKILL.md
  • references/ci-flake-diagnosis.md

Open the folder on GitHubat commit a79fe9a

Compare with similar skills

Alego CI Test Reliability 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.

Alego CI Test Reliability compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Alego CI Test Reliability this skillsingula-ai/alego109—~2.4kAutomated safety check: PassMIT
Dsh CI Test ReliabilityZhou-Yujing114514/deepseek-harness-linux120—~2.4kAutomated safety check: PassMIT
Tanstack Querybskimball/tanstack-hono1191 repos~5.4kAutomated safety check: PassMIT
Choruz CI Test ReliabilityinclusionAI/Choruz1k—~1.8kAutomated safety check: PassApache-2.0
JavaScript IO Effects With Sagasparalleldrive/aidd384—~587Automated safety check: PassMIT
Frontend API Integration Patternssickn33/agentic-awesome-skills47k1 repos~1.9kAutomated safety check: PassMIT

Similar skills

  • Dsh CI Test Reliability

    Zhou-Yujing114514/deepseek-harness-linux

    Design, review, and diagnose DeepSeek Harness tests and fixtures that can fail nondeterministically under CI concurrency, shared host resources, clocks, process-global state, subprocesses, network…

    120 GitHub stars~2.4k tokensUpdated 4 days ago
    Frontend & DesignAuto-check passed
  • Tanstack Query

    bskimball/tanstack-hono

    Powerful asynchronous state management, server-state utilities, and data fetching for TS/JS, React, Vue, Solid, Svelte & Angular.

    119 GitHub starsUsed in 1 repo~5.4k tokens
    Frontend & DesignAuto-check passed
  • Choruz CI Test Reliability

    inclusionAI/Choruz

    Design, review, and diagnose Choruz tests and fixtures that can fail nondeterministically under CI concurrency: parallel Playwright workers sharing one PostgreSQL and one API, vitest workers, cargo…

    1k GitHub stars~1.8k tokensUpdated 3 days ago
    Testing & QAAuto-check passed
  • Teaches the saga pattern with call and put so network requests and side effects stay out of the logic and sagas can be tested without mocks.

    384 GitHub stars~587 tokensUpdated 3 mo ago
    DevelopmentAuto-check passed
  • Frontend API Integration Patterns

    sickn33/agentic-awesome-skills

    Production-ready patterns for integrating frontend applications with backend APIs, including race condition handling, request cancellation, retry strategies, error normalization, and UI state…

    47k GitHub starsUsed in 1 repo~1.9k tokens
    Frontend & DesignAuto-check passed
  • Qovery UI

    Qovery/console

    Design review and implementation guidance for the Qovery Console.

    227 GitHub stars~2k tokensUpdated today
    Frontend & DesignAuto-check passed

More from singula-ai/alego

All 20 skills in this repo
  • Record Browser Gif

    singula-ai/alego

    Record browser or Web UI interaction demos as optimized GIFs using the available browser-control workflow, optional Playwright Videos for higher capture frame rates, and deterministic encoding, then…

    109 GitHub starsUsed in 1 repo~4.1k tokens
    Auto-check: notes
  • A skill your agent uses when adding, auditing, pruning, archiving, restoring, or reviewing Agent Notes in alego; checks every new note for superseded active records, deletes small UI and purely…

    109 GitHub starsUsed in 1 repo~1.7k tokens
    Auto-check passed
  • A skill your agent uses when landing a stack of dependent GitHub PRs (A ← B ← C, where each bases on the one below) onto master, merging a PR whose base is another open PR's branch, or whenever a…

    109 GitHub starsUsed in 1 repo~2k tokens
    Auto-check passed
  • A skill your agent uses when creating, changing, or validating an agent preset or other Cordis composition for this harness, including deciding host versus preset placement and checking that an…

    109 GitHub starsUsed in 1 repo~1.4k tokens
    Auto-check passed
  • Office DOCX

    singula-ai/alego

    Create, read, edit, and check Word documents (.docx), including reports, letters, and formatted tables.

    109 GitHub starsUsed in 1 repo~1.5k tokens
    Auto-check passed
  • Office PPTX

    singula-ai/alego

    Create, read, edit, and check PowerPoint presentations (.pptx), including slide text, tables, images, and charts.

    109 GitHub starsUsed in 1 repo~1.7k tokens
    Auto-check passed

Works with

Questions about Alego CI Test Reliability

What does Alego CI Test Reliability do?

Design, review, and diagnose Alego tests and fixtures that can fail nondeterministically under CI concurrency, shared host resources, clocks, process-global state, subprocesses, network listeners…. Alego CI Test Reliability is an agent skill from singula-ai/alego. Design, review, and diagnose Alego tests and fixtures that can fail nondeterministically under CI concurrency, shared host resources, clocks, process-global state, subprocesses, network listeners, or asynchronous teardown.

When should I use Alego CI Test Reliability?

Alego CI Test Reliability fits situations like: changing tests with those risks; investigating flaky CI; reviewing test isolation; use alego-pre-push-checks separately to select outgoing commands.

How do I install Alego CI Test Reliability in Claude Code?

Run `npx skills add singula-ai/alego --skill alego-ci-test-reliability -a claude-code`. Or copy the skill folder (.agents/skills/alego-ci-test-reliability in singula-ai/alego) into .claude/skills/alego-ci-test-reliability in your project. Claude Code loads it when a task matches its description.

How do I install Alego CI Test Reliability in Codex?

Run `npx skills add singula-ai/alego --skill alego-ci-test-reliability -a codex`. Or copy the skill folder (.agents/skills/alego-ci-test-reliability in singula-ai/alego) into .agents/skills/alego-ci-test-reliability in your project. Codex loads it when a task matches its description.

Can I use Alego CI Test Reliability in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add singula-ai/alego --skill alego-ci-test-reliability -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/alego-ci-test-reliability, .gemini/skills/alego-ci-test-reliability, .github/skills/alego-ci-test-reliability and .opencode/skills/alego-ci-test-reliability in your project.

What does Alego CI Test Reliability need to run?

SKILL.md names no scripts, command-line tools or credentials: Alego CI Test Reliability is instructions for the agent only.

Does Alego CI Test Reliability access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Alego CI Test Reliability safe to install?

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.

What licence does Alego CI Test Reliability use?

Alego CI Test Reliability is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Alego CI Test Reliability use?

About 2.4k tokens (SKILL.md is roughly 9.4k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.3k tokens, read only when the agent opens those files.

What are the alternatives to Alego CI Test Reliability?

Skills that share tags, products or a category with Alego CI Test Reliability: Dsh CI Test Reliability (Zhou-Yujing114514/deepseek-harness-linux, 120 stars), Tanstack Query (bskimball/tanstack-hono, 119 stars), Choruz CI Test Reliability (inclusionAI/Choruz, 1k stars) and JavaScript IO Effects With Sagas (paralleldrive/aidd, 384 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Alego CI Test Reliability?

singula-ai (a GitHub organization) maintains it in singula-ai/alego, which has 109 GitHub stars. The repository holds 20 skills in this directory. The repository was last updated on September 28, 2026.

Source: singula-ai/alego on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.