The-Artificer-of-Ciphers-LLC
Organization29 drop-in Claude Code skills: cost-tier model routing, debugging (rubber-duck, test-first-bugfix, trust-but-verify), and 24 laws-of-software reference skills. Install with: npx skills add The-Artificer-of-Ciphers-LLC/skills-from-the-artificer --all
Categories
Indexed Skills (31)
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/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").
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?". This skill helps teams resist shiny-object syndrome and make grounded technology choices.
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 relationship between org structure and technical design. Conway's Law is one of the most important—and most underappreciated—forces shaping software systems.
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 questions, ADRs, and tradeoff analysis. Use whenever a request lands in the main context and might involve file IO, code search, code edits, or design reasoning — which is almost every turn.
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" question. Also triggers when the orchestrator (you, on opus) is about to write straightforward code that a sonnet subagent could handle.
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 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.
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 what makes product teams excellent vs. mediocre. Doerr's Law is foundational for anyone thinking seriously about building a product organization.
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 with an element. Fitts's Law is one of the oldest and most empirically reliable principles in human-computer interaction.
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 directly to a sophisticated, full-featured solution. Gall's Law is a powerful antidote to over-engineering and big-bang thinking.
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 become a target. Goodhart's Law is critical for anyone designing incentive systems or interpreting data.
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 reinvented a programming language feature or general-purpose tool inside their application. This rule is a useful diagnostic for spotting accidental complexity.
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 scheduling. Hofstadter's Law is one of the most universally experienced phenomena in software development.
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 discussion about evolving a public or widely-used API. Hyrum's Law is essential reading for anyone building platforms, libraries, or APIs.
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", or any security discussion where the secrecy of the design—rather than the secrecy of a key—is the security mechanism. This is a foundational principle of modern cryptography and security engineering.
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 someone is struggling to debug complex code or asking whether a clever approach is worth the cost.
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 performance", "this might be slow", or any discussion where performance is the motivation for added complexity that hasn't been validated by measurement.
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 what it's doing?", "can software originate ideas?", or any philosophical discussion about the relationship between human intention and machine output.
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 I'm using library Y", "why do I need to know the underlying SQL?", "this abstraction is breaking down", or any situation where a layer of abstraction has forced someone to understand what it was supposed to hide.
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 between the number of people examining code and the quality of that code.
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 cheaper", "what can we expect hardware to look like in 5 years?", or any discussion where the trend in computing power is relevant. Also trigger when Moore's Law is cited — because its current status is contested.
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 to a technology that already has significant penetration. Also useful when evaluating numeracy in tech journalism and analyst reports.
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 between available time and how long work takes. Parkinson's Law is a universal phenomenon in project management.
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 situation where promotion or career development decisions intersect with competence and role fit.
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 strictness and permissiveness in an interface design. Postel's Law is a foundational principle of robust interface design, with important modern caveats.
rubber-duck
Rubber duck debugging session. Use when the user is stuck on a bug and can't find the cause, says "I don't understand why this isn't working", "help me think through this", "talk me through this bug", or "rubber duck". Also use when a developer has been debugging for >20 minutes without progress — the duck is most valuable before frustration distorts thinking. Triggers on: "stuck", "can't figure out", "doesn't make sense", "walk me through", "help me think", "rubber duck", "explain why".
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 they just adopt the better solution?", "why does this bureaucracy exist?", or any situation where an institution's incentives seem misaligned with its stated purpose.
test-first-bugfix
Test-driven bug fixing — reproduce before you fix. Use this skill whenever the user reports a bug, describes unexpected behavior, says something is broken, mentions a regression, or asks you to fix an error. This includes phrases like "this is broken", "X doesn't work", "there's a bug in", "getting an error when", "it used to work but now", "failing on", or any variation. Even if the user says "just fix it" or "quick fix", use this skill — the reproduce-first discipline catches regressions and proves the fix actually works. Do NOT skip this skill just because the bug seems obvious or simple.
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 result you're about to rely on, and whenever the user says "trust but verify", "verify these claims", "double-check what the agent found", "did it actually confirm that", or "where's the source for X". A subagent's report is a lead, not a fact. Nothing is verified until a source was opened and quoted; guessing, inferring, and "that looks right" are not verification.
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", or any discussion about the growing resource demands of software relative to hardware capability gains.
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 creep", or any discussion about the pressure on software to expand into adjacent functionality. Zawinski's Law is darkly funny and deeply true.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.