Selected work

Case study 02 · Rust systems tooling

Tink

A Rust CLI that installs and verifies agent skills inside a project. It pins sources, hashes complete trees with file modes, and stops when the filesystem state is unsafe.

  • Release v1.0.0
  • Targets macOS + Linux · x86_64 + arm64
  • Verified CI + release workflow

01

Problem

Reusable agent skills become risky when they rely on hidden global state or when a refresh can overwrite project-owned work. I wanted a clear lifecycle for discovering, importing, locking, syncing, and verifying complete skill trees.

02

Constraints

  • At runtime, Tink discovers skills only in <project>/.agents/skills. The home library is offline inventory.
  • Imported trees must reject symlinks and special files, preserve safe executable modes, and detect content or mode drift.
  • Project state, library state, catalogs, source receipts, skillset receipts, and lockfiles have different owners.
  • The CLI manages skill artifacts; it does not execute skill code.

03

My decisions

I made project-local state canonical. For GitHub sources, Tink records the full revision and repository-relative path. Lock, sync, and verify use those receipts and tree digests. Receipt classification is a trust boundary: a skillset-owned root cannot be published as an unrelated standalone skill.

The filesystem collector normalizes allowed modes, includes paths and modes in the v2 digest, and rejects symlinked or unsupported entries. Self-update verifies both the release digest and the payload's reported version before replacing the executable.

04

Difficult tradeoffs

For sync, Tink checks every locked skill before publication. It then changes state sequentially so a failed step can be retried. Those changes are not one transaction across the project, library, catalog, receipt, and manifest. Concurrent writers are outside the safety guarantee.

v1 supports macOS and Linux on x86_64 and arm64. It does not promise Windows support, private GitHub authentication, or cross-filesystem rollback.

05

Implementation

The Rust CLI keeps source resolution, tree handling, project publication, manifests, subprocess supervision, and self-update in separate modules. add protects the project target before repairing derived library state. sync checks every locked skill before publishing any of them. Subprocesses run in process groups with cancellation, output limits, and cleanup.

  • OwnershipProject root · home inventory · catalog · receipts
  • IdentityImmutable revisions · relative paths · v2 tree digests
  • SafetySymlink refusal · drift refusal · bounded subprocesses
  • LifecycleAdd · lock · sync · verify · update

06

Verification

A public acceptance contract gives each requirement a stable identifier. Executable tests cover overwrite refusal, explicit skillset membership, bad-hash preflight, updates, cancellation, and other lifecycle boundaries. A traceability test catches missing or duplicate sensors.

CI checks formatting, compilation, Clippy, documentation, native tests, and release builds. The v1.0.0 commit passed CI and the four-target release workflow, which verified the expected archives and SHA-256 digests before publication.

Claim boundary

The release does not establish adoption, a reliability percentage, a general performance SLA, Windows support, private-repository support, concurrent mutation safety, or whole-operation atomicity.

07

Outcome

Tink v1.0.0 is publicly released at commit 2b082b5. It supports project-local discovery, reproducible imports, lock, sync, and verify workflows, unsafe-tree refusals, and verified binary replacement.

Proof

Traceable evidence