Add a continuous-improvement friction-log convention
Convention suggested by @jyn.

Assisted-by: Claude Opus 4.8 via Claude Code
change oysvqznoqtznusnnlunxwnnszvuytoum
commit 75d9c0576ac65ba3598474f999e5e8cc538cc083
author Alpha Chen <alpha@kejadlen.dev>
date
parent quyqnmpq
diff --git a/ai/_AGENTS.md b/ai/_AGENTS.md
index 94fe18de..88b55c33 100644
--- a/ai/_AGENTS.md
+++ b/ai/_AGENTS.md
@@ -145,6 +145,24 @@ nowhere.
 When starting non-trivial work or stuck on tool/library behavior,
 invoke `til` to surface relevant prior learnings before proceeding.
 
+## Continuous improvement
+
+When something slows you down mid-task, name it in a line or two at the
+end of your turn. Report only friction you actually hit this turn, not
+hypotheticals, and list at most one or two. If nothing got in your way,
+say nothing — don't invent friction, and don't report its absence.
+
+Friction worth naming:
+- documentation that was wrong and cost extra debugging steps
+- poor errors or diagnostics that don't give enough information to
+  diagnose the problem
+- noisy messages that fill the context window
+- a workaround for a bad API that makes the code worse
+- a step with no shortcuts, done by hand several times
+
+Just name it — don't fix or file it unless asked. Don't pad the reply
+or restate points already made; surface only what hasn't come up.
+
 ## Anti-rationalization
 
 These conventions exist because LLMs skip steps when unsupervised.