Run any Skill in Manus with one click

adding-nix-tests

Stars30

Forks1

UpdatedJuly 3, 2026 at 08:30

Use this skill when new or improved test coverage is needed for a nix module or behavior. Trigger phrases include 'add a test for this module', 'improve test coverage', 'write a test that X', 'register this test', 'test the new module', 'cover this with a test'. Drives the author-run-triage loop across nix-test-author, nix-checker, and nix-debugger. Does NOT cover merely running the existing suite with no new test (dispatch nix-checker directly instead) or authoring non-test config (use creating-nix-modules instead).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

nicolkrit999

nicolkrit999/nix

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name

adding-nix-tests

description

Adding Nix Tests

The repo CLAUDE.md mandates delegating verification and debugging to agents - never run the test suite directly in the main loop. The orchestrator (this chat) dispatches each stage and loops; agents cannot call each other.

The loop

1. AUTHOR - dispatch nix-test-author with the module or behavior to cover. Its contract for a new test requires all 4 deliverables:

mirrors an existing test's structure (same platform's test layout/style)
a test dir templates/tests/<platform>/test-<name>/ with a scenario .nix file and check-*.sh script(s) (or a nix-tests dir where that pattern applies)
a MANDATORY README at test-<name>-readme.md in that test dir
registration of the new test in templates/tests/run-tests.sh

It also runs just the new test itself to confirm basic behavior before handing off.

2. RUN - dispatch nix-checker to run the FULL templates/tests suite, not just the new test - a new test can break or collide with the existing registry.

3. TRIAGE any failures:

Test itself is wrong or unidiomatic (bad assertion, wrong platform dir, registry mistake) -> back to nix-test-author to fix the test.
Test is correct and exposes a REAL config bug -> dispatch nix-debugger to fix the underlying config. NEVER weaken or delete the test to make it pass - the test's job is to catch this.
After either fix, re-run via nix-checker (step 2) on the full suite, not just the one test.

Loop 2 -> 3 until the suite is green.

Safeguard: after ~4 rounds without convergence, stop and report the remaining issues to the user instead of continuing indefinitely.

Exit condition

Full suite green including the new test, AND all 4 deliverables confirmed present - spot-check that the README file actually exists at test-<name>-readme.md, since it's mandatory for every test dir in this repo and easy to silently skip. Report to the user what was added and where.

Out of scope

Merely running the existing suite with no new test to add - dispatch nix-checker directly instead of this loop.
Authoring non-test config (new modules, options, host wiring) - that's creating-nix-modules.

More from this repository

same repository

investigating-nix-issues

nicolkrit999/nix

Use this skill for general debugging of this nix config whenever it is NOT already known that a build/flake check/rebuild is failing - runtime or boot-time misbehavior, hardware quirks driven by config, config that silently doesn't take effect, code that looks broken but builds, suspected dead/orphaned code, an unresolved issue recorded in a memory file, or any vague observation that something is off. The issue can come from existing code, a memory entry, or a user report alike. Trigger phrases include 'debug this', 'something is wrong with X', 'it builds but doesn't work', 'X stopped working after a successful rebuild', 'this option seems to have no effect', 'is this module even used', 'find dead code', 'look into that unresolved issue from memory', 'retry the fix we reverted', 'debug why X behaves like this'. Drives the frame-investigate-fix-verify loop across nix-debugger, nix-config-architect, nix-package-researcher, nix-checker, and Explore. Does NOT cover a KNOWN-failing build/flake check/rebuild (use d

2026-07-0330

creating-nix-modules

nicolkrit999/nix

Use this skill when adding or modifying nix configuration that introduces new functionality, such as new denix modules, enabling programs/services, host constants, theming, or home-manager config. Trigger phrases include 'add a module', 'enable X on host Y', 'install/integrate package Z', 'configure <service> in nix', 'add this to my nixos config', 'set up <program> via home-manager'. Drives the research-author-lint-verify pipeline across nix-package-researcher, nix-config-architect, nix-syntax-linter, and nix-checker. Does NOT cover diagnosing an existing build failure (use debugging-nix-failures instead) or pure attribute/option lookups with no authoring (dispatch nix-package-researcher directly).

2026-07-0330

checking-nix-compat

nicolkrit999/nix

Use this skill when a nix change needs cross-platform or cross-architecture judgment before or after authoring. Trigger phrases include 'will this build on the mac', 'is this safe in a shared module', 'where should this module live', 'does this work on aarch64', 'check cross-platform compat', 'is this Linux-only'. Drives the judge-author-verify loop across nix-compat-checker, nix-config-architect, nix-checker, and nix-debugger. Does NOT cover general authoring with no placement/guard question (use creating-nix-modules instead) or diagnosing a failure unrelated to platform differences (use debugging-nix-failures instead).

2026-07-0330

debugging-nix-failures

nicolkrit999/nix

Use this skill when a nix build, flake check, nixos-rebuild, or darwin-rebuild is failing and needs to be diagnosed and fixed. Trigger phrases include 'the build failed', 'flake check fails', 'nixos-rebuild broke', 'why won't it evaluate', 'fix this nix error', 'option does not exist', 'darwin-rebuild is erroring', 'my rebuild is broken'. Drives the reproduce-diagnose-fix-reverify loop across nix-checker and nix-debugger. Does NOT cover authoring new functionality (use creating-nix-modules instead) or pure style/format sweeps with no build failure (dispatch nix-syntax-linter directly).

2026-07-0330

name

adding-nix-tests

description

Adding Nix Tests

The loop

1. AUTHOR - dispatch nix-test-author with the module or behavior to cover. Its contract for a new test requires all 4 deliverables:

mirrors an existing test's structure (same platform's test layout/style)
a test dir templates/tests/<platform>/test-<name>/ with a scenario .nix file and check-*.sh script(s) (or a nix-tests dir where that pattern applies)
a MANDATORY README at test-<name>-readme.md in that test dir
registration of the new test in templates/tests/run-tests.sh

It also runs just the new test itself to confirm basic behavior before handing off.

2. RUN - dispatch nix-checker to run the FULL templates/tests suite, not just the new test - a new test can break or collide with the existing registry.

3. TRIAGE any failures:

Test itself is wrong or unidiomatic (bad assertion, wrong platform dir, registry mistake) -> back to nix-test-author to fix the test.
Test is correct and exposes a REAL config bug -> dispatch nix-debugger to fix the underlying config. NEVER weaken or delete the test to make it pass - the test's job is to catch this.
After either fix, re-run via nix-checker (step 2) on the full suite, not just the one test.

Loop 2 -> 3 until the suite is green.

Safeguard: after ~4 rounds without convergence, stop and report the remaining issues to the user instead of continuing indefinitely.

Exit condition

Out of scope

Merely running the existing suite with no new test to add - dispatch nix-checker directly instead of this loop.
Authoring non-test config (new modules, options, host wiring) - that's creating-nix-modules.