Imported from jacob-balslev/skills (skills/reasoning-strategy/constraint-awareness/SKILL.md). Install upstream with npx skills add jacob-balslev/skills --skill constraint-awareness. Copyright stays with the author (MIT).

Constraint Awareness

Concept of the skill

Constraint awareness is the discipline of identifying the single resource that limits a system's throughput at any given time, and routing all improvement work through that resource. Drawn from Eliyahu Goldratt's Theory of Constraints (1984, The Goal), it treats systems as throughput pipelines whose total output is bounded by their narrowest section — and treats local optimization of non-constraints as effort that produces no system-level gain. Five Focusing Steps: (1) IDENTIFY the constraint (in an AI-coding team, almost always a class of human activity — review bandwidth, validation, decision-making, learning — not a class of agent activity); (2) EXPLOIT the constraint (maximize the value of every minute of constraint-time; never waste it on work the constraint shouldn't be touching); (3) SUBORDINATE everything else to the constraint (non-constraint resources — agents, automation, tooling — exist to serve the constraint, not the other way around); (4) ELEVATE the constraint (invest in increasing the constraint's capacity — better tooling, better skills, higher agent autonomy, better pre-review); (5) REPEAT (when the constraint moves, restart from step 1).

Replaces "add more tooling, more agents, more parallelism" as a default response to "we're not shipping fast enough" with TOC's constraint-first prioritization. Solves the problem that most AI-coding systems fail not because the agents are incapable, but because they waste the one resource that cannot be scaled — the human operator's attention. Without explicit constraint-awareness, agents treat all tasks as equal-priority, interrupt the operator with questions they could have answered themselves, and produce verbose output nobody reads. Theory of Constraints turns this into a tractable engineering problem rather than a vague productivity complaint: identify the constraint, route work around it, invest only in changes that genuinely move it. Anti-pattern catalog: unnecessary questions (better skill content fixes them, not more questions), spawning without consent (never spawn without an explicit user signal — context-switching is expensive for the constraint), summaries nobody reads (the diff is the summary; only elaborate when non-obvious), over-engineering that creates maintenance debt (every abstraction layer is future demand on the constraint), circular discussions (re-litigating settled decisions because they weren't durably recorded). Attention-audit ratios measure constraint health: 30-40% reviewing agent output (>50% means agents need more autonomy), 20-30% design/product decisions, 5-10% debugging agent failures (>20% means skill content is incomplete), 5-10% answering agent questions (>15% means rules are incomplete), 15-25% learning/research/strategy (<10% means the constraint is consumed by operations).

Distinct from ai-native-development, which is the conceptual frame for AI-coding (Software 3.0, autonomy slider, vibe vs agentic) — this skill is the prioritization lens applied within that frame. Distinct from agent-engineering, which owns production reliability patterns (orchestration, error budgets, observability) — this skill owns which of those to invest in based on where the bottleneck currently is. Distinct from code-review, which evaluates one piece of work — this skill reasons about whether the review gate itself is the bottleneck. Distinct from tool-call-strategy, which decides per-action which tool an agent calls — this skill decides per-process whether that whole class of action should require human intervention at all. Distinct from task-sizing skills (effort estimation per task), prioritization-framework skills (RICE/WSJF/ICE — scoring backlog initiatives against each other), and model-routing/agents skills (which AI model gets a specific task). The throughput-bottleneck question is upstream of all of these — they each optimize within a frame this skill questions. Constraint awareness is to AI-coding what Drum-Buffer-Rope is to a factory floor — the slowest machine on the line sets the pace for the whole plant; speeding up the other machines just piles inventory in front of the bottleneck. Adding more agents to an AI-coding team where review bandwidth is the constraint is the same as buying faster CNC mills when the constraint is the inspection station — the parts pile up at inspection, the lead time gets worse, and the new mills look efficient locally while the whole shop ships less per day. The wrong mental model is that more agents, more parallelism, more tooling, more cleverness automatically increases throughput. They do not, except when targeted at the actual constraint — which in an AI-coding team is almost always the human operator's attention, not the agent's speed. Adjacent misconceptions: that every optimization is improvement (it is not — Goldratt's central lesson is that local optimization of non-constraints produces no system-level gain, and overloading the constraint degrades the entire system; a four-model review panel on every architectural decision sounds rigorous but overloads the constraint with attention demands); that the constraint is fixed (it is not — once agent autonomy improves, the bottleneck shifts: review bandwidth → strategic decisions → user research → market timing → a resource constraint like capital or headcount; the Five Focusing Steps must restart when the constraint moves, and processes that served the old constraint may be irrelevant or counterproductive to the new one); that every agent question is legitimate (it is not — questions about always-yes things, about documented patterns, about safe defaults are false dependencies on the constraint and should be promoted to rules or skills; if the answer is always the same, it shouldn't live in a question to the constraint); that more abstraction is more capability (it is not — every abstraction creates future demand on the constraint to maintain; the simplest design that passes the constraint lens wins); that constraint analysis means more meetings (it does not — TOC is a decision framework, applied to specific proposed changes, not a recurring overhead); and that throughput is the same as utilization (it is not — a constraint at 100% utilization with a queue of waiting work has the same throughput as a constraint at 100% utilization with no queue; queueing is the symptom of overload, not the goal).

Coverage

Theory-of-Constraints (Goldratt) applied to the cost-structure inversion of AI-assisted software development. Identifies the constraint as the human activity that cannot be delegated to an agent — review, validation, decision-making, learning. Walks the Five Focusing Steps (Identify, Exploit, Subordinate, Elevate, Repeat) and shows how each step maps to a team operating multiple coding agents. Names the four constraint-aware process-design rules: front-load agent work and back-load human judgment; batch constraint touches; present options + recommendation rather than open questions; eliminate false dependencies on the constraint by promoting recurring questions into rules or skills. Catalogs five anti-patterns (unnecessary questions, spawning without consent, summaries nobody reads, over-engineering with maintenance debt, circular discussions). Specifies attention-audit ratios for measuring constraint health. Explains the constraint-shift model — that the bottleneck moves over time as agent autonomy improves, from review bandwidth → strategic decisions → user research → market timing — and that the focusing steps must restart when it does.

Philosophy of the skill

Most AI-coding systems fail not because the agents are incapable, but because they waste the one resource that cannot be scaled: the human operator's attention. Without explicit constraint-awareness, agents treat all tasks as equal-priority, interrupt the operator with questions they could have answered themselves, and produce verbose output nobody reads. Theory of Constraints turns this into a tractable engineering problem rather than a vague productivity complaint: identify the constraint, route work around it, invest only in changes that genuinely move it.

The single sharpest insight TOC offers an AI-coding team is the cost-structure inversion. Pre-AI, code production was the dominant cost — every feature took hours of typing, every test took hours of writing. Post-AI, code production is nearly free; an agent can produce ten thousand lines in minutes. The bottleneck has moved entirely to the activities that cannot be delegated: reviewing whether the agent's output is correct, deciding what to build next, validating that the system matches user reality, and learning from outcomes. Every team optimization should now be evaluated through one question: does this reduce demand on the constraint?

1. Goldratt's Theory of Constraints

Eliyahu Goldratt's TOC states that every system has exactly one constraint that limits its throughput. Improving anything other than the constraint does not improve the system. Overloading the constraint degrades the entire system.

The Five Focusing Steps

1. IDENTIFY the constraint. What single resource currently limits system throughput? In an AI-coding team, this is almost always a class of human activity, not a class of agent activity.
2. EXPLOIT the constraint. Maximize the value of every minute of constraint-time. Never waste it on work the constraint shouldn't be touching.
3. SUBORDINATE everything else to the constraint. Non-constraint resources (agents, automation, tooling) exist to serve the constraint, not the other way around. Their schedules, outputs, and APIs should be shaped around the constraint's needs.
4. ELEVATE the constraint. Invest in increasing the constraint's capacity — better tooling, better skills, higher agent autonomy, better pre-review.
5. REPEAT. When the constraint moves (and it will), restart from step 1. The subordination rules change.

The map for an AI-coding team

2. The Constraint Shift — When Building Becomes Cheap

The AI revolution changes the cost structure of software development. Understanding this inversion is essential for correct prioritization.

Pre-AI cost structure

Code production    [=============================]  HIGH    (hours per feature)
Code review        [=================]              MEDIUM  (~30 min per PR)
Testing            [=================]              MEDIUM  (hours per test suite)
Documentation      [===========]                    MEDIUM  (often skipped)
Decision-making    [=======]                        LOW     (fast, drawn from experience)

Post-AI cost structure

Code production    [===]                            CHEAP   (minutes per feature; agent-generated)
Code review        [=================]              MEDIUM  (still requires human judgment)
Testing            [========]                       LOW     (agents write tests; CI runs them)
Documentation      [===]                            CHEAP   (agents write docs alongside code)
Decision-making    [=============================]  HIGH    (more decisions, faster, higher stakes)

The inversion: code production was the bottleneck; now it is nearly free. The bottleneck moved to the human activities that cannot be delegated — review, validation, deciding, learning.

Implications for prioritization

3. The Constraint Lens — One Question for Every Decision

Every proposed process, tool, and workflow should be evaluated with one question:

Does this reduce demand on the constraint?

Decision framework

Proposed change / process / tool
        │
        ▼
Does it reduce decisions the constraint must make?
        │
       YES → Subordinates to the constraint. APPROVE.
        │
       NO
        ▼
Does it improve the *quality* of decisions presented to the constraint?
        │
       YES → Exploits the constraint (more value per attention-minute). APPROVE.
        │
       NO
        ▼
Does it create *new* demands on the constraint?
        │
       YES → REJECT or REDESIGN. It overloads the constraint.
        │
       NO
        ▼
Does it improve a non-constraint resource (agent speed, CI time, lint pass-rate)?
        │
       YES → Low priority. Only do if free. It will not move throughput.
        │
       NO  → No value. Do not build.

The first three branches are the test that matters. A change that does not reduce demand on the constraint, does not improve decision quality, and does not introduce new demands is by definition optimizing a non-constraint — and per TOC, optimizing a non-constraint does not improve the system.

4. Constraint-Aware Process Design

When designing any new process, workflow, or tool, apply these four rules:

4.1 Front-load agent work; back-load human judgment

BAD:  human decides → agent builds → human reviews → agent fixes → human reviews
GOOD: agent researches → agent builds → agent tests → agent pre-reviews → human spot-checks

The bad pattern touches the constraint three times. The good pattern touches it once.

4.2 Batch constraint touches

Instead of interrupting the constraint with each decision:

BAD:  agent asks question 1 → human answers → agent asks question 2 → human answers → ...
GOOD: agent collects all questions → presents them in one batch → human answers all at once

Context-switching is expensive for the constraint. Batching decisions reduces switching cost dramatically.

4.3 Present options + recommendation, not open questions

BAD:  "How should we handle the edge case where the upstream API returns null for the tracking field?"
GOOD: "Upstream null tracking — three options:
       A) Retry in 6h. Covers ~80% of cases (the upstream is usually catching up).
       B) Mark as manual-check. Zero false positives but increases human queue.
       C) Fall back to a secondary tracking source. Works for ~60% of orders.
       Recommendation: A. Approve?"

The bad pattern requires the constraint to generate the solution. The good pattern requires only a yes/no judgment.

4.4 Eliminate false dependencies on the constraint

Some tasks that seem to require the constraint actually do not:

If the answer is always the same, it should live in a rule or skill, not in a question to the constraint.

5. Anti-Patterns That Waste the Constraint

5.1 Unnecessary questions

Agents asking questions they could answer from already-loaded context. Every question consumes constraint bandwidth.

Fix: better skill content, better rules, higher agent autonomy within defined guardrails. Promote recurring questions to skills until they stop recurring.

5.2 Spawning without consent

Spawning agents, tabs, or processes without an explicit user signal. Forces context-switching and creates an interruption — overloading the constraint.

Rule: never spawn without an explicit signal from the constraint, and always make the spawned process visible (not background, not silent).

5.3 Summaries nobody reads

Producing verbose summaries at the end of every response. If the diff is readable, the summary is waste.

Rule: terse responses. The diff is the summary. Only elaborate when the change is non-obvious from the diff alone.

5.4 Over-engineering that creates maintenance debt

Building sophisticated abstractions that require ongoing constraint-attention to maintain. Every abstraction layer is a future demand on the constraint.

Test: "Will this abstraction save more constraint-time over its lifetime than it costs to maintain?" If no, keep it simple. The simplest design that passes the constraint lens wins.

5.5 Circular discussions

Multi-agent debates that produce no actionable output. Re-litigating settled decisions because the prior decision was not durably recorded.

Fix: check decision records / memory before re-debating. If a decision was already made, execute it; do not reopen it without new information.

6. Measuring Constraint Health

6.1 Attention audit

Periodically review where constraint-attention actually went. Healthy and unhealthy ranges:

6.2 Constraint throughput

Measure tasks completed per unit of constraint-time:

constraint efficiency = tasks completed / constraint-hours spent

This number should increase over time as agents become more autonomous and skills become more complete. A flat or declining trend is a signal that the elevation work has stalled.

6.3 Leading indicators

7. When the Constraint Moves

The constraint is not permanently fixed. As agent autonomy improves, the bottleneck shifts:

When the constraint moves, the Five Focusing Steps restart from step 1. The processes that served the old constraint may now be irrelevant or actively counterproductive. Subordination targets change. The team's job changes.

Verification

• The current system constraint has been explicitly identified, named, and agreed on
• Every proposed process, tool, or workflow change has been evaluated against the constraint decision framework before being adopted
• Agent-autonomous tasks are scheduled first; constraint-touching tasks are batched into a small number of structured surfaces (review, decision)
• When agents present a decision to the constraint, they present options + recommendation, not an open question
• Recurring questions have been promoted to rules or skills until they stop recurring
• Attention-audit ratios are within the healthy bands; outliers have a known cause and an active elevation action
• The team has named what would cause the constraint to move and what the next constraint is likely to be

Do NOT Use When

Key Sources

• Goldratt, E. M., & Cox, J. (1984). The Goal: A Process of Ongoing Improvement. North River Press. The original business-novel introduction of the Theory of Constraints and the Five Focusing Steps. The plant-floor parable formalizes the throughput / inventory / operating-expense triple.
• Goldratt, E. M. (1990). Theory of Constraints. North River Press. The non-fiction follow-up; canonical statement of the focusing-steps protocol, Drum-Buffer-Rope scheduling, and the Thinking Processes (Current Reality Tree, Evaporating Cloud, Future Reality Tree).
• Goldratt, E. M. (1997). Critical Chain. North River Press. Application of constraint logic to project scheduling; buffer management as a substitute for per-task safety padding.
• Cox, J. F., & Schleier, J. G. (Eds.). (2010). Theory of Constraints Handbook. McGraw-Hill. Comprehensive reference; covers Throughput Accounting, the Thinking Processes, application domains beyond manufacturing.
• Womack, J. P., & Jones, D. T. (1996). Lean Thinking. Simon & Schuster. The complementary Lean discipline; useful for understanding the composition rule between Lean (waste reduction across the stream) and TOC (constraint-first prioritization).
• Reinertsen, D. G. (2009). The Principles of Product Development Flow. Celeritas. Flow-based product development; queueing theory and WIP constraints connect Theory of Constraints to knowledge-work systems beyond manufacturing.