Context Engineering

Source

Derived from: Everything You Need to Know About Context Engineering in 40 Minutes | Ravi Mehta — Peter Yang Saved note: knowledge/youtube/2026-05-04-everything-you-need-to-know-about-context-engineering-ravi-mehta.md

When to Use

Use this skill when Charlie asks for any of the following:

• Build a prototype, app, landing page, dashboard, automation, content system, prompt, skill, or agent workflow.
• Improve weak AI output that feels generic, fake, placeholder-heavy, or “AI slop.”
• Turn a rough idea into a prompt/spec for Codex, OpenClaw, a design tool, or another AI builder.
• Create a reusable prompt or product brief where quality depends on requirements, taste, and real data.

Do not use this for simple Q&A, one-off summaries, or tasks where no creative/product output is being generated.

Core Framework

Before asking AI to build, create a three-layer context stack.

1. Functional Context

Define what the thing must do. Include:

• Goal of the output.
• User or audience.
• Required features, sections, steps, or behavior.
• Inputs and outputs.
• Constraints, edge cases, and success criteria.
• What “done” means.

If this layer is missing, ask one concise question or make reasonable assumptions and label them.

2. Visual Context

Define what good should look and feel like. Use any available references:

• Screenshots, Figma/wireframes, examples, brands, creators, UI patterns, tone references, or formatting examples.
• If no visual reference exists, describe the desired style in concrete terms: layout, pacing, density, vibe, hierarchy, and what to avoid.

Never rely on “make it beautiful” or “make it viral” as visual context. Translate taste into usable constraints.

For OpenClaw skills, include a real example of the expected output inside the SKILL.md. That example is the visual context layer.

3. Data Context

Define the real content or structured data the output should use. Include:

• Real names, examples, URLs, quotes, datasets, products, offers, audience pains, trading pairs, metrics, or source material.
• For prototypes, prefer JSON or structured lists.
• Separate the data layer from the design and function so it can be swapped later without rebuilding the whole system.

If data is missing, create clearly marked sample data only when safe. Avoid pretending placeholder data is real.

Execution Rule

Do not jump straight to the final build prompt. First produce the context stack, then generate the final prompt/spec from it.

Final prompt/spec should combine:

• Functional requirements.
• Visual/taste direction.
• Data/source layer.
• Constraints and acceptance criteria.

Output Format

When this skill runs, output:

## Context Stack

### Functional Context
- Goal:
- Audience/User:
- Required behavior/sections:
- Constraints:
- Success criteria:

### Visual Context
- References/style:
- Layout/format:
- Tone/vibe:
- Avoid:

### Data Context
- Source material:
- Structured data:
- Swap-ready elements:

## Final Build Prompt / Spec
[One clean prompt or Codex-ready spec that uses all three layers.]

## Verification
- [Smallest meaningful check: preview, test, lint, screenshot, sample output, or manual review criteria.]

When improving an existing prompt or skill:

1. Identify which layer is missing or weak.
2. State the gap in one line.
3. Rewrite only the weak layer unless Charlie asks for a full rebuild.
4. Show before/after only if helpful.

Charlie-Specific Application

AI Tooling / OpenClaw

Turn rough agent ideas into Codex-ready specs with:

• Functional context: exact trigger, behavior, files, constraints, verification.
• Visual context: how Elon should sound and behave, with example output.
• Data context: existing workspace files, skill examples, memory rules, Telegram context.

Content Creation

Turn content ideas into stronger assets with:

• Functional context: platform, format, CTA, audience, outcome.
• Visual context: creator references like Chente, Rogan, Westcol, Escuela de Nada, raw/contrarian tone.
• Data context: the actual story, video notes, quotes, market/context facts, Charlie’s take.

Trading Research

Turn trading research requests into structured briefs with:

• Functional context: pair, timeframe, decision needed, risk lens.
• Visual context: preferred format, chart/screenshot references if provided.
• Data context: live market levels, news, journal notes, prior setup rules.

Basic Usage

Charlie can trigger this casually with:

• “Use context stack for this.”
• “Build the 3 layers first.”
• “Make this less AI slop.”
• “Turn this idea into a Codex-ready spec.”
• “Before building, give me functional, visual, and data context.”

What to Avoid

• Do not turn every request into a giant spec. Use the stack only when quality depends on context.
• Do not generate fake data without labeling it as sample data.
• Do not confuse visual context with decoration. It is taste, hierarchy, layout, and reference material.
• Do not treat the video as saying PRDs are dead. The better read: PRDs evolve into living context bundles.
• Do not rewrite prompts longer hoping the model “gets it.” Better context beats longer prompts.
• Do not let the model invent requirements, design, and data simultaneously.