|
| 1 | +--- |
| 2 | +description: Distill this conversation into a documentation file |
| 3 | +--- |
| 4 | + |
| 5 | +# Doc |
| 6 | + |
| 7 | +Distill the knowledge from this conversation into a documentation file. Figure out what kind of document best captures what was discussed. |
| 8 | + |
| 9 | +## Workflow |
| 10 | + |
| 11 | +### 1. Extract |
| 12 | + |
| 13 | +Review the conversation and identify what's worth documenting: |
| 14 | + |
| 15 | +- Key findings, decisions, conclusions, or insights |
| 16 | +- Context that would be lost when the conversation ends |
| 17 | +- Technical details someone would need to understand or reproduce this work |
| 18 | +- Don't include conversation mechanics — extract the substance |
| 19 | + |
| 20 | +### 2. Place |
| 21 | + |
| 22 | +Figure out where and how to write the doc: |
| 23 | + |
| 24 | +- Check existing project documentation — look at doc directories, READMEs, conventions |
| 25 | +- Match the format, structure, and tone of what's already there |
| 26 | +- If the project has no doc conventions, create a reasonable file in a sensible location |
| 27 | +- Choose a clear, descriptive filename |
| 28 | + |
| 29 | +### 3. Write |
| 30 | + |
| 31 | +Create the documentation file: |
| 32 | + |
| 33 | +- Write it to stand alone — a reader shouldn't need the conversation to understand it |
| 34 | +- Be concise and accurate — verify claims against the code |
| 35 | +- Structure for skimmability — headings, lists, short paragraphs |
| 36 | +- Include date and relevant context (what prompted the investigation, what was the scope) |
| 37 | + |
| 38 | +### 4. Verify |
| 39 | + |
| 40 | +Check the result: |
| 41 | + |
| 42 | +- Re-read the file — does it make sense without the conversation? |
| 43 | +- Is anything important from the conversation missing? |
| 44 | +- Does it fit naturally alongside existing project docs? |
0 commit comments