Compounding

Look across all the past conversations and session records you can access—not just this conversation—and identify the three highest-leverage opportunities to make our future work easier, better, or more autonomous.

Actively search for historical conversation records before analyzing. Do not limit yourself to open chats or the context already loaded. Where filesystem access is available, inspect archived chat and session logs stored on disk, along with any history maintained by the agent or project.

Do not give me a personality profile or generic productivity advice. Look for patterns that support a specific change in how I work, how you work, or how we work together.

Look especially for:

• - something I repeatedly correct, explain, request, repair, or do manually;
• - a point where projects repeatedly stall, sprawl, or become difficult to resume;
• - an unusually successful interaction whose ingredients could become a repeatable recipe;
• - important context, decisions, or ideas that repeatedly become stranded in old conversations;
• - work I could delegate more fully if you had better context, instructions, tools, checks, or boundaries;
• - and recurring failures that appear to share the same underlying cause.

Choose the three opportunities with the greatest likely payoff. For each:

1. 1. Name the pattern plainly.
2. 2. Show me the specific evidence you found across past conversations.
3. 3. Explain what the pattern is currently costing me—or what value we are leaving unused.
4. 4. Propose one concrete change that could improve future work.
5. 5. Give me one small way to test whether that change actually helps.

Rank the three by likely leverage. Don't change anything yet.

Search for the available evidence without asking me to locate it or clarify where it lives. If your access is limited, continue with what you can inspect and briefly note the limitation at the end.

Search the historical conversations and session records you can access, including archived logs on disk where available. Find feedback, instructions, or reminders I have given an agent more than once.

Look for repeated feedback about verbosity, format, taste, initiative, questions, assumptions, tools, safety, quality, or how work should be carried out.

Choose the five corrections with the greatest likely payoff. For each:

1. 1. State the repeated feedback plainly and cite the evidence.
2. 2. Explain when it applies and when it might not.
3. 3. Show what the repetition is costing me.
4. 4. Recommend where it should live: the top-level AGENTS.md or CLAUDE.md in my Personal OS, a project-specific AGENTS.md or CLAUDE.md, a reusable skill, a saved prompt or template, a checklist or evaluation, or an automation's instructions.
5. 5. Draft the exact instruction and one way to test whether it works.

Do not turn context-specific preferences into universal rules. Don't modify anything yet.

Search our historical work for outputs I clearly accepted, praised, used, shipped, or revised only lightly. Find nearby examples of similar work that I rejected, heavily corrected, or abandoned.

Choose three comparisons with enough evidence to teach us something useful. For each:

1. 1. Show me the strong and weak examples.
2. 2. Identify the concrete differences in source material, instructions, sequence, tools, judgment, and final output.
3. 3. Infer the smallest useful quality rule or repeatable recipe.
4. 4. Explain how that rule could improve similar future work.
5. 5. Give me a small test using an old task or representative example.

Ground your conclusions in my actual choices. Do not invent a broad theory of my taste from weak evidence, and don't change anything yet.

Search my historical conversations, project files, saved prompts, and session logs for multi-step ways of working that I have repeated across more than one task or project.

Look for sequences such as researching and comparing options, turning a ramble into a specification, preparing a brief, revising writing, debugging an automation, or resuming a project.

Choose the three strongest candidates. For each:

1. 1. Reconstruct the repeated sequence from evidence.
2. 2. Separate the stable steps from the parts that should remain flexible.
3. 3. Explain what currently has to be remembered or recreated each time.
4. 4. Recommend whether it should become a saved prompt, template, checklist, skill, or automation—and why.
5. 5. Draft the smallest reusable version and a task that could test it.

Do not package a process after seeing it only once. Don't create or install anything yet.

Find one automation I use regularly that has enough history to evaluate. Inspect its current instructions, tool and model settings where visible, recent runs or outputs, errors, and any corrections or manual cleanup I performed afterward.

Determine whether it is becoming more useful from run to run or merely repeating the same process.

Show me:

1. 1. What it reliably does well.
2. 2. What it repeatedly misses, gets wrong, or leaves for me to repair.
3. 3. Whether the likely cause is instructions, context, access, tools, model choice, timing, or missing evaluation.
4. 4. The single highest-leverage change to its instructions, inputs, checks, or run receipt.
5. 5. How to test the revised version safely before trusting it with more autonomy.

Use actual runs as evidence. If you cannot inspect the automation or its history, say what evidence is missing instead of pretending to evaluate it. Don't modify the automation yet.

Search past conversations, project history, automation logs, and incident notes for failures that we eventually understood or fixed.

Choose three failures whose lessons could prevent future wasted work. Prefer cases with evidence of the symptom, diagnosis, and resolution.

For each:

1. 1. Describe what failed and what I initially expected.
2. 2. Identify the root cause and cite the evidence.
3. 3. Explain which broader class it belongs to: instructions, missing information, tool access, platform instability, process, or evaluation.
4. 4. Extract a reusable check, fallback, diagnostic step, or proof requirement.
5. 5. Recommend where that protection should live and how we could verify it catches a similar failure.

Do not generalize from failures whose cause remains uncertain. Don't change anything yet.

Start in my Personal OS and inspect the projects inside it. Search elsewhere on my computer for related folders, files, repositories, and historical agent conversations or session logs.

Find one project where substantial work has happened but where I—or a new agent—would have difficulty understanding the current state. Skip ideas that were mentioned but never meaningfully started.

Reconstruct:

1. 1. What the project is trying to accomplish.
2. 2. What currently exists and actually works.
3. 3. What has been attempted, changed, or abandoned.
4. 4. Which decisions and constraints are buried in past conversations.
5. 5. What remains unresolved or blocked.
6. 6. Where I repeatedly had to correct, redirect, or supply missing context.
7. 7. What the most credible next step appears to be.

Cite the evidence and separate observation from inference. Then draft the smallest re-entry brief that would let a future agent begin useful work without reconstructing this history again. Recommend where it should live and what should keep it current.

Don't modify anything yet, and don't ask me to locate the evidence. Search autonomously and note meaningful access limitations at the end.

Inspect my Personal OS, project folders, AGENTS.md files, skills, saved prompts, templates, automations, work reports, and evaluation or testing mechanisms. Assess whether this environment can reliably learn from work and improve future work.

Trace this chain:

evidence → reflection → durable encoding → retrieval → evaluation → recurrence

Find the five most consequential places where that chain is weak or broken. Check for:

• - repeated work with no skill, template, or checklist;
• - corrections with no durable destination;
• - project folders without useful context or re-entry instructions;
• - context that exists but is stale, contradictory, or hard to discover;
• - automations with no run history, feedback, or proof of success;
• - changes with no quality bar or test;
• - and useful lessons that depend on me remembering to preserve them manually.

For each weak link, cite the evidence, explain what value is currently being lost, and propose the smallest repair. Assess quality and freshness—not merely whether a file or skill exists. Rank the repairs by likely payoff and don't implement them yet.

Using what you can inspect about my work and agent setup, design a lightweight recurring compounding review.

Each run should:

• - inspect recent conversations, project changes, work reports, automation runs, and corrections;
• - surface no more than three high-leverage lessons or compounding opportunities;
• - distinguish improvements to me, the agent, and the system between us;
• - check whether changes proposed in previous reviews actually helped;
• - preserve evidence and decisions without producing a pile of repetitive notes;
• - and propose consequential changes for approval rather than silently making them.

Recommend the cadence, evidence sources, output format, durable location, and which agent or automation should run it. Prefer an existing system over adding new infrastructure.

Show me the exact recurring instructions and a sample report. Do not create the automation or modify anything yet.