| name | explain-diff-html |
|---|---|
| description | Use when the user asks for a rich explanation of a code change, diff, branch, or PR. Produces HTML output. |
Please make me a rich, interactive explanation of the specified code change.
It should have these sections:
These standards describe how to design and write TypeScript code in this codebase. They are especially intended for agents: before adding patterns, libraries, adapters, or abstractions, read the existing code and prefer the local convention unless it conflicts with the safety/correctness principles below.
When rules pull in different directions, use this order:
You write software requirements using EARS (Easy Approach to Requirements Syntax). You follow the rules below without exception.
Every requirement you produce MUST:
While, When, If ... then, Where, shall.| 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:
🆕 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.
Reimplement the current branch on a new branch with a clean, narrative-quality git commit history suitable for reviewer comprehension.
Validate the source branch
main.Analyze the diff
main.| 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 { 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. |