All authors
Claude Skills by nuttakulsv
github.com/nuttakulsv26 skills1 installs57 views
- BeckKent Beck's test-driven, small-steps way of building: write a failing test, make it pass in the simplest way, then clean up; make it work, then make it right, then make it fast; tidy before you change. Use when implementing a feature or fixing a bug where behavior matters, when changes feel risky, or when the agent is about to write a large change in one go. Triggers: "think like Kent Beck", "TDD", "test first", "small steps", "tidy first", "red green refactor", "คิดแบบเคนต์ เบ็ก", "เขียนเทสต...Votes: 0GitHub stars: 2
- BezosDecision and product habits Jeff Bezos described in Amazon's shareholder letters and that former Amazon leaders documented: work backwards from the customer (press release and FAQ before code), sort decisions into one-way and two-way doors, and disagree and commit. Use when deciding whether to build a feature, writing a product proposal or RFC, choosing how much process a decision needs, or when a team is stuck debating. Triggers: "think like Bezos", "working backwards", "PR/FAQ", "one-way do...Votes: 0GitHub stars: 2
- BrooksFred Brooks's lessons from The Mythical Man-Month and "No Silver Bullet": adding people to a late project makes it later, most difficulty is essential not accidental, conceptual integrity matters more than features, and the second system tends to be overbuilt. Use for estimates, staffing and deadline decisions, rewrites and "v2" plans, choosing tools that promise big productivity gains, and architecture ownership questions. Triggers: "think like Brooks", "mythical man-month", "add more people...Votes: 0GitHub stars: 2
- CarmackJohn Carmack's engineering habits as he has described them publicly: measure instead of guessing, look at the real data and the real hot path, keep state and control flow visible, and choose the simplest thing that works well. Use for performance problems, game/graphics/real-time code, latency budgets, profiling, and code where hidden state or deep call chains make behavior hard to follow. Triggers: "think like Carmack", "profile this", "why is it slow", "frame budget", "latency", "คิดแบบคาร์...Votes: 0GitHub stars: 2
- CouncilConvene a council of 3–5 great minds from this pack to review one decision, design, plan, or piece of code. Each mind critiques it with its own method, then a synthesis makes the disagreements explicit and recommends what to do. Use for important or contested decisions: architecture choices, build vs buy, rewrites, risky migrations, launch plans, or a pull request that deserves more than one point of view. Triggers: "council", "convene the council", "ask the great minds", "get multiple perspe...Votes: 0GitHub stars: 2
- DijkstraEdsger Dijkstra's discipline for code that must be correct: reason about it before testing it, write down the invariant, keep each piece small enough to hold in your head, and avoid clever tricks. Use for algorithms, concurrency, money and inventory logic, state machines, loops with tricky bounds, and reviewing code where a bug would be expensive. Triggers: "think like Dijkstra", "prove it works", "is this correct", "invariant", "edge cases", "คิดแบบไดก์สตรา", "พิสูจน์ว่าถูก", "โค้ดนี้ถูกจริง...Votes: 0GitHub stars: 2
- EinsteinAlbert Einstein's thought experiments applied to systems: push a design to its limits in your head (infinite load, zero latency, clocks that disagree, two observers who see different things) and keep the basic assumptions as few and simple as the facts allow. Use when designing distributed systems, caches, time and ordering logic, scaling plans, or when a design rests on assumptions nobody has written down. Triggers: "think like Einstein", "thought experiment", "what if at scale", "edge of th...Votes: 0GitHub stars: 2
- FeynmanRichard Feynman's way of understanding things: explain it in plain words, find the exact spot where the explanation breaks, and refuse cargo-cult answers. Use when the user wants to understand confusing code, a concept, an error, or a design; when asked to explain something simply or teach it; or when an answer "works" but nobody can say why. Triggers: "think like Feynman", "Feynman mode", "explain it simply", "explain like I'm new", "why does this work", "คิดแบบไฟน์แมน", "อธิบายแบบไฟน์แมน", ...Votes: 0GitHub stars: 2
- FowlerMartin Fowler's refactoring discipline: name the code smell, pick a known refactoring from the catalog, and change structure in small behavior-preserving steps with tests running after each. Use when code is hard to read or change, when reviewing a messy pull request, before adding a feature to tangled code, or when the user asks to clean up or refactor. Triggers: "think like Fowler", "refactor this", "code smell", "clean this up", "make this readable", "คิดแบบฟาวเลอร์", "รีแฟกเตอร์", "โค้ดอ่...Votes: 0GitHub stars: 2
- HickeyRich Hickey's distinction between simple (not intertwined) and easy (familiar, near at hand): find where concerns are complected together and pull them apart, prefer plain data and values over hidden state. Use when choosing libraries or frameworks, designing data models and state management, reviewing code that mixes concerns (time, state, identity, I/O, logic), or when something "convenient" keeps causing bugs. Triggers: "think like Hickey", "simple made easy", "decomplect", "too coupled", ...Votes: 0GitHub stars: 2
- HopperGrace Hopper's way of moving people and organizations: make abstract costs physical and visible (like her 11.8-inch "nanosecond" wires), build a working demo instead of arguing, and make technology usable by people who aren't specialists. Use when you need to convince stakeholders, explain a technical cost or risk to non-engineers, justify a refactor or performance work, write a proposal, or challenge a process kept only out of habit. Triggers: "think like Grace Hopper", "explain to managemen...Votes: 0GitHub stars: 2
- KahnemanDaniel Kahneman's tools against predictable errors in judgment: take the outside view (reference-class forecasting) before trusting your own estimate, run a pre-mortem (with Gary Klein's method) before committing, and separate fast intuition from slow checking. Use for estimates, deadlines, roadmaps, launch plans, hiring decisions, and any plan the team feels very confident about. Triggers: "think like Kahneman", "pre-mortem", "how long will this really take", "estimate", "planning fallacy", ...Votes: 0GitHub stars: 2
- KnuthDonald Knuth's habits for algorithms and performance: analyze before optimizing, optimize only the critical part that measurement points to, and explain programs to humans as if they were literature. Use when choosing or analyzing an algorithm or data structure, estimating complexity, deciding whether an optimization is worth it, or writing code and docs that need to be read carefully. Triggers: "think like Knuth", "big O", "is this fast enough", "premature optimization", "analyze the algorit...Votes: 0GitHub stars: 2
- LiskovBarbara Liskov's principles of data abstraction and substitutability: hide representation behind a clear abstraction, and make sure anything that claims to be a subtype or implementation can stand in for the original without surprising its callers. Use when designing interfaces, inheritance, plugins, adapters, repository or storage layers, API versions, or when a "drop-in replacement" keeps breaking callers. Triggers: "think like Liskov", "substitutability", "LSP", "interface design", "can I ...Votes: 0GitHub stars: 2
- Mind MakerBuild a new mind skill for this pack from sources the user provides (books, papers, talks, interviews, blog posts, a mentor's own notes): extract the person's methods, heuristics and anti-patterns into a SKILL.md with the same structure as the other minds, with sources and an ethics check for living people. Use when the user wants to add a person, mentor, or expert to think-like, or turn someone's way of working into an agent skill. Triggers: "make a mind", "create a skill from this person", ...Votes: 0GitHub stars: 2
- MindsIndex of the think-like pack: lists every great mind available, what each one makes the agent do, and which to pick for a given problem. Use when the user asks which mind to use, what minds are available, for help with think-like, or describes a problem and wants a recommendation. Triggers: "think-like help", "which mind", "list minds", "who should I ask", "what minds are there", "/minds", "มีใครบ้าง", "ควรใช้ใครดี", "รายชื่ออัจฉริยะ".Votes: 0GitHub stars: 2
- MungerCharlie Munger's decision checklist: invert the problem (how would this fail?), follow the incentives, check for the classic misjudgment biases, and stay inside your circle of competence. Use for risky or expensive decisions: vendor and architecture choices, build vs buy, pricing, hiring, security trade-offs, migrations, or any plan everyone in the room already agrees with. Triggers: "think like Munger", "invert", "what could go wrong", "incentives", "mental models", "devil's advocate", "คิดแ...Votes: 0GitHub stars: 2
- MuskThe five-step engineering "algorithm" Elon Musk has described publicly, plus first-principles reasoning: make every requirement less dumb and give it a named owner, delete parts and steps, simplify, then speed up, and automate last. Use when a feature, spec, process, pipeline, or architecture feels over-specified or bloated; when estimating cost from scratch; or before automating anything. Triggers: "think like Musk", "first principles", "the algorithm", "delete the part", "question the requi...Votes: 0GitHub stars: 2
- OhnoTaiichi Ohno's root-cause method from the Toyota Production System: go and see the real evidence, ask "why" until you reach a cause you can fix, then put in a countermeasure so it cannot happen again. Use for production incidents, recurring bugs, flaky tests, failed deploys, postmortems, and any "we fixed it but it came back" situation. Triggers: "think like Ohno", "5 whys", "root cause", "why did this happen", "postmortem", "คิดแบบโอโนะ", "หาต้นเหตุ", "ทำไมถึงพัง". Not for brainstorming new ...Votes: 0GitHub stars: 2
- OusterhoutJohn Ousterhout's "A Philosophy of Software Design": fight complexity with deep modules (simple interface, lots of functionality behind it), information hiding, and strategic rather than tactical programming. Use when designing or reviewing modules, classes, APIs, services, or refactors; when a change touches too many files; or when code is full of shallow pass-through layers. Triggers: "think like Ousterhout", "deep module", "philosophy of software design", "too many layers", "design review"...Votes: 0GitHub stars: 2
- PolyaGeorge Pólya's "How to Solve It" method for problems you are stuck on: understand the problem, devise a plan, carry it out, look back. Use when a bug, algorithm, query, or puzzle-like task has resisted a first attempt, when the agent keeps trying random fixes, or when the user says they are stuck. Triggers: "think like Polya", "how to solve it", "I'm stuck", "we've tried everything", "solve this step by step", "คิดแบบโพลยา", "ติดอยู่", "แก้ไม่ออก". Not for simple tasks with an obvious solution.Votes: 0GitHub stars: 2
- ShannonClaude Shannon's six ways to attack a hard design problem, from his 1952 Bell Labs talk on creative thinking: simplify, find a similar solved problem, restate it, generalize, break it into parts, invert it. Use when you need a new approach rather than a fix: designing an algorithm, protocol, data model, or architecture where the obvious idea doesn't work. Also useful for cutting noise from alerts, logs, and metrics. Triggers: "think like Shannon", "need a new approach", "different angle", "cr...Votes: 0GitHub stars: 2
- SocratesSocratic questioning before building: ask short, pointed questions that expose undefined terms, hidden assumptions, and contradictions in a request, until the real goal is clear. Use when a request is ambiguous, when requirements conflict, when the agent is about to guess at what the user means, during requirement gathering, or to help someone reason through their own design without handing them the answer (mentoring, interviews). Triggers: "think like Socrates", "ask me questions first", "cl...Votes: 0GitHub stars: 2
- TeslaNikola Tesla's habit of building and running a machine completely in his head before touching material: walk through the whole system end to end, change the construction, and fix flaws on paper before any code is written. Use before implementing a feature or service that spans several components, for design reviews, migration plans, and onboarding flows, or when the agent is about to start coding without a full picture. Triggers: "think like Tesla", "walk through the whole flow", "simulate it...Votes: 0GitHub stars: 2
- TorvaldsLinus Torvalds's engineering standards as he has described them in public: good taste means restructuring code so special cases disappear, never break existing users, and judge patches by the code, not by the talk around them. Use for code review, API and CLI changes that existing users rely on, low-level or performance-sensitive code, and pull requests with lots of if-branches for edge cases. Triggers: "think like Linus", "Torvalds review", "good taste", "don't break users", "show me the cod...Votes: 0GitHub stars: 2
- TuringAlan Turing's move of replacing a vague question with a precise, mechanical one that can be checked: turn fuzzy requirements ("fast", "secure", "user-friendly", "works correctly") into an exact procedure or test that decides yes or no. Use when acceptance criteria are vague, when writing specs, tests, SLOs, or evaluation suites, when people argue about whether something is "done", or when evaluating AI or heuristic features. Triggers: "think like Turing", "define done", "make it testable", "a...Votes: 0GitHub stars: 2