undefined | Better HN

0 pointsako6mo ago0 comments

I’ve experimented with feature chats, so start a new chat for every change, just like a feature branch. At the end of a chat I’ll have it summarize the the feature chat and save it as a markdown document in the project, so the knowledge is still available for next chats. Seems to work well.

You can also ask the llm at the end of a feature chat to prepare a prompt to start the next feature chat so it can determine what knowledge is important to communicate to the next feature chat.

Summarizing a chat also helps getting rid of wrong info, as you’ll often trial and error towards the right solution. You don’t want these incorrect approaches to leak into the context of the next feature chat, maybe just add the “don’t dos” into a guidelines and rules document so it will avoid it in the future.

0 comments

rufasterisco6mo ago

i too have discovered that feature chats are surely a winner (as well as a pre-requirement for parallelization)

in a similar vein, i match github project issues to md files committed to repo

essentially, the github issue content is just a link to the md file in the repo also, epics are folders with links (+ a readme that gets updated after each task)

i am very happy about it too

it's also very fast and handy to reference either from claude using @ .ie: did you consider what has been done @

other major improvements that worked for me were - DOC_INDEX.md build around the concept of "read this if you are working on X (infra, db, frontend, domain, ....)" - COMMON_TASKS.md (if you need to do X read Y, if you need to add a new frontend component read HOW_TO_ADD_A_COMPONENT.md )

common tasks tend to be increase quality when they are epxpressed in a checklist format

dpkirchner6mo ago

I ask the bot to come up with a list of "don't dos"/lessons learned based on what went right or required lots of edits. Then I have it merge them in to an ongoing list. It works OK.

j / k navigate · click thread line to collapse