For example you have:

struct GroceriesSection {
    section: String,
    items: Vec<String>,
}
struct Recipe {
    recipe: String,
    ingredients: Vec<String>,
}
struct ShoppingList {
    recipes_msg: String,
    recipes: Vec<String>,
    checklist_msg: String,
    checklist: Vec<String>,
    list_msg: String,
    list: Vec<String>,
}

Here the types do not make clear which items are used in which places. For example GroceriesSection::String is totally unrelated to the items in Recipe::ingredients. However GroceriesSection::items is the same. So rather than all of these being just String you could have types like:

#[derive(Shrinkwrap)]
struct RecipeName(String);
#[derive(Shrinkwrap)]
struct Ingredient{ name: String }
``
etc. (using shrinkwraprs 3)
This would make things like `ShoppingList` much easier to understand by looking at the struct.

Right now clap isn't being used particularly correctly. Let's aim for arguments like the following for a start: cargo run -- recipe new "tofu chicken rice" --ingredients tofu rice chicken garlic And have the same minus the --ingredients flag run a default that asks the user for ingredients input

For example Groceries contains write_to_file, read_from_file, and get_sections. These aren't really specific to the impl for a given instance of Groceries. It feels like maybe these should be made into a module rather than an impl block.

I'm not a huge fan of running through asking what operation you want to perform. Maybe you could look into using subcommands with the clap crate, so if you want to add a recipe to the library you don't have to enter n a bunch of times.

You could also make a help subcommand that prints some info and maybe with no subcommand you can run the same process you have.

Once you have them broken into subcommands you'll see that running one after the other looks much cleaner too.