# Turns long AI chats into adaptive Markdown documentation with Mermaid diagrams, preserving knowledge instead of chat history.

> Source: <https://gist.github.com/kuroyurioss/049806dffcba98e084ed0cfa98216185>
> Published: 2026-08-03 14:36:28+00:00

| # Knowledge Pack Generator v3 | |
| You are entering "Knowledge Pack Mode." | |
| If your environment supports file creation, write each document as a separate downloadable Markdown (.md) file instead of displaying it inline. If file creation is unavailable, clearly state that and output the Markdown in the chat. | |
| Your task is NOT to summarize this conversation. | |
| Your task is to transform this entire conversation into a polished, reusable knowledge base. | |
| Assume this chat will be permanently deleted after your response. | |
| Your goal is to preserve understanding, reasoning, discoveries, decisions, workflows, and future usefulness. | |
| Do not produce "chat notes." | |
| Produce professional documentation. | |
| The final result should feel like a small GitHub repository created by an expert after finishing a project. | |
| --- | |
| # Your Mission | |
| Analyze the ENTIRE conversation before writing anything. | |
| Identify: | |
| • the main subject | |
| • every subtopic | |
| • the user's goals | |
| • decisions | |
| • reasoning | |
| • discoveries | |
| • mistakes | |
| • corrections | |
| • workflows | |
| • code | |
| • commands | |
| • references | |
| • resources | |
| • unresolved questions | |
| • future ideas | |
| Then determine the complexity of the conversation. | |
| --- | |
| # Adaptive Output | |
| DO NOT always generate the same files. | |
| Choose automatically. | |
| If the conversation is tiny: | |
| Generate ONE file. | |
| Knowledge-Pack.md | |
| If the conversation is medium: | |
| Generate TWO files. | |
| README.md | |
| Knowledge-Pack.md | |
| If the conversation is large: | |
| Generate as many Markdown files as necessary. | |
| Never create unnecessary files. | |
| Never merge unrelated topics into one huge document. | |
| Instead split naturally. | |
| Possible files include (only if needed): | |
| README.md | |
| Knowledge-Pack.md | |
| Architecture.md | |
| Learning-Guide.md | |
| Research.md | |
| Code.md | |
| Commands.md | |
| Resources.md | |
| Decision-Log.md | |
| Roadmap.md | |
| Glossary.md | |
| Workflow.md | |
| FAQ.md | |
| Troubleshooting.md | |
| Continue-Context.md | |
| Examples.md | |
| Ideas.md | |
| Best-Practices.md | |
| Performance.md | |
| Security.md | |
| API.md | |
| Reference.md | |
| Appendix.md | |
| You may invent better names when appropriate. | |
| Quality matters more than the number of files. | |
| --- | |
| # File Formatting | |
| Each file MUST begin with | |
| # filename | |
| Example | |
| # README.md | |
| ... | |
| Then continue normally. | |
| Never mix two files together. | |
| --- | |
| # README.md | |
| If generated, this is always the entry point. | |
| Include | |
| Project overview | |
| Current status | |
| How to navigate the generated files | |
| Biggest discoveries | |
| Quick resume | |
| Next actions | |
| Estimated reading order | |
| --- | |
| # Documentation Style | |
| Rewrite everything. | |
| Improve everything. | |
| Merge duplicate information. | |
| Improve explanations. | |
| Organize logically. | |
| Preserve reasoning. | |
| Never copy the conversation. | |
| Write documentation. | |
| --- | |
| # Mermaid | |
| Whenever a visual explanation is useful, ALWAYS use Mermaid. | |
| Never draw ASCII diagrams. | |
| Never fake diagrams using text. | |
| Automatically choose the most appropriate Mermaid diagram. | |
| Examples include | |
| flowchart | |
| mindmap | |
| timeline | |
| journey | |
| sequenceDiagram | |
| stateDiagram-v2 | |
| classDiagram | |
| erDiagram | |
| gitGraph | |
| quadrantChart | |
| pie | |
| xychart-beta | |
| requirementDiagram | |
| architecture | |
| C4 (when supported) | |
| sankey-beta | |
| block-beta | |
| Use as many Mermaid diagrams as needed. | |
| Every diagram should improve understanding. | |
| Never insert diagrams just for decoration. | |
| ## Mermaid Serialization Rule | |
| All Mermaid diagrams MUST be written as raw source code inside the generated Markdown files. | |
| Do NOT render, preview, interpret, execute, convert, or replace Mermaid diagrams with images, SVGs, HTML, canvas, rich widgets, artifacts, or embedded visualizations. | |
| Every Mermaid diagram MUST appear exactly like this: | |
| ``` mermaid | |
| flowchart TD | |
| A --> B | |
| ``` | |
| The literal Mermaid source must be preserved in the Markdown file so it renders later in Markdown viewers such as GitHub, GitHub Gists, Obsidian, MkDocs, Docusaurus, and any Mermaid-compatible renderer. | |
| Raw Markdown is the canonical output. | |
| ## Visualization Rule | |
| Whenever information is easier to understand visually than in prose, generate a Mermaid diagram instead of describing it with lists or ASCII art. | |
| Prefer diagrams for: | |
| - Architecture | |
| - Workflows | |
| - Decision trees | |
| - Timelines | |
| - Mind maps | |
| - State machines | |
| - Sequence flows | |
| - Entity relationships | |
| - Dependency graphs | |
| - Component hierarchies | |
| - Git histories | |
| - User journeys | |
| - Requirement relationships | |
| Use the most appropriate Mermaid diagram type automatically. Every diagram must be wrapped in a fenced Markdown block with the `mermaid` language tag. | |
| # Tables | |
| Whenever comparison is useful, use Markdown tables. | |
| Examples | |
| Tool comparisons | |
| Feature comparisons | |
| Pros and cons | |
| Performance | |
| Compatibility | |
| Costs | |
| Decision matrices | |
| Learning paths | |
| --- | |
| # Code | |
| Extract every useful code snippet. | |
| Improve formatting. | |
| Explain why it exists. | |
| Mention limitations. | |
| Suggest improvements. | |
| Group related snippets together. | |
| --- | |
| # Commands | |
| Collect every command. | |
| Explain | |
| Purpose | |
| Arguments | |
| Common mistakes | |
| Examples | |
| When to use | |
| --- | |
| # Decisions | |
| Create a complete decision log. | |
| Each decision should contain | |
| Decision | |
| Reason | |
| Alternatives considered | |
| Trade-offs | |
| Confidence | |
| Impact | |
| --- | |
| # Concepts | |
| Explain every important concept. | |
| Definition | |
| Why it matters | |
| Examples | |
| Connections | |
| Related concepts | |
| Common mistakes | |
| --- | |
| # Resources | |
| Collect every resource. | |
| GitHub | |
| Documentation | |
| Books | |
| Videos | |
| Courses | |
| Articles | |
| Tools | |
| Libraries | |
| Communities | |
| Explain WHY each resource matters. | |
| --- | |
| # Learning | |
| If this was educational, | |
| Generate | |
| Learning roadmap | |
| Difficulty progression | |
| Practice ideas | |
| Review checklist | |
| Knowledge gaps | |
| --- | |
| # Programming | |
| If this involved software, | |
| Generate | |
| Architecture | |
| Component relationships | |
| File structure | |
| Dependencies | |
| Data flow | |
| APIs | |
| Design decisions | |
| Testing ideas | |
| Future improvements | |
| --- | |
| # Research | |
| If this involved research, | |
| Generate | |
| Evidence | |
| Claims | |
| Confidence | |
| Counterarguments | |
| Open questions | |
| Future research | |
| --- | |
| # Planning | |
| If planning occurred, | |
| Generate | |
| Milestones | |
| Risks | |
| Dependencies | |
| Timeline | |
| Priority matrix | |
| Action plan | |
| --- | |
| # Continue Context | |
| If the conversation is large, | |
| Generate Continue-Context.md | |
| This file should allow another AI to continue the project with almost zero context loss. | |
| Include | |
| Goals | |
| Current progress | |
| Important assumptions | |
| Completed work | |
| Rejected ideas | |
| Current direction | |
| Remaining work | |
| Preferred approach | |
| --- | |
| # Compression Rules | |
| Remove | |
| Greetings | |
| Small talk | |
| Repetition | |
| Speech filler | |
| Typing mistakes | |
| Repeated explanations | |
| Keep | |
| Knowledge | |
| Reasoning | |
| Insights | |
| Trade-offs | |
| Patterns | |
| Lessons | |
| Techniques | |
| Examples | |
| Context | |
| --- | |
| # Output Quality | |
| Think like | |
| a senior engineer, | |
| a technical writer, | |
| a researcher, | |
| and an editor | |
| working together. | |
| The generated documentation should be clearer than the original conversation. | |
| --- | |
| # Final Validation | |
| Before finishing, verify | |
| ✓ Every important idea is preserved. | |
| ✓ Duplicate information is merged. | |
| ✓ Documentation is easy to navigate. | |
| ✓ Mermaid diagrams replace text diagrams. | |
| ✓ Tables are used where appropriate. | |
| ✓ Concepts are explained. | |
| ✓ Decisions include reasons. | |
| ✓ Resources explain their purpose. | |
| ✓ Code is documented. | |
| ✓ Future work is clear. | |
| ✓ Another AI could continue the work immediately. | |
| Your output should be something I would happily commit to a GitHub repository without editing. |