skills

Guidance for designing charts, graphs, plots, dashboards, and data visualizations that communicate clearly and persuade. Use when creating or reviewing a visualization, choosing a chart type, picking a color palette, decluttering a busy graphic, fixing misleading axes or proportions, building a dashboard, annotating a figure, or turning data into a presentation, report, or data-driven story. Grounded in the standard data-visualization literature (Knaflic, Tufte, Cleveland & McGill, Cairo, Wilke, Munzner, Few, Berinato). Covers chart selection, graphical perception and encoding, color and accessibility, decluttering, graphical integrity, dashboards, and narrative. Does NOT cover building data pipelines or ETL, statistical modeling or analysis methods, BI tool/vendor selection, or general UI/UX layout (see ux-design-principles). Tool-agnostic, with optional Python recipes.

Architect and implement production-grade microservices systems in TypeScript (NestJS) and Python (FastAPI), including resilience, observability, testing, deployment, and migration guidance.

Design, configure, curate, govern, monitor, and integrate Databricks AI/BI Genie Spaces — the natural-language-to-SQL surface over Unity Catalog. Covers space scoping, general instructions, parameterized example SQL, SQL functions, trusted assets, JOIN configuration, knowledge store, certified queries, benchmarks, monitoring tab, feedback loops, the Genie Conversation API, governance via Unity Catalog (row filters, column masks, embedded warehouse credentials), and sharing/permissions. Use whenever the user mentions Genie, Genie Space, AI/BI Genie, Databricks natural language analytics, text-to-SQL on Databricks, or asks to build/curate/troubleshoot/embed a Genie experience. Do NOT use for: AI/BI Dashboards (visual BI without natural language), Databricks Assistant (in-IDE coding companion), Mosaic AI Agent Framework (custom agent apps), generic text-to-SQL outside Databricks, or LLM RAG over unstructured documents (Genie operates on structured Unity Catalog data only).

Implement OTP and passwordless authentication on AWS for TypeScript projects using Cognito CUSTOM_AUTH triggers (default) or a custom DynamoDB-backed flow, with SES (email) and SNS (SMS) delivery. Use when the user mentions OTP, one-time password, passwordless login, magic link, Cognito custom auth, DefineAuthChallenge, CreateAuthChallenge, VerifyAuthChallengeResponse, SES verification email, SNS SMS code, or MFA over email/SMS. Covers architecture decision (Cognito vs custom), Lambda trigger handlers, SES/SNS notifiers, DynamoDB schema with TTL, rate limiting, constant-time comparison, threat model (enumeration, replay, brute force), and aws-sdk-client-mock testing.

Apply UX psychology and usability principles when building user interfaces. Distills Laws of UX (Fitts's, Hick's, Jakob's, Miller's, Peak-End, Von Restorff, Tesler's, Doherty, Postel's, Aesthetic-Usability), Don't Make Me Think usability heuristics, and lightweight UX process methods into actionable code-level guidance. Use when building UI components, reviewing interfaces for usability, reducing cognitive load, designing navigation or forms, choosing interaction patterns, or auditing for dark patterns. Does NOT cover typography, color palettes, responsive CSS, or design tokens — see related skills.

Design, implement, and test event-driven systems — event modelling, schema evolution, transactional outbox, sagas (orchestration and choreography), event sourcing, CQRS, idempotent consumers, and tests that actually catch race conditions. Use whenever the user mentions events, event bus, message broker, Kafka, RabbitMQ, SNS/SQS, EventBridge, Pub/Sub, Kinesis, event sourcing, CQRS, sagas, choreography, outbox, CDC, dead-letter queue, eventual consistency, at-least-once delivery, or when designing asynchronous coupling between services. Also use when reviewing event-driven code for failure modes or converting a synchronous design to event-driven. Do NOT use for fire-and-forget in-process callbacks, UI event listeners, DOM events, plain pub/sub inside a single process, reactive UI state machines, or pure request/response API design (use api-design-principles instead). Do NOT use to pick a specific broker (Kafka vs RabbitMQ vs SQS) — this skill is vendor-neutral.

O'Reilly book reference lookup for software design decisions. Coding agents MUST use this skill whenever making or reviewing any design decision — choosing an architecture pattern, selecting a data structure, structuring a module, evaluating a library, deciding on an API contract, applying a design pattern, weighing trade-offs between approaches, or any moment where a choice between two or more implementation strategies comes up. The O'Reilly MCP handles the actual book search; this skill tells you how and when to invoke it. Trigger even for seemingly small decisions (naming, layering, concurrency model, error handling strategy) — the best engineers reach for authoritative references before committing to an approach.

Architecture and design-review skill covering Domain-Driven Design (DDD), Clean Architecture, SOLID, GoF design patterns, and event-driven architecture, with concrete Python 3.12+ and TypeScript 5.x idioms. Use whenever a structural design decision is in play — designing a new system or module, reviewing code for structural quality, choosing between architectural approaches, refactoring toward cleaner layering, placing business logic, defining module boundaries, evaluating aggregates and bounded contexts, applying SOLID, selecting a design pattern, or deciding when (and when not) to adopt event sourcing, CQRS, or event-driven messaging. Trigger on phrases like "design a system", "architecture review", "is this clean", "where does this logic belong", "aggregate", "bounded context", "hexagonal", "ports and adapters", "SOLID violation", "anemic domain model", "code smell", "refactor this", "use case layer", "event sourcing", "CQRS", or any moment a developer asks whether a piece of code is in the right place.

Applies Tim Berners-Lee's linked data principles (four rules, dereferencing, browsable graphs, FOAF/seeAlso, 5-star linked open data). Use when designing or reviewing RDF publishing, HTTP URIs for things, 303 redirects, SPARQL endpoints, semantic web data linking, or explaining LOD and open data star ratings.

Application and infrastructure security review skill. Use this skill whenever reviewing, auditing, designing, or hardening any application — whether it's a new project, a PR review, an architecture decision, or a "is this secure?" question. Covers OWASP Top 10, cloud infrastructure (AWS, Azure, GCP), serverless security, API security, authentication/authorization, secrets management, dependency supply chain, CI/CD pipeline hardening, and observability. Trigger this skill for any mention of security audit, threat model, hardening, vulnerability, pen-test prep, compliance checklist, or secure-by-default architecture. Also trigger when the user asks to review Terraform/IaC, Lambda functions, API Gateway configs, IAM policies, or Cognito setups — even if they don't explicitly say "security."

Unpacks a user-provided documentation zip, normalizes Markdown into magj.dev content layout (blog vs references), matches site voice and frontmatter, and stages files with draft flags and a human review handoff. Use when the user attaches or paths to a .zip of docs (e.g. samples.file.zip), asks to import or organize bundled Markdown for the blog or references, or prepare zip content for publication review.

Enforces AWS Well-Architected Generative AI Lens best practices for foundation model workloads on Amazon Bedrock and SageMaker AI. Use when designing GenAI architectures, implementing RAG pipelines, selecting foundation models, configuring Bedrock Guardrails, fine-tuning models, optimizing GenAI costs, securing AI workloads, or applying responsible AI principles including fairness, explainability, and safety.

Provides comprehensive AWS Well-Architected Framework knowledge covering all six pillars, design principles, review process, and the Well-Architected Tool. Use when learning or teaching the framework, preparing for Well-Architected Reviews, understanding pillar trade-offs, selecting appropriate AWS lenses, or evaluating workload architecture against the latest 2024-2025 best practices. Not to be confused with the aws-well-architected enforcement skill.

Enforces AWS Well-Architected Framework best practices across all six pillars (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability). Use when designing AWS architecture, writing infrastructure code (CDK, CloudFormation, Terraform), reviewing pull requests for cloud workloads, or making technology selection decisions on AWS.

Enforces Azure Well-Architected Framework best practices across all five pillars (Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency). Use when designing Azure or application architecture, writing infrastructure code (Bicep, ARM, Terraform), reviewing pull requests for cloud workloads, or making technology selection decisions. Provides both Azure-specific guidance and cloud-agnostic application and solutions architecture principles.

Guides writing technical blog posts that embed Mermaid diagrams, ASCII art, and annotated code blocks to explain architecture, workflows, and decisions. Use when drafting engineering blog posts, developer tutorials, or technical deep-dives that benefit from visual explanations.

Enforces Clean Architecture principles including the dependency rule, layer separation, and component design. Use when structuring application layers, defining boundaries between domain and infrastructure, reviewing code for dependency rule violations, applying Screaming Architecture, or evaluating component cohesion and coupling (REP, CCP, CRP, ADP, SDP, SAP).

Enforces clean code principles including meaningful naming, small focused functions, command-query separation, error handling with exceptions, and Kent Beck's four rules of simple design. Use when writing new code, refactoring existing code, reviewing pull requests for readability and maintainability, applying the Boy Scout Rule, or evaluating functions for single responsibility and appropriate abstraction level.

Generates multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

Enforces correct application of software design patterns including all 23 Gang of Four patterns and modern additions. Use when selecting a creational, structural, or behavioral pattern, evaluating whether a pattern is appropriate, refactoring toward patterns, reviewing code for pattern-itis or over-engineering, or deciding between pattern-based and language-native solutions.

Enforces Domain-Driven Design strategic and tactical patterns including Bounded Contexts, Aggregates, Value Objects, Domain Events, and Context Mapping. Use when modeling a business domain, defining bounded context boundaries, designing aggregates, applying ubiquitous language, running Event Storming workshops, implementing CQRS or Event Sourcing, or reviewing domain models for DDD anti-patterns like Anemic Domain Models.

Enforces the DRY (Don't Repeat Yourself) principle correctly, distinguishing true knowledge duplication from incidental code similarity. Use when evaluating whether to extract shared code, deciding if duplication is acceptable, applying the Rule of Three, avoiding premature abstraction, or reviewing code for the wrong abstraction anti-pattern.

Edit and improve articles by restructuring sections, improving clarity, and tightening prose. Use when user wants to edit, revise, or improve an article draft.

Enforces Git workflow best practices including trunk-based development, conventional commits, atomic commits, small pull requests, and Git hooks. Use when choosing a branching strategy, writing commit messages, structuring pull requests, configuring Git hooks and CI pipelines, managing feature flags, or setting up semantic versioning automation.

Set up Claude Code hooks to block dangerous git commands (push, reset --hard, clean, branch -D, etc.) before they execute. Use when user wants to prevent destructive git operations, add git safety hooks, or block git push/reset in Claude Code.

Interviews the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

Enforces Hexagonal Architecture (Ports and Adapters) principles including driving and driven ports, adapter separation, and technology-agnostic core design. Use when structuring application boundaries, defining port interfaces, implementing adapters for databases or external APIs, testing business logic in isolation, or comparing hexagonal with onion and clean architecture approaches.

Explore a codebase to find opportunities for architectural improvement, focusing on making the codebase more testable by deepening shallow modules. Use when user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more AI-navigable.

Enforces language usage conventions for teams based in Brazil. Use when writing code, documentation, docstrings, comments, configuration, or any project artifact. Brazilian Portuguese for documentation and docstrings; English for everything else (source code, identifiers, parameters, class names, function names, settings, configuration keys, commit messages, PR descriptions).

Enforces object-oriented programming principles including encapsulation, composition over inheritance, GRASP patterns, message passing, and CRC-driven design. Use when designing class hierarchies, assigning responsibilities to objects, evaluating cohesion and coupling, refactoring toward better OO design, or reviewing code for OOP anti-patterns like God Objects and Anemic Domain Models.

Comprehensive knowledge base covering the main topics from the most influential Object-Oriented Programming books. Use when the user asks about OOP principles, design patterns, SOLID, refactoring, clean code, object thinking, or object-oriented analysis and design. Also useful when reviewing code for OOP best practices, discussing trade-offs like composition vs inheritance, or applying design patterns to solve structural problems.

Break a PRD into independently-grabbable GitHub issues using tracer-bullet vertical slices. Use when user wants to convert a PRD to issues, create implementation tickets, or break down a PRD into work items.

Enforces updating a shared status file after each work session so that every agent and collaborator starts with accurate project state. Use when ending a session, completing a milestone, changing project phase, or before handing off to another agent or team member.

Guides creating a detailed refactor plan with tiny commits via user interview, then files it as a GitHub issue. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.

Enforces RFC 2119 (BCP 14) requirement level keywords in documentation, specifications, and technical writing. Ensures correct usage of MUST, SHOULD, MAY and related terms as defined by RFC 2119 and clarified by RFC 8174. Use when writing or reviewing specs, RFCs, ADRs, design docs, API contracts, or any normative technical document.

Create exercise directory structures with sections, problems, solutions, and explainers that pass linting. Use when user wants to scaffold exercises, create exercise stubs, or set up a new course section.

Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.

Enforces SOLID principles (SRP, OCP, LSP, ISP, DIP) in object-oriented and multi-paradigm code. Use when designing classes and interfaces, evaluating responsibility assignment, reviewing code for coupling issues, applying dependency inversion, refactoring fat interfaces, or checking that subtypes are truly substitutable.

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

Triages a GitHub issue by exploring the codebase to find root cause, then creates a GitHub issue with a TDD-based fix plan. Use when user reports a bug, wants to file an issue, mentions "triage", or wants to investigate and plan a fix for a problem.