The “Field Guide” Technique — Persisting Agent Feedback Across Sessions ![rw-book-cover](https://pbs.twimg.com/profile_images/1924503772094517249/DfKkH0ph.jpg) 🔗 **Source:** [The “Field Guide” Technique — Persisting Agent Feedback Across Sessions](https://twitter.com/ThePrimeagen/status/2081066227619836308/?rw_tt_thread=True) > [!note]+ Document Notes > tags: [llm-workflow, context-engineering, coding-agents, developer-tooling, feedback-loops] > author: ThePrimeagen > source: X (Twitter) > reference: https://twitter.com/ThePrimeagen/status/2081066227619836308/ > date created: 2026-07-26 16:10 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: The "Field Guide" Technique — Persisting Agent Feedback Across Sessions > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Original post](https://twitter.com/ThePrimeagen/status/2081066227619836308/) - [Cursor Rules documentation](https://docs.cursor.com/context/rules-for-ai) — the practice the technique is adapted from - [Anthropic — Claude Code memory and CLAUDE.md](https://docs.claude.com/en/docs/claude-code/memory) — the equivalent mechanism in another harness - [agents.md](https://agents.md/) — emerging cross-tool convention for the same problem ## 📝 Summary - **What happened.** A short field-note post describing a personal workflow for improving LLM-generated code reliability, adapted from a Cursor practice. Four moving parts: be maximally specific up front (using voice dictation to sustain the volume of instruction), log every exchange to a markdown file alongside the commit hash for the resulting change, have the agent periodically review those exchanges and distill *generalized* lessons into a "field guide" directory, and keep that directory behind an `init.md` index of links and one-line descriptions so the agent retrieves entries on demand rather than loading everything into context. - **Why it matters.** It's a concrete, low-tech answer to a structural weakness in agentic coding: correction doesn't persist. Every session, the same feedback gets re-given. The post treats accumulated corrections as an artifact to be maintained rather than as conversational exhaust — and pairs it with an indexed-retrieval pattern so the artifact doesn't eat the context window it was meant to save. - **Key stakeholders.** Individual developers using coding agents; teams considering shared convention files (`CLAUDE.md`, `AGENTS.md`, Cursor rules); tool vendors, for whom this is a user working around a memory gap the product could close. - **Risks and tradeoffs.** The reported improvement is uncontrolled self-observation over ten sessions with no baseline and a known confound the author himself names (the model and harness may have changed without his knowledge). The guide also accrues maintenance debt — stale entries silently misdirect the agent, and nothing in the described process prunes them. The author accepts a real limitation up front: the feedback is project-specific, not universal. - **Bottom line.** A good instinct expressed as a workable pattern: separate the *log* (every exchange, with commit hashes) from the *distillation* (generalized, durable lessons), and index the distillation so retrieval is cheap. Worth adopting; worth measuring rather than trusting the vibe. ## 📖 Main Content The post identifies a problem most people using coding agents hit within a week: you correct the same thing repeatedly. The agent produces code, you explain why it's wrong, it fixes it, and the next session it makes the same mistake because the correction lived only in a conversation that ended. The described technique has four distinct stages, and their separation is the interesting part. **Stage one — front-load specificity.** The author describes nitpicking everything and forcing the model to produce the exact code wanted, using voice dictation to sustain a volume of instruction that would be tedious to type. This is a throughput observation rather than a quality one: dictation lowers the cost of being verbose, and being verbose is what the technique requires. It's an ergonomic workaround for a real friction point — high-specificity prompting is expensive in keystrokes, and people default to underspecifying because typing is slow. **Stage two — log everything, with provenance.** Every back-and-forth goes into a markdown file *along with the commit hash for the change*. The commit hash is the load-bearing detail and easy to skip past. It makes each logged exchange traceable to a concrete diff, which means the log is auditable: you can go back and see what the instruction actually produced. Without it you have a transcript; with it you have a dataset linking instruction to outcome. **Stage three — distill, don't accumulate.** The agent reviews the exchanges and the changes and produces "durable and generalized feedback" stored in a field guide directory. This is the step that separates the technique from simply keeping notes. A raw log grows without bound and its signal density falls; a distilled guide is meant to hold lessons that generalize beyond the instance that produced them. Delegating the distillation to the agent is pragmatic — it's summarization, which models do well — though it also means the guide's quality depends on the agent correctly identifying which corrections generalize, and nothing in the post describes a human review gate on that step. **Stage four — index, don't preload.** The directory has an `init.md` that is "just a bunch of links and short descriptions for each file." The stated purpose is explicit: avoid blowing the context. The agent reads the index, decides what's relevant, and uses tool calls to fetch only those files. This is retrieval-augmented context management implemented with a table of contents and a filesystem — no vector store, no embedding pipeline. For a project-scale corpus that is very likely the correct engineering call, since the index fits in a few hundred tokens and file reads are cheap and exact. **The reported result and its honesty.** Over the last ten sessions the in-depth feedback the author has had to give "has greatly reduced despite no change in model or harness that I'm aware of." The hedge is doing real work: harnesses and models update silently and often, so the counterfactual isn't controlled. There's no baseline measurement, no definition of what counts as "in-depth feedback," and n=10 with a single observer who has an obvious stake in the technique working. The claim is a hypothesis worth testing, not a result. **The concession.** The closing line — the feedback is project-specific, not universal, and that's acceptable — is the most useful sentence in the post. It sets the scope correctly. What a project's field guide accumulates is largely local convention (this codebase's patterns, this team's preferences, this stack's gotchas), and expecting those to transfer would produce a bloated, wrong guide. Accepting locality keeps the artifact small and correct. **Contested and uncertain.** Whether the improvement is real, whether agent-authored distillation reliably separates general lessons from one-off corrections, and whether the guide degrades as the codebase evolves are all open. None is addressed in the post, which is appropriate for a field note but means the technique should be adopted with measurement attached. ## 🗒️ Notes Not a transcript and contains no timestamps, so no timestamped subheadings. Dense notes follow. - **Provenance of the idea.** Explicitly borrowed from Cursor — the post is adapting a tool-specific convention (rules files) into a hand-rolled, tool-agnostic workflow. This matters for portability: nothing described depends on a particular vendor. - **Voice dictation as a throughput lever.** Named as part of the technique, not an aside. The insight is that specificity is rate-limited by typing speed, and removing that limit changes what level of instruction is practical. - **Commit hash as the join key.** Each logged exchange carries the hash of the change it produced. This is what makes the log auditable rather than merely voluminous — instruction and outcome stay linked. - **Two-tier storage.** The raw log and the distilled guide are separate artifacts with separate lifecycles. Conflating them is the common failure; keeping them apart is why this works. - **Agent as its own retrospective.** The agent reviews the exchanges and writes the durable feedback. Cheap and well-matched to model capability, but unreviewed — the post describes no human gate on what enters the guide. - **`init.md` as a router.** Links plus short descriptions. Small enough to always load, informative enough to route. This is the whole context-management strategy, and it's about six lines of concept. - **Retrieval by tool call.** "Basic tool calls and operations to find exactly what it's looking for" — the agent pulls what it needs rather than being handed everything. Lazy loading applied to prompt context. - **The evidence.** Ten sessions, self-observed, no baseline, confound acknowledged. Direction of the claim is plausible; the strength of it is unestablished. - **Scope discipline.** Project-specific by design. The author declines to overclaim generality, which is both intellectually honest and, in practice, what keeps the guide useful. ## 📚 References - [Original post — ThePrimeagen on X](https://twitter.com/ThePrimeagen/status/2081066227619836308/) - [Cursor — Rules for AI](https://docs.cursor.com/context/rules-for-ai) — the source convention - [Claude Code — memory / CLAUDE.md](https://docs.claude.com/en/docs/claude-code/memory) — equivalent persistent-instruction mechanism - [AGENTS.md](https://agents.md/) — cross-tool convention addressing the same gap - [Anthropic — effective context engineering for agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) — the just-in-time retrieval pattern the `init.md` index implements ## 🗣️ Paraphrase - The author reports a reliability gain in LLM-produced code from a technique adapted from Cursor, and offers it as a field guide. - Working style up front: nitpick everything, insist on exactly the intended code, and use voice dictation to sustain a high volume of spoken instruction. - Every exchange is recorded to a markdown file, paired with the commit hash of the change it produced. - The agent then reviews those exchanges and the resulting changes and writes generalized, durable feedback into a dedicated field guide directory. - That directory carries an `init.md` holding links and brief descriptions of each file, so the agent can locate what it needs without the whole corpus entering context. - Over roughly the last ten sessions, the amount of detailed correction required has dropped substantially, with no model or harness change the author is aware of. - The accumulated feedback is acknowledged to be specific to the project rather than universally applicable, and the author is content with that limitation. ## 📰 Newsletter **The corrections you give your coding agent evaporate when the session ends. Here's a fix that's mostly just files.** ThePrimeagen posted a short field note this week that's worth stealing regardless of which agent you drive. The problem it solves is one every WordPress dev using Claude Code or Cursor has hit: you explain that this project uses `wp_enqueue_script` with a version constant, not a hardcoded string, and the agent gets it — until tomorrow, when you explain it again. The technique has four parts, and the separation between them is the clever bit. First, be relentlessly specific up front — he uses voice dictation, on the theory that specificity is limited by typing speed more than by patience. Second, log every exchange to a markdown file *with the commit hash* of the resulting change, so you can trace instruction to diff. Third — and this is the part most people skip — have the agent periodically read those exchanges and distill *generalized* lessons into a separate "field guide" directory. A raw log just gets longer; a distilled guide gets more useful. Fourth, and most portable: that directory has an `init.md` that's nothing but links and one-line descriptions. The agent reads the index, figures out what's relevant, and fetches only those files with ordinary tool calls. No vector database, no embedding pipeline — a table of contents and a filesystem. For project-scale knowledge that's almost certainly the right call, and it's the same instinct behind [AGENTS.md](https://agents.md/) and [CLAUDE.md](https://docs.claude.com/en/docs/claude-code/memory) conventions, just with a retrieval layer bolted on so the file doesn't grow until it eats your context window. Two honest caveats, both of which he raises himself. The evidence is ten sessions of self-observation with no baseline, and he explicitly notes the model or harness may have changed underneath him without his knowing — which is exactly the confound that would produce the same result. And the guide is project-specific, not universal. That second one reads like a limitation but is really the design constraint that keeps it working: most of what you'd write down is local convention, and a guide that tried to be universal would be both enormous and wrong. If you're maintaining a plugin with house patterns — sanitization helpers, nonce conventions, the one weird thing about your build step — this is a cheap experiment. Start the log, add the commit hashes, and see whether your correction volume actually drops. Measure it, though. That's the part the post skips. ## ✅ Action Items #### DevRel - Developer advocacy: demo the two-tier pattern (raw log versus distilled guide) in agent-tooling talks — the distinction is the transferable insight and it's routinely collapsed into "just use a rules file." - Education: build a short workshop exercise where participants run five sessions, log them, distill a guide, and measure correction volume before and after. The measurement is the lesson. - Developer experience: ship a starter `init.md` + field-guide directory scaffold alongside SDK examples, so the retrieval pattern is the default rather than something each user reinvents. - Developer marketing: none applicable to this source; nothing here bears on campaigns or attribution. - Community management: none applicable to this source. - Internal/external/cross-project: adopt "index, don't preload" as shared vocabulary when discussing context budgets across teams. #### OSPO - Policy & Governance: decide whether agent field-guide files are project artifacts subject to review or personal scratch. If they influence generated code that ships, they're closer to config than to notes and belong in review. - License Compliance: none applicable to this source. - Security Management: worth flagging — a field guide is instruction that an agent follows, so it's an injection surface. A guide file writable by anyone who can open a PR can steer code generation. Treat it with the same review rigor as CI config. - Software Inventory: none applicable to this source. - Developer Support: publish a recommended layout for agent convention files so contributors aren't guessing between `CLAUDE.md`, `AGENTS.md`, and ad-hoc directories. - Community Engagement: none applicable to this source. - Strategic Alignment: none applicable to this source. #### Community - Maintainers: consider a committed field-guide directory capturing project conventions an agent keeps getting wrong — it doubles as onboarding documentation for humans, which is a genuine two-for-one. - Contributors: the log-with-commit-hash habit is a good personal practice regardless of agents; it makes your own decisions auditable months later. - Sponsors: none applicable to this source. - Ecosystem: none applicable to this source. #### WordPress - Core: none applicable to this source; no Core-facing claim appears. - Core Performance: none applicable to this source. - Core AI: relevant — if guidance is published for contributors using AI assistance, the two-tier pattern and the injection-surface warning both belong in it. - **Core Program Team:** none applicable to this source. - Mobile: none applicable to this source. - Playground: none applicable to this source. - Community: none applicable to this source. - Training: a Learn WordPress lesson on context management for coding agents would land well, and this pattern is small enough to teach in fifteen minutes. - Marketing: none applicable to this source. - Support: none applicable to this source. - Design: none applicable to this source. - Documentation: the `init.md` index pattern is a documentation-architecture idea in disguise — short routing descriptions beat comprehensive front pages for both agents and humans. - Photos: none applicable to this source. - TV: none applicable to this source. - Polyglots: none applicable to this source. - Accessibility: none applicable to this source. - Meta: none applicable to this source. - CLI: a `wp` scaffold command for an agent convention directory would be a small, useful addition if the conventions settle. - Hosting: none applicable to this source. - Tide: none applicable to this source. - Openverse: none applicable to this source. - Themes: none applicable to this source. - Plugins: none applicable to this source. #### The WPOCC - Programs: none applicable to this source. - Projects: none applicable to this source. - Funding experiments: none applicable to this source. ### FAIR - Technical independence: mildly relevant — a tool-agnostic, plain-files convention resists vendor lock-in in a way that a proprietary rules format does not. Worth noting as a general principle. - Policies and covenants: none applicable to this source. - Productized governance artifacts: none applicable to this source. ## 🧪 Hypotheses 1. **Persisted distilled feedback reduces correction volume.** Developers maintaining a distilled field guide require measurably fewer corrective turns per task over time than developers using the same model and harness without one. 2. **Distillation beats raw logging.** A distilled guide outperforms an equivalently-sized raw transcript excerpt at reducing repeat errors, because signal density rather than volume drives the effect. 3. **Indexed retrieval preserves quality at lower context cost.** An `init.md` routing index plus on-demand file reads achieves comparable output quality to preloading the whole guide, at materially lower token cost. 4. **Guides decay.** Field guide entries lose accuracy as the codebase evolves, and un-pruned guides eventually degrade output relative to no guide at all. 5. **Locality is real.** Field guide entries transfer poorly across projects — a guide built on project A measurably underperforms on project B relative to a guide built on B. 6. **Dictation raises specificity.** Voice input produces longer, more specific prompts than typing for the same developer and task, and specificity mediates the quality effect. ### 📊 Methodology - **H1 (correction volume).** Within-subjects, counterbalanced: developers complete matched task sets with and without a field guide, order randomized. Primary outcome: corrective turns per completed task, with "corrective turn" operationally defined in advance (a turn whose content rejects or revises prior agent output). Pin model version and harness build for the duration — the author's own confound is the main threat, and it's controllable. Blind the coders scoring turns to condition. - **H2 (distillation vs raw).** Three arms at matched token budgets: distilled guide, raw log excerpt, no artifact. Same tasks, same model. Outcome: repeat-error rate against a pre-registered list of project-specific error types. Matching on token budget is essential or the comparison just measures context size. - **H3 (indexed retrieval).** A/B the loading strategy — full preload versus `init.md` index plus tool-call retrieval. Measure output quality (rubric-scored by blinded reviewers), total tokens consumed, and wall-clock latency. Expect a quality/cost frontier rather than a clean win. - **H4 (decay).** Longitudinal, 6+ months on an actively developed codebase. Periodically sample guide entries and have maintainers label each still-accurate / stale / actively wrong. Correlate stale-entry proportion with error rate. This is the study most worth running and the one nobody will run, because it takes half a year. - **H5 (locality).** Cross-over: build guides on projects A and B, then apply each to the other. Measure error rates in matched and mismatched conditions. Also worth extracting: which *categories* of entry transfer (language idioms) versus which don't (local architecture). - **H6 (dictation).** Within-subjects, same developer and tasks, voice versus typed input. Measure prompt length, a specificity rubric score, and downstream output quality. Mediation analysis to test whether specificity carries the effect. Watch for the obvious confound that dictation suits some task types better than others. ### ❓ Questions - Who reviews what enters the field guide? If the agent distills its own lessons unreviewed, a misdiagnosed correction becomes durable instruction — an error that compounds rather than washes out. - How do you prune? Nothing in the technique removes entries, and a guide that only grows will eventually contain contradictions the agent resolves arbitrarily. - Is a field guide a security boundary? It's instruction an agent follows. In a shared repository, who can write to it, and does the review process treat it like code? - At what corpus size does `init.md` routing break down? A short index works for dozens of files; does it survive hundreds, or does it need hierarchy? - Does this substitute for or compensate for missing product features? Vendors are shipping memory systems; is this pattern durable engineering practice or a workaround with a shelf life? - Would a team-shared guide outperform per-developer guides, or would committee-authored conventions lose the specificity that makes personal guides work? - Does knowing corrections are being recorded change how the developer phrases them — and would that alone account for some of the improvement? ### 🔮 Future Research - **Provenance-linked instruction datasets.** The commit-hash pairing quietly creates a dataset of instruction → diff. That's a research asset for studying which prompt forms produce which code changes, and nobody appears to be collecting it systematically. - **Automated guide hygiene.** Tooling that flags entries contradicted by the current codebase, or unreferenced for N sessions, would address the decay problem directly and is straightforwardly buildable. - **Comparative context strategies.** Systematic comparison of preload, index-and-retrieve, and embedding-based retrieval for project-local agent knowledge, measured on the same tasks. The field has strong opinions and thin evidence. - **Transfer taxonomy.** Empirically classify which correction types generalize across projects and which don't. That would tell you what belongs in a personal guide versus a shared one versus a language-level convention. - **Human review gates.** Test whether requiring human approval for guide entries improves accuracy enough to justify the friction, or whether agent self-distillation is good enough. - **Multimodal input effects.** Beyond dictation — whether input modality systematically changes prompt specificity and, through it, output quality. ### 💡 Implications - **Practice.** The immediately adoptable idea is architectural, not procedural: keep the log and the distillation as separate artifacts with separate lifecycles, and put a routing index in front of the distillation. That structure is cheap and survives changes in tooling. Pair it with a pruning habit, which the post omits and which is where this pattern will fail first. - **Policy.** Agent instruction files occupy an ambiguous governance slot — treated as personal notes but functioning as configuration that shapes shipped code. Projects should decide explicitly whether these files are reviewable artifacts, and version them if so. - **Security.** A writable instruction file that an agent obeys is an injection surface. In any repository where contributors can propose changes, a field guide deserves the review posture given to CI configuration, not the posture given to a README. This is under-recognized and will produce an incident before it produces a policy. - **Education.** Context management is becoming a core developer skill and is barely taught. This pattern is an excellent teaching vehicle precisely because it's implementable with a directory and a markdown file — no infrastructure required, so the concept stays visible instead of hiding behind a vector database. - **Funding models.** Minimal direct relevance. Indirectly, tool-agnostic plain-file conventions reduce dependence on any single vendor's memory feature, which matters for projects that need their tooling choices to outlast a funding cycle. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade 7.0; Flesch Reading Ease 72.2 ("fairly easy"), computed on the 184-word post. Short declarative sentences and everyday vocabulary. The score understates real difficulty: comprehension requires prior knowledge of coding agents, context windows, commit hashes, and tool calls, none of which is explained. It reads easy to an audience that already knows the domain and is close to opaque outside it. #### 👀 Visual learners - Present: essentially nothing — plain prose with no diagram, screenshot, or directory tree. - Improve: a four-box flow (dictate → log+hash → distill → index) would communicate the entire technique faster than the text does, and a sample directory listing showing `init.md` alongside two guide files would remove all remaining ambiguity about the structure. #### 🔊 Aural learners - Present: nothing; text-only post with no audio companion. - Improve: this is a natural 90-second explainer. Ironically the author describes using voice input to *create* the workflow while offering no voice output describing it. #### 🗣️ Verbal learners - Present: reasonably strong for the format — "field guide" is an apt metaphor that carries the concept, and the prose is direct and unpadded. - Improve: key terms go undefined ("blow the context," "harness," "durable and generalized feedback"). One clause defining what makes feedback durable versus incidental would materially raise the post's usefulness, since that judgment is the crux of the technique. #### 🧩 Kinesthetic learners - Present: the post is procedural and could be followed as written — the steps are ordered and concrete. - Improve: no starter template, no example `init.md` contents, no sample guide entry. Anyone implementing this must invent the file formats themselves, which is precisely the friction that stops adoption. #### 🧠 Logical learners - Present: clean causal structure — problem (repeated corrections), mechanism (persist and distill), constraint (context limits), solution (index and retrieve). The reasoning chain is coherent and each step follows from the last. - Improve: the evidence doesn't match the structure's rigor. No baseline, no metric definition, n=10, and a self-acknowledged confound. A single before/after number with a stated definition of "in-depth feedback" would transform the claim. #### 🧑‍🤝‍🧑 Social learners - Present: posted to a platform built for reply and discussion, from an author with an active audience — the comment thread is part of the artifact. - Improve: no explicit invitation to share variants, no repository to contribute example guides to. A shared collection of field-guide entries by language or framework would be genuinely valuable and costs nothing to start. #### 🧘‍♀️ Solitary learners - Present: well-suited — short, self-contained, immediately actionable alone, with no dependency on others to try it. - Improve: no self-check. A reader can't tell whether their distilled entries are any good. Two contrasting examples — one durable lesson, one that shouldn't have been generalized — would give solitary readers a calibration reference. #### 🌿 Naturalistic learners - Present: minimal, though the underlying pattern is genuinely ecological — a system that accumulates, prunes (in principle), and adapts to its local environment rather than importing universal rules. - Improve: the lifecycle framing is missing entirely. Guides age, entries die, environments shift. Explicitly treating the guide as something tended rather than built would strengthen the technique and address its main unaddressed weakness. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: plain text with no markup complexity, which reads cleanly. - Improve: the platform wraps content in its own component structure; the post itself introduces no barriers. No images means no alt text is required — but also no visual aid exists. Maps to WCAG 2.2 AA 1.1.1 Non-text Content (satisfied vacuously). #### Keyboard navigation - Present: not assessable for the post itself; it's static text within a third-party platform. - Improve: platform-level concern outside the author's control. Maps to WCAG 2.2 AA 2.1.1 Keyboard. #### Contrast and readability - Present: inherits platform theming, which meets baseline contrast in both light and dark modes. - Improve: nothing author-controllable. Maps to WCAG 2.2 AA 1.4.3 Contrast (Minimum). #### Text resizing and reflow - Present: plain text reflows without issue at any zoom level. - Improve: none needed. Maps to WCAG 2.2 AA 1.4.4 Resize Text, 1.4.10 Reflow. #### Media and captions - Present: not applicable — no audio or video content in the post. - Improve: if the suggested explainer video is ever made, captions and a transcript would be required. Maps to WCAG 2.2 AA 1.2.2 Captions. #### Forms and interactions - Present: not applicable to this source; the post contains no interactive controls. - Improve: none. #### Standards reference - Aggregate: minimal accessibility surface, and what exists is largely platform-controlled rather than author-controlled. The one substantive author-side gap is cognitive rather than technical — undefined jargon in a post that reads as beginner-friendly by grade level but assumes substantial domain knowledge. That's a 3.1.3 Unusual Words consideration (AAA, not AA), but worth naming because the mismatch between apparent and actual difficulty is the real barrier here. ### 🌍 DEIB Assessment #### Cultural breadth - Present: the technique is culture-neutral and stack-agnostic — nothing in it assumes a region, language, or market. - Improve: assumes access to paid coding agents, reliable dictation (which performs measurably worse for non-native and accented English), and the discretionary time to maintain a personal knowledge system. None of that is universal, and the dictation dependency in particular is an unacknowledged equity issue. #### Inclusive language - Present: neutral throughout; no gendered defaults, no pejoratives, no exclusionary framing. - Improve: heavy undefined jargon ("blow the context," "harness," "tool calls") is the main inclusion barrier. It gatekeeps by assumed knowledge rather than by intent, which is the more common and less visible form. #### Neurodiversity support - Present: genuinely good — short, chunked, sequential, one idea per line, no wall of text. The externalization of memory into a maintained artifact is itself a pattern many neurodivergent developers already use deliberately. - Improve: the implicit expectation of consistent per-session maintenance is a real barrier for anyone with variable executive function. Automating the log capture — rather than relying on discipline — would make the technique far more robust and is entirely feasible. #### Representation - Present: not applicable in the usual sense; the post describes a personal workflow with no case studies, quoted individuals, or imagery. - Improve: the implicit reader is a solo developer with full control over tooling and process. Contributors working under prescribed toolchains, in regulated environments, or on shared machines can't necessarily adopt this, and that constraint goes unmentioned. #### Psychological safety - Present: notably good for the genre. The author hedges the causal claim, names his own confound, and concedes the limitation rather than overselling. That models honest technical communication in a space full of unqualified productivity claims. - Improve: the framing "reliability of the code I produce via LLM" quietly assumes agent-generated code as the baseline. For developers who don't work that way — by preference or by policy — the post offers nothing, and its confident framing can read as though that choice is already settled. ### ✅ Logical Validity #### Strong reasoning - **Sound causal identification of the problem.** The implicit premise — corrections don't persist because conversations end — correctly locates the failure in system architecture rather than in model capability. That's the right diagnosis and it's what makes the proposed fix structural rather than a prompting trick. - **Constraint-driven design.** The `init.md` index is explicitly justified by the context limit ("this way I don't blow the context"). The solution is derived from a named constraint rather than adopted by fashion, which is why it's a lazy-loading index and not an embedding pipeline. Good engineering reasoning, tersely expressed. - **Appropriate scope limitation.** Concluding that the feedback is project-specific and accepting it is inductively sound — accumulated corrections on one codebase are evidence about that codebase, and the author declines to generalize past his evidence. Rarer than it should be. - **Explicit confound acknowledgment.** "Despite no change in model or harness that I'm aware of" names the exact alternative explanation. The hedge "that I'm aware of" is epistemically precise: he's reporting the limit of his knowledge rather than asserting the counterfactual. #### Fallacies - **Post hoc reasoning (weak form) — the results claim.** "Over the last 10 sessions, the in-depth feedback I've had to give has greatly reduced." Temporal succession is offered as the evidence for causation. Competing explanations are untested: the author's own prompting improved with practice; the tasks in those ten sessions were easier or more familiar; silent model or harness updates occurred; or his threshold for what counts as needing correction drifted. **Weakness:** the central empirical claim is uncontrolled. **Fix:** define "in-depth feedback" operationally, count it, and compare against a matched period without the guide, pinning the model version. Mitigating credit — the author flags the main confound himself, which moves this from fallacy to acknowledged limitation more than most posts manage. - **Small-sample generalization.** Ten sessions, one observer, one project, no control. **Weakness:** insufficient to support "greatly improved the reliability of the code I produce" as stated in the opening line, which is a stronger and broader claim than the ten-session observation supports. **Fix:** soften the opening to match the evidence, or gather the evidence to match the opening. - **Unexamined delegation.** The agent distills its own durable feedback, with no described review. The implicit assumption is that a model reliably distinguishes lessons that generalize from corrections that were situational — an assumption neither stated nor tested. **Weakness:** if distillation is unreliable, the guide accumulates confident wrong instruction, and the failure mode is silent and compounding. **Fix:** state the assumption, and add a human review gate on guide entries — or at least periodically audit them against the codebase. - **Omission — no pruning mechanism.** Not a fallacy in the strict sense but a genuine gap in the argument's completeness: a monotonically growing artifact in a changing codebase must eventually contain stale entries, and the post's logic provides no answer. **Fix:** add an expiry or audit step. #### Tone of voice - Terse, practical, and unembellished — a working note rather than a persuasion attempt. No hype vocabulary, no engagement bait, no promise of transformation. - Confident but appropriately hedged. The strongest claim ("greatly improved") appears in the opening; every subsequent claim is qualified. The overall effect is credible rather than promotional. - Self-aware and non-defensive. The closing concession about project specificity is offered plainly, without apology or spin, and does more for the post's credibility than any amount of evidence would. - Assumes peer status with the reader — no explanation of basics, no condescension either. That's a deliberate register choice that trades reach for density. ### 🛡️ DARVO Analysis - **Deny:** No DARVO pattern present. There is no accusation in play and nothing being denied or minimized. The opposite occurs — the author volunteers the primary weakness in his own evidence (possible silent model or harness changes) and concedes a scope limitation nobody had raised. - **Attack:** Not present. No person, group, tool, or critic is attacked. The post makes no comparative claims against other techniques and disparages nothing, including the tools it borrows from — Cursor is credited rather than positioned against. - **Reverse victim/offender:** Not present. No accused party, no victim framing, no role reversal. The post is a first-person workflow description with no adversarial dimension whatsoever. - **Emotional cues and rhetoric:** Flat, technical register with no grievance, no in-group/out-group framing, and no emotional appeal. Applying the DARVO lens here is a category error — the frame is built for defensive responses to accusation, and this is an unprompted technical field note. The honest finding is absence, and the epistemic weaknesses that do exist are logged under Fallacies where they belong. ## 🎯 Conclusion - **Bottom line.** A compact, portable pattern for making agent corrections persist: log every exchange with its commit hash, have the agent distill generalized lessons into a separate guide, and put a lightweight `init.md` index in front of that guide so retrieval stays cheap. The architecture is the contribution — separating raw log from distillation, and routing rather than preloading. The evidence behind the reported improvement is thin and the author says so. - **Next steps for readers.** Try it on one project with measurement attached. Define what counts as a correction before you start, count them for a week without the guide, then a week with it, and pin your model version so the comparison means something. That single discipline is what the post lacks and what would turn a plausible pattern into a known one. - **Two additions worth making.** Add a pruning step — audit guide entries against the codebase monthly and delete what's stale, because nothing in the described process prevents rot. And add a review gate on what the agent writes into the guide, since an unreviewed misdiagnosis becomes durable instruction that compounds instead of washing out. - **One thing to watch.** If your guide lives in a shared repository, treat it as executable configuration rather than notes. It's instruction an agent obeys, which makes it an injection surface, and it should get the review posture you'd give CI config. ## 🔄 Refactor Appendix — The "Field Guide" Technique > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) ### [H1] Distilled guides beat raw logs for agent memory > [!quote] ID:rw_pending > have the agent review the back and forth and the changes and come up with durable and generalized feedback **Context & use**: - Post body, third step - The separation of raw log from distilled artifact is the actual contribution. A transcript grows without bound and loses signal density; a distilled guide is meant to hold only what generalizes. Most people conflate these and end up with a file too big to load and too noisy to help. **Tags**: #xref #share **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H2] Index the knowledge base instead of preloading it > [!quote] ID:rw_pending > This way I don't blow the context, but instead it can do some basic tool calls and operations to find exactly what it's looking for. **Context & use**: - Post body, fourth step - Retrieval-augmented context with a table of contents and a filesystem — no vector store required. For project-scale corpora this is very likely the right engineering call, and it's the most portable idea in the post. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H3] Commit hashes make the instruction log auditable > [!quote] ID:rw_pending > every single back and forth is recorded to the markdown file. Along with each commit hash for the change. **Context & use**: - Post body, second step - Easy detail to skip; it's what turns a transcript into a dataset. Each instruction stays joined to the diff it produced, so you can later check what a given prompt actually caused. Useful well beyond agent workflows. **Tags**: #xref **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H4] Project-specific feedback is the right scope > [!quote] ID:rw_pending > Now the feedback is project specific, and is not universal. I am okay with that. **Context & use**: - Post body, closing line - Reads as a limitation, functions as the design constraint that keeps the artifact small and correct. Most of what accumulates is local convention; a guide attempting universality would be both enormous and wrong. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Externalized memory needs a router, not just a store **Claim** (one sentence, Courtney's voice): A knowledge base only stays useful when something cheap sits in front of it deciding what to retrieve. **Evidence pointer**: [[#H2]] > [!quote] > This way I don't blow the context, but instead it can do some basic tool calls and operations to find exactly what it's looking for. **Scope & conditions**: Holds when retrieval is cheap and exact and the index stays small enough to always load — true for project-scale file corpora. Breaks when the corpus outgrows a flat index (hierarchy or embeddings become necessary), when descriptions are too vague to route on, or when entries go stale and the router confidently sends the reader somewhere wrong. **Links**: - [[Progressive summarization]] — because extends - [[MOC as index note]] — because applies-in Obsidian vault structure - [[Context engineering]] — because evidence-for <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Direct parallel to my own vault: `init.md` with links and one-line descriptions is structurally identical to a MOC. Worth asking whether my MOCs are written as *routers* (short descriptions optimized for deciding what to open) or as *summaries* — they're currently closer to summaries, which is the less useful shape for both agents and me. — #fleeting #inbox #articleseed - [F2] Security angle nobody is discussing: a committed agent instruction file is an injection surface with the review posture of a README. Anyone who can open a PR can steer code generation for everyone. This deserves a write-up before it produces an incident. — #fleeting #inbox #articleseed - [F3] The missing step in every version of this pattern is pruning. Guides only grow; codebases change. An automated "flag entries unreferenced for N sessions or contradicted by current code" tool is small and doesn't exist. — #fleeting #inbox - [F4] Dictation-as-specificity-lever is an accessibility observation hiding in a productivity tip — and it cuts both ways, since dictation accuracy is measurably worse for accented and non-native English. Worth noting if I ever teach this. — #fleeting #inbox - [F5] Cross-link candidate: this is the same two-tier structure as the deep-read pipeline itself (raw transcript → distilled 18-section analysis → atoms). Same insight, different domain. — #fleeting #inbox #xref ### → Things 3 (max 2 actions) - [ ] Audit whether my Obsidian MOCs are written as routers or summaries — rewrite two as short link-plus-description indexes and compare retrieval usefulness — vault structure #things - [ ] Add a field-guide directory with init.md to one active plugin repo, log corrections with commit hashes for two weeks, and count corrective turns before and after — agent workflow experiment #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Tweets/The “Field Guide” Technique — Persisting Agent Feedback Across Sessions.md|The “Field Guide” Technique — Persisting Agent Feedback Across Sessions by ThePrimeagen]] ## Highlights - Then I have the agent review the back and forth and the changes and come up with durable and generalized feedback that it stores in a directory (field guide). The directory has [init.md](http://init.md) that is just a bunch of links and short descriptions for each file. ([View Highlight](https://read.readwise.io/read/01kyg108z33kw50zhjv0x5ww4j)) - Note: [H1] Distilled guides beat raw logs for agent memory. The separation of raw log from distilled artifact is the actual contribution here — a transcript grows without bound and loses signal density; a distilled guide holds only what generalizes. Most people conflate the two and end up with a file too big to load and too noisy to help. CAVEAT: the agent distills its own lessons with no described review gate. If distillation is unreliable, a misdiagnosed correction becomes durable instruction — a failure mode that is silent and compounds rather than washing out. - Tags: context-engineering, atom/zettel/z1, atom/literature/h1 - This way I don't blow the context, but instead it can do some basic tool calls and operations to find exactly what it's looking for. ([View Highlight](https://read.readwise.io/read/01kyg10kfctfcj2ahfd9wx0wvx)) - Note: [H2 / P1] Index the knowledge base instead of preloading it. Retrieval-augmented context implemented with a table of contents and a filesystem — no vector store. For project-scale corpora this is very likely the right engineering call, and it's the most portable idea in the post. DIRECT PARALLEL TO MY VAULT: init.md with links + one-line descriptions is structurally identical to a MOC. Worth asking whether my MOCs are written as ROUTERS (short descriptions optimized for deciding what to open) or as SUMMARIES. Currently closer to summaries — the less useful shape for both agents and me. - Tags: context-engineering, atom/literature/h1, atom/zettel/z1 - Over the last 10 sessions, the in-depth feedback I've had to give has greatly reduced despite no change in model or harness that I'm aware of. ([View Highlight](https://read.readwise.io/read/01kyg10yz5gag21ncqq9588m57)) - Note: FALLACY (post hoc, weak form): temporal succession offered as evidence for causation. Untested competing explanations — the author's own prompting improved with practice; those ten sessions were easier or more familiar; silent model/harness updates occurred; or his threshold for "needs correction" drifted. Mitigating credit: he names the main confound himself ("that I'm aware of"), which is epistemically precise — reporting the limit of his knowledge rather than asserting the counterfactual. That moves this closer to acknowledged limitation than to fallacy. FIX if I run this experiment: define "in-depth feedback" operationally, count corrective turns for a week without the guide and a week with it, and PIN the model version so the comparison means something. - Tags: atom/literature/h3, fallacy/post-hoc ## Links - [[3. Resources/Permanent Notes/Raw Provenance and Distilled Guidance Serve Different Memory Jobs]] — evidence-for: commit-linked logs and a small routed guide solve separate memory needs. - [[3. Resources/Permanent Notes/Retrieval Quality Is Set by the Unit of Knowledge Not the Retrieval Algorithm]] — applies-in: local distilled lessons outperform preloading a raw archive.