skills

Review a diff or PR against my conventions — Result not throw, vertical slices, AItError codes, node:test, Biome, entity normalisation, a11y. Findings are triaged by severity (correctness → conventions → polish), not piled in a flat list. Use when reviewing a diff, reviewing a PR before merge, self-reviewing before opening a PR, or when user says "review this", "review the diff", "code review", or invokes `/code-review`.

Ultra-compressed communication mode. Cuts token usage ~75% by dropping filler, articles, and pleasantries while keeping full technical accuracy. Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens", "be brief", or invokes /caveman.

Break a plan, spec, or PRD into independently-grabbable issues using vertical-slice tracer bullets. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.

Turn the current conversation context into a PRD and publish it to the issue tracker. Use when user wants to create a PRD from the current context.

Triage issues through a state machine driven by triage roles. Use when you want to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.

Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill.

Include error telemetry, request context, and queue visibility in production code. Use when writing error handlers, queue processors, async jobs, or boundary code that talks to external systems.

Use strict TypeScript patterns — discriminated unions for domain concepts, exhaustive checks, nominal typing where needed. Use when writing domain logic that deals with user IDs, order IDs, or other concepts that should not be interchangeable even if their runtime type is the same.

Find deepening opportunities in a codebase, informed by domain language in CONTEXT.md and decisions in docs/adr/. Use when you want to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.

Build a throwaway prototype to flush out a design before committing. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when you want to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".

Test-driven development with red-green-refactor loop. Use when you want to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.

Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.

Scaffold the per-repo conventions my other engineering skills assume — pnpm + corepack, Biome (1.9 legacy or 2.x new), node:test posture, CONTEXT.md, docs/adr/. Run once per repo before using result-not-throw, vertical-slices, node-native-tests, or single-tool-per-job. Use when user says "setup mateonunez skills", "scaffold conventions", "wire up my skills", or invokes /setup-mateonunez-skills.

Quick accessibility pass after UI changes — keyboard nav, focus visibility, semantic HTML, aria-live for async, reduced motion. The bar is WCAG 2.1 AA, the same bar I hold mateonunez.co to. Use when reviewing UI changes, when adding interactive components, or when user mentions "accessibility", "a11y", "WCAG", "screen reader", or "keyboard".

I write Conventional Commits with scopes (feat(seo): …, fix(spotify): …). Scope comes from the repo's existing scope catalogue, never invented. Use when staging or proposing commits, when user says "commit", "commit message", or invokes /commit.

Grill me on a plan or change before I write code, but with my canonical four questions baked in — package boundary, error code, vertical slice, ADR. Use when the user says "grill me", "stress-test this", or before starting a non-trivial feature in ait, mateonunez.co, or any repo set up via setup-mateonunez-skills.

When data crosses a system boundary into my code, I normalise it into a typed entity with a __type discriminator and a fixed common shape. The vendor's wire format is not my domain model. Use when ingesting external API data, when adding a new connector, when proposing entity types, or when user mentions "normalize", "entity", "ETL", "__type", or "mapper".

How I write Fastify plugins — fastify-plugin wrapper, idempotency guard, decorator pattern, withX() helper for TS narrowing, module augmentation. The shape I use for fastify-orama, fastify-at-mysql, lyra-impact. Use when writing or reviewing a Fastify plugin, when proposing a new decorator, when configuring `fp()`, or when user mentions "Fastify plugin", "decorate", or "fastify-plugin".

I use node:test + borp + c8, not Jest or Vitest. The runtime ships a test runner — I use it. Use when adding tests, when an agent reaches for Jest/Vitest, when configuring coverage, or when user says "add a test", "test runner", or "borp".

I return Result<T, E extends Error> from business logic — never throw. Errors are typed Error subclasses with a code field (AItError pattern). Throws are reserved for boundary code (Fastify handlers, CLI entry, framework adapters). Use when writing TypeScript service/domain functions, when reviewing code that throws inside happy paths, when the codebase already exposes ok()/err() helpers, or when user says "Result type", "don't throw", or "no exceptions".

Biome is enough. I don't run ESLint or Prettier — never alongside Biome, never instead of it. For every other job (types, tests, packages, build, scripts), one tool. Use when adding lint/format/build/test tooling, when proposing dev dependencies, or when user mentions "Biome", "ESLint", "Prettier", "consolidate tools", or asks "should I add X".

I organise code by feature, not by layer. In monorepos, every feature is a workspace package; new files live with the feature they belong to, not in a shared utils/ pile. Use when adding a new feature, deciding where a file goes, proposing package structure, or when user says "vertical slice", "package by feature", or "where should this go".

Architectural invariants for ait — my personal AI platform. pnpm monorepo, Fastify gateway, Drizzle ORM, Qdrant vectors, Ollama generation, BullMQ scheduling, OAuth connectors (GitHub/Spotify/Linear/Notion/Slack/Google). Use when working in the ait repo, when proposing changes to connectors / RAG / scheduler, or when user mentions "ait", a connector name, or RAG.

When pair-programming on my machine, navigation keys are Colemak hnei, not QWERTY hjkl. Don't suggest hjkl mappings, don't paste default vim chord docs, and don't recommend keybindings that assume QWERTY home row. Use when proposing keybindings, vim chords, tmux shortcuts, or anything keyboard-layout-sensitive on my dotfiles.

Architectural invariants for mateonunez.co — Next.js 16 App Router, React 19 + React Compiler, Tailwind v4, MDX articles, Spotify/GitHub integrations, WCAG 2.1 AA, SEO-first. Use when working in the mateonunez.co repo, when proposing changes to my personal site, or when user mentions Spotify/GitHub integration, MDX articles, or the blog.

Knowledge pack for fastify-orama — a Fastify plugin that integrates Orama full-text search with persistence support.