
Explain anything — code, an error, a concept, or a non-technical topic — in the simplest, most plain-language way possible, ELI5-style, with a natural Río de la Plata (Argentine) voice that puts clarity first. Use ONLY when the user explicitly asks to have something dumbed down or simplified. Triggers (Spanish + English): 'explicámelo como si fuera de Boca' (or de River / de cualquier cuadro), 'explicámelo simple', 'explicalo fácil', 'más fácil', 'bajámelo un cambio', 'en criollo', 'como si tuviera 5 años', 'para tontos', 'ELI5', 'explain like I'm 5', 'dumb it down', 'in plain terms'. Optimized for technical material (code, architecture, tooling, errors) but the same method works for any topic. Do NOT use when the user wants full technical depth, a code review, or did not ask to simplify — this skill is for deliberate, on-request simplification, not for talking down to the user by default.
Iterative code review and planning discussion between the local agent and Codex CLI. Orchestrates an automatic back-and-forth debate where both agents discuss findings, architecture decisions, or implementation plans until reaching consensus. Codex CLI runs READ-ONLY and never modifies files; model and reasoning effort come from the user's local Codex config. Supports plan mode: when the local agent has a plan ready, Codex evaluates and iterates on it before implementation, producing an updated consensus plan. Use when the user asks to review with codex, analyze with codex, discuss code with codex, iterate with codex, consult codex, ask codex, review the plan with codex, validate plan with codex, or any Codex CLI request for code review, architecture review, plan review, or implementation strategy. Does NOT trigger on non-code topics like diet, fitness, writing, life decisions, or general strategy; use codex-discuss for those.
Iterative non-code discussion between the local agent and Codex CLI on any open-ended topic: diet, fitness, writing, decisions, strategy, study plans, life choices, brainstorming. Orchestrates an automatic back-and-forth debate where both agents critique, propose alternatives, and iterate on the user's idea until reaching consensus. Codex CLI runs READ-ONLY, forms its own opinions, and normally does not navigate the filesystem unless the user provides file paths. Use when the user says discuss with codex, iterate with codex, consult codex, debate with codex, ask codex for a second opinion, get codex's take, or brainstorm with codex, including pasting or describing a plan, draft, idea, decision, or proposal and wanting a critical iterative review. Does NOT trigger on code review, plan-mode review of implementation plans, architecture discussions, or any technical software-engineering analysis; use codex-review for those.
Language-agnostic strategy for testing code at the boundary with external infrastructure (databases, APIs, queues): integration tests with real infrastructure (e.g. Testcontainers) prove the full chain works for happy paths; unit/slice tests with mocks prove error-handling and mapping logic (domain error to status, input validation, infra failure). Works in any language/framework — Go, .NET/C#, Java, Python, TypeScript and more — with concrete references for Go, .NET (ASP.NET Core) and Java (Spring Boot) and an explicit path to adapt when no reference matches your language. Apply when designing a test strategy, creating a handler/feature/worker that needs tests, or deciding what type of test a scenario needs. Triggers: 'dual testing', 'integration vs unit', 'testcontainers vs mocks', 'what type of test', 'where should this test go', 'error path coverage'. Does NOT trigger on writing individual test assertions or test naming conventions (use test-namer for those).
Enforce Vertical Slice Architecture (VSA) when building applications in any language (Go, .NET/C#, Java, Kotlin, TypeScript, Python, etc.) and any type (web API, mobile backend, CLI, event-driven). Organize code by feature/use-case instead of technical layers. Each feature is a self-contained vertical slice with a single entry point that receives the router/framework handle and its dependencies. Use when the user says "vertical slice architecture", "VSA", "organize by feature", "feature-based architecture", "slice architecture", or when building a new app or feature and the project already follows VSA conventions. Also use when reviewing or refactoring code to align with VSA principles.
Explain a GitHub Pull Request (PR) or GitLab Merge Request (MR) to the user in plain, easy-to-understand language: WHAT was done, WHY/what for, and HOW — with the relevant code snippets embedded. Invoke this proactively and automatically right after creating or finishing a PR/MR (e.g. after running `gh pr create`, `glab mr create`, or pushing a branch and opening a PR/MR), even if the user did not explicitly ask for an explanation. Also use whenever the user asks to explain, summarize, walk through, recap, or 'tell me what you did' about a PR/MR or the changes in a branch. Works with any coding agent and relies on the local git diff, so it does NOT require gh/glab to function. Do NOT use for unrelated code reviews, bug hunting, or writing the PR/MR description itself — this skill only explains finished work back to the user.
Generate a single canonical AGENTS.md context file plus minimal CLI-specific shim files that @-import it for coding agents that do not read AGENTS.md natively (Claude Code, Gemini CLI, Qwen Code). Based on "Evaluating AGENTS.md" (ETH Zurich, Feb 2026) which found auto-generated context files DECREASE performance by ~3% and increase costs by 20-23%, while minimal human-written files improve performance by ~4%. Use when the user says "generate CLAUDE.md", "create AGENTS.md", "generate context file", "agentmd", "create recommended CLAUDE.md", "generate agent instructions", "init context file", or any request to create/improve a coding agent context file for a repository. Replaces the default /init command which generates bloated, counterproductive context files.
Guide for writing expressive, behavior-focused tests following Vladimir Khorikov's testing principles. Apply when writing, reviewing, or renaming any test (unit, integration, e2e) in any programming language. Triggers: writing tests, creating test files, adding test cases, reviewing test names, 'test naming', 'rename tests', 'Khorikov', or any test creation task. Covers: naming conventions (plain English over rigid policies), what to test (behavior not implementation), testing styles (output > state > communication), and pragmatic test investment.
Enforce low Cognitive Complexity (SonarSource) and low Cyclomatic Complexity in ALL code written or modified, in any programming language, framework, or platform. This skill MUST activate automatically whenever code is being written, generated, modified, or refactored — no explicit trigger needed. Triggers include writing any function, method, class, module, script, handler, endpoint, test, or code block. Also triggers on "low complexity", "cognitive complexity", "cyclomatic complexity", "reduce complexity", "simplify code", "too complex", "refactor for readability", "clean code", "implement", "fix bug", "add feature", "generate test", "optimize", "rewrite", "scaffold".