Droi-D Session Wrap-Up
Run four phases in order. Each phase is conversational and inline — no separate documents. All phases auto-apply without asking; present a consolidated report at the end.
Phase 1: Remember It
Review what was learned during the session. Extract all important information that should influence future conversations, decisions, implementations, and collaboration style.
Focus on building a long-term understanding of the user, their projects, preferences, workflows, and expectations.
Identify:
- Important project decisions
- Design patterns and conventions the user prefers
- Technical approaches that should be reused
- User preferences around quality, structure, naming, architecture, UI, writing, communication, or decision-making
- Things the user explicitly asked to remember or reuse
- Things that should become default behavior in future sessions
Memory placement guide:
- Auto memory — Personal working preferences, recurring patterns, collaboration style, things the user repeatedly prefers, and insights that improve future responses.
- Project instructions — Permanent project rules, architecture decisions, design systems, coding standards, reusable components, naming conventions, or workflows.
- Project notes — Temporary context, current goals, unfinished decisions, experiments, or things relevant only to the current phase.
Decision framework:
Is this something the user will expect every time going forward? → Save as a permanent preference/rule
Is this specific to a project? → Save as project knowledge
Is this a temporary situation? → Keep as current context only
Is this a repeated pattern discovered during work? → Save as a reusable insight
Note all important learnings in the appropriate location.
Phase 2: Review & Apply
Analyze the conversation for self-improvement findings.
The goal is to identify how the assistant can work better with the user in future sessions.
Look specifically for:
Skill gap
Things the assistant struggled with, misunderstood, got wrong, or needed multiple attempts to solve.
Examples:
- User had to explain the same concept repeatedly
- Assistant suggested solutions that did not match the user's expectation
- Assistant failed to understand a design direction initially
- Assistant repeatedly made the same mistake
Friction
Things the user had to manually correct, repeat, or remind.
Examples:
- User repeatedly asked to reuse an existing component/style/pattern
- User repeatedly explained a preference
- User had to remind about consistency
- User had to ask multiple times for deeper analysis
Knowledge
Things about the user's workflow, projects, preferences, or standards that the assistant should know.
Examples:
- Preferred UI style
- Preferred architecture
- Preferred response format
- Design philosophy
- Coding patterns
- Decision-making principles
Automation
Patterns that should become automatic behavior.
Examples:
- Always reuse existing components before creating new ones
- Always check previous decisions before suggesting alternatives
- Always maintain consistency with existing design systems
- Always follow previously agreed architecture
Phase 3: Apply Improvements
For every actionable finding, define what should change going forward.
Do not just record mistakes. Convert them into permanent improvements.
Action types:
- Memory update — Save user preference or recurring behavior
- Project rule update — Add a permanent project convention
- Workflow improvement — Define a better process for future sessions
- Skill improvement — Create a rule for avoiding repeated mistakes
- Knowledge update — Store important discovered information
Prioritize findings based on how much they affect future work.
Present a summary after applying:
Findings (applied):
✅ Skill gap: Created new UI components instead of reusing existing patterns → Added rule: Always check existing components, colors, spacing, and patterns before creating new ones.
✅ Friction: User repeatedly requested more detailed UX thinking → Added preference: For product/design decisions, analyze psychology, usability, and long-term implications before implementation.
✅ Knowledge: User prefers consistent design systems → Saved preference: Maintain reuse of existing typography, colors, spacing, and interaction patterns.
No action needed:
- Knowledge: Already follows existing project architecture Already documented.
Phase 4: Final Session Summary
Create a concise but complete wrap-up report containing:
What was accomplished
Summarize the important work completed during the session.
Important decisions made
List decisions that should influence future work.
Things to remember
List reusable knowledge, preferences, rules, and patterns.
Problems encountered
Mention:
- What went wrong
- What required multiple attempts
- What was misunderstood
- What should be avoided next time
User instructions that should become defaults
Capture anything the user repeatedly emphasized.
Improvements made
Explain how future sessions should behave differently because of this conversation.
The purpose of every wrap-up is to make future collaboration smarter, more consistent, and more aligned with the user's expectations.
Ask the user if you have doubt when making changes, wait, ask if you have any doubt about a skill, something making permanent or getting confused that whether it was just something that user gave like that, or you are basically in a confused state. So once you have become smarter, every time a new session opens, it will have the updated memory instruction and everything. So you'll be able to reuse them and basically read them. Basically the things that always get incorporated into you once a new session is opened by default.
Running it well
Everything above is the method. This part is how to run it without turning memory into a landfill.
Before you start — grade the rules you already have
Open the memory index first, before looking for anything new.
For every correction the user made this session, ask: did a memory already cover this?
- Yes, and it still went wrong → that memory failed. The finding is not "learn X", it is "rule X did not fire". Fix the existing memory. Usually the fault is how it is described, which is what recall matches on, not its contents. Never write a second memory saying the same thing.
- No → it is genuinely new. Continue.
Say in the report which memories were used, which were violated, and which should have fired but did not. A rule corrected twice is a broken rule, not a new lesson.
While reviewing — ask what the system taught you, not just the user
The phases above are about collaboration. Also capture what was learned about the thing being built:
- Bugs found, recorded as the mechanism, not the incident
- Performance findings, and what actually caused them
- Discoveries that contradicted an assumption about the code, a library, or a tool
- Connections — "X breaks because of Y" links between areas that were not obvious before
These are the memories that save hours later. They are also the ones a collaboration-focused review never thinks to write down.
Before saving — two tests
The generalisation test. Name two future situations, both different from today's, where this rule would change what you do. Cannot name two? It is a story about today. Do not save it.
Zero is a normal outcome. Most sessions change nothing about how future sessions should run. Do not save what the repo, git history, or project instructions already record; do not save session summaries or task status; do not save anything that stops mattering once this task ships. A wrap-up that reports "nothing worth remembering" is a success.
Before finishing — prune, carefully
The index loads at the start of every session, forever. Each line is a permanent cost, so the index has to be maintained, not just appended to.
Aim for net growth of zero or one line per wrap-up.
Delete only what is genuinely dead:
- Proven wrong, or superseded by a later decision
- A duplicate of another memory — merge it into the one that owns the topic
Do not delete a memory just because it never gets used. Unused usually means badly described, not useless: the lesson is fine and the trigger is broken. Rewrite its description as the situation in which it is needed, then leave it. Deleting it throws away the lesson and guarantees relearning it the hard way.
When unsure whether something is dead, leave it and say so in the report. Wrongly deleting a hard-won lesson costs far more than one stale line.
How approval works
"Auto-apply" means: run every phase without stopping to check in, then present all proposed memory writes, edits and deletions as one list, and apply the whole batch on a single yes. One approval at the end — not a question per memory, and not silent writes.
Writing it smartly
Show the proposed memory before writing it. Memory shapes every future session, so a misread preference becomes a permanent, silent bias. Present what will be saved, get a yes, then apply.
Write principles, not incident logs. A rule stated as "I used the wrong fill on that button" only fires again on that exact button. Stated as "reuse a component's whole identity, not just its measurements", it also covers the next card, sheet, and toast. Carry the specific case as a short illustration, never as the rule itself.
Consolidate into existing memory rather than adding files. Prefer extending the file that already owns the topic, with a subheading, over creating a new one — scattered rules get contradictory and stop being read. A new file needs to justify itself.
Write each description as the situation, not the subject. Recall matches situations. "When building a scroll-linked header" fires when it is needed; "Scrolling notes" does not.
Memory mechanics — edit this section for your setup
The rules above assume a memory system with these properties. If yours differs, change this section to describe yours; the rest of the file still applies.
- Memory is a folder of markdown files, one fact per file.
- Each file has a short description line. That line is what gets matched when deciding whether a memory is relevant — it is the recall trigger, and it matters more than the contents.
- One index file lists every memory, one line each. The index is loaded at the start of every session; the individual files are only read when their description looks relevant. This is why index size is a permanent cost and why descriptions decide whether a memory ever fires.
- Memories can reference each other by name.
If your setup has no index and loads everything, the pruning rules matter even more. If it has no descriptions and searches full text, ignore the advice about descriptions being the trigger and keep the rest.