tjboudreaux
52 verified skills12,649 total stars
thinking-opportunity-cost
Before committing scarce time/people/money to one thing, ask "what's the next-best use of these resources, and what does doing nothing cost?" — the real cost is the best option you skip.
tools324
thinking-red-team
Use when reviewing code, auth, or APIs for security vulnerabilities — adopt an attacker mindset, enumerate the attack surface, report only findings with a concrete reproducible attack path.
development324
thinking-ooda
Use under time pressure (incident, outage, debugging a moving target) when you must act before you have certainty—cycle Observe→Orient→Decide→Act on ~70% confidence, then re-observe.
development324
thinking-cynefin
Use when unsure how to approach a problem—plan, analyze, experiment, or stabilize first. Classify it by cause-effect (clear/complicated/complex/chaotic) and match the approach to the domain.
data-ai324
thinking-second-order
When a change has effects past the immediate fix (incentives, scale, feedback loops), ask "and then what?" across horizons before committing — the obvious fix often backfires downstream.
content-media324
thinking-theory-of-constraints
Use when optimizing latency or throughput in a pipeline and one stage dominates—focus all effort on that single bottleneck, since speeding up the others changes nothing until it's fixed.
devops324
thinking-reversibility
Before deliberating over a decision, ask if it's a one-way door (costly to undo) or two-way (cheap to undo) — decide two-way doors fast, and look for moves that make one-way doors reversible.
testing324
thinking-kepner-tregoe
Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
development324
thinking-regret-minimization
When advising a human on a high-stakes, hard-to-undo life/career choice, weigh the asymmetry between a recoverable downside and a permanent missed opportunity, not just the short-term cost.
tools324
thinking-via-negativa
About to add a feature/layer/process to fix a problem. First ask what to remove instead — subtraction is often more robust than addition. Use for simplification and complexity reduction.
tools324
thinking-margin-of-safety
Use when provisioning capacity, setting a timeout/limit, or committing to an estimate under uncertainty. Size a buffer to the cost of being wrong instead of optimizing to the edge.
testing324
thinking-fermi-estimation
Use when you need a number you can't measure and can't look up. Decompose the unknown into estimable factors and multiply for an order-of-magnitude answer. Don't Fermi a lookup-able value.
tools324
thinking-bounded-rationality
Use when a search or investigation could run indefinitely and you need a stopping rule. Set an explicit "good enough" threshold and stop at the first option that clears it.
development324
thinking-first-principles
When a constraint is treated as fixed ("too expensive", "impossible", "always done this way"), ask whether it's physics or just convention, then rebuild from what's actually true.
development324
thinking-model-selection
Choose the right mental model for the problem at hand. Use when facing new problems, when current approaches fail, or when you need to match tool to context.
tools324
thinking-inversion
When planning work where optimism may be hiding risks, ask "how would I guarantee this fails?" — enumerate failure paths, then turn the top ones into explicit requirements to avoid.
testing324
thinking-debiasing
In a long trajectory where you're defending a path you committed to early, run a quick self-check for sunk-cost and confirmation bias before continuing — only when evidence is being explained away.
testing324
thinking-map-territory
Use when behavior contradicts the docs, tests, diagram, or your assumption — stop reasoning from the description, go verify the running code or data directly, and let the territory overrule the map.
development324
thinking-systems
Use when debugging across services/an incident where a fix in one place breaks another, or behavior is emergent and no single component explains it. Maps the system and traces causes.
development324
thinking-circle-of-competence
Use when you're unsure whether you actually know the answer. If you lack the evidence or context to answer reliably, abstain, ask, or fetch it — don't confabulate a confident reply.
testing324
thinking-model-router
Route to the right mental model based on your domain and problem type. The single entry point for all thinking skills.
data-ai324
thinking-model-combination
Combine multiple mental models for richer analysis. Use for complex problems requiring multiple lenses, high-stakes decisions, or when single models leave blind spots.
testing324
thinking-jobs-to-be-done
Deciding what to build or why a feature isn't adopted. Reframe from features to the "job" users hire the product for — the progress they seek — to prioritize and position.
development324
thinking-probabilistic
Use when stating a forecast, estimate, or risk. Anchor on the base rate, give a confidence range instead of a point, and update the number when new evidence arrives.
tools324
thinking-scientific-method
Use when a symptom could have several causes and you must find the faulty code by ranking falsifiable hypotheses and checking the cheapest discriminating observation first.
development324
thinking-socratic
Use before building when a request is vague, assumption-laden, or "obvious." Ask the clarifying questions that surface hidden requirements and false premises instead of guessing.
development324
thinking-steel-manning
Use before rejecting a proposal or when you're inclined to just agree with the user. Build the strongest version of the opposing case first, then engage that — not a weak version.
tools324
thinking-thought-experiment
You need to trace how a system would fail or behave at a scale you can't cheaply test or measure. Use to imagine the scenario and walk the consequence chain step by step.
testing324
thinking-bayesian
Use when interpreting a test result, metric, or new evidence and you risk over-reacting to it. State the base rate first, then update belief by the likelihood ratio.
development324
thinking-archetypes
Use when the same problem keeps recurring despite fixes, growth stalled with no obvious cause, or a quick fix made things worse—match it to a known structural pattern instead of re-diagnosing.
tools324
thinking-leverage-points
Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
data-ai324
thinking-feedback-loops
Use when a system shows runaway growth/collapse, oscillates around a target, or resists change, and you need to find the loop driving it. Identifies reinforcing/balancing loops and delays.
testing324
thinking-occams-razor
Use when multiple causes could explain a bug — test the fewest-assumption hypothesis first; escalate to complex only when evidence forces it. Skip the full procedure when one step resolves it.
testing324
thinking-lindy-effect
Choosing a technology/framework/dependency and longevity matters. Use the heuristic that for non-perishable things, expected remaining life is proportional to current age — favor the proven.
development324
thinking-effectuation
Start with means, not goals; co-create with partners; leverage contingencies. Use for startup strategy, innovation projects, and uncertain/novel domains where planning is unreliable.
development324
thinking-dual-process
Use when an answer arrives too fast on a high-stakes or unfamiliar task. Force one explicit verification pass before committing instead of shipping the first plausible answer.
testing324
thinking-five-whys-plus
Use when a fault is localized to a component and the proximate cause is known but the systemic root is not — chain 'why' with evidence, a counterfactual cause test, and an explicit stop condition.
testing324
thinking-triz
Use when stuck between two architecture or API requirements that seem mutually exclusive — name the contradiction precisely, then separate the conflicting states in time, space, or condition.
development324
thinking-pre-mortem
Before committing to a plan or launch, assume it has already failed and reason backward through why — prospective hindsight surfaces risks that "what could go wrong?" misses.
development324
eng-user-impact
Anchor every engineering decision in user value, measurable outcomes, accessibility, and cross-platform experience coherence.
testing1
eng-testing-anti-patterns
Use when writing or modifying tests, adding mocks, or considering test-only hooks—prevents common mistakes like testing mocks, polluting production with test helpers, and mocking without understanding dependencies.
tools1
meta-superpowers
Startup protocol for every task—discover applicable skills, run them, announce usage, and follow required workflows (brainstorming, TodoWrite checklists, etc.).
testing1
eng-security-safety
Apply proactive threat modeling, least-privilege design, and safety guardrails before delivering any code or infrastructure change.
development1
eng-iterative-delivery
Decompose work into safe, observable increments with feature flags, rollbacks, and communication baked in.
tools1
eng-performance
Guard latency, memory, battery, bandwidth, and gas/compute budgets by measuring before and after every change.
tools1
eng-observability
Design every change with traceability, diagnostics, and fast incident triage in mind across mobile, web, and web3 stacks.
development1
eng-rigorous-validation
Enforce reproducible testing, automated verification, and evidence-driven sign-off before merging any change.
development1
eng-verification
Mandatory checklist before claiming work is complete—run the evidence-producing command, inspect output, and only then state a result.
testing1
tools-debugging-root-cause
Systematic debugging playbook for tracing failures backward through the call chain, adding instrumentation, and fixing bugs at their origin.
tools1
eng-holistic-systems
Model the end-to-end system, constraints, and failure modes before touching code; use whenever a change spans multiple layers or unclear requirements.
development1
eng-quality-handoff
Deliver changes with clear communication, reviewer-ready context, and follow-up accountability.
testing1
eng-tdd
Enforces disciplined RED-GREEN-REFACTOR cycle—write failing test first, watch it fail, write minimal code to pass, then refactor.
development1