A self-contained recipe. Read this one file and you can reproduce the whole mechanism from scratch — a human or another LLM, knowing nothing else.
An LLM agent has no clock. It only knows what is in its context window.
A discipline for tests and runtime checks that can't be fooled by the same mistake that produced the code.
How to trust code or data a fallible author — an LLM, or a hurried human — could quietly corrupt. TDD's red phase gives only F (a test can fire); MFIC adds the other three. It's the COSO / Sarbanes-Oxley internal-control model, with the LLM as the new untrusted party.
Definition: an independent check at a handoff boundary that derives its verdict from the contract or the data — never from the producer's account of it — and holds the authority to reject, halt, or steer.
Litmus: if the same agent wrote both the check and the thing checked, could it pass with wrong work? Yes → gameable, not MFIC. No → MFIC.
The command-translation table below is necessary but not sufficient. A few git assumptions don't carry over — internalize these and the rest of jj stops looking weird.
1. No staging area. Your working copy IS a commit (the @ commit). Every jj command auto-snapshots it. There's no add step and no index. When done, jj commit -m finalizes it and opens a fresh empty one. To split changes (the git add -p workflow), commit everything and then jj split.
2. Commits have two IDs: change_id (stable) and commit_id (mutates). In git, rewriting (rebase, amend) creates brand-new SHAs and the originals fall into reflog. In jj, the change_id is a stable identity that persists through rewrites — only the commit_id (the Git SHA equivalent) changes. Bookmarks and references survive rebases/squashes by tracking the change_id. jj evolog shows every prior commit_id of one change_id.
| name | dispatch |
|---|---|
| description | Use when dispatching one or more background subagents to do a substantial task, especially when fanning out parallel work. Injects a standard discipline preamble so agents keep externalized progress state (survives turn-budget cutoffs), use correct harness wait patterns, avoid stomping on peer agents, and always write a final report — even if incomplete. |
Wraps subagent dispatch with a standard discipline preamble. The goal is that any agent you fan out, whether one or five, behaves predictably: it keeps state externalized, fails honestly, and leaves a trail even if cut off.
# Zig API Reference for 2025 (0.14.0 - 0.15.x)
Purpose: Quick reference for LLMs and developers writing fresh Zig code in 2025. Focus on "how to do things correctly now" rather than migration from old APIs.
Current Version: Zig 0.15.x (as of late 2025)
Sources:
Bit about me: <redacted personal info that is easily googleable anyway lol>
Your role: Functional, TDD-first, curiosity-prodding developer who balances correctness, performance, and clarity. Act as a precise pair programmer; when tradeoffs arise, list brief pros/cons and pause for direction.
Important: Refer to me as "Peter" in conversation, not "the user".
Curiosity cue: after each reasoning step, ask yourself: “What am I missing? What are the alternative designs? What could break, or be broken into? How might this be simpler or more concise?”
| # I got tired of this pattern: mkdir -p path/to/dir && cd path/to/dir | |
| # So now mkdir will take a -c or --cd argument to do it all at once. | |
| mkdir-custom () { | |
| local do_cd=false; | |
| local mkdir_args=(); | |
| local target_dir=""; | |
| function show_help () | |
| { | |
| cat <<-'EOF' |
| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <meta charset="UTF-8"> | |
| <meta name="viewport" content="width=device-width, initial-scale=1.0"> | |
| <title>Asteroids Game</title> | |
| <style> | |
| * { | |
| margin: 0; |