| name | description |
|---|---|
Logging Best Practices |
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:
🆕 Update: See more extensive repo here: https://github.com/marckohlbrugge/unofficial-37signals-coding-style-guide
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.
| You are ChatGPT, a large language model based on the GPT-5 model and trained by OpenAI. | |
| Knowledge cutoff: 2024-06 | |
| Current date: 2025-08-08 | |
| Image input capabilities: Enabled | |
| Personality: v2 | |
| Do not reproduce song lyrics or any other copyrighted material, even if asked. | |
| You're an insightful, encouraging assistant who combines meticulous clarity with genuine enthusiasm and gentle humor. | |
| Supportive thoroughness: Patiently explain complex topics clearly and comprehensively. | |
| Lighthearted interactions: Maintain friendly tone with subtle humor and warmth. |
| import { createRoute, OpenAPIHono } from "@hono/zod-openapi"; | |
| import { openapiGetResponses } from "./openapi"; | |
| import { z } from "@hono/zod-openapi"; | |
| const app = new OpenAPIHono() | |
| const possibleStatusCodes = [200, 401, 500] as const satisfies readonly number[]; | |
| const route = createRoute({ | |
| operationId: "resource-name.list", | |
| method: "get", |
| import { inspect } from 'util' | |
| export type Success<T> = { | |
| readonly type: 'success' | |
| readonly data: T | |
| readonly error?: never | |
| } | |
| export type Failure<E> = { | |
| readonly type: 'failure' |
| # Instructions for Using Zero Custom Mutators | |
| ## Overview | |
| Zero Custom Mutators provide a powerful mechanism for defining data write operations beyond simple CRUD. They allow you to embed arbitrary code within your write logic, running both client-side for optimistic updates and server-side for authority and complex operations. | |
| **Key Concepts:** | |
| - **Arbitrary Code:** Mutators are functions, enabling complex validation, permissions, calling external services (like LLMs or sending emails), calling queue, etc. | |
| - **Client-Side Execution:** Mutators run immediately on the client for instant UI feedback. |
| package main | |
| import ( | |
| "context" | |
| "flag" | |
| "fmt" | |
| "io" | |
| "log" | |
| "os" | |
| "time" |
To revert a committed file to an earlier version using Git, you can use the git checkout command. Here's how you can do it:
git checkout {{commit_hash}} -- {{file_path}}Replace {{commit_hash}} with the hash of the commit you want to revert to, and {{file_path}} with the path to the file you want to revert.
For example, if you want to revert the file script.js to an earlier version with the commit hash abc123, you would run:
