Use this skill whenever writing new code, proposing a bugfix, reviewing a PR/diff, or discussing whether to add an abstraction, config layer, plugin system, or generic mechanism. Also trigger for architecture/design discussions, is this too complex" questions, or any point where Claude is about to suggest introducing a new abstraction layer. The core stance — code is written for humans to read, not as an artwork to admire — optimize for affordance (like a road sign, instantly readable) rather than elegance or cleverness. Trigger even if the user doesn't name "simplicity" explicitly — e.g. "should I make this configurable", "quick fix for this bug", "review this PR", "should I abstract this into a helper", "this codebase feels messy".
TypeScript-specific best-practices and rule enforcement — type safety, runtime validation, error handling, and TS-only conventions. Routes to type-system and Zod sub-skills, the `javascript` skill for JS-foundation rules, and `oop-principles` for design patterns and SOLID. TRIGGER when: language (TypeScript, TS, .ts, .tsx, idiomatic TypeScript), type-system (discriminated unions, generics, utility types, make illegal states unrepresentable, type narrowing), safety (strict mode, any vs unknown, ts-expect-error, ts-ignore, type assertions), runtime (Zod, schema validation, runtime type checks, parse/safeParse), errors (error handling without throwing, union return errors, Result type), ts-conventions (readonly modifier, return type annotations, interface prefix, `as const`), contracts (domain vs DTO, monorepo types, API contract types). DO NOT USE when: user asks generic JS questions with no TS angle — use `javascript` instead.
Deep dive into TypeScript's type system — narrowing, discriminated unions, mapped types, conditional types, type guards, branding, and escape hatches. TRIGGER when: user asks about unknown vs any, type narrowing, discriminated unions, exhaustiveness checking, mapped types, conditional types, infer keyword, user-defined type guards, type branding, companion object pattern, as const, escape hatches, type assertion, how do I narrow a type, how do I write a type predicate, how to create nominal types, how to prevent structural aliasing, make illegal states unrepresentable, illegal states, state machine types, entity lifecycle types, optional field anti-pattern, discriminated union state modeling, interface vs type alias, when to use interface vs type, enum best practices, typescript enum, const enum, readonly property, ReadonlyArray, lazy object initialization, barrel exports, when to use generics, generic naming conventions, no interface prefix. DO NOT USE when: runtime/schema validation at boundaries (parsing e
Zod v4 best practices — schema design, error handling, transforms, coercion, branded types, and boundary validation. TRIGGER when: user mentions zod, zod validation, zod schema, zod v4, zod parse, zod transform, zod coerce, zod branded types, zod error handling, runtime validation, validate API response, schema composition, zod object, zod mini, zod infer, zod v3 to v4, migrate from zod v3, upgrade zod, zod breaking changes. DO NOT USE when: the question is pure compile-time typing with no runtime validation (discriminated unions, generics, narrowing, `as const`) → use `typescript-type-system`.
Expert Git assistant that answers questions about Git concepts, commands, workflows, and best practices — both in French and English. Use this skill whenever the user mentions Git, version control, commits, branches, merges, rebases, conflicts, stash, push/pull, remotes, history rewriting, or anything related to source code versioning. Also trigger when users say things like 'comment faire un rebase', 'I messed up my history', 'explain branching strategies', 'how do I undo a commit', 'what is the difference between merge and rebase', 'git tips', 'commit message best practices', or any git-related question — even phrased casually or in French. DO NOT USE when: choosing a commit-message emoji → use git-hero-gitmoji; designing/optimizing GitLab CI pipelines → use git-hero-gitlab-dag; non-Git version control (SVN, Mercurial, Perforce).
Git best practices — commit discipline, branching/history hygiene, safety, and CI/CD pipelines. Routes to `git-guru` (expert Q&A), `gitmoji`, and `gitlab-dag` sub-skills. TRIGGER when: commits (Conventional Commits, atomic commits, commit message format, commit hygiene), history (branch naming, rebase vs merge, clean git history, interactive rebase, history management), safety (force push safety, recover lost commits, reflog, reset), CI/CD (GitLab CI, pipeline optimization, DAG, .gitlab-ci.yml), emoji (gitmoji, commit emoji, "quel emoji pour ce commit"), setup (git configuration, "bonnes pratiques git", "comment faire un rebase", "configure git properly"). DO NOT USE when: user needs a single one-shot git command answer — let Claude answer directly.
Use this skill when the user wants to investigate a bug, defect, incident, or quality issue and find its root cause — including requests to run a "5 whys" analysis, write a postmortem, do a root-cause analysis (RCA), figure out why a bug reached production or slipped past code review/QA, set up a recurring defect-analysis routine, or run a daily/weekly quality-improvement (Kaizen) triage. Also known as the Dantotsu method (Sadao Nomura's Toyota-derived defect-analysis approach, adapted for software). Trigger even if the user doesn't name the method explicitly — e.g. "why did this bug get through code review", "a client reported a bug, help me analyze it", "I want to understand why this keeps happening", "write up a root cause report for this defect", or "help me prioritize which fixes to actually ship this week".
Go concurrency — goroutines, channels, select, sync primitives, context, and data race prevention. TRIGGER when: user asks about goroutines, Go channels, Go select, sync.Mutex, sync.WaitGroup, sync.Once, Go context, context.WithCancel, context.WithTimeout, Go data race, race condition in Go, Go concurrency patterns, fan-in fan-out, worker pool, Go channel direction, buffered channel, Go deadlock, -race flag, errgroup, Go concurrent map, Go goroutine leak. DO NOT USE when: user needs general concurrency theory unrelated to Go, or is asking about goroutines only as background context with no code to write or review.