mateonunez-skills

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.

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

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

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

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

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

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

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.

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.

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

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.

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.

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.

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

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.

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

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.

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.