These three are essential screens, so good job nailing down their design. I might also include a fourth essential screen, which is a screen that lists all the recipes that have been saved for a user. I would also try to name every screen that you need, even if you don't want to diagram them all ahead of time. Then, it would be very helpful to diagram how all your screens relate to each other (how you can navigate to and from each of them), as well as how data gets stored and retrieved from the backend. Think about your database schema.

The link to your project tracker did not work for me, so you may want to fix that as well.

I like the concept. Stick with this plan for your first prototype, but then I would try to incorporate some kind of user-interaction feature. As it stands, users aren't able to share recipes or look up recipes that have been submitted publicly to be discovered. For instance, maybe you get randomly paired with a friend who has a similar taste in food? (You can compare ingredient types, or food categories like "Mexican food" or "Mediterranean.")

The SMS service that you mention is interesting. It actually contains two problems—first, how do you push text updates to users' phones? And second, what recipes are being pushed out? If all recipes are private, then which recipes are getting recommended to users?