start-with-why-skillset for agentic workflows

Hello everyone! This is my first post on reddit. This text is NOT generated by AI, I want this post to be authentic 😃 I want to share my skillset that I have recently developed and shortly tested on small tasks and would like to get some feedback on it. **TL;DR**: it is a light-weight skill set that takes (or at least tries to do so) the best from superpower skillset and some ideas from Matt Pocock skills. The idea is to use as little tokens as possible, but have solid workflow that has kinda strict pipeline to follow. It is meant to be used (ideally) in large codebases since I am working C++/Qt/LegacyShit domain. The ideas I took from Matt Pocock: /grill-me alike approach to build **shared understanding** between human and agent, then plan and implement in **vertical slices**, but explore code in layers, **deepen** the layers/modules. I wanted it to be minimal intentionally so it does not blow up the context window. **Now to the long part:** * **WhoAmI**: I am a C++ developer based in Germany. My experience so far is working with legacy code. * **Motivation**: I am working in domain with C++/Qt/Legacy as mentioned before and we need to build local agents and I wanted to develop a skillset that would be useful with mid-size local models like Qwen3-Coder-Next and that would be applicable for my local project that uses modern tools (or not very modern) like FastAPI, Docker, Next.js. I am completely new to this stack, so it is kind of pain for me. But the skillset shall be still applicable to legacy code. * **Background**: I have used Claude Code with superpowers, then a bit of OpenCode mainly with Kimi K2.6 and superpowers and now I switched to Pi agent with GPT5.5 because "less is better" (IMHO). * **WhyPi**: I have watched some videos from Mario Zechner where he explains why he has built Pi. This strongly relates with me and my experiences, so I wanted to check it out. And I like it so far. * **The main problem**: LLMs get "dumb" when context window exceeds 40% of context window (or rather 100k tokens limit). * The problem I see with **superpowers** is that it takes a lot of context window and sometimes the results are unpredictable, also I get lost when I read the spec it generates and also the plan. Although I really like how it feels to work with it, it has strict pipeline and many verification steps in it, which I like. * The problem I see with **Matt Pocock skillset** is that it does not have clear workflow (at least for me) and there are lot of words that I do not understand. It is hard for me to read the output of my agent. Maybe I used it wrong... So I decided to implement my own as a light-weight combination of both. **And yes,** I generated it together with GPT5.5, it turned out interesting. **Important note**: this is not really automated workflow by intent because I want to be part of the process, I do not want to automate everything (at least for now). Also it is a draft version, keep that in mind. **Main characteristics I wanted to put into that skill:** 1. Skillset tries to understand the intention by asking questions, it tries to align with what you expect to see in the end when implementing a feature or fixing a bug and why you want exactly that behaviour (that is why it's called **"start-with-why-skillset"**). I strongly believe that if we provide more information on the intention of any particular change (namely intention and reason for the change/feature), then any LLM will do better. 2. It has strict pipeline to follow either when you try to implement a feature, or when you try to fix a bug. There is a skill to improve codebase architecture, but I have not tested it very much. 3. It has its own kind of task tracking system for what was done. Agent has information about current task and tracks the vertical slices implementation. It also verifies each slice implementation and then does final check. 4. N) I am **too lazy** to explain everything here, just check the repo and ask AI to walk through the files and explain the workflow and its intention 😄 You can find the link in comment section (according to rules I cannot put it in the post itself). You can download and test it. **It is in beta and very raw,** so it is kinda "put-it-manually-to-your-project" and still to be improved one (hopefully). There is also a branch called *"docs/task-lifecycle-structured-state"* with some structural improvement, you can check it out as well. It would be great if you try it out, share your results and provide some feedback (possible improvement points). I have not tested it with sub-agents in Pi yet, because I want to find light-weight sub-agent extension. The ones that exist on Pi's "Packages" page were very token-heavy. In future I want to figure out how to use it with codebase-memory-mcp (link in the comments) plugin, that builds AST graph of the codebase. So far it blowed up my context window but probably because I have not filtered out the spec/plan docs that were generated by superpowers. I would appreciate any feedback on the skillset, in particular: \- how it handles multi-phase tasks that require long sessions \- how well it integrates with your particular setup, but I am interested more in Pi agent \- how well does it work it legacy codebases \- if you are able to integrate it with RAG or any other AST-based memory for codebases, please share experiences Piece!