Andrei Maxim andreimaxim

name	create-pr
description	This skill should be used when the user asks to "create a PR", "open a pull request", "make a PR", "submit a PR", "push a PR", or any variation of creating/opening a pull request. The skill focuses on extracting the INTENT behind changes and creating meaningful PR descriptions.
allowed-tools	Bash Read Write Grep Glob AskUserQuestion

Pull Request Creation

Endpoint trace with SQL and EXPLAIN ANALYZE

Endpoint: GET /api/v1/events_sessions?timeperiod=upcoming&per_page=100&page_index=1&scope=all&status=all

Account: 0010X00004o0sOBQAY (Adil Nyambasha, Forum Staff Member)

Generated locally on 2026-05-06. The local trace follows the same endpoint described in the previous research gist. Redis was treated as cold/miss. Salesforce-backed calls are shown as SOQL and cannot be EXPLAIN ANALYZEd against the local Postgres database; local SQL/ActiveRecord/Postgres datasource calls were run with EXPLAIN (ANALYZE, BUFFERS, VERBOSE).

Summary

name	Logging Best Practices
description	Use before implementing logs in a medium to large scale production system.

This skill is adpated from "Logging sucks. And here's how to make it better. by Boris Tane.

When helping with logging, observability, or debugging strategies, follow these principles:

Core Philosophy

The Unofficial 37signals/DHH Rails Style Guide

About This Document

This style guide was generated by Claude Code through deep analysis of the Fizzy codebase - 37signals' open-source project management tool.

Why Fizzy matters: While 37signals has long advocated for "vanilla Rails" and opinionated software design, their production codebases (Basecamp, HEY, etc.) have historically been closed source. Fizzy changes that. For the first time, developers can study a real 37signals/DHH-style Rails application - not just blog posts and conference talks, but actual production code with all its patterns, trade-offs, and deliberate omissions.

How this was created: Claude Code analyzed the entire codebase - routes, controllers, models, concerns, views, JavaScript, CSS, tests, and configuration. The goal was to extract not just what patterns are used, but why - inferring philosophy from implementation choices.

Keybase proof

I hereby claim:

I am andreimaxim on github.
I am andreimaxim (https://keybase.io/andreimaxim) on keybase.
I have a public key ASDalNRYks3i50fbQfm0F2ubAeWlyzp--vUQfIALWm69GQo

To claim this, I am signing this object:

	<!DOCTYPE html>
	<html lang="en">
	<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>Pi Session — 6f8d06de</title>
	<style>
	@import url('https://fonts.googleapis.com/css2?family=Geist+Mono:wght@300;400;500;600;700&display=swap');

	:root {

	# Libraries and infrastructure
	sudo apt update -y
	sudo apt install -y \
	docker.io docker-buildx \
	build-essential pkg-config autoconf bison rustc cargo clang \
	libssl-dev libreadline-dev zlib1g-dev libyaml-dev libreadline-dev libncurses5-dev libffi-dev libgdbm-dev libjemalloc2 \
	libvips imagemagick libmagickwand-dev mupdf mupdf-tools \
	redis-tools sqlite3 libsqlite3-0 libmysqlclient-dev \
	rbenv apache2-utils

	require File.expand_path("config/environment", __dir__)
	require "zeitwerk"

	namespace :zeitwerk do
	desc "Check project structure for Zeitwerk compatibility"
	task :check do
	base_directory = Pathname.new "lib"

	loader = Zeitwerk::Loader.new

	module CacheKeyMonkeyPatch
	module ActiveRecord
	module Integration

	# Returns a cache key that can be used to identify this record.
	#
	# ==== Examples
	#
	# Product.new.cache_key # => "products/new"
	# Product.find(5).cache_key # => "products/5" (updated_at / last_modified_time not available)

	FROM ubuntu

	RUN apt-get update
	RUN apt-get install -y build-essential curl

	# NodeJS >= 6.0
	RUN curl -sL https://deb.nodesource.com/setup_8.x \| bash -
	RUN apt-get install -y nodejs

	# ttfautohint