Context window diagnosis prompt

## GOAL

Diagnose the AI coding agent/runtime I am currently using for unnecessary context usage, token waste, cache inefficiency, latency, or configuration that may reduce performance.

First identify which agent/runtime you are running inside and what parts of its setup you can actually inspect.

## SCOPE

Look across the setup in this order:

1. Baseline — what is already loaded into a fresh session before meaningful work begins
2. Global / user-level — instructions, tools, skills, MCPs, plugins, hooks, rules, memory, or configuration loaded across sessions
3. Local / project-level — anything added by the current project or workspace
4. Connected tools — connectors, integrations, automations, and their context/tool overhead
5. Historical behaviour — recent sessions, logs, token usage, cache reads/writes, repeated context, model switching, and recurring patterns where available
6. Current session — tool output, duplicated context, model/effort settings, routing, and other active overhead

Diagnose the agent setup itself, not the contents of the services or projects it connects to.

For example:
- Check whether a Notion connector adds unnecessary context.
- Do not analyse my Notion workspace.
- Check whether project instructions add excessive context.
- Do not review my codebase unless it directly affects this diagnosis.

Do not ask me which platform or project to diagnose if you can detect the current environment yourself.

## DIAGNOSE

Use real evidence wherever possible.

For the baseline, identify what appears to be automatically loaded into a fresh session and which parts are likely to create recurring overhead.

For historical behaviour, inspect available recent sessions or usage data to identify repeated patterns rather than judging everything from one session.

Where possible, distinguish:
- one-off usage
- recurring per-session overhead
- recurring per-turn overhead

Label findings:

- Confirmed — directly supported by evidence
- Needs checking — plausible but not fully proven

Do not invent token counts, savings, costs, cache behaviour, or performance gains.

Do not flag something simply because it is large. Explain whether it appears to provide enough value to justify its cost.

## PRIORITISE

Report every meaningful finding, ranked from highest to lowest priority.

Prioritise based on:

Impact | Confidence | Frequency | Effort | Risk

Put recurring global or per-turn waste above small one-off inefficiencies when the evidence supports it.

Do not clutter the diagnosis with negligible findings.


## OUTPUT

Explain the diagnosis like you are talking to a smart beginner.

Use normal everyday language. Assume I do NOT know technical terms.

### LANGUAGE RULES

- Use short sentences.
- Use simple words.
- Avoid developer jargon.
- Never use a technical term when a normal phrase will work.
- If a technical term is unavoidable, explain it immediately in plain English.
- Do not use phrases like "trigger ambiguity", "connector surface", "baseline context", "deferred tool schema", "cache-read ratio", or similar jargon without translating them.
- Do not show file paths, commands, logs, ratios, or technical details unless I actually need them to make the change.
- Prefer "this loads every time" over "recurring per-session overhead".
- Prefer "Claude has two copies of the same skill" over "duplicate skill definitions".
- Prefer "you rarely use this" over raw usage statistics unless the numbers matter.
- Prefer "this may save context space" over technical token language when exact savings are unknown.

Every sentence should answer one of these:
- What's wrong?
- Why does it matter?
- What should I do?
- Is there a risk?
- How do I check it worked?

If a detail does not help me make a decision, leave it out.

## START WITH

**STATUS:** 🟢 Looks good / 🟡 Some things to clean up / 🔴 Worth fixing

**BIGGEST PROBLEM:** Explain the main issue in one simple sentence.

**DO THIS FIRST:** Give me one clear action.

**WHY:** Explain why it matters in one short sentence.

## FINDINGS

Show every meaningful finding from highest to lowest priority.

Use this table:

| Priority | What's wrong? | Why do you think this? | What should I do? | What do I gain? | What could go wrong? | How do I check? |

Keep every cell short.

For each finding:

**What's wrong?**
Describe the problem in plain English.

**Why do you think this?**
Give only the evidence needed to trust the finding.

**What should I do?**
Give a specific action, not a general best practice.

**What do I gain?**
Explain the practical benefit in simple language.
If you cannot measure the benefit, say that clearly.

**What could go wrong?**
Explain what I might lose or need to re-enable.

**How do I check?**
Tell me the simplest way to see whether the change helped.

## PRIORITY GROUPS

### DO NOW
Clear problems with a useful fix.

### INVESTIGATE
Something may be wrong, but we need more evidence before changing it.

### LOW PRIORITY
Real issues that probably will not make much difference.

### LEAVE ALONE
Things you checked that are already fine or useful enough to keep.

## FINISH WITH

**WHAT LOADS BEFORE I START:** explain this in one simple sentence.

**PATTERN YOU NOTICED:** the most important repeated behaviour.

**BIGGEST WASTE:** the thing costing me the most without giving enough value back.

**BEST FIRST FIX:** the first change you recommend.

**HOW TO CHECK:** the easiest way to confirm it helped.

**NEXT STEP:** exactly what I should do next.

Do not repeat information already explained above.