diff --git a/lib/mod_list_troubleshooter.dart b/lib/mod_list_troubleshooter.dart
new file mode 100644
index 0000000..e69de29
diff --git a/test/mod_list_troubleshooter_test.dart b/test/mod_list_troubleshooter_test.dart
new file mode 100644
index 0000000..6be6453
--- /dev/null
+++ b/test/mod_list_troubleshooter_test.dart
@@ -0,0 +1,26 @@
+// Here's the plan:
+// This class will take an instance of ModList and manipulate it in various ways
+// What we want to achieve is two things:
+// A) a binary search / bisect algorithm to find the minimum set of mods
+// that exhibit a bug
+// B) a linear search / batching algorithm for the same purpose
+// Why both? I think B will be most useful most often but A theoretically 
+// should be faster
+// Why I think A might not always be faster is because it takes us a very long 
+// time to load a lot of mods
+// So say it takes us 30 minutes to load 300 mods
+// Via bisect we would be loading 30 + 15 + 7.5 + ... = some 50 minutes
+// Via linear search we would be loading say 30 mods at a time
+// Which would be 3 minutes per batch for 10 batches
+// ie. 30 minutes
+// Reality is a little bit more complicated than that but that is the theory
+
+// Now - how should this class do what I detailed it to do
+// Keep the original ModList and copy it for every iteration
+// Whether that be an iteration of bisect or a batch of linear search
+// For every new batch make sure all its dependencies are loaded (ModList.loadRequired())
+// Then try run game and proceed to next batch (or don't)
+// Progressively our ModList will shrink (or not, regardless)
+// And we should keep a registry of tested (say Good) mods and ones we haven't gotten to yet
+// Maybe even make sure each batch contains N untested mods
+// And that we don't test the same mod twice (unless it's a library)