{"kind":"Skill","metadata":{"namespace":"community","name":"thinking-bounded-rationality","version":"0.1.0"},"spec":{"description":"Apply Herbert Simon's Bounded Rationality and satisficing to make good-enough decisions under real-world constraints. Use for design decisions under time pressure, recognizing cognitive limits, and setting appropriate stopping criteria.","files":{"SKILL.md":"---\nname: thinking-bounded-rationality\ndescription: Apply Herbert Simon's Bounded Rationality and satisficing to make good-enough decisions under real-world constraints. Use for design decisions under time pressure, recognizing cognitive limits, and setting appropriate stopping criteria.\n---\n\n# Bounded Rationality and Satisficing\n\n## Overview\n\nHerbert Simon's Bounded Rationality recognizes that human decision-making is limited by three fundamental constraints: available information, cognitive capacity, and time. Rather than pursuing optimal solutions (which is often impossible), Simon proposed \"satisficing\"—a portmanteau of satisfy + suffice—choosing solutions that are good enough to meet requirements.\n\n**Core Principle:** \"Decision makers can satisfice either by finding optimum solutions for a simplified world, or by finding satisfactory solutions for a more realistic world.\" — Herbert Simon\n\n## When to Use\n\n- Making design decisions under time pressure\n- Facing complex problems with incomplete information\n- Analysis paralysis is blocking progress\n- Optimization costs exceed potential benefits\n- Need to set stopping criteria for searches/research\n- Evaluating when \"good enough\" beats \"perfect\"\n- Resource allocation under constraints\n\nDecision flow:\n\n```\nDecision needed? → yes → Do you have perfect information? → rarely\n                                                         ↘\n                    Is optimization cost justified? → no → SATISFICE\n                                                    ↘ yes → Optimize (but verify cost)\n```\n\n## The Three Constraints\n\n### 1. Information Bounds\n\n**What you can know is limited**\n\n- Complete information rarely exists\n- Gathering more information has costs\n- Information has diminishing returns\n- Future states are inherently uncertain\n\n```\nExample: Choosing a technology stack\nReality: You can't test every option in production\n         You can't predict 5-year industry shifts\n         You can't know your future team composition\nSatisfice: Pick a well-supported option that meets current needs\n```\n\n### 2. Cognitive Bounds\n\n**What you can process is limited**\n\n- Working memory holds ~4-7 items\n- Complex comparisons overwhelm analysis\n- Decision fatigue degrades quality\n- Expertise helps but doesn't eliminate limits\n\n```\nExample: Reviewing architecture options\nReality: You can't hold 20 tradeoffs in mind simultaneously\n         You can't model all interaction effects\n         You can't foresee all edge cases\nSatisfice: Focus on the 3-5 most critical criteria\n```\n\n### 3. Time Bounds\n\n**When you must decide is constrained**\n\n- Deadlines are real\n- Markets move\n- Opportunities expire\n- Perfect is the enemy of shipped\n\n```\nExample: Technical design for Q1 deadline\nReality: You have 2 weeks, not 2 months\n         The business needs an answer now\n         Delaying has its own costs\nSatisfice: Make the best decision possible with available time\n```\n\n## Satisficing vs. Optimizing\n\n### When to Satisfice\n\n| Signal | Why Satisfice |\n|--------|---------------|\n| Reversible decision | Can adjust later with more information |\n| Time pressure | Cost of delay exceeds value of more analysis |\n| Diminishing returns | 80% solution found, 100% would take 10x effort |\n| High uncertainty | More analysis won't reduce uncertainty meaningfully |\n| Many acceptable options | Several solutions meet requirements adequately |\n| Low stakes | Consequences of suboptimal choice are minor |\n\n### When to Optimize\n\n| Signal | Why Optimize |\n|--------|--------------|\n| Irreversible decision | Mistakes are permanent or very costly to undo |\n| High stakes | Wrong choice has severe consequences |\n| Clear criteria | You know exactly what \"best\" means |\n| Bounded search space | All options can actually be evaluated |\n| Available time | Deadline allows for thorough analysis |\n| Clear value of optimal | Difference between good and best is significant |\n\n## The Satisficing Process\n\n### Step 1: Define Aspiration Level\n\nSet the minimum acceptable threshold for each criterion:\n\n```\nExample: Hiring a senior engineer\nOptimizing: Find the absolute best candidate\nSatisficing: Find a candidate who:\n- Has 5+ years relevant experience ✓\n- Can pass technical interview ✓\n- Salary expectations fit budget ✓\n- Available to start within 4 weeks ✓\n- Culture fit (team confirms) ✓\n\nFirst candidate who meets all criteria → Hire\n```\n\n### Step 2: Search Sequentially\n\nEvaluate options one at a time against aspiration level:\n\n```\nOption A: Meets 4/5 criteria → Continue search\nOption B: Meets 3/5 criteria → Continue search  \nOption C: Meets 5/5 criteria → STOP, choose this one\n```\n\nKey insight: You don't compare options against each other, you compare each option against your threshold.\n\n### Step 3: Adjust Aspiration If Needed\n\nIf search is too long or too short, recalibrate:\n\n```\nToo many options qualify → Raise aspiration level\nNothing qualifies after reasonable search → Lower aspiration level\n```\n\n### Step 4: Commit and Move On\n\nOnce threshold is met:\n\n- Stop searching\n- Accept the decision\n- Resist second-guessing\n- Redirect energy to execution\n\n## Application Patterns\n\n### For Technical Design\n\n```\nScenario: Choose a message queue for new service\n\nSatisficing approach:\n1. Define requirements (aspiration level):\n   - At-least-once delivery ✓\n   - Handles 10k msg/sec ✓\n   - Team familiarity or fast learning curve ✓\n   - Managed option available ✓\n   - Within cost budget ✓\n\n2. Evaluate sequentially:\n   - RabbitMQ: Meets all → STOP, use RabbitMQ\n\n3. Don't continue researching Kafka, SQS, etc.\n   unless RabbitMQ fails threshold\n```\n\n### For Code Review\n\n```\nScenario: Reviewing a PR under time pressure\n\nSatisficing approach:\n1. Define \"good enough\" criteria:\n   - No security vulnerabilities ✓\n   - Tests pass ✓\n   - No obvious performance issues ✓\n   - Code is readable ✓\n   - Follows project conventions ✓\n\n2. Stop when criteria met\n   Don't perfect every line if shipping matters\n```\n\n### For Research/Investigation\n\n```\nScenario: Debugging production issue\n\nSatisficing approach:\n1. Define stopping criteria:\n   - Root cause identified ✓\n   - Fix verified in staging ✓\n   - Rollback plan exists ✓\n\n2. Stop investigating once you can fix\n   Don't exhaustively trace every code path\n   if you have a working solution\n```\n\n### For Feature Scope\n\n```\nScenario: MVP feature set decisions\n\nSatisficing approach:\n1. Define \"enough to learn\":\n   - Core user job addressed ✓\n   - Measurable success metric exists ✓\n   - Usable enough for feedback ✓\n   - Can ship within sprint ✓\n\n2. First scope that meets criteria → Ship it\n   Don't polish what you might throw away\n```\n\n## Setting Appropriate Aspiration Levels\n\n### Too High → Analysis Paralysis\n\nSymptoms:\n\n- Nothing ever meets the bar\n- Endless research and comparison\n- Decisions perpetually delayed\n- Perfect becomes enemy of good\n\nFix: Ask \"What's the minimum that would be acceptable?\"\n\n### Too Low → Poor Outcomes\n\nSymptoms:\n\n- Frequent rework required\n- Quality issues in production\n- Technical debt accumulation\n- Stakeholder dissatisfaction\n\nFix: Ask \"What past decisions do I regret? What threshold would have prevented them?\"\n\n### Calibration Heuristics\n\n```\nReversibility Check:\n- Easily reversible → Lower aspiration OK\n- Hard to reverse → Raise aspiration\n\nConsequence Check:\n- Minor consequences → Lower aspiration OK\n- Major consequences → Raise aspiration\n\nTime Check:\n- Tight deadline → Accept lower aspiration\n- Ample time → Can afford higher aspiration\n```\n\n## Common Traps\n\n### Trap 1: Satisficing Feels Like Settling\n\n**Reality:** Satisficing is rational under constraints, not lazy.\n\n```\nOptimizing with infinite time = mathematically correct\nOptimizing with real constraints = often irrational\nSatisficing = adapted to actual world\n```\n\n### Trap 2: Post-Decision Regret\n\n**Reality:** Finding a better option later doesn't mean the decision was wrong.\n\n```\nYou chose Option B (met threshold)\nLater discovered Option D was \"better\"\nThis is expected—you stopped searching at B\nRegret is only valid if B didn't meet your threshold\n```\n\n### Trap 3: Creeping Aspiration\n\n**Reality:** Moving goalposts prevent closure.\n\n```\nOriginal: \"Need 100ms response time\"\nAfter meeting it: \"Actually, 50ms would be better\"\nAfter that: \"Hmm, 25ms would be ideal...\"\n\nFix: Lock aspiration level before search begins\n```\n\n### Trap 4: Satisficing the Wrong Things\n\n**Reality:** Some decisions warrant optimization.\n\n```\nWrong to satisfice:\n- Security critical systems\n- Legal compliance\n- Safety-critical code\n- Irreversible architectural choices\n\nRight to satisfice:\n- Internal tooling\n- Reversible experiments\n- Style preferences\n- Low-stakes choices\n```\n\n## Integration with Other Thinking Models\n\n### With First Principles\n\n```\nUse First Principles to determine:\n- What constraints are real vs assumed?\n- What is the fundamental requirement?\nThen satisfice against those fundamentals\n```\n\n### With Inversion\n\n```\nUse Inversion to set aspiration level:\n- \"What would make this solution unacceptable?\"\n- Avoid those failure modes\n- Any option avoiding them satisfices\n```\n\n### With Circle of Competence\n\n```\nOutside your circle:\n- You can't evaluate \"optimal\" anyway\n- Satisficing is your only realistic option\n- Set thresholds based on expert input\n\nInside your circle:\n- You can choose when to optimize vs satisfice\n- Trust your calibrated aspiration levels\n```\n\n### With Pre-Mortem\n\n```\nRun pre-mortem to validate aspiration level:\n- \"If this satisficed solution fails, why?\"\n- Adjust thresholds to prevent likely failures\n- Don't over-engineer against unlikely failures\n```\n\n## Verification Checklist\n\n- [ ] Identified whether this decision warrants optimizing or satisficing\n- [ ] Set clear aspiration level before searching\n- [ ] Defined explicit stopping criteria\n- [ ] Evaluated options against threshold, not against each other\n- [ ] Stopped when threshold was met (or adjusted threshold rationally)\n- [ ] Committed to decision without continued comparison shopping\n- [ ] Documented reasoning for future reference\n\n## Key Questions\n\n- \"What's the minimum acceptable solution here?\"\n- \"What would 'good enough' look like for this decision?\"\n- \"Is more research likely to change my decision?\"\n- \"What's the cost of continued analysis vs acting now?\"\n- \"Can I reverse this decision if I learn more later?\"\n- \"Am I searching for best, or searching to avoid deciding?\"\n- \"What threshold would I set for someone else in my position?\"\n\n## Simon's Insight\n\n\"A wealth of information creates a poverty of attention.\"\n\nIn a world of infinite information and finite attention, satisficing isn't settling—it's adapting to reality. The goal isn't to make perfect decisions, but to make good decisions efficiently, preserving cognitive resources for the problems that truly require optimization.\n\nThe satisficer who ships beats the optimizer who's still researching.\n"},"import":{"commit_sha":"a31e22d4445ad8fef7cd771d32af537aebb68c49","imported_at":"2026-05-22T21:14:39Z","license_text":"MIT License\n\nCopyright (c) 2025 TJ Boudreaux\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","owner":"tjboudreaux","repo":"tjboudreaux/cc-thinking-skills","source_url":"https://github.com/tjboudreaux/cc-thinking-skills/tree/a31e22d4445ad8fef7cd771d32af537aebb68c49/skills/thinking-bounded-rationality"}},"content_hash":[205,228,16,120,140,121,70,35,166,4,20,252,16,2,3,78,68,243,169,159,78,145,5,65,38,10,74,115,56,133,158,216],"trust_level":"unsigned","yanked":false}