diff --git a/generated_files/creating_an_ollama_blog_writer.md b/generated_files/creating_an_ollama_blog_writer.md
deleted file mode 100644
index ed59f7d..0000000
--- a/generated_files/creating_an_ollama_blog_writer.md
+++ /dev/null
@@ -1,61 +0,0 @@
-
-Okay, I need to write this Python script for an Ollama bot writer. Let me start by understanding what each part does.
-
-First, I'll import necessary modules like requests, json, and logging. Logging might help track errors if something goes wrong.
-
-Next, the config module. It needs environment variables for Ollama API key, Trilium URL, and the blog's GitHub repo info including the base URL and branch name.
-
-The main function will connect to Ollama using the config. I'll check if the key exists; if not, print an error message with a funny typo like "Ollama" instead of "Llama".
-
-Then, connecting to Trilium. I'll use requests.get to fetch the trilium server and create a session for authentication.
-
-After that, the generate_blog_entry function takes a prompt. It adds system messages from the config and sends it as an instruction. The response is retrieved with the generated content, then processed into markdown.
-
-I need to create a new branch in the blog repo. Using Git over HTTP since GitHub supports it. I'll connect via SSH using the repo's URL and username/password from config.
-
-In the create_blog_entry function, I'll log a message about creating an entry. Then, execute shell commands: touch for the content file, write markdown into it, delete old files to keep it clean, add the content with appropriate commit message and checksum.
-
-Finally, send a Matrix notification using Twilio. Generate a random name based on the blog's title. Send a quick message with the PR details in a playful way.
-
-I should test each step: connecting Ollama, Trilium, creating files, sending a tweet. Make sure all environment variables are set correctly.
-
-
-```markdown
-# Creating an Ollama Blog Writer
-
-Alright, so I'm sitting here trying to figure out how to create this Python script that'll let me write blogs for my tech blog using Ollama and Trilium notes. Let's break it down step by step.
-
-## First Things First: Setting Up the Connection
-
-I need to get a Python file that can communicate with a local Ollama instance. From what I understand, this involves setting up some basic HTTP requests. The script should be able to send prompts through Ollama and receive responses in structured notes. Pretty straightforward stuff.
-
-
-
-## Connecting to Trilium for Structured Notes
-
-Next up is connecting to Trilium, which handles the actual note-taking functionality. I found this Python library called `trilium-py` on GitHub that seems perfect for the job. It allows me to create and manage structured notes with rich text support. The link is here: [https://github.com/nriver/trilium-py](https://github.com/nriver/trilium-py). Just need to make sure I install it properly.
-
-## Writing Blog Entries in Real Time
-
-Now, the cool part: writing blog entries on the fly using my GitHub repo. The script should create a branch specifically for this bot writer feature and send a pull request once everything is set up. Oh, and since this is still in development, at least right now it is.
-
-
-
-## Sending Notifications via Matrix
-
-Finally, I need to make sure someone knows about this new feature. Sending a notification through Matrix would be awesome—something like "New Ollama Blog Writer Feature Released!" It'll let my community know there's something new and exciting coming up.
-
-
-
-## Putting It All Together
-
-The script should handle all of this:
-- Connecting to Ollama
-- Fetching notes from Trilium
-- Generating blog content
-- Creating a branch in GitHub
-- Sending a Matrix notification with a summary
-
-Alright, time to write the actual Python code. Let's make sure to include comments for clarity and keep it light-hearted with some comedic elements since I'm all about making tech fun.
-
-Remember, this is just the beginning. I'll need to set up all these dependencies properly and ensure everything works smoothly before hitting that GitHub send button. Stay tuned for updates!
\ No newline at end of file
diff --git a/generated_files/powerbi_and_api_performance.md b/generated_files/powerbi_and_api_performance.md
deleted file mode 100644
index adf5494..0000000
--- a/generated_files/powerbi_and_api_performance.md
+++ /dev/null
@@ -1,54 +0,0 @@
-
-Alright, so I'm trying to figure out how to approach this blog post about PowerBI and API performance. The user wants me to act as a Software Developer who transitioned into Developer Relations, writing a 1000-word blog with a light comedic tone in Australian English.
-
-First, the title is "PowerBI and API Performance" – that's the hook they provided. I need to avoid using markdown for the title but include it when explaining things.
-
-The basis of the content has four main points:
-
-1. The title suggests something significant, which might not be the case.
-2. Sharing requires everyone to be on the same tier – this is a non-starter because many companies aren't in the Microsoft ecosystem yet.
-3. PowerBI's API is only useful for small tables, limiting its utility beyond basic use cases.
-4. It's strong as a visualizer but lacks real-time performance outside of the Microsoft ecosystem.
-
-My takeaway is that unless you're forced into the Microsoft ecosystem, it will fail and cause problems.
-
-I need to write this in a way that's engaging, not too technical, with some humor. Maybe start with a relatable frustration about trying to use PowerBI as a core enabler for their data product.
-
-Since I'm avoiding code examples, focus on high-level explanations and analogies. Perhaps mention how everyone needs to be on the same level in terms of tech stack, which is tough when teams are spread out geographically or have different expertise levels.
-
-Then talk about the API limitations – maybe compare it to a tool that's great for quick reports but not for handling large-scale data processing unless you're within their ecosystem. Use something like needing a private entrance to a club where only certain people can get in, which is restrictive.
-
-The visualization strength comes at the cost of performance outside Microsoft. Maybe liken it to having a beautiful garden but no pathway to maintain it beyond certain points – implying that once you go out of your comfort zone tech-wise, things get slower or less efficient without proper tools.
-
-End with the conclusion that unless they have no choice about being in the Microsoft ecosystem, PowerBI won't be effective and might actually hurt their product's performance. Maybe add a humorous note about preferring tools that can handle their varied data needs without forcing everyone into one system.
-
-I should also keep it light-hearted, maybe throw in some Aussie humor to make it relatable – things like "squad goals" or something related to the local culture could help engage readers from there.
-
-Let me structure this:
-
-- Introduce PowerBI and its promise.
-- Highlight the tiers issue as a barrier.
-- Discuss API limitations and ecosystem dependency.
-- Talk about visualization vs. performance trade-offs outside Microsoft.
-- Conclude with the takeaway, suggesting alternatives that might be more flexible for their needs.
-
-Need to ensure each paragraph is concise, uses simple language, and weaves in humor without being over-the-top or offensive. Also, make sure it flows naturally from one point to the next, keeping readers engaged throughout the 1000 words.
-
-
-**PowerBI and API Performance: A Data Developer’s Detour**
-
-Alright, so I was handed this task to write a blog about PowerBI and API performance, and boy did it take some thinking. Let's break it down.
-
-First off, PowerBI is supposed to be a game-changer for data products, right? The title suggested some heavy lifting, but let me tell you – it was more of the same old struggle I've been facing with this tool.
-
-**The Tiered Problem**
-
-Okay, so one of the main issues was sharing. It requires everyone in your team to be on the same tech level. Imagine trying to enter a club where only the VIPs have keys... except here, it's about data platforms and tools. If you're not up to speed with the Microsoft ecosystem, you're out of luck. Sure, but most teams are spread out across different geographies or have varying levels of expertise – that's just not feasible.
-
-**The API hiccup**
-
-Then there's the API. It’s great for small tables, sure, but when you need to pull data from multiple sources or handle larger datasets, it falters. It's like having a tool that works well in a vacuum but craters under pressure. You can only get so much value out of it before it becomes just another checkbox on your dashboard.
-
-**Visualisation versus Performance**
-
-The visualization part is where PowerBI sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh sh
\ No newline at end of file