Stackr

problem

Some work is not agent work. Planning a change or arguing about architecture wants a chat with the right files in front of it, and assembling that by hand means opening each one and pasting it in order.

The context is the input, and building it was the tedious part.

tracks

A track is a named working set. Bug Fix #123 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. Token counts update as the stack changes, amber above 5,000 and red above 10,000.

runtime

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.

The other constraint is the extension host, which is shared and single threaded. Building an ASCII tree from a large stack would block it, so the tree builder works in chunks of 500 files and yields between them. Batch deletions use the same pattern. Neither is a general performance concern. Both are specific to running inside an editor you do not own.