diff --git a/.github/workflows/generate-readme.yml b/.github/workflows/generate-readme.yml
index a1988f7..df6003c 100644
--- a/.github/workflows/generate-readme.yml
+++ b/.github/workflows/generate-readme.yml
@@ -4,8 +4,8 @@ name: Generate README
 on:
   push:
     paths:
-      - './source/data/applications.json'
-      - './source/data/categories.json'
+      - './source/data/**'
+      - './source/components/**'
   workflow_dispatch:
 
 jobs:
@@ -37,5 +37,7 @@ jobs:
           git config --global user.name "github-actions[bot]"
           git config --global user.email "github-actions[bot]@users.noreply.github.com"
           git add source/testing/test.md
-          git diff --quiet && git diff --staged --quiet || git commit -m "Auto-generate README from JSON"
+          git add readmes/
+          git add README.md
+          git diff --quiet && git diff --staged --quiet || git commit -m "Generate READMEs"
           git push
diff --git a/source/components/footer.md b/source/components/footer.md
index 97445d7..34a4b6f 100644
--- a/source/components/footer.md
+++ b/source/components/footer.md
@@ -24,14 +24,10 @@ Projects that were once on this list but removed - usually due to abandonement o
 
 ## FAQ
 <details>
-  <summary><b>How about a JSON file with scripts or a website?</b></summary> <br />
-A JSON file with scripts that generate the README(s) would make fundamental changes and reorganization far easier whilst minimizing formatting and grammatical errors. A website would provide much requested features like tag based filtering and even automation.
+  <summary><b>Will there ever be a definitive-opensource website?</b></summary> <br />
+A website is definitely on the roadmap. It would provide much requested features like tag based filtering and, on the backend, automate much of what we currently have to do manually. However, for the foreseeable future, the list will remain as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within. The complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file.
 <p>&nbsp;</p>
-However, for the foreseeable future, the list will to be edited directly as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within, not how to present said projects.
-<p>&nbsp;</p>
-The current markdown system could also be considered a stepping stone to guage the community's needs prior to building a more complex system. I will likely migrate to a JSON file as the project scales and when I have time to architect such a system. 
-<p>&nbsp;</p>
-As for the website, the complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file. Depending on the popularity of the project, however, this idea will remain in the back of my mind. 
+The current system could also be considered a stepping stone to guage the community's needs prior to building a website, which would inherently be far more complex. 
 </details>
 
 ## License
diff --git a/source/components/header.md b/source/components/header.md
index 1eb7e16..5d16bc3 100644
--- a/source/components/header.md
+++ b/source/components/header.md
@@ -38,10 +38,11 @@ This list aims to serve as a single centralized location for the best of open so
 
   Definitive-opensource was initially a single markdown file that was edited directly. However, as the list scaled, this manual approach proved cumbersome and limited. Additionally, as popularity increased, we recieved many requests for README's of individual platforms - something that would be not be realistic to do manually.
   <p>&nbsp;</p>
-  As of v0.6.2-beta, the project was fundamentally re-made. Categories and applications were put in categories.json and applications.json, respectively. Python scripts were made to generate one main list and more platform-specific lists. This was paired with GitHub actions to run the scripts when any changes were made. This makes refactoring the list format far easier and eliminates typos. This new system also opens the door to 
+  As of v0.6.2-beta, the project was fundamentally re-made. Categories and applications were put in categories.json and applications.json, respectively. Python scripts were made to generate one main list and more platform-specific lists. This was paired with GitHub actions to run the scripts when any changes were made. This makes refactoring the list format far easier and eliminates typos.
   <p>&nbsp;</p>
   The project architecture is as follows:
-  ```text
+  <p>&nbsp;</p>
+  <code>
   definitive-opensource/
   ├── assets/
   ├── readmes/
@@ -55,7 +56,7 @@ This list aims to serve as a single centralized location for the best of open so
   |       └── utils/
   │   └── testing/
   └── README.md
-  ```
+  </code>
 </details>
 
 ## Project Status