29 skills cover a six-stage engineering loop
Viserys organizes agent work as DEFINE, PLAN, BUILD, VERIFY, REVIEW, and SHIP. Its 29 skills cover requirements interviews, specifications, schema design, incremental implementation, debugging, testing, security, performance, documentation, and release work. Seven persona prompts provide narrower viewpoints such as planner, reviewer, security analyst, tester, UI reviewer, performance specialist, and documentation reviewer. The files are instructions and validators rather than an agent runtime.
The command layer turns recurring workflows into 13 entry points. /spec, /plan, /build, /test, /review, and /ship form the main route, while commands for PRDs, schemas, task files, design, constraints, simplification, and web performance cover narrower jobs. The contracts include useful boundaries: planning is read-only before approval, review does not edit by default, and shipping must return a GO or NO-GO decision with a rollback plan.
Claude Code gets the fullest adapter
The Claude Code path has a plugin manifest, two command directories, 7 personas, and an optional SessionStart hook. Installation from a checkout uses Claude's plugin validation, marketplace-add, and user-scope install commands. The repository's one CI workflow exercises that installation flow. Bash and jq are needed only for the optional hook, so the core skills and commands can still load without automatic context injection.
Other hosts receive thinner mappings. OpenCode has a primary viserys agent and one project command, but its root personas do not become subagents automatically. Gemini CLI and Antigravity each get 13 command adapters whose filenames and descriptions are checked for parity. Their runtime installation and persona dispatch have not been verified end to end. OMP uses copied or linked folders, while Codex exposes the skills directory through a plugin manifest.
What happened when we ran it
Our lab found the runnable npm project under evals/fixtures/ci-cd-and-automation/, not at the repository root. At commit 5ce22dc, npm completed in 8 seconds, installed 0 packages, and left 1 MB on disk. The whole checkout contained 222 files, about 3,921 lines of source, and occupied 1 MB. It had 1 CI workflow, no Dockerfile, and a tests directory.
There was no build script or target, so the build step was skipped. Node's test runner completed in 6 seconds with 1 test passed and 0 failed. Npm audit reported 0 known vulnerabilities across all listed severity levels. These results describe the small fixture selected by the harness. They do not establish that every skill routes correctly, that a plugin installs in each host, or that the personas improve a real coding task.
Structural checks stop at consistency
Viserys has scripts for skill frontmatter, command parity, persona references, artifact paths, links, and version consistency. A deterministic routing tier ranks skill descriptions against positive and negative prompts using a lexical method. The eval documentation calls that method an approximation and reserves behavioral evaluation for headless agent runs that create artifacts in throwaway repositories and spend model tokens. That distinction is unusually clear.
The limitation matters because a tidy skill file can still produce poor work. Structural validation can catch a missing command, broken path, or colliding description. It cannot prove that /review spots a security bug or that /build follows a specification under pressure. The behavioral tier is designed for those questions, but it needs the external agent harness, permissions, timeouts, and a grader. Users should run the cases for the skills they plan to trust.
Codex support ends at the skills manifest
The .codex-plugin/plugin.json file registers the shared skills/ directory and identifies version 0.1.0. The installation guide says there is no native Viserys command catalog, primary-agent adapter, verified persona orchestration, or repository-specific installer for Codex. A Codex user can distribute the skills through the host's plugin mechanism, but should not expect /ship to summon the documented reviewer fan-out automatically.
That gap changes the product. Viserys's strongest ideas involve handoffs, independent review perspectives, approval points, and a final merge of reports. Loading individual skills preserves the written workflow, while losing some orchestration around it. Teams using a thinner adapter should start with one direct skill invocation, inspect the resulting file changes, and verify which approval and delegation behavior the host actually honors.
September activity shows a new project, not a track record
GitHub showed 556 stars and 1 open pull request on October 3, 2026. The repository was created September 12 and last pushed September 21. There is no tagged GitHub release, while both plugin manifests identify version 0.1.0. The sole open pull request fixes a documentation anchor. Those facts show recent attention and very little history for judging upgrade stability or maintainer response.
Apache-2.0 licensing makes the instruction files easy to inspect and adapt, with upstream attribution retained for the design material. The support matrix is the best reason to take Viserys seriously: it separates available files, structural checks, and runtime proof instead of merging them into one compatibility claim. Use that same standard during adoption. The Claude path deserves the first trial; the other hosts need narrower expectations.