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.
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/design review wants the relevant software-law lenses surfaced automatically. Also the entry point for Step 2 of the Bug Remediation workflow ("adheres to safety, optimization, and legacy software principles").
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?". This skill helps teams resist shiny-object syndrome and make grounded technology choices.
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 relationship between org structure and technical design. Conway's Law is one of the most important—and most underappreciated—forces shaping software systems.
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 conversation started or surface hidden knowledge within a team. Cunningham's Law is a surprisingly powerful practical tool for anyone trying to learn or get unstuck.
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 what makes product teams excellent vs. mediocre. Doerr's Law is foundational for anyone thinking seriously about building a product organization.
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 with an element. Fitts's Law is one of the oldest and most empirically reliable principles in human-computer interaction.
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 directly to a sophisticated, full-featured solution. Gall's Law is a powerful antidote to over-engineering and big-bang thinking.