Run a bounded validation loop for current changes: tests, compile/checks, reviewer, verifier, fixes, then repeat until green or capped. Use when user asks to make changes green, run review and verify, 'until everything passes', or prepare a change for final validation.

2026-06-053

zenit-commit-message

FrauH0lle/emacs.d

Draft commit summaries and bodies using this repo's Conventional Commit plus GNU-style file bullet format.

2026-06-043

zenit-module-change

FrauH0lle/emacs.d

Safely modify Zenit modules, autoloads, patches, and core/module boundaries.

2026-06-043

zenit-package-change

FrauH0lle/emacs.d

Handle Zenit package declarations, package updates, and lockfiles.

2026-06-043

name	zenit-test
description	Run and interpret Zenit Emacs tests through the project CLI.
disable-model-invocation	true

Use this skill when the user asks to test Zenit changes, when an Elisp change needs validation, or when choosing between focused and broad checks.

Workflow

Identify the smallest useful test target.
- Core library tests usually live in lisp/core/lib/test/.
- Core integration tests usually live in lisp/core/test/.
- Module tests live under the module's test/*.el directory.
Run a focused file first when one exists:
- bin/emacs-config test -f path/to/test.el
Run the full CI-equivalent suite when the change affects startup, module resolution, package management, CLI behavior, or shared core helpers:
- bin/emacs-config test
Report failures by naming the failed test file/test names and the first actionable condition. Do not fix unrelated failures unless the user asks.

Notes

The test runner starts clean emacs -Q --batch --init-directory=... subprocesses and calls ERT.
Do not use clean --straight, clean --all, sync, or freeze as part of ordinary test validation.
If package or autoload state changed, run bin/emacs-config refresh before tests only when generated state is needed for the behavior under test.