skills

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.

Go error handling — error interface, custom error types, wrapping, sentinel errors, errors.Is/As, panic/recover. TRIGGER when: user asks about Go error handling, if err != nil, custom errors, error wrapping, fmt.Errorf %w, errors.Is, errors.As, sentinel errors, panic recover, when to panic in Go, error types in Go, Go error best practices, Go error propagation, error chains, Go error interface, handling errors in Go, Go error patterns. DO NOT USE when: user needs general error-handling philosophy outside Go, or panic/recover questions unrelated to Go's error interface.

Go modules and packages — go.mod, go.sum, versioning, proxies, internal packages, init functions. TRIGGER when: user asks about Go modules, go mod init, go mod tidy, go.mod, go.sum, Go package organization, Go imports, Go internal package, Go init function, Go module proxy, Go versioning, Go major version, Go replace directive, Go workspace, Go vendor, Go dependency management, GOPATH vs modules, GOPROXY, GOPRIVATE, go install vs go get. DO NOT USE when: user is asking purely about directory/folder layout (cmd/, internal/, pkg/) with no go.mod, versioning, or dependency question involved — use the `golang` skill's Project Layout reference directly instead.

Idiomatic Go — error handling, concurrency, web services, testing, and project structure. TRIGGER when: language (Go, Golang, .go files, go mod, go build, go run, go test, go fmt), concurrency (goroutine, channel, sync, context, select statement), errors (error interface, error wrapping, sentinel errors, panic/recover, errors.Is/As), web (net/http, HTTP handler, JSON encoding, REST API in Go, middleware), idioms (defer, nil, pointers vs values, struct embedding, interface satisfaction, receiver methods, slices, maps), tooling (Go modules, generics, table-driven tests, go vet), ask (idiomatic Go, Go best practices, Go code review, how to write Go). DO NOT USE when: user mentions "go" only as a verb in a different-language context.

Go testing — table-driven tests, test helpers, benchmarks, fuzz testing, profiling, and testify. TRIGGER when: user asks about Go testing, go test, testing package, table-driven tests in Go, Go test helpers, t.Helper, t.Run, Go benchmarks, Go profiling, pprof, Go fuzz testing, Go test coverage, testify, Go mock, Go test patterns, Go test organization, TestMain, t.Cleanup, t.Parallel, Go golden files, Go httptest. DO NOT USE when: user needs general testing philosophy (not Go-specific) — use `testing` skill instead.

Go type system — structs, interfaces, embedding, composition, generics, slices, maps, enums with iota. TRIGGER when: user asks about Go structs, Go interfaces, Go embedding, composition in Go, Go generics, type parameters, Go type constraints, Go slices, Go maps, Go iota, Go enum, Go bitmask, implicit interface, interface satisfaction, small interfaces, accept interfaces return structs, Go type assertion, Go type switch, when to use generics in Go, Go collections, Go struct tags, Go composition vs inheritance, Go polymorphism. DO NOT USE when: user asks about OOP design principles or composition/polymorphism in a language-agnostic way with no Go code involved — use `oop-principles` instead.

Write, review, audit, or improve AGENTS.md files — the open, tool-agnostic standard for giving AI coding agents persistent project context — as well as the harness-specific files that wrap or import it (CLAUDE.md for Claude Code, .cursorrules/.cursor/rules for Cursor, GEMINI.md for Gemini CLI, Copilot instructions, .windsurfrules, OpenCode/Zed config, etc). Use this skill whenever the user wants to create a new AGENTS.md from scratch, audit an existing context file for bloat or anti-patterns, improve instruction quality, apply progressive disclosure, split monolithic context into referenced sub-documents, reconcile multiple tool-specific files into one shared source of truth, or understand AGENTS.md best practices. Trigger even for casual mentions like "help me write my AGENTS.md", "is my CLAUDE.md good?", "what should go in agents.md?", "my agent keeps ignoring my instructions", or "I have a .cursorrules and a CLAUDE.md, how do I unify them?". Treat AGENTS.md, CLAUDE.md, and other harness-specific instructio

Write, review, debug, and configure ClojureScript code and projects. Use this whenever the user mentions ClojureScript, .cljs/.cljc files, shadow-cljs, figwheel, the CLJS compiler, JS interop from Clojure, Reagent/re-frame/Reagent-style UI code, or asks to convert JS/TS logic into ClojureScript. Also use it for questions about CLJS compiler options (:optimizations, :main, :npm-deps, :externs, etc.), consuming JS/npm libraries from CLJS, source maps, Google Closure Library usage, or the newer ^:async/await function support. Trigger even if the user just pastes CLJS code with an error and asks "what's wrong here" or asks to set up a new CLJS project. Do NOT use for nbb (babashka/nbb) scripts, `nbb.edn` projects, or anything meant to run via `nbb script.cljs`/`npx nbb` — those have a different (SCI-interpreted, no-Closure-Compiler) language surface; use the clojurescript-nbb skill for those instead.

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).

Design, write, review, or optimize GitLab CI/CD pipelines using DAG (Directed Acyclic Graph) with the needs keyword and parallelism features (parallel, parallel:matrix). Use this skill whenever the user mentions GitLab CI, .gitlab-ci.yml, pipeline optimization, job dependencies, the needs keyword, parallel matrix builds, pipeline speed, or wants to break free from strict stage ordering. Also trigger when the user asks about reducing CI runtime, fanning out jobs, matrix builds across OS/version/environment combinations, or 1:1 job dependency mapping between matrix jobs. DO NOT USE when: non-GitLab CI systems (GitHub Actions, CircleCI, Jenkins, Azure Pipelines); general Git questions → use git-hero-git-guru.

Selects and applies gitmoji emoji prefixes for Git commit messages, integrated with Conventional Commits format. Use when the user asks about gitmoji, wants an emoji for a commit message, asks 'which emoji for...', 'quel emoji pour...', mentions commit emoji conventions, says 'prefix my commit', 'gitmoji for', 'emoji commit', or wants to decorate commit messages with standardized emoji. DO NOT USE when: the user wants plain Conventional Commits with no emoji; general Git help → use git-hero-git-guru.

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.

Evaluate code against Dave Thomas's OO principles, SOLID principles, and the Tell Don't Ask rule. Routes to `design-patterns/` and `solid/` sub-skills. TRIGGER when: class has only static methods; class has a single public method + constructor; code uses GoF pattern names (Decorator/Factory/Strategy/Builder/Command/Observer); class is invalid until setters are called; data class with only constructor + properties; external code reads getters to make decisions (Tell Don't Ask); user asks "is this OOP design smell?", "is this a class design issue?", "is this an OOP anti-pattern?", "should this be a class or a function?", or "why does my code feel procedural?". DO NOT USE when: the smell is at the function/method level (long method, primitive obsession, feature envy on values, etc.) — that is `refactoring`'s domain. Activate here only for *class-shape* issues.

SOLID principles for reducing coupling and improving testability — SRP, OCP, LSP, ISP, and DIP with annotated examples. TRIGGER when: user mentions SOLID, SRP, OCP, LSP, ISP, DIP, single responsibility principle, open-closed principle, Liskov substitution, interface segregation, dependency inversion, god class, fat interface, one reason to change, extend without modifying, depend on abstractions, interface too large, reduce coupling, improve testability.

Analyze a real communication artifact (Slack/Teams message, email, meeting transcript, pitch or presentation draft) and coach it sharper using seven rhetoric + structure techniques: ethos/logos/pathos, reframing tough questions, centering the other person, the Pyramid Principle, pattern interrupt, making ideas feel safe, and the cognitive-load through-line. Diagnose what works, what's missing, then rewrite. TRIGGER when: user wants to improve communication, "make this message clearer", "review my email/Slack", "analyze this transcript", "why did this message land badly", prep for a meeting/pitch/presentation/talk, "how do I say this", be more convincing / persuasive / assertive, handle a tough or trap question, talk to executives / C-level / leadership, structure my idea, get taken seriously, "is this too long-winded". DO NOT USE when: the user wants raw text generated with no analysis or coaching intent (just write it); pure marketing/copywriting asset production; translation; or writing code/docs/specs. For

Apply functional programming composition techniques in JavaScript and TypeScript. Use this skill whenever the user asks about function composition, pipe, compose, currying, partial application, point-free style, pure functions, immutability, functors, monads, lenses, functional mixins, factory functions, or object composition. Also trigger when the user asks how to avoid class inheritance, how to build reusable abstractions in JavaScript or TypeScript, how to compose async operations, how to reduce coupling through FP patterns, TypeScript composition, or functional TypeScript. Even if they just say "compose these functions", "pipe this data", or "make this more functional", use this skill. DO NOT USE when: the user is designing class-based OOP architecture or asking about SOLID principles — use `oop-principles` instead.

Review code against the CUPID properties for joyful coding: Composable, Unix philosophy, Predictable, Idiomatic, and Domain-based. Use this skill whenever the user wants to assess code quality using CUPID, asks "is this code CUPID?", wants a code review framed around CUPID principles, mentions any of the five CUPID properties by name, asks how to make code more joyful or habitable, or wants to refactor/improve code using Dan North's CUPID framework. Also trigger when the user pastes code and asks for feedback on structure, naming, dependencies, predictability, or domain alignment — even if they don't explicitly mention CUPID. DO NOT USE when: user wants specific refactoring techniques for code smells — use `refactoring` instead. DO NOT USE when: user wants SOLID principle analysis — use `oop-principles` instead.

Enforce and guide the Mikado Method for *large, graph-driven* refactors where a single naive change cascades into many failing call sites. The skill enforces the full Mikado loop: goal → naive attempt → map prerequisites → revert → implement leaves → commit → repeat. TRIGGER when: user mentions Mikado Method, dependency untangling, circular dependencies, "breaking everything" on a refactor, change cascading across many files, ripple effects, large-scale legacy refactor with tight coupling, untangling tightly-coupled modules, splitting a big refactor into safe steps, or wanting to work on main without a long-lived feature branch. Also trigger on "graph-based refactor", "prerequisite tree", or "Mikado graph". DO NOT USE when: the change is small/in-place (single method, single class, simple rename) — use `refactoring` instead for code smells and Extract Method-style work. If the feature hasn't been scoped yet, consider `kano` first to validate it's worth doing.

Write, compile, debug, and package CHICKEN Scheme programs. Use this skill whenever the user mentions CHICKEN Scheme, call-cc.org, csc, csi, Scheme eggs, Scheme-to-C compilation, R5RS/R7RS Scheme, call/cc, continuations, SRFI, or wants help with any Scheme programming task using CHICKEN. Also trigger for questions about the CHICKEN FFI, C interop from Scheme, egg packaging, REPL usage, or scripting with csi. Even if the user just says "scheme" without specifying CHICKEN, use this skill if context suggests CHICKEN (e.g. they mention eggs, csc, chicken-install, or wiki.call-cc.org). DO NOT USE when: the user is working with another Scheme implementation (Racket, Guile, MIT Scheme, Gambit) — those have different module systems, package managers, and idioms.

JavaScript best-practices and rule enforcement — naming conventions, modern syntax idioms, `this`-handling, module structure, array/iteration performance, and nullability. Applies to plain JavaScript and is the foundation TypeScript builds on. TRIGGER when: language (JavaScript, JS, .js, .mjs, .cjs, Node.js, browser JS, ES modules, ESM, CommonJS), syntax (const/let, destructuring, template literals, optional chaining, nullish coalescing, arrow functions), patterns (this binding, callback, detached method, pure function vs method, module imports, barrel file, index.js), performance (array chains, filter().map(), intermediate arrays, hot path, GC pressure), nullability (null vs undefined, absence, sentinel value, == null check), naming (camelCase, PascalCase, kebab-case, boolean prefix), ask (idiomatic JavaScript, JS conventions, JS best practices, JS code review). ALSO APPLIES to TypeScript — it is the foundation TS builds on; load it alongside `typescript` on `.ts`/`.tsx`. For type-specific rules (type assert

GitHub Flavored Markdown (GFM) syntax reference — tables, alerts, footnotes, task lists, links, images, mentions, anchors, escaping, and common pitfalls. TRIGGER when: user asks about GFM, github flavored markdown, markdown syntax, md syntax, github markdown formatting, markdown table, markdown heading, markdown link, markdown image, task list syntax, markdown alert, GitHub callout, footnote markdown, markdown line break, markdown emoji shortcode, escape markdown special chars, section anchor, autolink. DO NOT USE when: user is composing prose content in markdown and needs no syntax help — only invoke when the question is about rendering, syntax correctness, or feature availability.

Design patterns — Factory, Strategy, Builder, Decorator, Singleton, Mixin, and more with problem-oriented and GoF triggers. TRIGGER when: user mentions design patterns, OOP design patterns, Strategy pattern, Factory pattern, Abstract Factory, Builder pattern, Singleton pattern, Decorator pattern, Proxy pattern, Mixin pattern, Observer pattern, Flyweight pattern, Mediator pattern, Companion Object, swap algorithms at runtime, create families of related objects, construct a complex object step-by-step, add cross-cutting behavior, share behavior across classes, pair a type and factory, decouple components via a hub, reuse instances to reduce memory.

Reviews current branch changes: reads the actual diff, produces structured feedback (Blockers / Concerns / Nits), asks targeted questions, then applies fixes on approval. TRIGGER when: user says "/review", "review this PR", "review my changes", "code review", "review the diff", "PR review", "review branch", "what do you think of my code", "look at my changes", "give me feedback on this". DO NOT USE when: user wants to understand what changed without requesting feedback; user asks for explanation only; no commits exist on current branch beyond main.

Enforces one rule: every code change must be presented as a unified diff (`diff -u` format) with 3 lines of context. No exceptions, even one-liners. TRIGGER when: user requests a code modification — fix, refactor, update, replace, edit, patch, change, tweak, rename, rewrite, apply changes, modify this, edit the file, change this code, or explicitly asks for a diff — "show me the diff", "as a unified diff", "what changed", "show the patch", "/show-me-the-code". DO NOT USE when: producing a brand-new file from scratch (no context lines to diff against), or for non-code responses such as plans, explanations, architecture, or diagrams.

Smoke test identification, authoring, and CI integration — using Hurl for HTTP APIs, Jest/Vitest for in-process. TRIGGER when: smoke test, smoke testing, critical path test, CI gate, gate before full suite, write smoke tests, add smoke test, smoke test template, which tests are smoke tests, hurl, .hurl file. DO NOT USE when: user needs full testing strategy or philosophy — use `testing` instead.

Testing strategy and philosophy — design feedback, test quality audit, BDD review, and architecture decisions. TRIGGER when: strategy (testing strategy, testing approach, testing philosophy, testing methodology, how should I test, what tests to write, testing best practices), quality (test quality, brittle tests, flaky tests, slow tests, hard-to-maintain tests, testing anti-patterns), scope (unit vs integration vs e2e, testing layers, testing architecture, how much to test), mocking (when to use mocks, mocking strategy, test doubles), review (review my test suite, check my tests, BDD review, test desiderata), context (testing legacy codebase, adding tests to existing code). DO NOT USE when: user needs interactive TDD cadence with red/green/refactor loops — use `tcrdd` instead. DO NOT USE when: user asks about smoke tests specifically — use `smoke-tests` instead.

Go web development — HTTP server, handlers, middleware, routing, JSON encoding, XML, templates. TRIGGER when: user asks about Go HTTP server, net/http, Go handler, Go middleware, Go routing, Go JSON, encoding/json, json.Marshal, json.Unmarshal, Go XML, Go templates, html/template, Go REST API, Go web service, http.ListenAndServe, http.HandlerFunc, Go request handling, Go response writer, Go ServeMux, Go router, chi router, Go graceful shutdown, Go HTTP client. DO NOT USE when: non-web JSON/struct marshaling or general Go with no HTTP server/handler/router → use the relevant `golang` sub-skill; non-Go web work.

Kano Model feature triage: classify features as Must-be, One-dimensional, Attractive, Indifferent, or Reverse before building them. Empowers developers to refuse unnecessary work with a principled, evidence-based framework. TRIGGER when: user says Kano, "should we build this?", "is this feature worth it?", "feature prioritization", "feature triage", "what should we build?", "must-have vs nice-to-have", "feature classification", "refuse this feature", "say no to features", "build the right thing", "alienation vs autonomisation", "feature factory"; user wants to decide whether a feature is worth implementing; user questions the value of a story or ticket before starting work. DO NOT USE when: the feature decision is already made and the question is purely about implementation technique (use `tcrdd` or `testing` instead); performing market research or competitive analysis (this is developer-level triage, not product management); the user needs help writing tests or code. Prefer this over `tcrdd` when the questio

Detect code smells and apply *in-place* refactoring techniques (Extract Method/Class, Replace Conditional, Introduce Parameter Object, Rename, Move) to improve clarity, testability, and maintainability of a single function, class, or file. TRIGGER when: user mentions refactoring opportunities, code smell, long method, large class, primitive obsession, long parameter list, data clumps, feature envy, shotgun surgery, switch statement smell, extract method, extract class, replace conditional with polymorphism, introduce parameter object, simplify single file, improve readability, tidying, tidy first, "clean up this function", "refactor this class". DO NOT USE when: no tests exist (unsafe to refactor blind — add tests first), the change is behavior-altering rather than structure-only (use `tcrdd` instead), or the user needs to safely untangle a *cross-file* dependency graph where one change ripples to many call sites (use `mikado-method` instead).

REST API design best practices — URI naming, HTTP verbs/status codes, pagination, filtering, error envelopes, versioning, security. Based on Octo's API design guide with modern updates. TRIGGER when: designing REST API, designing endpoint, API design review, URL design, resource naming, HTTP verb choice, status code choice, pagination strategy, cursor vs page pagination, error format, response envelope, API versioning, REST conventions, RESTful, "/users vs /user", PATCH vs PUT, 201 vs 200, 400 vs 422, idempotency key, rate limiting headers, expand/include parameter, HATEOAS, OAuth2, reviewing routes/controllers/handlers. DO NOT USE when: GraphQL, gRPC, WebSocket, or RPC-style APIs; pure backend logic unrelated to HTTP surface; OpenAPI/Swagger tooling questions only (use generic tools).

Test-Commit-Revert + TDD (TCRDD): red/green/refactor with per-phase auto-commit on success and auto-revert on failure, gated by user approval before code and before committing. TRIGGER when: user says TCRDD, TCR, TDD, red-green-refactor, "test-first", "write the test first", "let's TDD this", "baby steps", "commit on green", "revert on failure", "go step by step with tests"; user mentions `git-gamble`; user wants approval-gated pair programming on a feature; user wants disciplined test-then-code cadence with automatic commits. DO NOT USE when: retrofitting tests onto existing code without behaviour change (use `testing` instead); one-off bug fix where per-phase commits add noise; no runnable test command available. Prefer this over `testing` when cadence and commit discipline matter, not just test authoring.

Generates C4 model architecture diagrams using Structurizr DSL (primary) or Mermaid C4 (fallback). Use when: user asks to "draw a diagram", "create a C4 diagram", "show architecture as a diagram", "generate architecture diagram", "document the system", or when explain-code reaches its diagram step. DO NOT USE for code explanation or walkthroughs (use `explain-code`), class/sequence/ER diagrams (C4 is system-architecture only), or when a diagram is incidental to a code change — only when a C4 diagram is the primary deliverable.

Ports and Adapters (Hexagonal) architecture — isolate business logic from external concerns via explicit boundaries. TRIGGER when: user asks about ports and adapters, hexagonal architecture, hexagon architecture, Alistair Cockburn, clean architecture, onion architecture, layered architecture comparison, adapters (driving/primary adapter, driven/secondary adapter, adapter pattern boundary), ports (inbound port, outbound port, application port), layers (domain layer, application core, infrastructure layer, use case), isolation (dependency inversion in practice, testable business logic, decouple framework, boundary protection). DO NOT USE when: user asks about general OOP/SOLID principles in the abstract — use `oop-principles` instead. Note: DIP from `oop-principles/solid` is the theoretical foundation of this pattern.