| 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:
| --- | |
| name: robot | |
| description: Operate a local multi-agent development workflow built on Kata (issue/work ledger), kwt (git worktrees + tmux workspaces), Roborev (optional, operator-approved AI code review), and AgentsView (agent session history). Use when choosing or claiming work, creating a worktree for an issue, recording progress or evidence, reviewing commits, closing or abandoning work, running experiments, handing off between agents, supervising parallel worker agents, recovering after a crash, or when the user mentions kata, kwt, roborev, agentsview, /robot, "ready work", "claim", "worktree", "review loop", or "close with evidence". | |
| --- | |
| # Robot: local agent development control plane | |
| Four tools by Wes McKinney / kenn.io, plus Git. There is no other database. Every piece of state comes from the system that owns it: | |
| | Question | Authority | Look at | |
| #!/usr/bin/env bash | |
| # | |
| # php2shell-triage.sh | |
| # Read-only triage for PHP2Shell (CVE-2026-109618 / CVE-2026-109619). | |
| # It checks whether your PHP build was in the vulnerable range and looks for | |
| # the few signals an exploitation attempt tends to leave behind. | |
| # | |
| # It never changes anything on the system. It only reads logs and lists files. | |
| # Run as root (or via sudo) so it can read FPM and auth logs: | |
| # sudo bash php2shell-triage.sh [WEBROOT] |
Bedrock opens a WebSocket to Netherite (/connect ws://127.0.0.1:19190 by default) and sends JSON packets if subscribed. From testing, received events only use this format - a header and body:
{
"header": {
"eventName": "BlockBroken",
"messagePurpose": "event",
"version": 1 // ive only ever seen version 1| deb https://deb.debian.org/debian/ trixie contrib main non-free non-free-firmware | |
| # deb-src https://deb.debian.org/debian/ trixie contrib main non-free non-free-firmware | |
| deb https://deb.debian.org/debian/ trixie-updates contrib main non-free non-free-firmware | |
| # deb-src https://deb.debian.org/debian/ trixie-updates contrib main non-free non-free-firmware | |
| deb https://deb.debian.org/debian/ trixie-proposed-updates contrib main non-free non-free-firmware | |
| # deb-src https://deb.debian.org/debian/ trixie-proposed-updates contrib main non-free non-free-firmware | |
| deb https://deb.debian.org/debian/ trixie-backports contrib main non-free non-free-firmware |
Esta guía a modo de learning path o roadmap pretende ayudar a las personas que deseen aprender a programar de manera autodidacta, pero que no provienen del mundo de la informática o sistemas, y por lo tanto no tienen ningún tipo de conocimiento.
Por supuesto, también puede servirle a quienes ya estén en tema.
Todo el material aquí contenido es gratuito, y en castellano.
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.