← ClaudeAtlas

kitaru-adapter-builderlisted

Build a project-local Kitaru adapter for an unsupported Python or TypeScript agent framework. Use when a user wants to record or replay framework-native agent runs in Kitaru, needs a custom adapter, has no supported Kitaru integration for their framework, or needs to assess whether public framework hooks and the installed Kitaru SDK can support an adapter.
zenml-io/kitaru-skills · ★ 4 · Web & Frontend · score 70
Install: claude install-skill zenml-io/kitaru-skills
# Kitaru adapter builder Build the smallest honest adapter inside the user's project. Preserve the framework's public entrypoint and report exactly what the adapter can observe, record, replay, and recover from. Do not assume every framework can support the same fidelity. A useful result is either a locally tested adapter or a precise blocker tied to the installed versions and public hooks. ## Core contract - Start with read-only inspection of the user's project and installed packages. - Prefer supported Kitaru adapters, importers, or OTLP export when they meet the requested recording and replay needs. Do not create a duplicate integration. - Treat the user's installed SDK and framework as authority. Use Kitaru reference adapters as patterns, not as source to copy or as proof of a published API. - Use only public framework hooks. Offer a coarser boundary or stop when complete coverage would require private internals. - Implement in the user's project first. Do not edit Kitaru core or prepare an upstream contribution unless the user separately approves that work. - Keep per-run session IDs, clients, node indexes, buffers, replay state, and framework context isolated. Never store invocation state on a shared wrapper. - Treat a partially recorded run as partial or failed evidence. Never call it a complete trace because the application returned successfully. - Treat replay as execution, not a transaction. Block unknown or write-capable side effects unless the se