I’ll be the first to admit I’m not some stellar coder. I’ve spent years building automation systems and internal applications for security teams, I’ve worked in and led (small) AppSec programs, but I’ve never been a full-time software developer. I’m probably closer to a “vibe coder” than anything else, though I do understand the principles and workflows needed to make decent software. Well, “decent” is relative I suppose… At minimum, software where security isn’t an afterthought, which tends to align with good coding practices more often than not.
With that caveat out of the way: I’ve been working on a plugin called KitTools. It’s designed to help coding agents work more effectively in your codebase, understand it better, and maintain running “context documentation” that stays human-readable.
This project basically spawned from a Sublime notepad where I kept a collection of reusable prompts. I’d copy and paste them to start sessions, create documentation, and close sessions out. Basically tasks I was running over and over again. Prompts like “act like a salty engineer and tear this project apart.”
Then I discovered Claude skills. Game changer, right? Run the /skill command and no more copy-pasta. Pretty neat.
At the same time, I was also maintaining a mess of markdown files under a directory I called /dev_tools. These files contained write-ups of architecture decisions, what features did what, random to-do lists with phases of work that hadn’t been completed, things like that. It was basically an unorganized repository of knowledge about whatever codebase I was working on. I’d have Claude read the directory on startup, then update any changes when closing out the session. It was way more efficient than having Claude explore the entire codebase before each session. And let’s be honest, once a codebase gets large enough, there’s no way you can start every session with Claude exploring the whole thing without causing problems. Context windows fill up and then shit goes sideways.
My little system was working for most of my projects, but it was sloppy. It required me remembering to run a bunch of skills in the correct order to keep everything synced. Not great.
Then a buddy sent me this video from @IndyDevDan (great channel, would definitely recommend giving them a follow). The video was a primer on using Claude’s hook system to get coding agents to do self-validation after implementing a feature. By the end, I was thinking about my /dev_tools framework differently. Why wasn’t I using hooks for things like auto-updating documentation after finishing a new feature or phase of work?
That video basically gave rise to KitTools. Once I started with hooks, new ideas for automations and workflow improvements just started flowing out. I formalized all the documentation templates so the plugin could be used across multiple projects. I added /commands to set up the framework easily, instead of my previous approach of copying and pasting an entire folder structure from a blank “project” template into each new one.
<start-ai-generated-project-summary>
What KitTools Actually Does
KitTools is a documentation framework designed specifically to be an entry
point that helps coding agents work more effectively in your codebase.
It's the first thing Claude interacts with when starting a session and the
last thing it updates when closing out.
The core concept is maintaining structured context that both humans and AI
can read and use. Instead of letting your agent fumble around trying to
understand your project each time, KitTools gives it a map.
Here's what that looks like in practice
Feature Mapping. Each feature in your project gets documented with what it
does, its dependencies, architecture decisions, and relevant infrastructure
details. When Claude needs to touch a feature, it knows what it's working
with before writing a single line of code.
Session Management. Hooks handle the repetitive stuff automatically. When
you start a session, Claude loads the current state of your project
documentation. When you close out, it updates anything that changed. No
more remembering to run five different commands in the right order.
Living Documentation. The docs evolve with your code. Finished a new
feature? The documentation updates to reflect it. Made an architecture
change? It gets captured. This isn't documentation you write once and
forget. It's documentation that stays useful because it stays current.
Portable Structure. The framework is designed to drop into any project.
Set it up once with a command, and you've got a consistent structure for
context management across all your work.
Who This Is For
If you're a solo developer or small team using AI coding agents and you've
felt the pain of context loss between sessions, KitTools might help. If
you've ever had Claude confidently break something because it didn't
understand how a feature connected to everything else, this is built to
prevent that.
It's not magic. It's just structured documentation with automation to keep
it maintained. But that structure makes a real difference when you're trying
to move fast without breaking things.
</end-ai-generated-project-summary>
Anywho, check out the docs here to go more in depth on the plugin’s usage or to use the project yourself (git links are also there). Hope you find it helpful!