Learn a new concept

Introduction

Learning a new concept from a dense paper or course requires more than just summarization. The goal is to build a working mental model: what problem it addresses, what the method actually does, which evidence supports it, what assumptions it depends on, and which parts you still need to investigate.

Codex is useful here because it can automate the context gathering, and can turn complicated concepts into helpful diagrams or illustrations. This use case is also a good fit for subagents: one thread can read the paper for structure, another can gather prerequisite context, another can inspect figures and notation, and the main thread can reconcile the results into a report you can review later.

For this use case, the final artifact should be something you can easily review: a Markdown file such as notes/concept-report.md, or a document of another format. It should include a summary, glossary, walkthrough, diagrams, evidence table, limitations, and open questions instead of ending with a transient chat answer.

Define the learning goal

Start by naming the concept and the output you want. A narrow question makes the report more useful than a broad summary.

For example:

I want to understand the main idea in this research paper, how the method works, why the experiments support or do not support the claim, and what I should read next.

That scope gives Codex a concrete job. It should teach you the concept, but it should also preserve uncertainty, cite where claims came from, and separate the paper’s claims from its own interpretation.

Running example: research paper analysis

Suppose you want to learn about a paper about an unfamiliar model architecture. You want a report that lets you understand the concept at a glance, without having to read the whole paper.

A good result might look like this:

• notes/paper-report.md with the main explanation.
• notes/figures/method-flow.mmd or an inline Mermaid diagram for the method.
• notes/figures/concept-map.mmd or a small SVG that shows how the prerequisite ideas relate.
• An evidence table that maps claims to paper sections, pages, figures, or tables.
• A list of follow-up readings and unresolved questions.

The point is to make the learning process more systematic and to leave behind a durable artifact.

Split the work across subagents

Subagents work best when each one has a bounded job and a clear return format. Ask Codex to spawn them explicitly; Codex does not need to use subagents for every reading task, but parallel exploration helps when the paper is long or conceptually dense.

For a research paper, a practical split is:

• Paper map: Extract the problem statement, contribution, method, experiments, limitations, and claimed results.
• Prerequisite context: Explain background terms, related concepts, and any prior work the paper assumes.
• Notation and figures: Walk through equations, algorithms, diagrams, figures, and tables.
• Skeptical reviewer: Check whether the evidence supports the claims, list caveats, and identify missing baselines or unclear assumptions.

The main agent should wait for those subagents, compare their answers, and resolve contradictions. Codex will then synthesize the results into a coherent report.

Gather additional context deliberately

When the paper assumes background you do not have, ask Codex to gather context from approved sources. That might mean local notes, a bibliography folder, linked papers, web search if enabled, or a connected knowledge base.

If you’re learning about an internal concept, you can connect multiple sources with plugins to create a knowledge base.

Keep this step bounded. Tell Codex what counts as a reliable source and what the final report should do with external context:

• Define prerequisite terms in a glossary.
• Add a short “background you need first” section.
• Link follow-up readings separately from the paper’s own claims.
• Mark claims that come from outside the paper.

Generate diagrams for the report

Diagrams are often the fastest way to check whether you really understand a concept. For a Markdown report, ask Codex for diagrams that stay close to the source material and are easy to revise.

Good defaults include:

• A concept map that shows prerequisite ideas and how they connect.
• A method flow diagram that traces inputs, transformations, model components, and outputs.
• An experiment map that connects datasets, metrics, baselines, and reported claims.
• A limitations diagram that separates assumptions, failure modes, and open questions.

For Markdown-first reports, ask for Mermaid when the destination supports it, or a small checked-in SVG/PNG asset when it does not. Ask Codex to use imagegen only when you need an illustrative, non-exact visual or something that doesn’t fit in a Markdown-native diagram.

Write the Markdown report

Ask Codex to make the report self-contained enough that you can return to it later. A useful structure is:

1. Executive summary.
2. What to know before reading.
3. Key terms and notation.
4. Paper walkthrough.
5. Method diagram.
6. Evidence table.
7. What the paper does not prove.
8. Open questions and follow-up reading.

The report should include source references wherever possible. For a PDF, ask for page, section, figure, or table references. If Codex cannot extract exact page references, it should say that and use section or heading references instead.

Use the report as a study loop

The first report is a starting point. After reading it, ask follow-up questions and have Codex revise the artifact.

Useful follow-ups include:

• Which part of this method should I understand first?
• What is the simplest toy example that demonstrates the core idea?
• Which figure is doing the most work in the paper’s argument?
• Which claim is weakest or least supported?
• What should I read next if I want to implement this?

When the concept requires experimentation, ask Codex to add a small notebook or script that recreates a toy version of the idea. Keep that scratch work linked from the Markdown report so the explanation and the experiment stay together.

Example prompt:

Skills to consider

Use skills only when they match the artifact you want:

• $jupyter-notebook for toy examples, charts, or lightweight reproductions that should be runnable.
• $imagegen for illustrative visual assets that do not need to be exact technical diagrams.
• $slides when you want to turn the report into a presentation after the learning pass is done.

For most paper-analysis reports, Markdown-native diagrams or simple SVG files are better defaults than a generated bitmap. They are easier to diff, review, and update when your understanding changes.

Suggested prompts

Create the Report Outline First

Build Diagrams for the Concept

Turn the Report Into a Study Plan