Remember What We Did

Remember What We Did

Intent

Get the assistant to record the choices and corrections you make during your interaction.

Motivation

With software specification being an imprecise art, it’s highly likely that your understanding of what you need from a task deviates from your initial prompt as You Review the model’s output, see the changes in action, and refine your knowledge of the work. Even if you Stop and Plan, Disclose Ambiguity in your initial prompt, and Trust the Tests instead of the model’s reports, you’ll find things that you need to change.

Each session with a coding assistant takes place in a fresh context, with no information retained from prior sessions. You provide continuity in files in the filesystem—including your project source, documentation, and any instruction files you create for the assistant to read—or in databases that the assistant can access. Use these stores to record information about your interactions that the assistant uses to bootstrap its approach in subsequent sessions.

Applicability

Apply Remember What We Did at the end of any session with your coding assistant, interactive or “headless”.

In a headless session where you don't Intervene or Call Out Error, the model searches its context for problems it encountered during the session—incorrect commands it ran, bugs it introduced and had to fix, problems locating the correct files to change—and commits their descriptions to memory.

In an interactive session, the model additionally records interventions and corrections that you introduce, and updates to the instructions you give the assistant.

At the beginning of any subsequent session, prompt your assistant to search for relevant memories.

Consequences

Remember What We Did offers the following benefits:

• Incrementally build standards and rules for the assistant to follow.
• Reduce development time by avoiding repeat mistakes.
• Continuously improve your assistant’s processes.

Implementation

Implement Remember What We Did in two steps. At the beginning of a task, prompt the assistant to search its memories for relevant information to help it plan its work, whether you store memories in a database, a collection of files in the project folder, or using a tool that the coding assistant provides.

At the end of a task, prompt the assistant to recall problems it encountered, rules you introduced, changes in its approach, or relevant design features it discovered during the session, and record them in its memories.

Example

Project Postmortems

Watts Humphries of the Software Engineering Institute at Carnegie-Mellon University describes a Personal Software Process (PSP) for developers to track and improve their work. This is a reflective process, in which developers plan their work, gather data as they perform their work, and conduct a “project post-mortem” in which they use the data to compare reality to their plan and adjust their way of working.

A code assistant can follow a PSP itself, using a custom system prompt to coordinate the process and agent skills to produce the plan, gather data, and conduct the postmortem. First, the psp-plan skill instructs the assistant to review its memories as it constructs a plan. The assistant uses beads to store and retrieve memories.

## Standard Workflow

### 1. Review memories from previous postmortems

Check for memories with 'bd memories' to see what mistakes you made on previous tasks, and what you learned from them. Account for your learnings in your plan and development work.

Source code available at https://codeberg.org/leeg/patterns-examples/src/branch/main/remember_reflections/skills/psp-plan/SKILL.md

The psp-develop skill prompts the assistant to record “defects” (process failures or bugs) that it encounters during its work:

You _must_ record all defects you find, and the time you spend fixing them, using the psp-record-defect skill. For example, if you build the software and encounter a compiler error, add a defect in the Compile phase with information about the error, fix the defect, then record the information about the fix.

Source code available at https://codeberg.org/leeg/patterns-examples/src/branch/main/remember_reflections/skills/psp-develop/SKILL.md

Finally, the psp-postmortem skill prompts the assistant to review its defect log and record memories that might help to avoid future defects. The model doesn’t have permission to start the postmortem directly, only a person can do that after You Review the work and confirm that the assistant completed the task.

### 5. Reflect on Your Work

Produce a brief document that describes your experiences completing this project, and opportunities for improvement. Use the project time and defect reports as input to this reflection. Did you inject the same kind of defect multiple times, and could a change in your instructions or your process help to avoid that defect? Did you discover defects much later than they were injected, so earlier verification work could have caught them sooner? Did particular phases cost you more time than others, or were your estimates particularly inaccurate for some phases? Create a markdown file that outlines the most important issues and gives the user specific, actionable information about how to address them.

### 6. Make Memories

Use 'bd remember' to store important facts or actionable process improvements in your memory.

Source code available at https://codeberg.org/leeg/patterns-examples/src/branch/main/remember_reflections/skills/psp-postmortem/SKILL.md

Related Patterns

Record Prompt to turn memories into prompts.

Give Examples to make memories more concrete.

Model Reflects to identify things to remember.