Skillsmith - part of the stack, used to make the other frameworks and skills. Paul came first though, which shaped Skillsmith due to how well Paul worked out in the architecture and syntaxing. It's been a really solid skill overall. Other than that Paul is far more useful overall, but it's more of a framework than a standard "skill" per say.

MCP tools didn't affect the context window (deffered means not loaded, but available to load). Your biggest consumption point are your skills loadout. Skills load into Claude's system for auto invocation. I'll have to retest if commands are included here in the event Anthropic has updated and changed things, but I make everything framework related as commands for this purpose. This gives invocation powers to the user to choose when tokens get consumed. I'd audit your .claude/skills and see what might be causing the bloat. But going back to mcp, the MCP is very minimal overhead. The tools being deferred means if all tools were loaded in for reference that's how much they'd total, but that never happens - claude just has awareness of the tools at this point and when needs one will load it in and that's when just that tools data loads for claude to see which is once again minimal in comparison to claude making those executions manually.

https://github.com/yvgude/lean-ctx try this out as well - something I'm just exploring, but appears to be valid and useful for context management

Yes, additional tokens is a cost for higher throughput quality. What I mean by this is, the structured ceremony does tax on cost for a gain on better reliability and output. It's not perfect, but in my experience better than not having altogether in the long run. A few things you can do to mitigate, which are practices I do as well: 1 - in your project/state/roadmap add a rule to never run subagents for planning. Instead, default to targeted tool calling. 2 - When claude prompts you for next steps using the [1] Apply Phase XYZ [2] Questions First [3] Pause Here << when you see this, avoid running the slash command. Instead just say 1, 2, or 3 and you can include additional context to this to further instruct claude. 3 - If you're running Opus 1mil context window, try not to exceed past 200k-230k tokens on any single session. Use handoffs and clear the session. Each back and forth resends the entire conversation, caching helps mitigate this but cache expires rather quickly within claude code so it's not always reliable. You can reduce token consumption by upwards to 70% on identical tasks / prompts just by running a handoff and clearing as opposed to continuing through the larger context window. 4 - last thing to consider, and this is something I've learned by experience. Claude conflates the line to token ratio - what it's calling out actually isn't much consumption (the number of lines, etc). If you ask it how many tokens that actually equates to, it might correct itself and say in actually it's not as much as it thought. Does this to me all the time when running my testing. Last thing I want to add is that, I've weighed the pros and cons of less consumption for saving context vs a little more ceremony and structure (at cost of more consumption) for better quality output. I've seen in my own use and experience, with proper session management, that the ceremony is most definitely worth it. The big picture actually saves more consumption long run as it gets far closer / reliable in outputting higher quality the first time around, reducing debugging, remediation, and revision on what you're creating.

Yes! This is great to see. I like to build with Laravel / Intertia / Vue stack on the applications builds (where that stack fits, it's super fun to work in). I did something similar with CARL after hammering best practice research and enterprise / security hardened principles for these technologies. There's also an "audit plan" function that can be activated for any project that slots a step after plan before apply which will audit the plan and remediate it before applying. You can modify the specs of this audit to your liking! Maybe even spin off variations of it for different "types" of projects you are running through PAUL in order to have dialed in audit phases per project. Great feedback, these are just some of my approaches and experience.

@Charles Dove looking into it now!