Skip to main content
Use this when you want the AI to research before fixing or building. Don’t reveal the task yet—have it explain what’s happening so you know it has enough context.

​
Why it works

  • Forces a shared mental model of systems, flows, and constraints before changes.
  • Reduces wrong-path debugging caused by missing context.
  • Produces a reusable summary you can keep referencing during the work.

​
How to prompt

  • Ask the assistant to explore and document the area: modules, endpoints, data flow, state transitions, and edge cases.
  • Request diagrams or step-by-step traces when helpful.
  • Only after it explains the current state, hand over the actual task or bug.

​
Example prompts

  • Investigating a flow: “Walk through how password resets are handled. Map the endpoints, data flow, and edge cases. Explain what’s happening in detail before I give the task.”
  • Understanding a bug area: “Survey the session-refresh logic. List where tokens are issued, refreshed, and stored. Explain the flow in detail; I’ll share the bug after you have context.”
  • Preparing a new build: “Explore the notifications system. Identify the key modules, data model, and rendering pipeline. Explain it thoroughly before I propose changes.”

​
Quick templates

  • Context sweep (debugging): “Do a context sweep on <area>. Map data sources, key functions, state transitions, and recent changes. Include suspected weak points. Stop with a summary; no edits.”
  • Flow map (journey first): “Map the user journey for <feature>. Steps, inputs, outputs, side effects, error paths. Provide a short diagram or ordered list. Wait for my task.”
  • Performance reconnaissance: “Scan <component/service> for perf risks: redundant calls, render hotspots, unoptimized assets. Report findings and likely fixes; don’t change code.”

​
Bad vs. good (context-first)

  • Bad: “Why is the dashboard slow?”
  • Good: “Profile the dashboard load. Identify API calls, caching, rendering hotspots, and asset sizes. Give a finding list and probable fixes; do not modify code yet.”

​
When to use

  • Before touching fragile systems (auth, payments, data migrations).
  • When behavior is unclear or multiple teams have touched the code.
  • When you need a shared map (flows, dependencies) before planning a change.