The Theory of Constraints Analyst skill for Claude

No software to install, no subscription, no consultancy project: a single 1,309-word text file that puts Claude in the role of an analyst trained on the work of Eliyahu M. Goldratt, with a fixed method, a fixed output format and six rules it may not let go of. You download the zip at the top of this page, put it in your Claude environment, and from that moment Claude looks for the constraint first in every stuck process. What a skill actually is and how that file format works is explained in what are Claude skills NL.

The problem this skill solves is one that hits hard-working teams in particular: everything is running flat out and yet nothing grows. The reflex then is to improve a little everywhere, or to hire people, and that reflex is exactly the mistake according to Goldratt. In any system there is, at any moment, exactly one constraint that sets the throughput.

The file's frontmatter lists the situations that trigger the skill: where is the bottleneck, my process is stuck, we are running flat out but not growing, reduce lead time, increase capacity, what is the weakest link, raise throughput. It also includes the technical terms, from drum buffer rope to current reality tree, for anyone who already knows the framework.

It is written for business owners with several departments or steps in their process who do not know which step is holding back the whole chain. It is part of the library we make freely available through the AI and automation service, with no account and no sales email afterwards.

One thing you should know beforehand: the skill draws no conclusions from your first sentence. One of its six fixed rules forbids advice about the constraint without first asking for observable evidence, and another rule instructs it to keep asking until it really knows where the constraint sits. So expect follow-up questions about queues, idle time and lead times before you get a verdict. That is not slowness, that is the framework.

To make that measurable, the skill uses Goldratt's three units of measure, in a fixed order. Throughput: the rate at which the system generates money through sales. Inventory, also called investment: all the money tied up in the system. And operating expense: all the money needed to turn inventory into throughput. The goal is throughput up and the other two down, in that order. Anyone who does not have their own figures to hand is not turned away: the skill briefly explains the terms and helps you estimate them yourself.

The difference from the usual improvement reflex is best shown as a diff:

To manage the chain, the file uses drum buffer rope, another term from The Goal. The drum: the bottleneck sets the rhythm for the whole system. The buffer: a small stock around the bottleneck so it never sits idle. The rope: a signal back to the start of the chain, so only work the bottleneck can handle gets released. Other resources are explicitly not allowed to work faster than the constraint can process, because that just piles up inventory.

The file's source list counts six titles: The Goal (1984), It's Not Luck (1994) and Critical Chain (1997) by Goldratt, The Goal: A Process of Ongoing Improvement by Goldratt and Jeff Cox, the Body of Knowledge from the TOC International Certification Organization, and Goldratt's Theory of Constraints: A Systems Approach by H. William Dettmer. If you want to learn how to set up an instruction file this well grounded yourself, the method is in writing a SKILL.md NL.

The method has five fixed parts. First ask for context: what is the system, what is the goal, and what are the current levels of throughput, inventory and operating expense. Then identify the constraint through observable signals: queues, idle time, complaints, lead time. Then run through the five focusing steps, each with concrete questions and actions. Along the way the skill also points to policy constraints and mental constraints, because the real constraint is often an assumption, not a machine. And it always closes with a concrete action list for the next 30 days.

The five focusing steps themselves are the heart of the file, and the instruction is strict: follow them exactly in order and skip nothing. Step one, identify: find the point that sets the pace for the whole system. Step two, exploit: get the maximum out of the constraint without spending money, no breaks on the bottleneck, no rework, no work that does not contribute to throughput.

Step three, subordinate: align everything else to the pace of the constraint, using drum buffer rope. Step four, elevate: only once steps two and three are done does money come into view, for extra people, machines or training. Step five, repeat: as soon as the constraint is broken it moves somewhere else, so go back to step one, and do not let the old constraint's old rules keep existing.

For larger change questions the file also includes the three questions of the thinking processes, in order: what needs to change (the current reality tree, looking for the root cause), what does it need to change into (the future reality tree), and how do you cause the change (the prerequisite tree and the transition tree). The output is fixed too: the system laid out, the levels of T, I and OE, the constraint with its type, location and evidence, the five steps each worked out, the 30-day plan per week, and the assumptions that may or may not hold.

The file closes with six important rules, and these set the tone of the conversation: force the user to walk all five steps, always point to policy and assumptions as possible real constraints, never give advice without asking for observable evidence, use drum buffer rope where it fits, keep asking until you are sure where the constraint sits, and explain T, I and OE if the user does not know them. How those rules play out you can see below in FIG.03.

After that, using it is simple: describe your system and your goal, and answer the follow-up questions about where the work is piling up. It asks itself about anything that is missing. If you get stuck anywhere, the full step-by-step guide per environment is in installing Claude skills NL, and the broader explanation of working with AI is in the knowledge base.

There are also situations where you are better off leaving it be. A problem with no chain is one of them: if it is about a single decision or a one-off task, there is no throughput to optimise and a different framework will serve you better. If you mainly want to know why something keeps going wrong, you are better off with the 5 Whys Analyst, which follows the cause chain rather than the work chain. And if your question is about which customers or tasks deliver the most value, that is the domain of the Pareto Analyst: Pareto looks for where the value sits, Theory of Constraints looks for where the flow stalls, and the two complement each other well.

One more honest limit: the skill delivers an analysis and a plan, not execution. The 30-day plan in the example only works if someone in week one genuinely measures the lead time per stage, and the file itself is honest about that by closing every analysis with assumptions that may or may not hold. Anyone who never tests the conclusions against reality gets nothing out of any framework.

Not every bottleneck sits inside: for many businesses the analysis ultimately points to the inflow. There is capacity to spare, but too few enquiries come in to fill it. Then the work shifts from the chain to visibility: getting found by the people looking for you. The free SEO scan shows in seconds where your site stands. And if you would like to talk further about what else AI can do for your business, from separate skills to full automation, we simply do that in a conversation.