Copilot Memory Bank Template for Project Handoffs

A Copilot memory bank template is a small, maintained set of project files that tells a fresh session what the work is, what people decided, and where to resume. The example below separates a project summary, session plan, decisions, and handoff notes, with a reusable skill for updating them.

These files are a workflow you choose, not a special built-in Copilot memory database. fenbs offers a shared home for the same work when several connected assistants need it. Start with files if they suit your project, then use a shared record when maintaining separate copies becomes the harder job.

What should your memory bank contain?

Use four files, each with one purpose. The project summary explains the goal and boundaries. The session plan names the current objective and checks. The decisions file records choices people actually made. The handoff says what changed, what remains uncertain, and where the next session should begin.

The paths below are a suggested organization, not names that make Copilot load the files automatically. Tell the assistant to read them explicitly and keep that startup instruction where your chosen Copilot interface supports it. GitHub’s custom instructions guide↗ (opens in a new tab) explains the recognized instruction locations.

docs/ai-memory/project.md
docs/ai-memory/session-plan.md
docs/ai-memory/decisions.md
docs/ai-memory/handoff.md
.github/skills/copilot-memory/SKILL.md

Keep ordinary project documentation in its current home. Link to a design, contract, or architecture document rather than copying it into all four files. A memory bank should shorten the route to the current answer. It should not become a second documentation site that someone must update after every change.

What goes in the project summary?

Write the facts that stay useful across several sessions. Explain the user’s problem, the outcome you want, the important boundaries, and where authoritative references live. Leave implementation status out of this file; otherwise every minor change forces a rewrite of the project’s basic explanation.

# Project
Name: [project name]
Goal: [the outcome and who needs it]
Success means: [observable result]
In scope: [the work this project includes]
Out of scope: [explicit boundaries]

## Sources
- Current requirements: [path or approved reference]
- Design: [path or approved reference]
- Repository guidance: [instruction file path]

## People and open questions
Decision owner: [role or agreed contact]
Unresolved question: [question, not an assumed answer]

For example, a scheduling project might aim to let customers cancel reservations while retaining the record. Its summary should say that deleting reservation history is outside the agreed scope. The file does not need every conversation that led there, but it should point to the decision explaining that boundary.

Use plain descriptions that a teammate outside engineering can understand. This also makes it easier to carry the same project context between the workflows in Copilot vs ChatGPT. A file full of unexplained abbreviations makes a new session repeat the same discovery work you were trying to avoid.

How should the session plan describe current work?

A session plan is a proposal for the work immediately ahead. Give it a narrow objective, a short sequence, and the evidence needed before declaring success. Write the stop condition as carefully as the action: an unanswered product choice should not quietly become a coding assumption.

# Current session plan
Task: [task reference and outcome]
Starting state: [what is already true]

## Steps
1. [inspect the relevant current state]
2. [make the agreed change]
3. [run the appropriate verification]

## Checks
- Check: [command or human review]
- Expected result: [what demonstrates success]
- Not covered: [remaining limitation]

## Stop and ask
- [choice that requires a person]

Status: [planned / in progress / waiting / complete]

Replace this plan when the approach changes, while preserving any consequential reason in the decision record. Avoid leaving two files that both claim to be the current plan. If a check cannot run, say why and name what remains unverified instead of changing the expected result to make the work look finished.

How do you record decisions without inventing approval?

Separate an assistant’s recommendation from a person’s choice. A decision needs a clear status, scope, and source. “Suggested retaining history” is a proposal; “the owner chose to retain history” is a decision only when that choice actually happened. Keep unresolved questions visible.

# Decisions

## [decision title]
Status: [open / decided / superseded]
Scope: [where it applies]
Choice: [the person-approved answer, or the open question]
Decided by: [person, only if actually decided]
Reason: [why the person chose this]
Source: [approved reference]
Replaces: [earlier decision, if any]

## Continuing rules
- [approved continuing rule, scope, and source]

Treat a continuing rule differently from a one-time choice. One cancellation behavior may be approved for a single project without becoming the policy for every product. Give each entry enough scope that the next assistant will not extend it further than the person intended. fenbs keeps these distinctions in Decisions and rules.

What makes handoff notes useful tomorrow?

Write outcomes and evidence before intentions. “Changed the handler” and “verified the cancellation flow” are different claims. A useful handoff says which one is true, identifies what another person still needs to check, and gives the next session one safe place to start.

# Where we left off
Updated: [date]
Task: [reference]

## Completed
- [actual change]

## Verified
- [check performed, result, relevant change]

## Unverified or failed
- [check not run or failure and what it means]

## Waiting on a person
- [question and who can answer it]

## Start here next
1. [concrete next action]

## Still running
- [process or operation, or none]

Keep the latest handoff easy to find, and use ordinary project history for older revisions. Do not paste credentials, customer records, or entire terminal logs into it. A short reference to appropriate evidence is usually more useful than pages of output. For the analogous workflow in another assistant, see Claude memory banks.

Ask someone unfamiliar with the session to read the handoff once. If they cannot tell whether work is finished, waiting, or untested, revise the summary before adding more background. Clear status matters more than a longer account of the investigation.

How can a reusable skill maintain these files?

A skill packages a repeatable procedure the assistant can use when relevant. GitHub explains the concept in its agent skills documentation↗ (opens in a new tab). Use the following original example to make reading and updating the four files a deliberate task, rather than hoping that a closing conversation becomes a reliable summary.

---
name: copilot-memory
description: Maintain the project memory files when starting work, changing the plan, or preparing a handoff.
---

1. Read docs/ai-memory/project.md, session-plan.md, decisions.md, and handoff.md.
2. Compare the recorded state with the current task and files. Report conflicts before acting.
3. Keep a single current session plan. Record proposed choices as open.
4. Record a decision only when a person made it, including scope and source.
5. Before stopping, update handoff.md with actual changes, checks and results, unverified work, and the next step.
6. Keep secrets and customer information out of these files.
7. Summarize the updates for review. Never claim a check that did not run.

GitHub’s CLI skills setup guide↗ (opens in a new tab) documents project skill locations, required name and description fields, and ways to load and invoke a skill. Ask for /copilot-memory explicitly when you want this procedure. The template defines a routine; it does not guarantee that every session has followed it.

How to do this with fenbs?

1. Create a free account, add the project, and use the project summary above to explain its goal.
2. Add current tasks with their plans and actual verification results. Record person-approved choices in Decisions and rules.
3. Connect your supported AI apps through Integrations using MCP, a standard connection for outside tools, and browser sign-in.
4. Ask the assistant to read project context before working and save task progress and Where we left off before stopping.

fenbs is free for one person, with no credit card. It does not automatically import these Markdown files. Files may be the better fit for a single repository whose contributors already review documentation changes there. A shared record becomes useful when work crosses apps, people, or repositories; the AI memory hub covers those choices.

Test either arrangement with a fresh session. Ask it to identify the goal, unresolved choice, last check, and next action before proceeding. You can use the same test with the GitHub Copilot app: success means the assistant distinguishes what is known from what still needs a person.