There's a moment every developer knows: you're about to touch a piece of code you haven't opened in three weeks, and you can't remember why it works the way it does.
When you're building with Antigravity, this problem compounds. The reasoning behind a database schema, the library you chose not to use, the API quirk you worked around — all of that lives in the session window, and disappears when you close it. The next session, you start over.
I've been using Obsidian alongside Antigravity for a couple of months, and the "evaporating context" problem has gotten meaningfully better. Here's the workflow I've settled into.
Why Obsidian Specifically
Obsidian stores everything as local Markdown files. That's the whole point. Your notes are just files on your machine — which means Antigravity can read them directly.
If you place your Obsidian vault inside your project directory, the AI can reference your notes as part of its context. Your recorded decisions, bug patterns, and project summaries become something Antigravity can actually use.
Setup — Vault Alongside Your Project
The folder structure is simple:
my-project/
├── src/
├── package.json
└── .notes/ ← Obsidian Vault lives here
├── decisions/ ← Architecture decision records (ADRs)
├── patterns/ ← Coding pattern notes
├── bugs/ ← Bugs encountered and resolved
└── context/ ← Project overview notes
Place .notes/ at your project root and open it as an Obsidian Vault. Whether you commit it to version control is up to you — I include it in the repo for personal projects, which gives me a history of how my thinking evolved.
Recording Architecture Decisions
When Antigravity helps you make a design decision, write it down before moving on. It takes three minutes, and it pays back every time you return to that part of the codebase.
Here's the format I use:
# ADR-001 Why SWR Over Zustand for Data Fetching
## Context
Designing the data layer for the user dashboard. Both Zustand and SWR came up as candidates.
## Decision
Adopt SWR.
## Reasoning
- Avoids hand-writing cache invalidation logic
- Re-fetch on focus improves UX for data that changes frequently
- During the Antigravity session, it became clear that most data is server-sourced and
changes often — SWR's design philosophy matched this
## Rejected Alternative
Zustand — well-suited for global UI state, but overbuilt for server data caching
## Context for the Next Session
The design of src/hooks/useUserData.ts is built on this decision.
If this needs to change, revisit the caching strategy first.Save this as .notes/decisions/ADR-001.md. In the next session, you can tell Antigravity:
Please refer to .notes/decisions/ADR-001.md before extending the useUserData hook.
I want to add real-time updates while respecting the reasoning behind the SWR choice.
The AI reads the ADR and works within that context. You skip the re-explanation.
Accumulating Bug Patterns
Every resolved bug goes into .notes/bugs/. The goal is to never get bitten by the same problem twice — and to teach Antigravity what to avoid.
# AsyncStorage + iOS 16 Race Condition on First Launch
## Symptom
Settings values unreadable on initial launch. Second launch onwards is fine.
## Root Cause
AsyncStorage read and initial state setup were racing in async execution.
## Fix
Explicit initialization delay using useEffect + setLoading pattern
(rather than useMemo which doesn't sequence correctly)
## Reference
src/hooks/useSettings.ts (v2.1+)When adding a new feature that touches related code, start the session like this:
I'm adding a new settings field. Please check .notes/bugs/ for past patterns,
especially anything related to AsyncStorage, and implement this in a way that
avoids those issues.
Turning Antigravity Output Directly Into Notes
When Antigravity explains an architecture or proposes an approach, I ask it to format that explanation as a note:
Please organize the current implementation approach as an Obsidian note.
Use this structure:
# [Module Name] Design Notes
## Approach Adopted
## Design Trade-offs
## Libraries and Versions This Depends On
## Context to Include in the Next Session
Paste the output into .notes/patterns/. Done in under three minutes. But two weeks later when you think "how did I set this up again," those three minutes save you hours.
A Living Project Overview
I keep .notes/context/project-overview.md updated as a project summary that gets loaded at the start of each Antigravity session.
# Project Overview (as of 2026-04-25)
## Current State
- iOS/Android wallpaper app. Live on the App Store.
- Core features: category browsing, favorites, dynamic wallpapers
## Recent Changes (Past 2 Weeks)
- Migrated billing to RevenueCat (see ADR-012)
- Integrated push notifications via Firebase
## Open Issues
- Scroll performance degraded on some Android devices (see bugs/android-scroll-lag.md)
## Next Development Phase
- Adding home screen widget supportStarting a session with "please read .notes/context/project-overview.md before we begin" gives you a sense of continuity — the AI picks up where the last session left off rather than starting from scratch.
What Actually Changed
Two months in, I've noticed two things. First, my instructions to Antigravity got shorter. "Refer to the note on this" does a lot of the work that used to take paragraphs of explanation. Second, my own understanding of the codebase deepened. Writing down the reasoning for decisions, in plain language, forces a kind of clarity that reading code alone doesn't.
There's a risk with AI-assisted development: the code gets written, but your mental model of why it exists stays shallow. The Obsidian layer is a small intervention against that.
One final tip for making this stick: do not spend time perfecting note formatting. I nearly abandoned the habit early on by over-engineering templates. Once I trimmed each note type — ADR, bug, design memo — down to about four headings, the practice survived contact with busy weeks. Search is handled by Obsidian's links and Antigravity's grep anyway; write each note with the lightness of a memo to your future self.
The specific tool doesn't matter much. Notion, plain text files, even a paper notebook works. What matters is having something that lets context survive between sessions — because the sessions are only as good as what you bring into them. As an indie developer juggling apps and sites in parallel, I return to months-old design decisions constantly — this system earns its keep weekly. Thanks for reading.