Cunninghams Law
Apply Cunningham's Law when someone wants to elicit information, feedback, or corrections from others—especially online. Trigger on phrases like "how do I get people to respond?", "nobody is answering my question", "I want to get feedback on this", or when someone is drafting a question for Stack Overflow, a forum, a team Slack, or a pull request. Also useful when discussing how to get a conversa…
Parkinsons Law
Apply Parkinson's Law when discussing project planning, sprint duration, deadline setting, scope creep, or why work seems to expand no matter how much time is allocated. Trigger on phrases like "we always use up all the time we're given", "if we give the team a month they'll take a month", "why does scope keep growing?", "should we set tighter deadlines?", or any discussion about the relationship…
Galls Law
Apply Gall's Law when someone proposes building a complex system from scratch, planning a big-bang rewrite, designing a greenfield platform, or debating whether to "just rebuild it the right way." Trigger on phrases like "let's rewrite this properly", "we need to start fresh", "the architecture is too complex to fix", "let's build the perfect system", or any situation where someone wants to leap…
Doerrs Law
Apply Doerr's Law when discussing product team culture, motivation, team engagement, hiring philosophy, outsourcing decisions, or the difference between intrinsically motivated vs. extrinsically motivated teams. Trigger on phrases like "how do we get our team more engaged?", "should we outsource this?", "our team feels like contractors", "how do we build a product culture?", or any question about…
Peter Principle
Apply the Peter Principle when discussing promotions, career ladders, hiring for leadership roles, why managers sometimes struggle, or how to build healthy engineering organizations. Trigger on phrases like "we promoted our best engineer to manager", "they were great as an IC but struggling as a lead", "how should we think about promotions?", "our managers weren't trained for this", or any situat…
Postels Law
Apply Postel's Law when designing APIs, data interchange formats, network protocols, input validation, or any interface that will receive data from other systems or users. Trigger on phrases like "how strict should our API be?", "should we accept slightly malformed input?", "what should we send vs. accept?", "how do we handle unexpected fields?", or any question about the balance between strictne…
Rubber Duck
>
Ci Preflight
Run before pushing any branch that adds shipped files, hooks, or platform-specific code. Prevents the CI-whiplash pattern — multiple red pushes that could have been caught locally.
Skills From The Artificer
Dispatcher for the Artificer laws-of-software collection. Given a proposed change, fix, diff, design, or decision, classify it and invoke the relevant law/principle skill(s) — instead of recalling all 24 individually. Use when the user says "cross-reference against the Artificer laws", "which laws apply here?", "run the artificer review", "apply the laws of software to this", or when a code/desig…
Zawinskis Law
Apply Zawinski's Law when discussing feature creep, scope expansion, the tendency for software to grow beyond its original purpose, or when evaluating whether to add a communication feature to a non-communication product. Trigger on phrases like "should we add messaging?", "every app becomes a platform", "our product is becoming too broad", "why does this tool have so many features?", "feature cr…
Test First Bugfix
>
Linuss Law
Apply Linus's Law when discussing code review practices, open source contributions, bug finding strategies, security auditing, or the value of having more people look at code. Trigger on phrases like "should we do code reviews?", "we don't have time for reviews", "how do we find bugs faster?", "open source is more secure", "how many reviewers do we need?", or any discussion about the relationship…
Goodharts Law
Apply Goodhart's Law when designing metrics, OKRs, KPIs, performance reviews, engineering productivity measures, or any system where people are evaluated by a number. Trigger on phrases like "how should we measure this?", "our metrics aren't capturing what we want", "people are gaming the metric", "velocity doesn't feel like a real measure of progress", or any situation where a measurement has be…
Moores Law
Apply Moore's Law when discussing hardware capacity planning, compute cost trends, the feasibility of computationally intensive features, why software that was impractical five years ago is now possible, or the historical arc of what computers can do. Trigger on phrases like "this requires too much compute", "hardware will catch up", "we couldn't do this ten years ago", "cloud compute is getting…
Fitts Law
Apply Fitts's Law whenever someone is designing or critiquing a user interface—button placement, click targets, menu design, touch UI, navigation, or any interactive element. Trigger on phrases like "where should I put this button?", "users are missing this control", "the click target feels small", "how should I design this menu?", or any UX/UI discussion about the effort required to interact wit…
Cost Tier Routing
Use BEFORE doing direct file search, bulk reads, data import/export, or routine coding edits in the main conversation. Routes work to the cheapest model that can do it correctly — haiku for search/IO, sonnet for coding, opus for orchestration/architecture. Triggers when about to call Read on >2 files, Grep/Glob across the repo, batch CSV/JSON transforms, or any "where is X / list all Y / count Z"…
Trust But Verify
Use when you receive findings, a report, or any factual claims back from a subagent/Task before you act on them — re-validate every claim against a primary source (the code itself, the memory directory, CONTEXT.md, docs/ and docs/adr/, context7 library docs, package/API references, or a language spec) instead of trusting the agent's summary. Trigger automatically after any Task/subagent returns a…
Hofstadters Law
Apply Hofstadter's Law when estimating project timelines, discussing why software projects are always late, helping someone plan a sprint or roadmap, or coaching on estimation techniques. Trigger on phrases like "how long will this take?", "why does everything take longer than we plan?", "our estimates are always wrong", "we keep missing deadlines", or any discussion of software estimation and sc…
Kernighans Law
Apply Kernighan's Law when reviewing code, discussing code complexity, advising on coding style, or coaching developers on how to write maintainable code. Trigger on phrases like "this clever solution", "I wrote a really elegant piece of code", "look at this one-liner", "why is this code hard to debug?", or any situation involving the trade-off between cleverness and clarity. Also trigger when so…
Conways Law
Apply Conway's Law when discussing system architecture, team structure, org design, microservices, API ownership, or any situation where communication patterns and software design intersect. Trigger on phrases like "who owns this service?", "our teams keep stepping on each other", "how should we split up this system?", "why does our architecture look like this?", or any question about the relatio…
Wirths Law
Apply Wirth's Law when discussing software performance, application bloat, why software feels slower despite hardware improvements, resource usage in modern applications, or the relationship between software quality and hardware progress. Trigger on phrases like "why is this app so slow?", "software is getting bloat-ier", "we can just rely on hardware to compensate", "modern apps use too much RAM…
Kerckhoffs Principle
Apply Kerckhoffs's Principle when reviewing security designs, authentication systems, encryption implementations, or any situation where someone relies on keeping an algorithm, method, or system architecture secret for security. Trigger on phrases like "security through obscurity", "we keep the algorithm secret", "don't publish how this works", "our system is secure because nobody knows about it"…
Choose Boring Technology
Apply the "Choose Boring Technology" principle when evaluating tech stack decisions, adding new tools or frameworks, proposing a rewrite, or debating between a familiar vs. cutting-edge approach. Use this skill whenever someone is considering adopting a new library, language, database, or service—even if they frame it as "should we use X?", "what tech should we pick?", or "is it worth trying Y?".…
Lady Lovelaces Objection
Apply Lady Lovelace's Objection when discussing the creative or intellectual limits of software and AI, questions about whether machines can "truly" create or think, the nature of AI-generated art and writing, or debates about what computers can and cannot do autonomously. Trigger on phrases like "can AI really be creative?", "did the computer come up with this on its own?", "does AI understand w…
Greenspuns Tenth Rule
Apply Greenspun's Tenth Rule when reviewing complex codebases that have grown their own configuration systems, rule engines, templating languages, scripting layers, or workflow DSLs. Trigger on phrases like "we built our own config language", "we have a custom rules engine", "this template system has gotten really complex", "we're basically reimplementing X ourselves", or any time a team has rein…
Shirky Principle
Apply the Shirky Principle when analyzing why legacy systems persist, why incumbents resist disruptive solutions, why organizations seem to make self-defeating decisions, or why a tool or institution appears to be prolonging the problem it was meant to solve. Trigger on phrases like "why do they keep the old system running?", "this tool is creating the problem it's supposed to fix", "why won't th…
Knuths Optimization Principle
Apply Knuth's Optimization Principle when someone wants to optimize code before establishing it's a bottleneck, is using complex data structures for perceived performance, is making code harder to read "for speed", or is debating whether to optimize something that hasn't been profiled. Trigger on phrases like "I should make this faster", "let's pre-optimize this", "I used X instead of Y for perfo…
Norvigs Law
Apply Norvig's Law when evaluating growth claims about technology adoption, market size projections, "exponential growth" narratives, or headlines claiming a technology will "double" its reach when it's already dominant. Trigger on phrases like "X is growing exponentially", "this will double in the next year", "the market will 2x", or any context where someone is applying growth rate assumptions…
Cost Routing
Top-level dispatcher that classifies every incoming request into scout / coder / architect tiers BEFORE any tool call. Routes Read, Grep, Glob, file-search, symbol-lookup, "where is X", and "list files matching Y" to haiku-scout. Routes known-location Edit, Write, multi-file refactor, test authoring, and bounded code changes to sonnet-coder. Reserves the main opus context for ambiguous design que…
Leaky Abstractions
Apply the Law of Leaky Abstractions when someone is frustrated that a library, framework, or ORM isn't hiding complexity the way it promised, when debugging requires diving into implementation details that "shouldn't matter", or when deciding how much abstraction to build on top of something. Trigger on phrases like "the ORM is doing something weird", "I have to understand how X works even though…
Hyrums Law
Apply Hyrum's Law when discussing API design, backward compatibility, deprecation, versioning, or any situation where a system has enough users that its observable behavior—not just its documented interface—has become depended upon. Trigger on phrases like "can we change this behavior?", "is this a breaking change?", "users are depending on a bug we fixed", "we want to deprecate this", or any dis…