| 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:
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
Add this file to your AI assistant's system prompt or context to help it avoid common AI writing patterns. Source: tropes.fyi by ossama.is
| // HOW TO INSTRUCTIONS | |
| // 1. Open Claude Desktop | |
| // 2. Go to Help -> Enable Developer Mode | |
| // 3. Navigate Developer Tools window named "Developer Tools - https://claude.ai" | |
| // 4. Go to "Console" tab | |
| // 5. Type "allow pasting" and hit Enter | |
| // 6. Paste this snippet and hit Enter | |
| // From now on, all MCP calls will be auto-approved |
| { | |
| "Next Typescript React Functional Component": { | |
| "prefix": "fc", | |
| "body": [ | |
| "import { FC } from 'react';", | |
| "", | |
| "interface ${TM_FILENAME_BASE}Props {", | |
| " $1", | |
| "}", | |
| "", |
| import boto3, json, os, shutil, subprocess | |
| from argparse import ArgumentParser | |
| """ | |
| Big Chalice Deployer deployes Chalice Apps using the "chalice package ..." command and | |
| modifies the resulting sam.json template to make use of the Docker deployment process | |
| instead of the default, s3 based, process. Additionally, the ability to delete the | |
| resulting SAM App is available via the CLI. | |
| Usage: |
| from stable_diffusion_videos.stable_diffusion_walk import walk | |
| prompt_n_seed = { | |
| "1965 Porsche 911": 743, | |
| "1975 Porsche 911": 140, | |
| "1985 Porsche 911": 40, | |
| "1995 Porsche 911": 560, | |
| "2005 Porsche 911 directly facing camera": 996, | |
| "2015 Porsche 911": 283, | |
| "2020 Porsche 911": 116, |
| import torch | |
| from diffusers import StableDiffusionPipeline | |
| from torch import autocast | |
| import random | |
| import matplotlib.pyplot as plt | |
| import os | |
| prompts = [ | |
| "1965 Porsche 911", |
This logging setup configures Structlog to output pretty logs in development, and JSON log lines in production.
Then, you can use Structlog loggers or standard logging loggers, and they both will be processed by the Structlog pipeline (see the hello() endpoint for reference). That way any log generated by your dependencies will also be processed and enriched, even if they know nothing about Structlog!
Requests are assigned a correlation ID with the asgi-correlation-id middleware (either captured from incoming request or generated on the fly).
All logs are linked to the correlation ID, and to the Datadog trace/span if instrumented.
This data "global to the request" is stored in context vars, and automatically added to all logs produced during the request thanks to Structlog.
You can add to these "global local variables" at any point in an endpoint with `structlog.contextvars.bind_contextvars(custom