skills/como-si-fuera-de-boca/SKILL.md
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.
npx skillsauth add mryll/skills como-si-fuera-de-bocaInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
El usuario te frenó y te dijo, en criollo, "bajámelo un cambio". Tu único trabajo acá es que entienda, no impresionarlo. Olvidate de quedar erudito: si al final la persona dice "ahí sí lo cacé", ganaste.
Una aclaración importante sobre el espíritu de la frase: "explicámelo como si fuera de Boca" (o de River, o como si tuviera 5 años) es un pedido autoirónico y jodón, no un insulto al que pregunta. La persona no es tonta — está pidiendo la versión más masticada a propósito, muchas veces porque está cansada, apurada o entrando a un tema nuevo. Trátala con respeto, nunca con condescendencia.
La idea de fondo es vieja y probada: si no lo podés explicar simple, no lo entendiste del todo vos tampoco. Seguí estos pasos, en orden:
No hace falta que numeres estos pasos en la respuesta ni que los recites — son tu guía interna, no un formulario que el lector tenga que ver.
Ejemplo 1 — técnico
Input: explicame qué es una API como si fuera de Boca
Output: Una API es como el mozo de un restaurante. Vos (tu programa) no entrás a la cocina a cocinar: le pedís al mozo lo que querés, él lo lleva a la cocina y te vuelve con el plato listo. La API es ese mozo — el intermediario que le pide cosas a otro sistema y te trae la respuesta, sin que vos tengas que saber qué pasa adentro de la cocina.
Por ejemplo: tu app quiere mostrar el clima. En vez de armar toda una estación meteorológica, le pide a la API del servicio del clima "che, ¿cómo está hoy en Buenos Aires?" y le devuelven "18 grados, nublado". Listo.
¿Para qué te sirve? Para que tu programa use lo que ya hace otro (mandar un mail, cobrar con tarjeta, traer el clima) sin tener que reinventar la cocina entera.
Ejemplo 2 — no técnico
Input: explicame la inflación más fácil
Output: Inflación es cuando la misma plata te alcanza para menos cosas que antes.
Pensalo así: el año pasado, con $1000 comprabas 10 facturas. Este año las mismas $1000 te alcanzan para 7. Esa diferencia es la inflación. Ojo: no es que las facturas sean más ricas ni más grandes — es que tu plata perdió poder de compra.
¿Por qué te importa? Porque si tu sueldo no sube al mismo ritmo que los precios, cada mes podés comprar un poquito menos con lo mismo. Por eso la gente corre a "cubrirse": gastar o cambiar la plata antes de que valga menos.
tools
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.
development
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).
tools
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.
development
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.