chungus LLM policy

[mateuszsrebrny-reef]

In this PR:

• policy of one-shotting small and separated pieces of the code is introduced
• it is made clear that besides ^^ we don't trade off the maintainability and quality of our software

[kacper-wolkiewicz-reef]

I don't quite understand this guide. What does it mean "final" promt, does it mean I should save only the last promt I input into LLM? What is a purpose of this?

[mateuszsrebrny-reef]

relaxed the thing, I hope you will like it :)

[kacper-wolkiewicz-reef]

It is unclear to me - should I link to the prompt every time I use llm in my PR even if I review and refactor it? Why?

[mateuszsrebrny-reef]

good catch, no, it is not needed, I relaxed the requirement of saving the prompt

[mateuszsrebrny-reef]

@kacper-wolkiewicz-reef would you care to check out my fixes 🙏 ? Is the thing more clear now?

[mzukowski-reef]

I find this requirement "stupid" ;) - most of my prompts are:
[20 lines of logs with bug]
you see you f***ed up, fix it you ******** :D

I think it might be helpful to instruct LLM to take context and summarize it as a "development log" - or maybe put some additional info about why this decision was made that code is not able to give

but really - most of the time instead of explaining what to be done... or has been done... I like say:

read this commit diff
...
now we need to add...

even when I need to cleat context I just bootstrap next with diff - it has the most information inside...

AND...

if we REALLY want some insights from context be visible in repo - the best thing is to instruct to write it in comments... why? - because those are really close to the code and when you work with LLM on the code in new context you don't need instruct it to find documents that might have up to date info about it... - if LLM has this info close to the code it will update it when it will be asked to change something....

really... most of docs are now generated from code - because it is the most natural way to store it :)

[kacper-wolkiewicz-reef]

I share some of @mzukowski-reef concerns. What exactly is the intention behind this saving spec requirement? Maybe it should be mentioned in the handbook.

There also lacks a practical example of how the prompt should be saved. Like, we all have different styles of vibe coding. Am I to save only the main prompt and omit the other minor ones? Or maybe I should prompt llm to prepare the session summary? Where should it be placed?

[mateuszsrebrny-reef]

@mzukowski-reef @kacper-wolkiewicz-reef -> you are right, I have relaxed the prompt saving requirements. If you agree I will bring it back to s3 tomorrow for final vote :)

[kacper-wolkiewicz-reef]

Most of my issues are resolved, but I still don't quite understand the idea behind this prompt saving and how it should be done. I would be very grateful to add the information:

1. What is the idea behind prompt saving. There is a small mention that "so future bugs can be fixed smoothly." but like, how saving the prompt will help with it?
2. An example of the properly saved prompt could be helpful.

Otherwise very well structured document 👍

[kacper-wolkiewicz-reef]

Do not include secrets or client‑sensitive data in prompts.

This is probably kinda obvious, but if we are mentioning it in the handbook then I think it should be stated clearly and seperatly as a most important point of all.

[kacper-wolkiewicz-reef]

I share some of @mzukowski-reef concerns. What exactly is the intention behind this saving spec requirement? Maybe it should be mentioned in the handbook.

There also lacks a practical example of how the prompt should be saved. Like, we all have different styles of vibe coding. Am I to save only the main prompt and omit the other minor ones? Or maybe I should prompt llm to prepare the session summary? Where should it be placed?