An agent picking up a task cannot tell a one-line fix from a migration that touches money. Both arrive as the same JSON, and it chooses how hard to think by whatever was set in its session half an hour ago for something else. Cheap work eats the ceiling; expensive work gets done carelessly - and the second is much more expensive than the first.
Effort describes the work, not the model
A task can carry an effort: trivial, routine, involved or intricate. The words describe a property of the work ("this has a lot of connections"), never a tier of a client. That is deliberate - high and xhigh are Claude Code's vocabulary, Codex has different ones, and a person has none at all. A task can perfectly well be picked up by a person.
A task with no effort of its own inherits its epic's. Empty is a real answer, not a setting somebody forgot: nothing here invents a level for work nobody has judged.
What makermap can and cannot do
It cannot change how your agent reasons. No tool here switches a reasoning level, and a design that pretended otherwise would be a lie in the API. What it does instead:
- the level travels with the task, so it arrives at the moment work is picked up;
get_effort_profile translates makermap's four levels into your client's tier names, and that mapping is workspace data - a client we have never heard of is configured in a minute, without waiting for us to ship anything;- the one form of compliance that needs nobody: an agent below the recommended level can delegate to a subagent started at it.
On plans that include the Intelligence Layer, a task also carries a recommendation with its reasons - a decision blocking it, a deadline close by, a database nobody may touch. It is computed every time you read it and stored nowhere, so it moves when the situation moves. It never recommends trivial: nothing in the data separates mechanical work from ordinary work, and inventing that from an absence of evidence is the one mistake here that costs something real.
When the work is done, an agent reports what it actually ran at. That report is stored with its name on it and never overwrites what the task says - the disagreement between the two is the useful part, and it is readable.
Shipped skills, and how you extend them
makermap ships a small library of skills and rules that explain how to work here. They are code, not rows in your workspace: nobody owns them, nobody edits them, and they update when the product updates. That last part is what the design is for. A copy in every workspace would drift from ours the day one of them is corrected, and six months later everyone would have their own stale version - while it looked like a working feature the whole time.
So you extend one instead of editing it. Your addition is composed after the shipped text and stays marked as yours; the shipped half keeps updating underneath it. You can switch one off in your workspace, and you cannot delete it - there is nothing to delete, and a "deleted" one would come back with the next deploy looking like a bug.
If the shipped text changes after you wrote your addition, makermap tells you - not your agent. Your text is still applied in full: we do not know what you meant, and an addition usually outlives the paragraph it was written against. It is a note that the ground moved, never a claim that you are wrong, and it clears when you save.
When our skill simply does not fit, you can fork it into an ordinary asset of your own. That is allowed on purpose - sometimes you need a different skill, not an addition to ours. What is not allowed is forking without being told what you lose, so makermap says it at the moment you do it: from then on, updates stop.