Agent Toolkit

My coding setup includes more than an assistant executable. It includes how I choose a working method, when I bring in a specialist, what evidence counts as verification, and how a task leaves a checkpoint another session can resume. Those instructions had become useful across projects. I wanted to restore them on a new machine without reconstructing the setup by hand.

Agent Toolkit packages that working system into a public repository. The September 21 release contains 25 enrolled standalone skills, reusable preferences, and entrypoints into a pinned ECC reference library. The project is the distribution and ownership mechanism around those materials. It gives the publisher a reviewable export and gives a receiving machine a preview of the files installation would change.

The original skills and preference document remain the publisher's sources of truth. An explicit enrollment selects which skill directories, preference sections and reference package enter the bundle. Public templates replace machine-specific runbooks and private vault context. Supporting scripts, relative references and license notices travel with the instructions so a copied entrypoint does not lose the material it depends on.

A consumer clone has the resulting public files and a SHA-256 distribution manifest. It does not acquire the private publisher configuration. The two directions have different responsibilities: export decides what can be shared, while installation decides where the reviewed files belong and whether an existing destination can be changed. Keeping those responsibilities separate makes a new-machine setup possible without turning that machine into another publisher.

For a new export, the sync command builds a prospective public copy and presents its diff for review. With required review enabled, publication needs the fingerprint for that same export. A change to the generated bytes after review stops that release. Changes removed by sanitization do not necessarily change the fingerprint. The publisher must also be on the expected branch with a clean checkout and the configured remote.

The automated publisher is configured to check every 15 minutes while its machine and runner are available. It reviews changes before invoking the fingerprint-bound publish command. New skill folders need explicit enrollment, and missing enrolled sources, private-content matches, changed unreviewed binaries, local edits or diverged history stop the flow. This is deliberately a single-publisher system. A scheduled check cannot discover changes on an offline machine.

Retrying a pending commit takes a separate path. It checks commit shape, generated file paths and sensitive-content patterns before pushing, without checking a persisted review fingerprint for that commit. That recovery path therefore has a narrower guarantee than a newly reviewed export. Pattern checks also cannot judge every piece of prose. Narrow enrollment and review of the complete public diff remain necessary, and a fingerprint is not a signature or proof that review found every disclosure.

Installation previews changes unless the apply flag is supplied. Before writing, it verifies the bundle manifest and checks the planned destinations. A differing, unmanaged skill is a conflict. So is a managed instruction block that someone has edited since installation. A conflict discovered later in the plan must not leave the earlier files partially installed.

Global instruction files use a managed block so surrounding personal instructions survive. A local ownership receipt records installed hashes and the previous bytes needed for restoration. Later updates can distinguish a file the toolkit still owns from a local edit that needs reconciliation. Removal uses that same ownership information and preserves locally modified files rather than treating a matching filename as permission to delete them.

This makes updating slightly more deliberate than blindly copying a directory. Receiving machines pull the repository and rerun the installer with their selected targets. If a local change conflicts, it has to be reconciled. The tradeoff is intentional: a portable setup should not erase the work done after its last installation.

I authored the surrounding working system: its preferences, orchestration, task routing, ownership boundaries and integration design. Selected methods from ECC and other projects were adapted into that system. Imported reference material keeps its own authors and licenses. The repository's authorship statement and third-party notices make that distinction explicit.

The ECC collection is available through small entrypoints that retrieve relevant references on demand. Bundling an agent brief does not create a native subagent, and copying a provider's instructions does not recreate its tools. The installer therefore leaves account authentication, native plugins, host permissions and hook trust outside the public bundle. The portable unit is the reviewed instruction and its support files, with runtime dependencies still made explicit.

At the pinned release, GitHub Actions ran the same 23 tests on Windows, macOS and Linux with Node.js 22. All 23 passed on each operating system, followed by distribution verification. The tests cover export determinism, privacy checks, review-bound publication, installation, updates, instruction merging, conflict handling and removal. Publication fixtures use a local bare Git remote to exercise the commit and push path.

Those results establish behavior for the tested filesystem and Git scenarios. They do not show that every copied skill works with every assistant, or that the setup improves coding speed or quality. Provider-specific tool invocation and a realistic before-and-after agent evaluation remain separate checks. The useful outcome so far is narrower and tangible: the working system has a public, inspectable distribution and a tested way to move its files without silently replacing local work.