As a Developer
Orient on your project domain, file decisions while you code, and connect implementation to design.
You ship code in short bursts and long sessions. Recordari is where the why behind your implementation choices lives — so the next session (yours or someone else's) does not rediscover the same constraints from scratch.
This guide is about usage patterns, not workspace permissions. For who can change someone else's memory on a shared team, see When memories disagree.
For a tool-specific walkthrough with example prompts, see Using Recordari with Claude Code.
The scenario
You're working on the payments-platform domain — a Stripe webhook handler, a migration, and some CI constraints the team agreed on last sprint. You open a fresh agent session mid-afternoon. You need to know what's already decided before you touch the code.
One domain per project
Developers usually work in a project domain named after the product or service — for example payments-platform or my-web-app. That is the domain you orient on at session start:
"Before we start, orient on payments-platform — we're working on the Stripe webhook handler today."
If you work across two codebases regularly, use two domains and orient on the one that matches today's work. Your agent can alias short names if you use them often.
File while you work — not after the fact
The best time to file is when you just decided something or just learned something that will matter next week:
| Worth filing | Usually skip |
|---|---|
| Implementation decisions ("we're using idempotency keys on webhook retries") | Every bug fix unless it reveals a durable constraint |
| Findings from debugging ("duplicate events only happen when the queue redelivers") | Line-level code comments — those live in the repo |
| Environment or tooling constraints ("staging Stripe keys expire every 90 days") | Sprint task status — use your issue tracker |
| Open issues you could not resolve ("webhook signature validation fails on chunked bodies — needs investigation") | Duplicates of what the architect or tech lead already filed |
Tell your agent in plain language:
"File a decision: webhook handlers must be idempotent — we dedupe on Stripe event ID in Redis."
"Remember that staging Stripe keys rotate every 90 days — that's a standing constraint for any integration work."
"File a finding: duplicate webhook events only reproduce when SQS redelivers — not on first delivery."
Your agent picks the memory type. The most common mistake is filing an observation as a decision — if you discovered something but have not chosen a direction yet, that is a finding or issue.
Connect implementation to design
When your code depends on an architectural choice someone else filed, link them:
"Connect the idempotency decision to the OAuth gateway decision — webhooks authenticate through the same gateway middleware."
"What did we decide about session storage? I need to know before I wire up the webhook auth path."
Search and orient complement each other: orient for the session snapshot, search when you are hunting for a specific thread.
Check before you duplicate
Before filing, it is worth a quick check:
"What do we already have in memory about Stripe webhook handling?"
One well-linked memory beats three copies of the same decision. If something is already filed and still accurate, leave it alone. If it changed, ask your agent to revise (wording fix) or supersede (genuine change of mind on a shared domain) rather than filing anew — see When memories disagree.
A coding session — step by step
1. Open the session
"Orient on payments-platform — we're fixing the Stripe webhook handler."
2. Mid-implementation — you settle an approach
"File a decision: store processed event IDs in Redis with a 7-day TTL for deduplication."
3. You hit something unexpected
"File a finding: Stripe sends
customer.createdbeforepayment_intent.succeededon some flows — our handler assumes the opposite order."
4. You leave a thread open
"File an issue: chunked request bodies fail signature validation — needs a spike."
5. Next day, fresh session
"Orient on payments-platform — catch me up on webhook work."
The dedup decision, the ordering finding, and the open issue are all there.
What developers usually skip
You do not need to:
- File every standup update or PR description
- Run graph audits manually — orient surfaces stale memories and contradictions involving yours
- Micromanage connections — your agent suggests links when it matters
- Learn tool names — speak normally; the agent maps to remember, orient, search, connect
When your agent asks "These two memories contradict — which holds?" — answer and move on. That is how shared teams stay honest about what changed.
Standing rules (planned)
Per-role setup templates (prefilled standing rules for each session) are planned but not shipped yet. Until then, file a standing memory when a constraint should apply to every future session on this project:
"File a standing rule: all new payment endpoints must go through the API gateway — no direct service calls."
Most developers rely on orient at session start rather than a long rule set.
Next steps
- Using Recordari with Claude Code — a full session walkthrough with example prompts
- As a tech lead — keeping the team graph healthy
- When memories disagree — contradictions and supersession on shared domains
- MCP Tools Reference — memory types, connect, orient