Tag
packkit
-
Scaffolding as a native tool an agent can call
I wanted an agent to scaffold a project by calling a typed tool, not by guessing at a CLI. Packkit's MCP server exposes every generator as one tool surface, and adding a language to it is a two line change.
-
The Packkit bugs I only found by using it
A generator can pass every test it has and still write a broken project. The bugs that mattered showed up when I scaffolded real work, and each fix now ships with a test that is proven to fail on the bug.
-
Composing a full stack app from two separate generators
I wanted a React front end and a Python back end in one repo without teaching either generator about the other. The answer was composition, a core primitive that stitches two generated projects and writes a neutral orchestration.
-
A deploy provider should not know what language it is deploying
Packkit generators emit a language-neutral deployment contract. A provider reads that contract and deploys it, and never asks whether a Node, Python, or Go program wrote it.
-
Creating a GitHub repo and pushing one clean commit, from a browser tab
I wanted the browser configurator to create your new repo and push the scaffold as a single clean commit. It worked, after a misleading 404 sent me chasing the wrong bug for a day.
-
Adding a language to Packkit should change nothing in the core
The test of a protocol is a second implementation that forces no change. I added Python, then Go, to Packkit and used the exceptions to find where my abstraction actually leaked.
-
I turned my project scaffolder into a protocol
Packkit started as a tool that wrote a modern JavaScript package for me. The useful part is what it became, a small protocol that lets any language plug in and every surface drive it the same way.