Content Mode: Codebase Analysis for a Nutrition AI App

April 26, 2026

This case study covers a Content Mode session where the input was not a prompt describing a project — it was a GitHub repository. Ileen connected to the repo, read the codebase, and produced a complete project briefing autonomously.

This is the entry point for Content Mode on existing projects: instead of asking the team to write documentation from scratch, Ileen reads what exists and builds the context itself.

At a glance


Project	Codebase briefing for a nutrition AI assistant
Mode	Content Mode
Input	GitHub repository (private, via PAT)
Output	Structured project briefing ready for documentation, marketing or onboarding
Human role	Connect the repo, validate the briefing, choose what to publish

The project

A nutrition AI assistant — a React frontend (nutribot-fe) connected to an AI backend that provides personalised nutrition guidance. The team needed:

Developer documentation for the codebase.
User-facing onboarding guides.
Marketing copy for the product launch.

None of these existed. The team did not want to write a briefing document first — they wanted to connect the repo and let Ileen figure out what the project was.

What Content Mode did

Step 1 — Repository connection

The team provided the GitHub repository URL and branch. Ileen connected via the standard Git integration, cloned the repo into a sandboxed environment and began analysis.

Step 2 — Codebase exploration

Ileen explored the repository structure autonomously:

I’ll analyse this project for you. Let me start by exploring the structure and understanding what we’re working with.

It read:

package.json — dependencies, scripts, project name and description.
src/ directory structure — components, services, hooks, routes.
Key component files — to understand the UI structure and user flows.
API service files — to understand what backend endpoints the frontend consumes.
README and any existing documentation files.
Environment variable templates — to identify required configuration.

Step 3 — Briefing generation

From the codebase analysis, Ileen produced a structured project briefing covering:

What the application does (inferred from component names, routes and API calls).
Who the target user is (inferred from onboarding flows and UI copy found in the codebase).
What the main user flows are (inferred from routing structure and component composition).
What external services the application depends on (inferred from environment variables and API service files).
What documentation gaps exist.

This briefing becomes the context for all subsequent Content Mode tasks in the project.

Why this matters

The typical content generation workflow assumes a human writes a brief. This works for new projects where the team has a clear picture in their head. It breaks down for:

Existing codebases where the documentation was never written.
Inherited projects where the team is new and does not fully know what they have.
Fast-moving projects where the code evolves faster than any human can keep documentation up to date.

In all three cases, connecting the repository and letting Content Mode read the code is faster and more accurate than asking someone to write a brief. The code is the ground truth — not someone’s memory of what they built six months ago.

What comes after the briefing

Once the briefing is ready, Content Mode can produce:

Developer documentation:

Component API reference (props, events, usage examples).
Architecture overview (how the frontend connects to the backend).
Setup guide (how to run the project locally, required environment variables).
Contribution guide.

User-facing content:

Onboarding guide (first-time user walkthrough).
Feature documentation (what each screen does and why).
FAQ (inferred from UI error messages and empty states).

Marketing copy:

Product description for the website.
Feature highlights for a launch post.
Email sequences for user onboarding.

All of this is generated with the codebase as the source of truth — not a brief that may be out of date.

Honest limitations

Content Mode reads what is in the code. If the code is misleading (e.g., a component named UserProfile that actually manages billing), the briefing will reflect the code’s intent, not the intended design.
API endpoints consumed by the frontend are visible; what those endpoints do server-side is not, unless the backend repository is also connected.
Generated documentation requires human review before publishing. Ileen produces accurate-to-the-code content, but editorial judgement on tone, structure and what to include or exclude is a human responsibility.
Private repositories require a Personal Access Token with read access. The token is stored encrypted and used only for the connected project.

Browse the full case study library →