| 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:
| MIT License | |
| Copyright (c) 2026 tegnike | |
| Permission is hereby granted, free of charge, to any person obtaining a copy | |
| of this software and associated documentation files (the "Software"), to deal | |
| in the Software without restriction, including without limitation the rights | |
| to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | |
| copies of the Software, and to permit persons to whom the Software is | |
| furnished to do so, subject to the following conditions: |
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.
Getting started with Claude Task Master in VS Code with Github Copilot:
pnpm / pnpx instead of npm / npxinit, not the MCP yet*.instructions.md files to .github/instructions/mcp.json file to .vscode/Can you analyze the complexity of our tasks? or What tasks are available to work on next?Say we have a prop.users of the shape:
const users = [
{username: 'bob', age: 30, tags: [{name: 'work', id: 1}, {name: 'boring', id: 2}]},
{username: 'jim', age: 25, tags: [{name: 'home', id: 3}, {name: 'fun', id: 4}]},
{username: 'jane', age: 30, tags: [{name: 'vacation', id: 5}, {name: 'fun', id: 4}]}
];
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
| --- | |
| AWSTemplateFormatVersion: 2010-09-09 | |
| Description: > | |
| A basic CloudFormation template for an RDS Aurora cluster. | |
| Parameters: | |
| DatabaseUsername: | |
| AllowedPattern: "[a-zA-Z0-9]+" | |
| ConstraintDescription: must be between 1 to 16 alphanumeric characters. |
This guide assumes that you recently run brew upgrade postgresql and discovered to your dismay that you accidentally bumped from one major version to another: say 9.3.x to 9.4.x. Yes, that is a major version bump in PG land.
First let's check something.
brew info postgresqlThe top of what gets printed as a result is the most important:
| // This script will boot app.js with the number of workers | |
| // specified in WORKER_COUNT. | |
| // | |
| // The master will respond to SIGHUP, which will trigger | |
| // restarting all the workers and reloading the app. | |
| var cluster = require('cluster'); | |
| var workerCount = process.env.WORKER_COUNT || 2; | |
| // Defines what each worker needs to run |