Zimsterv0.7.2
Zimster

One development workflow for coding agents.

Without the agent sprawl. Zimster combines planning, specifications, TDD, debugging, review, delegation, and verification while keeping one implementation owner responsible for the result.

Keep one agent responsible from request to verified result.

Zimster scales the workflow to the work: lightweight for clear local changes, deeper for consequential design or risky integration, and selective about when another agent is worth using.

See how the workflow is structured →

Install for the coding agent you use.

Zimster 0.7.2 works with Codex, Claude Code, Grok, OpenCode, Pi, Kimi Code, and skills-only setups. You can install it from GitHub or npm now. Host directories may list it on their own schedule.

Codex

Clone the repository, add it as a Git/custom marketplace, then install Zimster.

git clone https://github.com/wazimmerman/zimster.gitcodex plugin marketplace add /absolute/path/to/zimstercodex plugin add zimster@zimster --json
Codex install notes →

Claude Code

Add the GitHub repository as a marketplace and install the Claude package.

claude plugin marketplace add wazimmerman/zimsterclaude plugin install zimster@zimster
Claude Code install notes →

Grok

Extract the portable Agent Plugin ZIP, validate it, then install the local package.

grok plugin validate /absolute/path/to/zimstergrok plugin install /absolute/path/to/zimster --trustgrok plugin details zimster
Grok install notes →

OpenCode

Use the npm package as a package root so the OpenCode adapter and canonical skills stay together, then confirm skill discovery.

opencode debug configopencode debug skill
OpenCode install notes →

Pi

The published zimster npm package is also the Pi package.

pi install npm:zimsterpi list
Pi install notes →

Kimi Code

The npm package and repository include the Kimi plugin manifest and canonical skills.

/plugins install /absolute/path/to/zimster/plugins info zimster/plugins reload
Kimi Code install notes →

A disciplined workflow without unnecessary orchestration.

Zimster keeps the engineering practices that help and applies them in proportion to the task. It does not turn every request into a planning exercise or every change into a multi-agent run.

One owner stays responsible

The main agent keeps the architecture, implementation, and final verification in one continuous line of responsibility.

Design scales with the decision

Clear local work can proceed directly. Consequential product, architecture, UX, security, migration, or public-contract choices get deeper design, and oversized requests can be split into coherent workstreams.

Tests drive implementation

RED-GREEN-REFACTOR is tied to observable behavior. Debugging starts with reproduction and root cause instead of patching symptoms.

Delegation and model routing are separate

Zimster decides whether another agent is useful first. If it delegates, configuration can map roles to model classes and concrete model IDs.

Review matches the risk

Small local changes stay lightweight. Public interfaces, security, migrations, concurrency, and other high-risk work receive stronger independent review.

Long work keeps its place

Git-local run state carries the mission, decisions, current slice, verification records, and next action across compaction or context renewal.

One owner carries the work through the full cycle.

  1. Read the context and classify risk

    Start from the repository, identify the Git disposition, and choose the Micro, Standard, or High-risk workflow that fits the change.

  2. Design when real choices exist

    Resolve consequential choices before coding. For clear, low-risk work, skip the extra design step.

  3. Plan coherent slices

    Keep architecture, dependencies, requirements, and the checks for each slice together instead of expanding the plan into dozens of microtasks.

  4. Implement with TDD and systematic debugging

    The owner drives RED-GREEN-REFACTOR, reproduces defects before fixing them, and keeps the full change in view.

  5. Delegate selectively

    Use scouts, reviewers, diagnosticians, or independent implementation only when the boundary is useful. Model selection happens after that decision.

  6. Verify, review, and finish

    Run the affected checks and review the risky seams. Critical or Important findings get one owner correction and one recheck by the same reviewer. If a load-bearing problem survives, Zimster stops that review cycle and changes strategy instead of looping. Then finish from the evidence and the actual Git state.

The core set

Twelve skills cover the recurring development workflow without assigning a separate persona to every activity.

Using Zimster

Selects the smallest workflow that fits the task and its risk.

Designing Work

Handles consequential choices and decomposes genuinely oversized requests.

Writing Plans

Turns larger work into coherent, testable slices with dependencies intact.

Owner-Driven Development

Keeps one implementation owner responsible from plan through verification.

Test-Driven Development

Uses observable RED-GREEN-REFACTOR for behavior changes.

Parallel Agents

Delegates only work with a useful, independently checkable boundary.

Risk-Adaptive Review

Matches review depth and independence to the risk in the change.

Receiving Code Review

Evaluates feedback before changing the implementation.

Systematic Debugging

Reproduces the problem, isolates the cause, and proves the fix.

Verification Before Completion

Requires current test and verification results before completion.

Git Worktrees

Creates isolated work areas for changes that benefit from separation.

Finishing a Development Branch

Checks the result and hands off a clean, understood branch.

What has been tested

These labels reflect the 0.7.2 release checks. Installation, structural checks, authentication, and model-backed execution are kept separate so the table does not imply more than was tested.

Coding agentTesting statusWhat was checked
Codex 0.147.0 / Desktop 0.147.0-alpha.6.6Live + installed-package verifiedThe Codex ZIP installed and was discovered in both runtimes. The standalone CLI also completed an authenticated smoke. That check did not establish the effective model or reasoning effort.
Claude Code 2.1.226Installed-package verifiedThe Claude ZIP validated and installed with 12 skills, 4 agents, and the SessionStart hook. The model-backed smoke stopped at an expired OAuth session.
Grok 1.0.0Live verifiedThe portable ZIP loaded and completed an authenticated smoke on Grok 1.0.0. The observed model was Grok 4.6.
OpenCode 1.18.18Installed-package verifiedThe npm package exposed the OpenCode adapter and the Zimster skills. The release check did not include a model-backed coding task.
Pi 0.84.1Installed-package verifiedThe npm package loaded on Pi 0.84.1. When Pi cannot enforce Zimster's two-agent limit, delegated work stays with the owner.
Kimi CodeCLI unavailable; structure validatedThe Kimi manifest and skill paths validated, but the Kimi CLI was not available for installation or live execution.

Release files

All files below come directly from the Zimster 0.7.2 Public Beta release on GitHub.

ZIP

Claude package

Claude plugin with agents, hooks, skills, and package helpers.

Download →
ZIP

OpenAI skills bundle

Skills-only package with the 12 skills and their bundled helper runtime.

Download →
ZIP

Portable Agent Plugin

Standards-based portable package for Grok and other compatible Agent Plugin hosts.

Download →
TGZ

npm package

Primary npm package used by Pi and the OpenCode package path.

Download →
TXT

SHA-256 checksums

Checksums for every release artifact.

Download →

Found a problem?

Open an issue with the Zimster version, coding agent and version, and the shortest steps that reproduce the problem.

Open GitHub Issues