Use cases
If it can be written in Markdown and committed to Git, every assistant your team uses can read it. Ten ways teams and individuals put a repository on the line.
For teams
- kb/policies.md Company knowledge base Policies and processes live in one private repository. Each person’s assistant reads the parts they have been given, and nothing else.
- projects/acme/context.md Project knowledge Briefs, specs, decisions and open questions kept per project, so every assistant working on it starts from the same facts instead of a pasted summary.
- tutorials/getting-started.md Product tutorials Feature descriptions, tutorials, limitations and naming in one product repository, so support, marketing and developers describe the product from the same source.
- playbooks/code-review.md Development playbooks Architecture rules, naming, testing and review checklists in Markdown, read by the coding assistant inside the IDE before it writes code.
- marketing/positioning.md Marketing notes Positioning, personas, messaging and approved phrases in one repository, so every draft starts from what the team already agreed instead of improvising.
- content/2026-plan.md Content plans The content calendar, topic list, briefs and drafts side by side in Markdown, readable from whichever assistant you write with today.
For solo
- notes/daily.md Personal notes A private Obsidian vault or notes repository, connected to the assistant you use, and to nobody else’s.
- second-brain/inbox.md Second brain Linked notes, sources and half-formed ideas your assistant can search across months, then help you turn into finished work.
- agents/memory.md Agent memory What your agents decided, tried and learned, written to Markdown and committed, so every new session and every agent starts with it.
- anything/you-want.md Anything you want Research, templates, glossaries, reading lists: if it is Markdown in a Git repository, Notedigit can serve it to your assistants.