What it does
ask-eddy tells you which skill to reach for. You describe the situation you’re in — a foggy idea, a bug that won’t reproduce, a codebase that’s drifting — and it names the skill that fits and why.
It routes, it does not do. Nothing about your repo changes when you run it; the only output is a recommendation and the reason behind it. That constraint is what lets it stay cheap enough to run whenever you’re unsure.
When to reach for it
- Invocation mode. You invoke this by typing
/ask-eddy— the agent won’t reach for it on its own. - Trigger boundary. Reach for this when you know you have work to do but not which skill owns it. If you already know the skill, skip the router and type that skill directly.
The map, not the menu
The value isn’t the list of skills — npx skills and the repo README already give you that. It’s the shape: which skills sit on the main flow from idea to shipped, which are on-ramps that merge onto it from a different starting situation, which run underneath as vocabulary, and which are genuinely standalone.
A menu makes you compare N options. A map tells you where you already are, so there’s usually only one next step. That’s the cognitive load this skill exists to remove.
It’s working if
- It names one skill, not three, and gives a because-clause.
- It tells you plainly when your situation matches nothing in the repo, instead of bending the closest skill to fit.
- Nothing in your working tree changed.
Where it fits
ask-eddy is the index over everything else — a reach-for-it-anytime standalone that sits above the flows rather than inside one. Every other docs page links back here rather than redrawing the graph, which means this page is the one place the whole system is described at once.
Its neighbours are whichever skills currently sit at the head of a flow, because those are what it most often routes you to.