Stackr

problem

I was assembling context for a planning conversation by opening files one at a time and pasting them in order, often enough that it started to grate.

Planning a change or arguing about architecture still wants a chat with the right files in front of it. The context is the input, and building it was the tedious part.

tracks

A track is a named working set. Fix Session Timeout and Refactor Auth each keep their own staged list and swap on one keystroke, so the context for one piece of work survives while you go and do another.

Copying a track emits an ASCII directory tree followed by the file contents, which gives the model the shape of the codebase before it reads any of it. Estimated token counts update as the stack changes, per file and for the whole track, and a file turns amber above 5,000 and red above 10,000. Tracks survive a restart of VS Code.

runtime

The feature runs inside someone else's editor, which makes the runtime itself part of the problem.

The extension carries no runtime dependencies. Everything runs against the VS Code API and the Node standard library, with esbuild bundling and every other package sitting in devDependencies.

For code loaded into someone else's editor the dependency tree is the risk surface, so removing it beats auditing it.

Every pull request runs the tests on Ubuntu, macOS, and Windows. A version tag runs them again and, once they pass, publishes to the VS Code Marketplace and Open VSX and attaches the package to a GitHub release.

The other constraint is the extension host, which is shared and single threaded. Building the tree for a large stack would block it, so the tree builder works in chunks of 500 files and yields between them. Cleaning deleted files out of every track yields on time instead, whenever 16 milliseconds have passed.