There's a feeling everyone working with AI agents is talking about right now, and it goes something like this: "I'm a monkey that hits enter all the time. I don't even know what's going on."
I feel it too. I'm juggling a few projects, with several features in each, and some of those features are big and long. Two things kept wearing me down.
The first was overload. Following the work meant reading in the terminal, scrolling back, reading again. That alone became a real overhead.
The second was worse. Once a feature was ready, or a plan was about to be executed, I wasn't confident I could answer the simplest question about it: "So, how does it work?" If I were in an office and a manager or a colleague asked me that, would I be confident enough to answer?
The usual fix is to read the plan more carefully. Review it, have it reviewed, approve it, and get back to hitting enter. An approved plan feels like an understood plan.
It isn't. I had a plan that went through five rounds of decisions and two architecture reviews. I approved it. It still hid two design problems, and the reviews didn't find them. A quiz did.
Nodding at a plan doesn't find the problems. Having to explain it does.
This post is about the two skills I built to unclutter my mind: one for making decisions without drowning in the terminal, and one for checking that I actually know what's being built. Both are open source, and both are meant to be bent to your own flow.
The Decisions Page: Getting Decisions Out of the Terminal
Every feature plan comes with decisions waiting on me. In a terminal they show up as one long list, and answering means scrolling up and down to match my reply to the right point.
decisions-page turns that list into a page. Every question gets plain context, a short example story when the trade-off is abstract, the options, my recommended option with the reason for it, and a box for notes. I reply point by point, close to the point, and the answers save as I type. When I'm done, Claude reads them back, logs them and acts on them.
The page is a Claude artifact: a private web page hosted on claude.ai. That means I don't have to answer it where it was made. I can answer from my phone.
One of them was created on my computer and had 30+ items. So I took a break, went out to the balcony, sat down with a cup of coffee, and went through it there. A change of atmosphere, and I tackled it fresh.
Thirty decisions in a terminal is a wall of text. On a page, with the context next to every choice, it's a coffee break.
The Quiz: Can You Answer "So, How Does It Work?"
quiz-plan reads a feature plan and turns it into a quiz about what's going to be built: what the user will see, where the data lives, what keeps it safe, how it gets built and released. Every answer explains itself the moment you pick it, with links to the part of the plan it comes from. Every question has a box to ask something, flag something, or change something. At the end you get a grade and a map of the areas you know well versus the ones worth a re-read.
It isn't an exam to pass. The explanations are the point. Reading why an answer is right is exactly when you notice what's wrong. Sometimes you understand, through the questions, that something's off in the plan itself.
The Plan I'd Already Approved
Here's what that looks like in practice.
Before building a feature for Pregni, I ran /quiz-plan on the plan. That plan had already been through five rounds of decision pages and two architecture reviews, and I'd approved it. The skill turned it into a 31-question quiz. I scored 22.
Two of the explanations stopped me.
The first was about a crash risk. The repo root and the mobile app ran different React versions, so any shared component using hooks could crash. The plan included a test for it, and its answer was "test it, and ask if it fails." Reading that, I realised the fix wasn't a better test. It was not having two versions.
The second was about the next feature. The explanation walked through what a second feature would have to add to the new shared library, and it showed the library was organised per feature. The next feature wanting private photos would set it all up again. I changed it to reusable flows: the library ships "private documents" or "public avatar" once, and each feature picks one and overrides what it needs.
Both changes went into the plan that day, before any code existed.
In the build, removing ten unused packages left exactly one React in the app, checked on iOS and Android. The library shipped as flows, and an existing upload moved onto it without a single test assertion changing.
Five rounds of decisions. Two architecture reviews. My own approval. And two design problems sat in the plan the whole time. Reviewing it didn't surface them. Having to explain it did.
"Isn't That Spying on People?"
The obvious worry with a quiz is that it's a way to check up on people.
I built it for my own confidence. That's where it started.
A company can decide to make it part of its flow. You could add it to a CI pipeline (the automated checks every pull request runs through) and show it before a PR is merged, so you know the stakeholders understand what's about to ship. A company running a swarm of AI agents with human checkpoints could make it one of those checkpoints.
Some people might feel watched. But the idea is accountability and ownership, and communicating that properly is management's job. I'm putting the skill out there. How people use it is their call.
The other pushback: if you need a quiz to understand your own plan, haven't you handed too much to the AI? The pain is there, and everyone's feeling it. The quiz is there so you can be confident in what you're doing. If you write code no one ever checks, where's the joy?
Make It Yours
Both skills are generic on purpose. The first time you run one in a project, it asks a few questions: where your plans live, which files make up a plan, where you log decisions (if anywhere), and which ticket tracker you use. It saves the answers in the project and fits itself to your flow from then on.
Then bend it further. People care about different things in a quiz like this, so make several: a DevOps quiz, a product quiz, a frontend quiz, a team lead quiz. One quiz per role deserves a post of its own, and so does why AI-written quizzes give the answer away.
Who's this for? Anyone using Claude Code, from a developer to a founder. On a different tool, the ideas carry over with some tweaks. If you want something that runs unchanged outside Claude Code, this isn't it.
So What Do I Do Next?
Take it for a spin. Grab the skills from github.com/sashka-ltd/skills, run the quiz on the next plan you're about to approve, answer its setup questions, and see how it feels. Then adjust it to your own flow.
You'll know it's working when someone asks "so, how does it work?" and you're confident in the answer.
