plugins/craftwork-all/skills/limit-thinking/SKILL.md
Apply limit thinking whenever the user wants to understand what happens when a variable, parameter, or condition is pushed toward its extreme — zero, infinity, 100%, or any boundary. Triggers on phrases like 'what happens if we scale this?', 'what if everyone adopts this?', 'where does this break?', 'what's the ceiling?', 'how does this behave at the extreme?', 'what does this converge to?', 'what if we push this to the max?', 'what's the asymptote?', or any situation where the user is evaluating a system, strategy, rollout, or design by exploring its trajectory rather than its current state. Also trigger when someone is making a decision based on a snapshot ('should we do X?') but hasn't examined the trajectory ('what does X converge to at scale?'). This skill catches the blind spot of static evaluation — most planning failures come from reasoning about where things are, not where things are going. Use this before any scaling decision, rollout plan, or growth strategy.
npx skillsauth add andurilcode/skills limit-thinkingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Core principle: Don't ask "what is the value at this point?" — ask "what does this converge to as we push the variable toward its extreme?" Most planning failures happen because people evaluate a snapshot instead of a trajectory. Limit thinking reveals the destination that incremental progress is silently heading toward.
The mathematical concept of a limit — studying what a function approaches rather than where it is — is a powerful reasoning tool far beyond calculus. It exposes asymptotes, phase transitions, and convergence traps hiding inside seemingly linear plans.
For the system, decision, or strategy being evaluated, identify the key variables that could be pushed toward an extreme.
LIMIT ANALYSIS SETUP
System: [what's being evaluated]
Variables to push:
- Variable 1: [what is it?] → Push toward: [0 / ∞ / 100% / some boundary]
- Variable 2: [what is it?] → Push toward: [0 / ∞ / 100% / some boundary]
- Variable 3: [what is it?] → Push toward: [0 / ∞ / 100% / some boundary]
For each: What does intuition say happens? (This is the naive expectation to test.)
Good variables to push include:
A vague or ambitious prompt ("scale AI across the org", "go all-in on microservices") can generate 5+ candidate variables. Tracing all of them produces an exhaustive but overwhelming analysis. Instead, identify all candidates first, then select the 2-3 most critical using these filters:
List all candidates, mark the 2-3 you'll trace, and briefly note why the others are deprioritized. This keeps the analysis focused and the output actionable.
For each variable, don't jump to the extreme — approach it incrementally and watch what happens. This is where the insight lives.
CONVERGENCE TRACE: [Variable] → [Extreme]
Current state: [where things are now]
↓ Push slightly...
Incremental: [what improves or changes — usually positive]
↓ Push further...
Midpoint: [what secondary effects appear — often the first sign of non-linearity]
↓ Push toward extreme...
Near-limit: [what breaks, saturates, or reverses — the real finding]
↓ At the limit...
Convergence: [variable] → [extreme] means [outcome] → [what it converges to]
Does the outcome converge to what intuition predicted? YES / NO
If NO — what's the actual limit, and why is it counterintuitive?
Key patterns to watch for:
| Pattern | What it looks like | Example | |---|---|---| | Asymptotic ceiling | Returns diminish and flatten. You approach a maximum but never reach it. | Adding more engineers to a team: productivity asymptotes, then declines (Brooks's Law) | | Phase transition | The system changes state entirely at some threshold. No amount of incremental change prepares you for the discontinuity. | Water at 100°C: more heat doesn't make it "hotter water" — it becomes steam. Org maturity hitting L4: more tools don't help, you need structural change | | Reversal / collapse | The variable's effect flips sign. What was helping starts hurting. | Context in an agent: more context helps until it doesn't, then success rate drops (ETH Zurich finding). Automation of review: reduces burden until reviewers disengage entirely | | Convergence to zero | A human quality (attention, responsibility, skill) atrophies as the system takes over. | Pilots and autopilot: the more autopilot flies, the less skilled pilots become at manual flight — the limit of pilot skill as automation → 100% is dangerously low | | Divergence | No stable limit exists. The system oscillates or explodes. | Feedback loops without damping: over-correction → under-correction → chaos |
The value of limit thinking is the delta between naive expectation and actual convergence. State it explicitly:
LIMIT INSIGHT
Naive expectation: "If we push [variable] toward [extreme], [outcome] will [improve/increase/get better]."
Actual convergence: As [variable] → [extreme], [outcome] → [surprising result].
The delta: [Why the actual limit differs from expectation.
What force, feedback loop, or phase transition causes the divergence?]
Implication for the decision: [What should change about the plan, strategy, or design
given that the trajectory leads somewhere unexpected?]
Limit thinking doesn't just reveal where things break — it helps find where to stop pushing. If the convergence trace shows diminishing returns, reversal, or collapse past a certain point, that inflection point is the practical operating target.
OPERATING POINT ANALYSIS
Variable: [what we're tuning]
Benefit curve: [how benefit changes as variable increases]
Inflection point: [where marginal benefit starts declining significantly]
Recommended range: [where to operate, stated as a range not a precise number]
Signal to watch: [what early indicator tells you you've pushed past the optimal point]
List each variable being pushed and toward what extreme.
For each variable, the incremental trace from current state to limit:
For each trace where actual ≠ expected:
Where to operate if the limit reveals diminishing returns or reversal:
What changes about the plan, strategy, or design given these convergence findings.
Use these to sharpen the analysis:
development
Apply kaizen continuous improvement philosophy to any codebase — identifying waste, unevenness, and overburden at the code level and producing small, actionable improvement opportunities. Triggers on '/kaizen', 'kaizen this codebase', 'continuous improvement audit', 'find waste in this code', 'what small improvements can we make?', 'improve this codebase incrementally', 'code health check', 'codebase hygiene', 'tech debt sweep', or any request to find incremental improvement opportunities in code. Also trigger when the user says 'clean up', 'tidy up', 'make this codebase better', or expresses frustration about code quality without wanting a full rewrite. This is NOT a code review skill for PRs or diffs — kaizen operates on the codebase as a whole or a focus area, looking for systemic improvement opportunities. Use this skill even for small codebases — the philosophy scales down gracefully.
tools
Build automation scripts and pipelines that use coding-agent CLIs (Claude Code, Codex, Gemini CLI, GitHub Copilot CLI) in headless/non-interactive mode as the AI engine, or delegate work to cloud agents (`gh agent-task`) that open pull requests asynchronously. Use this skill whenever the user wants to write a shell script, CI job, cron task, batch processor, webhook handler, or any automation that shells out to `claude`, `codex`, `gemini`, `copilot`, or `gh agent-task` — single-turn prompts, multi-turn agentic loops, parallel fan-out across files/folders, structured JSON outputs consumed by downstream tools, or cloud-delegated tasks that produce PRs. Trigger on phrases like "script that uses Claude", "automate with Claude Code", "headless Claude", "batch process files with an LLM", "pipeline with codex exec", "gemini -p", "copilot --autopilot", "gh agent-task create", "GitHub Action that calls Claude", "cron job to review PRs", "agent loop in bash", "dispatch an agent task to open a PR", "fleet-wide agent-task across repos", or any request to integrate a coding agent CLI into an automated workflow. Also trigger when the user describes the shape of a pipeline (fan-out, map-reduce, review-then-fix, extract-then-summarize, ticket-to-PR, scheduled fleet upgrade) and AI is the engine, even if they don't name the CLI explicitly.
development
Entry point for context engineering work. Routes to the right skill based on what the user needs — creating instructions, debugging agent failures, building documentation, or measuring outcomes. Use this when the user's goal involves agent context but they haven't named a specific skill.
documentation
Apply this skill whenever the user asks to have a topic, concept, technology, or idea explained to them. Triggers on phrases like 'explain X to me', 'what is X?', 'how does X work?', 'teach me about X', 'help me understand X', 'break down X', 'ELI5', 'explain like I'm five', 'give me an overview of X', 'I don't understand X', 'walk me through X', or any situation where the user wants to learn or understand something rather than produce an artifact. Also trigger when someone pastes a concept and asks for clarification, when they ask 'why' something works a certain way, or when they need a refresher on a topic they've encountered before. This skill does NOT apply to 'write documentation about X' (use technical-writing) or 'analyze X' (use reasoning skills). This skill is for when the human is the learner.