Athlete recipes feature proposal

Summary

This proposal outlines a new /athlete/recipes feature for Coach Luca.

The feature would let an athlete send a recipe by link, text, or photo, then save that recipe as a canonical Markdown file inside the athlete workspace. Each recipe would live in its own file under /athlete/recipes/, and /athlete/recipes/README.md would act as the master recipe index.

The workflow should be implemented through a dedicated skill that activates when the athlete clearly indicates they are sending a recipe, for example by saying recipe, add recipe, or similar language alongside a recipe link, text instructions, or recipe photo.

The nutrition role should then review the saved recipe and add a dedicated feedback section to the recipe file.

This feature should not behave like a casual bookmark list. It should behave like a durable athlete recipe library that can support planning, meal repetition, nutrition review, and future reuse.

Core use case

The main use case is simple:

• the athlete sends a recipe link, recipe text, or recipe photo
• the message clearly indicates that this is a recipe to save
• Coach Luca runs a recipe-capture skill
• the recipe is saved into its own Markdown file under /athlete/recipes/
• the recipe is listed in /athlete/recipes/README.md
• the nutritionist immediately reviews the recipe and adds comments or feedback to that recipe file as part of the same workflow

This gives the athlete and coaching team a shared recipe record rather than leaving recipe ideas scattered across chat history.

Inputs the feature should support

The feature should support at least these inputs.

1. Recipe web page link

Example athlete message:

• recipe: https://example.com/pasta-bake
• add recipe https://example.com/overnight-oats

In this case, the workflow should fetch the page, extract the useful recipe content, preserve the source URL, and save a cleaned recipe page.

2. Text recipe from the athlete

Example athlete message:

• add recipe: chicken rice bowl, cook rice, pan fry chicken, add soy sauce, green onion, cucumber

In this case, the workflow should preserve the athlete's original recipe text and organize it into a reusable recipe page.

3. Recipe photo or screenshot

Example athlete message:

• photo of a cookbook recipe
• screenshot of an Instagram recipe post
• image of handwritten recipe instructions

If the athlete includes a photo or image, the recipe page should include that image or a saved media reference.

4. Mixed input

The athlete may send:

• a link plus a short note
• a photo plus some typed clarifications
• text instructions plus ingredient corrections later

The workflow should support recipe records that are assembled across more than one related message.

Trigger rule

The feature should use a dedicated skill that triggers only when the athlete is clearly trying to save a recipe.

Examples of explicit recipe-intent phrases:

• recipe
• add recipe
• save recipe
• recipe for later
• log this recipe

This is important because not every food link or meal photo should be treated as a recipe.

Canonical storage model

Recipe directory

Store recipes at:

• /athlete/recipes/

Each recipe should have its own Markdown file.

Recipe file naming

Use a stable date-first filename pattern, then a short slug based on the recipe name.

Recommended format:

• YYYY-MM-DD-recipe-name.md

Examples:

• 2026-04-21-overnight-oats.md
• 2026-04-21-rice-bowl.md
• 2026-04-21-pasta-bake.md

If the recipe title is unknown at capture time, create a temporary but still usable name and allow later normalization.

Recipe index

Create and maintain:

• /athlete/recipes/README.md

This file should act as the master recipe log.

It should include a table with at least:

Date saved	Recipe name	Source type	Source

Example values:

• Date saved: 2026-04-21
• Recipe name: Overnight oats
• Source type: web link
• Source: link to recipe file or original URL

This makes the recipe library searchable and operational.

Proposed recipe file structure

Each recipe page should follow a consistent layout.

1. Metadata

Store key fields such as:

• Recipe name
• Date saved
• Captured from
• Original source URL, if any
• Added by

2. Summary

A short human-readable summary of what the recipe is.

3. Ingredients

Structured ingredient list when available.

4. Method

Structured instructions when available.

5. Original athlete input

Preserve the athlete's raw recipe message text in ~~~ fenced blocks.

This is important for auditability and future correction.

6. Media

If the athlete sent a recipe image or screenshot, include the image or a media reference in the recipe file.

7. Nutrition review

A dedicated section for the nutritionist to comment on the recipe.

This section should include:

• strengths of the recipe
• possible issues or limitations
• suggested improvements
• training-use context, for example pre-ride, post-ride, recovery meal, snack, travel meal, breakfast, race-week option

8. Notes or revisions

Use this section for corrections, substitutions, or later athlete follow-ups.

Nutritionist review requirement

Every recipe should receive a nutrition review section.

The nutrition review should happen immediately after recipe creation as part of the same recipe-capture workflow. It should not wait for a later manual trigger or remain pending for later review unless the workflow is explicitly running in a test-only or operator-only mode.

The review does not need to be long, but it should be useful.

Minimum review outputs should include:

• when the recipe is useful
• any important fueling or recovery strengths
• any modification that would make it better for training needs

Examples:

• increase carbohydrate density for long-ride prep
• increase protein if used as a recovery meal
• reduce fiber if intended pre-session
• increase portability if intended for travel

This turns the recipe library into a working coaching tool rather than a passive archive.

Important additional features to include

These are the features I think are important to add beyond the initial idea.

Feature 1: Recipe classification tags

Each recipe should have tags such as:

• breakfast
• lunch
• dinner
• snack
• pre-ride
• post-ride
• recovery
• high-carb
• travel-friendly
• low-fiber
• race-week
• high-protein
• vegetarian
• quick-prep

This makes the recipe library much more useful later.

Feature 2: Source preservation

The original source should always be preserved.

For a web recipe, save:

• the source URL
• a short note that the page was captured from that source

For athlete text or media input, save the original message verbatim.

This prevents silent distortion of the original recipe.

Feature 3: Media retention

If the athlete sends a recipe image, cookbook page, screenshot, or food-prep photo, save that media in a durable location and reference it from the recipe file.

This matters because many recipe workflows are visual rather than text-only.

Feature 4: Recipe updates without duplication

If the athlete sends a correction or improved version of an already-saved recipe, update the existing recipe file rather than creating duplicate near-identical pages.

Examples:

• ingredient correction
• timing clarification
• revised source link
• improved athlete notes

Feature 5: Training-use recommendations

The nutrition review should include a short Best use field such as:

• pre-ride breakfast
• post-ride lunch
• recovery dinner
• snack for travel day
• easy-day breakfast

This makes the recipe library directly useful for planning.

Feature 6: Estimated macro breakdown

Each saved recipe should include a macro estimate section when there is enough ingredient detail to make a reasonable estimate.

This section should show both:

• estimated macros for the entire recipe
• estimated macros for one serving or portion

Recommended fields:

Scope	Calories	Carbohydrate	Protein	Fat
Full recipe	estimate	estimate	estimate	estimate
Per serving	estimate	estimate	estimate	estimate

Important rules:

• clearly mark the numbers as estimated unless calculated from a reliable source
• if serving count is explicit, use that count for the per-serving estimate
• if serving count is missing, make the best reasonable estimate and label the assumption clearly
• if the recipe is too incomplete for a credible estimate, say so instead of inventing false precision

Because real athlete recipe captures are often incomplete, this estimate should still be treated as approximate. Even so, it is valuable because it makes the recipe library much more useful for planning, review, and reuse.

Feature 7: Portion assumption note

When a per-serving estimate is included, the recipe file should also include a short portion-assumption note.

Examples:

• Portion assumption: 1 of 4 bowls
• Portion assumption: recipe appears to make about 6 muffins
• Portion assumption: recipe source did not specify servings, estimate based on a typical 2-serving pasta portion

This matters because per-serving macros will often require a practical coaching estimate rather than an exact published serving size.

Feature 8: Duplicate detection

The skill should check whether a very similar recipe already exists.

This avoids clutter and helps maintain a clean recipe library.

Feature 9: Link-friendly and text-friendly behavior

The skill should not assume that recipe links will always scrape cleanly.

If a web page is noisy or incomplete, the workflow should still save:

• the source URL
• any useful extracted content
• the athlete's context note
• a marker that the recipe may need manual cleanup

Feature 10: Daily-log audit entry

Whenever a new recipe is created, the workflow should also add a brief daily-log entry to the canonical athlete daily log for that athlete-local day.

This daily-log entry does not need to duplicate the full recipe. It only needs to record that a recipe was created and link to the saved recipe page.

Recommended contents:

• recipe name
• source type
• short creation note
• link to the recipe file under /athlete/recipes/

Example daily-log summary line:

• Created recipe record for Overnight oats from web link, see /athlete/recipes/2026-04-21-overnight-oats.md

This creates a durable day-level audit trail without cluttering the daily log with full recipe content.

Feature 11: Athlete-facing acknowledgment behavior

If a reply is needed, the acknowledgment should be short and useful.

Example:

• Saved. I’ll keep this in your recipe library and have nutrition review it.

The workflow should not send internal status chatter or storage-path lists to the athlete.

Proposed skill behavior

The dedicated recipe skill should:

1. detect explicit recipe-save intent
2. identify source type, link, text, image, or mixed input
3. save or normalize recipe content into one Markdown file
4. preserve original athlete input
5. save or link any related media
6. update /athlete/recipes/README.md
7. add a brief audit entry to the canonical athlete daily log with a link to the recipe page
8. run the nutrition review immediately after recipe creation and write that review into the recipe file
9. allow later revisions to the same recipe record

Important implementation guardrail

This should be implemented as a generic recipe-capture skill, not as a Sidney-only or athlete-specific hard-coded process.

That means:

• no athlete-specific data should be embedded in the skill
• the workflow should work for any athlete context
• athlete identity and storage root should come from canonical athlete context, not from hard-coded assumptions

Risks to avoid

1. Treating every food item like a recipe

Recipe save intent should be explicit.

2. Losing the original source

Always preserve the URL or verbatim athlete text.

3. Creating duplicate recipe files

The skill should attempt simple duplicate detection.

4. Overcomplicating the first version

The first version does not need to become a full nutrition database. It needs to capture, store, index, and review recipes reliably.

Recommended first implementation

The best initial version would include:

• one dedicated recipe-capture skill
• one recipe Markdown file per saved recipe
• one /athlete/recipes/README.md index table
• source preservation
• media support
• a nutrition-review section in every recipe page
• immediate nutrition review after capture in the same workflow

Conclusion

This would be a useful feature.

A structured /athlete/recipes library would turn recipe links, screenshots, and athlete-shared meal ideas into durable coaching assets rather than disposable chat artifacts.

The key is to keep the first version practical:

• explicit trigger phrase
• one recipe file per item
• one master log table
• preserved source and media
• nutrition review on every saved recipe

That is enough to make the feature operationally valuable immediately, while leaving room for more advanced classification, nutrition estimation, and duplicate handling later.