For agents that plan what happens next, hand out work, and ask a person for a decision.
8 skills
Open be-ambitious# Be ambitiousThis skill makes your task bigger in three directions: altitude, depth and rangeMost limits on ambition come from what you think is possible. A specific, hard g## 1. Altitude: find the goal above the taskThe task is a person's best guess about how to get an outcome. Find that outcome- Ask: "What must happen after this task is done? What is this task for?" Exampl- Ask what can get that outcome directly. Ask if a different work product can ge- To show that a different way is better, use evidence from real history. Show t- Look for a workflow that continues to give the outcome without new tasks from - Altitude is best for tasks that have a real outcome. Creative work usually nee## 2. Depth: do the task as the best people in the field do itMake the task deeper, not bigger. Before you start, answer these questions:1. What does a top professional in this field do here that the person did not as2. What is the most raw material that they start from? Example: the logs, not th
I ask for something and get back the small safe version.
Open decide# DecideThe user judges results, not plans. So decide, then show them a short comparison1. The question and its options. Include doing nothing. The set of options is op2. For whom. List the parties each option touches, for example the user, every C3. The door. Is it cheap to undo (a two-way door, so decide now) or costly (a on4. Reward and cost for each party for each option, including how sure you are of5. Pre-mortem. Assume the choice failed a month from now. Write the most likely 6. The call. Say which option, why, and what would make you revisit it.7. Show it as one short table plus the call. Don't show the steps.
My agent asks me to choose and hands me a wall of options.
Open dig-apc# Dig: axioms, principles, cruxesYou failed because you believe something that is false. If you use more effort o1. Write what you did, and the result.2. Write each thing that you thought was true, in three groups. Include the beli- Axioms: what you took as given.- Principles: the rules that you followed.- Cruxes: the beliefs that change what you do if they are wrong.3. For each belief, ask: "What can show that this is false?" For a belief about 4. Find the beliefs that failed. There can be more than one. Write each one.5. Start again from the correct beliefs. Do not repair the old work.Then show the user only the wrong beliefs and what you did with them. Do not shoIf a wrong belief is about a fact in the world, test it: write down what you exp
My agent keeps trying harder at the same wrong idea.
Open encode-lessons# Encode lessons in structureThe second time a lesson comes up, the text failed. Hold it with structure inste- Pick the cheapest guard that holds it: a type, then a lint rule, then a hook o- If the fix is structural, ship only the structural fix. Delete the instruction- If the lesson needs judgement and no guard can hold it, make the line more pro- Record the lesson's origin (the user's words, with the time) on the ticket, noExample: "never auto-compact" was a habit to remember. It became DISABLE_AUTO_CO
I told my agent the same thing twice and it did it again.
Open first-principles# Redesign from first principlesDon't bolt a change onto the current design. Redesign as if the new requirement 1. Read every affected file, type and rule. Know the current design before you c2. Ask: "Writing this from scratch with this requirement, what would we build?" 3. Propagate the change everywhere it reaches: types, states, events, errors cat4. Design the whole redesign, then deliver it in small verifiable steps.Signs you bolted it on: a new optional field or flag beside an old one, a specia
Open prove-it# Prove it worksUnverified work has unknown correctness. Check the real thing directly.- Run the real program from outside and read what it prints (a demonstration, de- Check liveness directly (the process, the listener), not state derived from it- When a check fails, suspect the way you looked before you suspect the system.- Script the check when you can, so a reviewer reruns it instead of trusting you- A script that proves a fix is a demonstration, not a new test. Add a test only- Visual results go to the user, shown inline. Their eyes are the check.
Open skill-design# Skill design: small, researched, testedMackenzie (2026-10-16 13:58): "our lever is environment changes, and that paretoA change to a skill, rule, CLAUDE.md or hook ships only when all three hold:1. Small. One or two intentful changes. Every added line carries implicit claims2. Researched. You looked up the problem the change is for, in sources rather th3. Tested. A run with the change and a run without it show the behaviour it was Write it in a technical register: a defined term ("user-facing view", "hydrationFor a skill whose work reaches people (a page, copy, a brief, a persona), have A
Every rule I add to my agent's instructions makes it worse.
Open unblock# Don't block on the humanThe user supervises asynchronously. Keep moving: decide, do, then show what you - Proceed on reversible work: code, notes, tickets, branches, local config. Do i- Settle mechanics yourself: names, conventions, facts in the code. List the ass- Still ask first: anything hard to reverse or outward-facing (deleting, publish- The user's to decide: product direction, taste, shared-type placement. Ask one- When you notice a problem, log it on the ticket and fix it in the next round.
be-ambitious: Before your agent starts, it asks what the job is really for and what an expert would do, then asks for more than you first typed. decide: It compares the options for each person a choice affects, including doing nothing, then shows you a short result you can check. dig-apc: After a failure, it has your agent write what it did and what it believed, as axioms, principles and cruxes, then test each belief to find the one that is wrong. encode-lessons: When the same correction comes up a second time, it picks the cheapest guard that holds it (a type, a lint rule, a hook or a script) instead of adding another line of text. first-principles: When a rule changes, it redesigns the type model or module from the start instead of adding another special case. prove-it: Before your agent says it is done, it runs the real program from outside and reads what it prints, instead of trusting a compile, a cached screenshot or its own word. skill-design: A change to a skill, rule or hook ships only if it is small, one or two intentful edits, because every added line carries claims nobody checked. unblock: Your agent proceeds on reversible work, settles the mechanics itself and shows what it did and why, and still asks first about anything hard to reverse, outward-facing or costly.