Jeyaram Ashokraj jeyaramashok

LLM Wiki

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.

The core idea

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.

Overview

How to document a new codebase

Use this template to document a new codebase.

Business Logic

A place to record any important logic that you come across that is worth documenting.

Landmarks

Refers to the different landmarks of a codebase to help you navigate around. Where are the API methods defined? Where are interactions with the database?

Call 1-800-829-1040
Press 1 for English (or other language as desired)
Press 2 for personal tax
Press 1 for form / tax history
Press 3 for other
Press 2 for other
Ignore 2 SSN prompts till you get secret other menu
Press 2 for personal tax
Press 3 for other
Wait for agent!

I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.

I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:

Purpose

Bootstrap knowledge of LLMs ASAP. With a bias/focus to GPT.

Avoid being a link dump. Try to provide only valuable well tuned information.

Prelude

Neural network links before starting with transformers.

Reference https://stackoverflow.com/a/34407620/13287790

$ printf %s 'encode this'|jq -sRr @uri
encode%20this

$ jq -rn --arg x 'encode this' '$x|@uri'
encode%20this

# -r (--raw-output) outputs the raw contents of strings instead of JSON string literals. -n (--null-input) doesn't read input from STDIN.

AJ's Blog Template (ex: Markdown Cheat Sheet)

Markdown is a standardized format for creating web pages and documentation, modeled after the way that people stylize plain-text.

TL;DR

"TL;DR" is a technical term that means "Too Long; Didn't Read". I recommend adding a TL;DR section to all documentation that you create, with the most concise instructions, without much or any explanation, as a quick copy-and-paste or quick-reference example.

Array

Using Git Commit Message Templates to Write Better Commit Messages

The always enthusiastic and knowledgeable mr. @jasaltvik shared with our team an article on writing (good) Git commit messages: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the

	# ruby's git repo investigation zsh one-liner-ish thingy
	# (a starting point for investigating anomalous contributions in git repositories)

	echo "$(find . -type f ! -size 0 ! -path './.git*' -exec grep -IL . "{}" \;)" \| \
	sed -e "s/^\.\///g" \| \
	while read line; \
	do \
	echo ">>>>>>>>$line"; \
	echo "$(git log --follow --find-renames=40% --pretty=format:"%ad%x0A%h%x0A%an%x20<%ae>%x0A%s" -- "$line" \| head -n 4)"; \
	commitdates="$(git log --follow --find-renames=40% --pretty=format:"%ae" -- "$line" \| head -n 1 \| xargs -I {} git log --author={} --pretty=format:"%ad")"; \