Anamnesis

Anamnesis Logo:))

Inspiration

Our team is a group of three university students studying CS and Robotics who recently started their internships. A realistic problem that office workers, including ourselves, face is never-ending distractions, which can take the form of Slack and Microsoft Teams pings, calls from your manager or advisor, or fellow interns asking you to grab some coffee... the point is, it's easy to lose focus, and even harder to get back to being focused.

So our team did a bit of digging and came across Guo et al. (2021), in which they discussed how interventions significantly reduce resumption lag and greatly improve task accuracy. And the key point to our solution, Anamnesis, is the fact that among all the intervention types, reminder cues were identified as one of the most effective methods for helping people get back on track with what they were doing.

What it does

Anamnesis is a local-first developer tool with a CLI and VS Code extension. It reconstructs working memory from the workspace you return to: Git state and diffs, recent file activity, optional shell history, optional captured command output, and conservative static analysis. When remote inference is explicitly enabled, GPT-5.6 turns that evidence into a concise Done / In progress / Broken / Next step briefing.

How we built it

We built Anamnesis as one shared TypeScript core with two ways to use it: a CLI and a VS Code extension.

The first design decision we made was to define a versioned SignalPayload contract before building the AI or UI. This was to prevent each member of the team from inventing their own data shape for different purposes, such as local-engine work and AI prompting work.

The payload includes:

Git branch, status, unstaged/staged diffs, and recent commit subjects
Recently modified file paths and modification times
Optional shell-history entries
The latest captured command's output, exit code, timestamps, and freshness
Deterministic static-analysis findings
Optional checkpoint intent and comparison metadata
Privacy/redaction and trimming metadata
Warnings when a signal is missing, disabled, or unreliable

Another key design choice we made was to implement two different paths:

Current State Only: no checkpoint; normal unplanned interruption
Checkpoint Comparison: an active checkpoint adds an intent note and local before/after comparison

This means that placing checkpoints is optional and is intended to be used when you want to compare the state of your workspace at the time you make the checkpoint with its state when you select 'Resume work'.

We split our work into three roles. One person:

builds the local signal engine
builds the AI briefing layer
builds the VS Code extension

local signal engine

The local engine collects evidence without asking the model to guess what happened.

It gathers:

Git signals: branch, changed files, current diffs, staged diffs, and recent commits.
File activity: recent file paths and modification times.
Wrapped test/run output: anamnesis run -- npm test runs a command normally while storing its latest sanitized output and exit status.
Optional shell history: PowerShell, zsh, and bash support, treated as supplemental because timestamps and exit codes are not always available.
Static analysis: a deliberately narrow deterministic check for some JS/TS refactor failures, such as a moved export with a stale direct import.

The engine records whether a captured test result is fresh. If a test failed before newer files were modified, Anamnesis marks that failure as stale, rather than claiming it is still broken.

The collection coordinator is src/local/collect.ts, while the shared dump, checkpoint, and resume behavior lives in src/local/engine.ts.

We also aimed to tackle the technical boundary of risk tolerance and token consumption for Anamnesis.

We did not want to send raw developer data to an AI and merely ask it to be careful.

Instead, Anamnesis sanitizes before local persistence and before any inference request:

.env, private-key, credential, and secret paths are excluded or redacted.
Recognizable API keys, tokens, passwords, bearer tokens, and private-key blocks are redacted.
Redactions are counted as metadata; the system never tries to reconstruct them.
Local state is stored in the workspace's ignored .anamnesis/ folder.
Remote inference is off by default.
Shell history is off by default.

We also bound payload size twice: Role 1 trims oversized local evidence first, then the AI layer applies a final context budget. This avoids sending massive diffs or terminal logs unnecessarily.

Checkpoints are a major feature of Anamnesis, and we store them locally. Each is a sanitized snapshot plus an optional one-line intent such as Finish updating xxx.

It does not call ChatGPT; instead, we treat it as a better snapshot that includes user input.

Since the user can have multiple checkpoints, we created a local checkpoint history:

Up to 10 checkpoints per workspace
The newest checkpoint becomes active automatically
The user can choose an older checkpoint as the active comparison baseline
The user can remove checkpoints
Removing the active checkpoint promotes the newest remaining one
Removing the final checkpoint returns immediately to checkpoint-free Resume
Old single-checkpoint storage migrates safely into the new history format

Only the active checkpoint is included in a Resume payload, so history does not inflate the AI context. The persistence logic is in src/local/checkpoint-store.ts.

AI briefing layer

The AI briefing layer consumes the validated, already-sanitized SignalPayload. It does not recollect files, read shell history, or bypass privacy controls.

The GPT-5.6 pipeline:

Validates the payload again.
Applies defense-in-depth redaction.
Trims the context while preserving high-value evidence.
Sends an evidence-prioritized prompt to GPT-5.6.
Requires structured output through a schema.
Returns a briefing with done, inProgress, broken, nextStep, and uncertainty.

The prompt establishes an evidence hierarchy:

Fresh captured failed test/run output is strongest.
High-confidence deterministic static findings can prove a narrow issue.
Checkpoint intent plus current diff provides task trajectory.
Shell history and file activity are weaker context.

The model is instructed not to invent test results, live failures, or recovered secret text. The implementation is in src/ai/briefing.ts and src/ai/prompt.ts.

VS Code extension

The extension does not reimplement the local engine. It calls the same shared functions as the CLI.

The UI includes:

A primary Resume work action
An optional Add checkpoint action
A status-bar shortcut
A sidebar with briefing sections
A vertical checkpoint timeline
Controls to select or remove a checkpoint
A local-save status so saving a checkpoint immediately closes the form rather than appearing frozen
A deterministic demo mode for recordings, clearly labelled as demo data

The extension registers VS Code commands and connects them to the shared provider in src/vscode/extension.ts.

Testing

The project has 79 passing tests across the local collectors, checkpoint history, CLI behaviour, AI context handling, privacy/redaction, and VS Code sidebar behaviour.

Challenges we ran into

Building Anamnesis was not linear; we ran into plenty of problems. To list just some of them, we faced issues with:

Design principles
Data sanitization
AI behaviour
Checkpoint behaviour
UI/UX

We'll focus on the one we had the most fun fixing.

Originally, checkpoints were treated as the normal requirement for Resume: the developer would work, save a checkpoint before a break, then return and resume. This created two problems. First, most interruptions are unplanned, so users often would not have created a checkpoint at all—contradicting our frictionless product promise. Second, a checkpoint saved right before leaving captures nearly the same state as the later Resume, so it gives little useful before/after comparison.

We replaced that with a checkpoint-free-first design. Resume work is now the primary action: it can reconstruct context from the current Git state, recent files, static analysis, and any captured run output even when no checkpoint exists. A checkpoint is now optional—a locally saved, sanitized baseline with an optional intent note that improves a later briefing when created before a meaningful task or change. We also added a selectable history of up to ten checkpoints, so users can choose or remove a baseline instead of being locked into one saved state.

Accomplishments that we're proud of

For two of us, this was our first time creating a product that uses an AI connector. So building Anamnesis introduced us to a new field of programming. Furthermore, our team is very proud of the story behind Anamnesis. There is a real and relatable pain point that not only interns but basically all programmers experience. Life is unpredictable, but we can always choose to live it to the best of our own capabilities.

Furthermore, we found it incredibly fun being able to utilize Codex to implement exhaustive tests for issues that we thought of. For example, while building the local signal engine, we realised that security and token consumption are both real issues that must be addressed. We then prompted Codex to review these issues and implemented fixes. We can all agree that a very satisfying part is running into problems with Anamnesis and then solving them.

What we learned

The key point we learnt through building Anamnesis is that a good developer tool is built to fit real human behaviour, not just to collect high-quality data. A key human behaviour that we took a deeper look at is how people inherently cannot always control their decisions. We were forced to build around this fact and, as a result, our solution must be frictionless—our product must work even when users forget to prepare.

We also learned to be honest about what AI can infer. Our data includes Git diffs and file activity, but those signals alone cannot prove that a task is complete. For example, if a user creates a checkpoint with the intent "Complete the remaining TODOs in xyz.py," then finishes the work and selects Resume Work, Anamnesis cannot reliably determine that every TODO was resolved from Git diffs alone. Instead, it should treat the checkpoint intent as context, clearly communicate any uncertainty, and avoid claiming that the task is complete—or still unfinished—without stronger evidence such as relevant test results or explicit code-level verification.

Technically, we learned how to build a local-first TypeScript product with a shared contract between collectors, the AI pipeline, and VS Code; protect privacy through redaction and opt-in remote inference; create CLI commands, checkpoint storage, and a VS Code interface; and validate behavior through tests and fixtures.

Most importantly, we developed product judgment for a hackathon: identify the core promise, test it through a real user flow, fix the highest-risk flaw, and avoid trying to build every possible feature before the deadline.

What's next for Anamnesis (Limitations and Improvements)

The main limitation of Anamnesis is that it can reconstruct evidence about a developer's workspace, but it cannot yet fully understand code or reliably prove that an arbitrary task is complete. Git diffs, file activity, checkpoints, and test output can show what changed, but they do not always explain why it changed or whether every requirement was satisfied. Its deterministic static analysis is also intentionally narrow: it currently focuses on limited JS/TS refactor issues rather than Python, full type checking, runtime behavior, or general code quality.

Other important limitations are that Anamnesis only captures test output when commands are run through anamnesis run -- ...; it cannot automatically see a separate terminal session. Untracked files and non-Git workspaces provide weaker code-level context; large diffs may need to be trimmed; and the product cannot see unsaved editor buffers, debugger state, browser/database state, or work happening outside the workspace. Checkpoint intent is useful context, but it can become stale and should not yet be treated as proof that a task remains unfinished or is complete.

Future plans could focus on making the evidence richer and more trustworthy. This includes building a true checkpoint-to-current code comparison, safely capturing bounded content from untracked text files, and adding language-aware analysis for Python and other ecosystems. We could add a transparent terminal or VS Code test integration so normal test runs become available without requiring a wrapper command. We could also improve trust by showing evidence citations for every AI claim, adding a user-controlled "mark checkpoint complete" flow, comparing committed changes after a checkpoint, and supporting more editor context such as open files, active tabs, and debugger state. Long term, Anamnesis could expand beyond VS Code while keeping its local-first privacy model and explicit user control over what is collected or sent to an AI.