undefined

points

[-]

I wonder if instead of checking the prompts into the repo as files, a better idea would be to store them inside the commit messages.

If prompts are specifications for a change of the system's behavior, then it seems natural to manage them as changes and not as resources.

This would also keep them in the right "historical context" of the repo and avoid the "prompt rot" you were talking about.

by aDyslecticCrow1 hours ago|

parent|

[-]

Git history is a bit annoying to navigate, but that may just be a tooling issue. I've long been bothered by the loss of the review history when merging a PR. Would actually be pretty cool to click on a row of code and see the commit messages that formed that row of code in a little sidebar, and the technical discussions that were behind it.

Functional safety development processes often demand code-review, technical design decisions, changes of plans, or intentional compromises; to be linked together with reference IDs in the code they effect. But the workflow for this is usually extremely manual and absolute misery. But a codebase made like this is like magic to read later.

by ffsm81 hours ago|

parent|

[-]

Gits data structure already allows for that, as you can add additional data to a commit after it was made.

You'd consequently only need to implement your custom git gui and extension to visualize this information.

Maybe a good project for the next weekend? Just eg make a prototype tui in golang and see where you end up

by 1 hours ago|

parent|

prev|

[-]

deleted

by sajithdilshan27 minutes ago|

prev|

[-]

I agree, because at the end of the day the source code is the source of truth and that's what the LLM should look at instead of some months old markdown file.

by viccis32 minutes ago|

prev|

[-]

Already happens in my experience. I'll try to figure out why it keeps doing this one thing and it turns out it's from some poorly advised info it put in a markdown file 20 commits ago that CLAUDE.md or AGENTS.md tell it to treat as gospel.