Raise your hand if you’ve never assembled IKEA furniture. And what’s your take on those tiny Allen keys they throw in? Good that IKEA provides the tools, but they’re not the best gear for hours of driving screws, are they? I’ve experienced this firsthand and ended up buying a decent toolset.

The Claude Code environment is my professional workbench. And before I walk you through the process I used to build minus-tracker — spec-driven vibe coding, starting next episode — I want to show you the bench I built it on, because that’s where I spent most of my time, before I ever wrote a single line of idea.md.

I’m planning to eventually open-source a sanitized version of my environment as a GitHub repo. Feel free to copy it. But a borrowed workbench never quite fits your hand, so my recommendation is to take inspiration from mine and build your own. What actually matters in this episode isn’t the tool list — it’s understanding why each one hangs where it does, so you can tune it to your own style instead of cloning it verbatim.

Under the hood of my environment lies a process, different from the dev one, aimed at evolving the environment itself and keeping it clean.

Why

Why is the environment so important? To me, the following aspects should convince you, at least when addressing spec-driven vibe coding projects:

• avoiding context rot as much as possible, by loading knowledge only when you really need it and restricting it to the topic you need to address. This is, in my experience, the single most impactful factor;

• avoiding re-inventing the wheel every time. I find myself adding new features to my apps every day, and over time I’ve acquired decent knowledge of the best way to execute a task (e.g. how to create an efficient plan). Building a good skillset in particular, developed with the skill-creator tool, is a great way to bank this knowledge: on your next project, you won’t have to remember every single nuance;

• spec-driven vibe coding and context engineering lead to a workflow divided into steps, independent and decoupled tasks to execute. A good environment configured with skills, commands and subagents is necessary to properly implement such a workflow;

• the community has created a ton of skills and subagents. I’m not personally in favor of just cloning a repo with 1000 subagents or skills and passively using them. I still encourage you to build your own tools, but taking a look at the descriptions of those public repos is extremely valuable for inspiration. I personally reuse a small subset of tools published by someone else, and then build my own.

One last but very important comment about my environment: it’s not static — it evolves over time. And to make that happen, there’s a well-defined process, because I only want to capture the truly relevant things I’ve learned from the past projects. We’re going to start by analyzing how my CLAUDE.md is structured, to understand what I mean by a dynamic environment.

The most important piece: a CLAUDE.md that’s an index, not a wall of rules

If I had to save exactly one tool off this bench, it would be this one.

My global CLAUDE.md (~/.claude/CLAUDE.md, loaded into every single project I work on) is deliberately short. It holds five always-on principles — simplicity first, no laziness, think before coding, surgical changes, low latency even at the expense of elegance — and little else written out in full. Sounds familiar? Well, it’s what Andrej Karpathy said in a post back in January 2026. I’m just copying from the Master (oops, I should probably say learning by imitation here).

Everything else isn’t in the file: it’s indexed by a table that routes to specific reference files depending on the situation:

• Non-trivial task (3+ steps): brainstorming → writing-plans → executing-plans

• Bug report: diagnose (structured repro → instrumentation → fix)

• Feature development: project-rules + tdd (if the spec is solid) or prototype (if exploratory)

• Before a commit: code-review + verify + security-review

• UI changes: prototype or frontend-design

• Git commits: convention lives in project-rules/references/git.md

The actual rulebook (project-rules) is a personal skill with a references/ folder — planning.md, code-quality.md, testing.md, workflow.md, git.md, ui-design.md — and each of those files loads only when it’s needed, not on every session. The root CLAUDE.md never grows unbounded, because it isn’t the thing holding the rules: it’s the map that says where to find them.

One thing worth noting: skills are automatically loaded if Claude Code infers that they are useful to fulfill the assigned task. Still, what I’ve learned from several experts is that explicitly “suggesting” the skill further increases efficiency.

The same philosophy repeats at the project level. The home-level CLAUDE.md contains generic principles applicable to every spec-driven vibe coding project. The project-level one is specialized to the context of that specific project.

The backward loop: the workbench that sharpens itself

A static index is already useful. What makes it genuinely powerful is that it doesn’t stay static.

A dedicated skill, build-insights-logger, records lessons learned during real sessions — not theoretical hunches, but things that actually happened: a pattern that caused the same bug twice, a shortcut that worked better than expected, a wrong assumption that cost real time. My own global CLAUDE.md includes a “self-improvement” section reminding me to check that log on a weekly cadence and, when a recurring pattern shows up, to fold it back into CLAUDE.md or the reference files it indexes.

It’s a literal backward loop: sessions produce insights, insights get reviewed weekly, the review rewrites the index that will guide future sessions. The workbench isn’t something you set up once and use forever — it’s something that reorganizes itself, a bit at a time, based on what you actually built on it, not what you assumed on day one you’d need. Of everything in this episode, if I had to point you to one thing to replicate first, it’s this: don’t write your CLAUDE.md once and call it done. Build the mechanism that keeps it current.

The tool pegboard: plugins and skills

My environment has a pegboard of third-party plugins, pulled down depending on the task. The most used is superpowers — it brings skills like brainstorming, systematic-debugging, and subagent-driven-development, and it’s designed to work alongside the project’s own command pipeline, not instead of it: the pipeline runs the actual spec-first flow (idea → PRD → test plan → impl plan → execution → verification), and superpowers‘ commands step in inside individual phases — stress-testing a plan before executing it, for instance, or debugging systematically when something breaks.

The rest of the pegboard stays hung up until it’s needed: tools for simplifying code after a refactor, for interface design, for handling Office documents or PDFs, for creating new skills, for autonomous loops on repetitive tasks, for dedicated code review, for browser automation during testing. None of these is “always on” — it’s the same indexing logic applied to tools: hung in an orderly row, pulled down only when the specific task calls for it.

If you want a data point instead of a vibe: I went back through this project’s actual session logs and counted which skills I invoked most while building minus-tracker. Here are the top 5, by raw invocation count:

• brainstorming (superpowers): Explores requirements, intent, and design options before any implementation starts — mandatory before creative or feature work.

• executing-plans (superpowers): Runs a written implementation plan step by step, with review checkpoints along the way, often in a separate session from the one that wrote it.

• claude-in-chrome (native, not a plugin): Drives an actual Chrome browser — clicking, filling forms, screenshots, reading console/network logs — for testing and browser-based tasks.

• writing-plans (superpowers): Turns a spec or a set of requirements into a concrete, written implementation plan, before any code gets touched.

• subagent-driven-development (superpowers): Delegates independent tasks from a plan to standalone subagents, each with a clear context, executed within the same session.

The six commands that drive the pipeline (names only, for now)

The private orchestration repo behind minus-tracker has six custom slash commands, one per stage of the spec-first pipeline: /spec_brainstorm, /spec_review, /write_test_plan, /write_impl_plan, /do_impl_plan, /run_test_plan. I’m naming them here purely for the workbench’s completeness — what each one actually does, and how they fit together, is next episode’s content. This specific workflow is hugely inspired by N

athan Onn (I can’t help thanking him for his great blog!) and is a pure context engineering implementation. As you will see in the next episodes, I’ve slightly revised his work, according to my needs.

The workflow is deterministic, we never change the phase order. Thereby, it would not make any sense to transform these commands into skills. Commands trigger tasks that are accomplished by delegating to subagents or by loading skills. This concept is important to understand how each piece fit in the puzzle.

Parallelize everything: subagents, agent view, and workflows

One principle from my CLAUDE.md I haven’t mentioned yet: parallelize as much as possible. It didn’t make the five headline principles — it lives one level down, in the workflow.md reference file inside project-rules, the same skill already indexed by the routing table earlier in this piece. Which is, again, the whole point of an index: the rule is there, it just isn’t cluttering the top.

The reasoning behind it is simple. A single conversation has one context window, and every search result, log, or file I read into it is space I can’t spend on the actual problem. Subagents are the first lever — workers Claude spawns inside the same session to handle a side task in their own context and report back only a summary. Pulling real numbers from this project’s session logs, my most-used subagent type by a wide margin is Explore (38 invocations, read-only codebase search, so I don’t pollute my own context with the search itself), followed by general-purpose (17, for heavier multi-step delegation) and Plan (5, when I want an architecture proposal weighed before committing to one).

Subagents cover a lot, but not everything. When I have several genuinely independent things going and want to hand them off instead of babysitting one conversation, I reach for agent view — one screen, opened with claude agents, that dispatches and monitors background sessions so I can check status at a glance and step in only when one actually needs me. And when a job is too large to coordinate turn by turn — a codebase-wide audit, a big migration, research that needs cross-checking — dynamic workflows move the plan itself into a script: Claude writes it, a runtime runs it in the background, and I get one synthesized result instead of a turn-by-turn transcript. My own CLAUDE.md is deliberately conservative about that last one: never launch a workflow unprompted, always propose it explicitly with a rough cost estimate first, and wait for the go-ahead. More hands on the bench is only worth it when I actually need them.

Small ergonomics: hooks and permissions

A few minor details round out the bench. A hook runs every file edit through prettier automatically, so I never end a session cleaning up inconsistent formatting; another plays a short sound when Claude finishes a turn, so I can step away during a long task without checking every thirty seconds. I also lean on remote control to hand a running session off to my phone when I need to step away mid-task but still want to check progress or approve a step.

Trust follows the same logic. The project’s .claude/settings.local.json isn’t “allow everything” granted up front — it’s an allowlist grown incrementally, pattern by pattern (Bash(npm test *), Bash(git diff *), WebFetch(domain:github.com)), never a blanket “allow all shell commands.” A broader, global sandbox configuration backs it up, constraining filesystem and network access even before a specific permission is granted. Trust grows with evidence, not before.

Build your own workbench

A good craftsman doesn’t spend most of their time on the material — they spend it on the bench, before ever touching it. This episode isn’t the complete list of every single tool I own — it’s the logic behind how I chose and organized them: an index instead of a wall of text, a loop that rewrites it on its own instead of a static file, permissions earned instead of granted in bulk. Copy them verbatim to get started if you want, but the point isn’t replicating my exact bench — it’s understanding why it’s built this way, and tuning it to your own style.

Rome wasn’t built in a day. It took me three months to fully set up everything I described here, and it keeps evolving. My last hint: learn by doing. Start with a basic environment setup, maybe with just one or two of the features mentioned above. Build your first project. You’ll have plenty of time to upgrade your config, no worries!

Next episode goes into the actual pipeline: how a 15-part spec translates Italian tax law into requirements an agent can implement without inventing anything along the way. Subscribe if you want the rest of it.

I still remember my accountant’s face the first time I handed him a brokerage statement — in English, every line item in dollars, from a US broker he’d never heard of. He flipped through it twice, looked up, and asked me for one more week to go through it.

That statement existed because of restricted stock units. I’d worked at Hewlett-Packard Enterprise, then moved to Google, and RSUs had been quietly vesting into a US brokerage account the whole time — grants nobody ever asked me to think about, because that’s the point of RSUs: you get equity, you wait, it shows up. I wasn’t interested in personal finance back then. I just let it sit.

That changed in 2023. I started reading — books, Italian finance writers (The Bull, Mr. RIP, Paolo Coletti, Pietro Michelangeli, if you want good sources), the whole rabbit hole — and one of the first things I did with that new knowledge was sell most of the RSUs and diversify into plain, boring, cap-weighted ETFs. Sensible. Except a US broker account isn’t an Italian Regime Amministrato account, where the bank withholds and reports gains for you automatically. Mine falls under Regime Dichiarativo: I calculate, I declare, I’m the one on the hook if I get it wrong. My accountant’s hesitation wasn’t a personal failing — foreign multi-currency brokers under Regime Dichiarativo are a genuine niche inside Italian tax prep, and niche means nobody’s built decent tooling for it. Which meant it was on me.

So I learned Quadro RT, RM, RW — the forms, and the specific arithmetic Italian law actually requires, most of which no general-purpose brokerage tool respects:

• LIFO, not FIFO — the last lot bought is the first one sold, by law, regardless of what your broker’s own report defaults to.

• The ECB reference rate on the exact trade date (±3 business days) — not a monthly average, not “today’s rate.”

• Two tax buckets that can’t touch each other — ETF gains (Art. 44 TUIR) and stock gains/losses (Art. 67 TUIR) are calculated and reported separately; a stock loss can’t offset an ETF gain.

By 2025 I could fill in RT/RM/RW by hand, from a spreadsheet, in an afternoon. It wasn’t a good use of an afternoon — and it’s also roughly when I started paying real attention to vibe coding.

Personal finance was the excuse, not the point

I founded a startup in 2012. I’ve been a builder for a long time, with a stubbornly pragmatic streak — when something new shows up, I want my hands on it, not just an opinion about it. When the whole vibe-coding trend broke out, I wanted in, past the headlines, actually building something.

Here’s the part I didn’t expect going in: personal finance wasn’t the reason I started this project. It was the vehicle. Getting genuinely good at vibe coding was the actual goal, and I needed a subject I already loved enough to stay obsessed with for months, not weeks — because that’s roughly how long a real side project takes before it’s real. It could have been almost anything. I picked the thing I’d already spent two years reading books and following Italian finance writers about, because obsession is the only fuel that survives week six.

That project has a name: minus-tracker — a CLI that turns a DEGIRO export into LIFO-matched, ECB-converted, correctly-bucketed capital gains, ready for Quadro RT/RM. Source is on GitHub; the package itself is on npm.

This is what this series is about: reporting the evolution of my journey into spec-driven vibe coding and context engineering. The adopted workflow, the skills, the subagents, the environment setup, everything that can be useful if you want to go down a similar path, with one important call out before starting: studying is important, but in the end you need to start building from day 0.

It takes a (fool-proof) workflow to remain sane

I don’t have one clean story about the moment doubt kicked in — if I’m honest, there wasn’t a single night or a single bug I can point to. What there was, instead, was a slow accumulation: weeks of prompting without a plan, watching Claude Code produce code that ran fine in isolation and fought everything around it — a new file for every new idea instead of extending what already existed, logic quietly duplicated in two or three places because nothing forced it to reuse what it had already built. No single moment stung. It was death by a thousand small rewrites, and it took me longer than I’d like to admit to notice the pattern instead of just patching around it each time.

I went looking for a better process, and what actually clicked for me was Nathan Onn’s writing (nathanonn.com) on structured, spec-driven ways of working with coding agents — worth a read if you’re hitting the same wall. What I built from that, over the following weeks, was a six-stage pipeline that treats writing software the way I’d treat filling out a tax form: get the requirements exactly right before you touch a single number.

idea.md & PRD.md — Requirements pinned down to the letter, before a single line of code.

test_plan.md & impl_plan.md — The map, drawn before the code.

execute — One focused sub-agent per task, grouped into dependency waves (~18% context used per task).

verify — One sub-agent at a time, up to 3 automatic fix cycles per failing test.

The execution step changed things the most. Every task runs in its own sub-agent, with a clean context — it never has to “remember” the whole project, just its one task and the interfaces it has to respect. Per my own setup notes, that’s roughly a third of what a single agent burns trying to hold the entire project in its head (~56%). Narrower context, fewer contradictions between pieces, and when something breaks I know exactly which task touched it.

The bar wasn’t “it runs” — it was “it’s legally correct”

Getting the code to execute was never the hard requirement. Getting it right under Italian law was. Every calculation rule — LIFO matching, the four-year loss-carryforward window, the split between the two tax buckets — is validated against the Agenzia delle Entrate’s own FAQ scenarios, not against expectations I wrote myself based on how I assumed the law worked. Twelve of those scenarios map one-to-one to official FAQ examples, accounting for 61 of the suite’s 506 test cases. One of them, worked in full:

        Units   Price/unit   Date         Fees
BUY     10      €100.00      2024-01-02   €2.00
SELL    10      €150.00      2024-06-03   €2.00

Result: a taxable gain of €496.00, fees allocated per lot, down to the cent — not an approximation.

That kind of precision didn’t show up in one sitting. It came together in stages, each version doing one thing. Grounding the software behavior to legal documentation and dedicating a significant amount of time to create a simulation environment to test it out alongside the software itself is, to me, mandatory to ensure vibe-coding is not producing crappy software.

Three and a half weeks, four versions

Version   Shipped        What it added
v0.5.0    Jun 16, 2026   Core: DEGIRO parser, LIFO/FIFO calculator, multi-currency via ECB rates, CLI
v0.6.0    Jun 29, 2026   Two-bucket tax classification, OpenFIGI lookup, 4-year carryforward
v0.7.0    Jul 3, 2026    Modello Redditi PF export (Quadro RT/RM)
v0.8.0    Jul 5, 2026    Stateless classification mode + minus-tracker-mcp server, for AI agents

Three and a half weeks, June 13 to July 5, from an empty repository to a package on npm with 506 passing tests. It’s public today, MIT-licensed, zero runtime dependencies in the core library.

It wasn’t flawless. A few hours after v0.8.0 shipped, I turned the same adversarial instinct I’d used to build the thing loose on the finished product — and it found seven real bugs, one of them with actual tax consequences if you’d hit it on the wrong trade. Full repro, root cause, and the same-day fix are Episode 8. For now: it happened, it got fixed before the day was over, and I’ll walk through exactly how later in the series.

What I’d actually like from you

I don’t think minus-tracker’s ceiling is “a CLI that fills in Quadro RT.” It’s the first capstone in what I’d like to grow into a broader personal finance toolkit — no promises on scope or timeline on that front. What exists right now is real, free, and on npm, and I’d genuinely like people to run it against their own portfolio and tell me what breaks:

npx @gabrielerandelli/minus-tracker

Your trades and results never leave your machine — the one optional network call sends ISIN codes, not amounts or account details, to classify instrument types, and even that’s skippable with --offline.

It’s a calculation aid, not tax advice — mine or the tool’s — so treat anything with real money behind it accordingly. But if you have a DEGIRO export, a multi-currency mess, or an RSU sale you never quite trusted your own math on, try it and reply with what you find.

Next tax season, I’ll walk into it with Quadro RT, RM, and RW already filled in — done myself, start to finish, with the tool I built for exactly that. That’s not a knock on what my accountant does; a niche, multi-currency Regime Dichiarativo filing like mine was never going to be where a general practice adds the most value, and that’s fine. It’s just that AI made it possible for me to close that gap myself, on my own numbers, instead of handing off a statement I couldn’t fully explain myself. That’s the part of “vibe coding” nobody puts in the tweet.

What’s Next

This is a 9-part series. Next up: the environment itself — the actual Claude Code setup, the skills, and the CLAUDE.md files behind everything above. Creating an efficient environment is where I spent most of my time and, in my opinion, the best favor I can do for you is to address this part before the workflow description. Subscribe if you want the rest of it.

Resources

In my constant interleaving between studying and executing, as you may imagine, not everything was built from scratch. It’s worth crediting those who have influenced me in this journey and to leave here some resources that, trust me, can accelerate your learning:

• Workflow and Context Engineering: Nathan Onn

• Agent Skills: Addy Osmani

• Loop Engineering: Shubham Saboo

• Knowledge Base: Andrej Karpathy

• SDLC: Giovanni Galloro

• Agents CLI: Elia Secchi & Pier Paolo Ippolito