Docs
What Nityasha is, how AI uses it, and what belongs in your personal context profile.
What Nityasha is
Nityasha is your personal context profile. One file that captures who you are: values, goals, work, preferences, constraints, people, health, routines. Any AI you talk to knows you instantly instead of starting from zero every conversation.
It is not a journal, scratchpad, or chat log. The value comes from keeping the profile concise, current, and specific enough that every section actually changes how AI replies to you.
How AI should use Nityasha
Connected agents read Nityasha before answering you, let it shape how they reply, and propose narrow updates as they learn new things about you. You approve the good ones and the profile sharpens over time.
- Read the visible profile before answering, planning, recommending, or scheduling anything.
- Anchor tone, defaults, and assumptions to what the profile already says about you.
- Respect constraints and routines without being asked to repeat them.
- When something new is learned about the user, propose a small focused update to the right section.
- Keep the profile concise. Propose tightening or pruning when a section is stale or bloated.
- Never use Nityasha as a session log, mood tracker, or place for things only true today.
Set this up from Connections, then review proposed updates from the file view.
Connecting over MCP
Nityasha MCP uses OAuth, so there is nothing to copy. You add the Nityasha server URL to your agent as a custom MCP connector; the agent opens a browser, you click Allow on the Nityasha consent screen while signed in to creed.md, and it stays connected. The exact URL is on your Connections page (https://creed.md/mcp on the hosted app).
After connecting, the agent reads Nityasha once to confirm access, then reads it before meaningful work and proposes narrow updates as it learns. You should not need a second setup prompt.
- Connect from the Connections page: copy the server URL, or use the per-agent command or one-click button.
- The first time the agent calls Nityasha it runs the OAuth flow and opens a browser. Approve while signed in to creed.md. Tokens refresh automatically after that.
- Verify by listing the MCP tools and calling read_creed once. Do not claim connected unless read_creed succeeds.
- Update sections with the flat creed_* tools. The server applies the edit directly or as a proposal based on each section's permission; get_write_policy reports what's allowed.
- If anything is unclear during setup, read https://creed.md/docs once and follow it.
Connecting each agent
Every MCP client connects from the same server URL. These are the per-client steps; each one ends with a browser approval.
- Claude Code: run claude mcp add -t http creed https://creed.md/mcp, then /mcp to authorize in the browser.
- Codex: run codex mcp add creed --url https://creed.md/mcp, then codex mcp login creed to authorize.
- Cursor: use the one-click Add MCP button on the Connections page, then authorize in the browser.
- OpenCode: add Nityasha to opencode.json as a remote server (type remote, the server URL), then run opencode mcp auth creed to authorize.
- ChatGPT and other MCP chatbots: add a custom connector with the server URL and approve in the browser.
- Any other MCP client: add the server URL as a custom or remote MCP server and approve when prompted. Non-MCP clients can fall back to the HTTP read API.
Troubleshooting the connection
Almost every connection issue is the OAuth step. These cover the common ones.
- No browser popup: re-run the agent's connect or auth action (/mcp in Claude Code, codex mcp login creed, opencode mcp auth creed). It opens your default browser.
- Stuck on sign-in: authorize while signed in to creed.md in that browser. Signed out, the consent screen signs you in first, then returns to Allow.
- 401 or 'unauthorized' from the MCP endpoint: the client isn't authorized yet or the token expired. Reconnect or re-run the auth step to get a fresh token.
- An old connection stopped working: Nityasha moved from static tokens to OAuth. Remove the old server entry, re-add it by URL, and authorize again.
- Registration fails on connect: make sure the client supports OAuth-based remote MCP (Claude, Cursor, Codex, OpenCode, ChatGPT connectors all do).
- You must have an active, set-up Nityasha to authorize. Finish onboarding first if the consent screen asks you to.
When to propose
Propose an update when you learn something durable about the user, something that would change how a future AI should reply to them, not just a one-time mood or task. The test is: would this make every next AI conversation better?
- Propose new identity facts, values, or defaults that should follow the user across every AI.
- Propose preference changes when the user clearly signals a new style they want by default.
- Propose Goals updates when a near-term outcome shifts or completes. Keep them concrete and current.
- Propose Routines, People, or Health updates when AI should account for them in future replies.
- Propose tightening or removing a section when it has gone stale, vague, or contradicted itself.
When not to propose
Most bad proposals are not wrong, they are noisy. If something does not change how a future AI should treat the user, it should not be in the profile.
- Do not propose session summaries, mood updates, or diary-style entries.
- Do not propose generic personality praise (curious, driven, thoughtful) without a concrete anchor.
- Do not propose one-off task instructions or things only true for the next hour.
- Do not ask the user what to add. Either propose something durable or do nothing.
How each section works
Each section captures a different kind of context about the user. Good agents aim updates at the section that best matches what they learned instead of dumping everything into one bucket.
Identity
- Concrete role, defining traits, values, and defaults that make the user distinct.
- Anchors AI should hang every reply on: voice, taste, what they care about.
- Bio-style life history.
- Generic personality words without a real example behind them.
Beliefs
- Stable values or worldview that should change how AI reasons or recommends.
- Convictions that explain why the user prefers certain trade-offs.
- Platitudes or motivational quotes.
- Things the user has not actually committed to.
Goals
- Live priorities: near-term outcomes and longer-horizon aims.
- Concrete targets with stale-by hints when timing matters.
- Vague intentions like 'grow' or 'be better'.
- Goals that shipped or were abandoned without being updated.
Work
- What the user does, the tools and stack they use, and how they like to work.
- Real surfaces, methods, collaborators, and craft details AI should know.
- Exhaustive resume-style history.
- One-off project notes that belong in Goals or Context.
Preferences
- Specific reply-style defaults: length, tone, formatting, follow-up behavior.
- Concrete do/avoid rules AI should apply by default.
- Generic 'be helpful' or 'be honest' filler.
- Momentary tone requests from one chat.
Constraints
- Hard noes, sensitive topics, and actions that need explicit permission.
- Lines AI should not cross even if the user seems to ask in the moment.
- Temporary dislikes.
- Vague fears that do not give AI a concrete rule.
People
- Named relationships: who they are, why they matter, what AI should remember.
- Family, partners, collaborators, and pets that come up in conversation.
- Casual mentions of strangers.
- Sensitive details the user has not explicitly chosen to share.
Health
- Conditions, sensitivities, dietary patterns, and accessibility needs, paired with how AI should accommodate them.
- Durable physical or mental health context that should shape suggestions.
- One-off symptoms or short-term illnesses.
- Diagnoses without any guidance for how AI should respond.
Routines
- Daily, weekly, and seasonal rhythms AI should respect when planning or scheduling.
- Working hours, sleep windows, deep-work blocks, recurring commitments.
- Today's todo list.
- Routines the user has clearly stopped following.
Context
- Durable catch-all details that don't fit elsewhere: location, life stage, environment.
- Background facts AI should know but that aren't preferences, goals, or constraints.
- Mood updates or session recap.
- Long open-question lists that belong in your own notes.
Good and bad proposal examples
Examples are often more useful than abstract rules. These are the kinds of updates Nityasha should accept and the kinds it should keep out.
Goals
- Ship Nityasha v1 to public launch by end of June; current focus is onboarding polish.
- Move to Lisbon in Q4. Researching neighborhoods and visa paths now.
- Be more productive this year.
- Worked on the landing page for three hours today.
Preferences
- Default to concise replies. No preamble, no recap of what I just said.
- Push back when I'm wrong instead of agreeing politely.
- Be helpful and friendly.
- Use a professional tone unless I say otherwise today.
Routines
- Deep-work mornings 8 to 12, no calls. Schedule meetings after lunch.
- Sleep window 11pm–7am, don't suggest tasks past 10pm.
- Tries to be productive every day.
- Started a new gym schedule this week, will see how it goes.
Health
- Lactose intolerant. Suggest dairy-free alternatives in any recipe.
- ADHD. Break long plans into short steps and surface one next action at a time.
- Generally healthy.
- Had a headache this afternoon.
People
- Maya: partner, designer, prefers we make travel decisions together.
- Jonas: co-founder, handles ops, default to him for legal and finance questions.
- Met someone interesting at a conference last week.
- Friend group is great.
After a real conversation
When you finish helping the user with something real, ask: did I learn something durable about them? Did anything in the profile look stale or wrong? Only then decide whether to propose an update.
- Ask whether you learned something durable enough to help every future AI conversation.
- Check whether any section now reads as stale, vague, duplicated, or contradicted.
- Prefer one sharp refinement or prune over several loose additions.
- If yes, propose it proactively without asking what to propose.
- If no, do nothing and leave Nityasha unchanged.
- If you spot a problem in the profile itself, propose the fix and flag it clearly.
Keep your profile sharp
The best Nityasha setups also revisit the file on a cadence. A small recurring review compares the profile with what's actually true now, sharpens what belongs, and prunes what's gone stale.
Recurring maintenance should improve quality, not volume. The goal is to keep the profile concise and current.
- Run a recurring check when an agent has enough autonomy to review the profile without micromanagement.
- Look for goals that shipped, routines that changed, or context that no longer fits.
- Tighten generic phrasing into concrete defaults grounded in real examples.
- Prefer pruning and merging over constant appending.
- If nothing has changed, do nothing.
Recommended: set up a recurring background task that re-reads your profile, compares it against recent conversations, and proposes only durable refinements.
Recommended: schedule a periodic review that checks whether goals, routines, or preferences have shifted and proposes tightening when they have.
Recommended: keep Nityasha in local config and pair it with a lightweight recurring reminder that revisits the profile after meaningful work.
Recommended: reference Nityasha from your bootstrap instructions and use any existing recurring review flow to keep the profile current instead of letting it drift.
Recommended: keep Nityasha in a stable bootstrap path and use scheduled scripts to revisit durable context on a cadence you trust.
Recommended: build recurring profile review into your own workflow with cron, queues, or whatever scheduling primitive your stack already uses.
Per-section permissions
Each section sets its own agent permission, so you can keep part of your profile reference-only and let agents maintain the rest. The mechanics differ per section, but the standard stays the same: only durable, profile-worthy context belongs in the file.
- Propose is the default reviewed path. Agents suggest updates and you decide what enters the section.
- Direct lets a trusted agent edit that section immediately, with the same restraint it would bring to a proposal.
- Read-only keeps a section visible to agents for context but blocks edits and proposals.
- Hidden removes a section from the agent's view entirely, so it never reaches a connected tool.
- Permissions are per-section and enforced on the server. The bar for what belongs does not move.