marvin-template: a personal assistant workspace wired into Claude Code

An acronym, a joke, and a fairly narrow claim

MARVIN expands to Manages Appointments, Reads Various Important Notifications, which tells you the register of the project: playful naming, serious intent, and a tool aimed at one person's working life rather than a team's. The name comes from the Paranoid Android in The Hitchhiker's Guide to the Galaxy, and the README credits Sterling Chin as the creator.

The description calls it a personal AI assistant that connects to the apps you need and helps handle your day. The README sharpens that into a chief of staff metaphor, someone who remembers conversations, tracks goals and helps you stay organised. Five capabilities carry the whole pitch: session continuity so you can resume days later, goal tracking with proactive nudging, tool integrations, extensibility through plain markdown files, and a stated intent to push back on weak ideas rather than agreeing with everything.

That last one is the most interesting claim and the least verifiable. Whether an assistant actually challenges you depends on the prompt content in `.marvin/` and `.claude/`, not on the template name. What the repository does give you is a place to put those instructions and a convention for keeping them consistent.

The repository is MIT licensed with 1,021 stars and 169 forks, its primary language is Shell, and the last push was 2026-08-18. There are no published releases, so `VERSION` and `CHANGELOG.md` in the tree are where version history lives.

Setup is a clone, a launch, and one sentence

The Claude Code path is deliberately minimal. Clone the repository, change into it, start Claude Code, then ask for help with setup:

git clone https://github.com/SterlingChin/marvin-template.git
cd marvin-template

claude

The prompt you give it is the fourth step, phrased as help me set up MARVIN. From there MARVIN handles the profile, the goals, the workspace location and any optional integrations, walking you through the prompts. Nothing is written without you answering something, which is the right shape for something that will end up holding your personal notes.

There is a second documented path for people who prefer GitHub Copilot CLI, and it is worth reading because it shows how the setup is wired. The commands are natural language suggestions rather than flags:

# Navigate to your projects directory
gh copilot suggest "clone marvin template repository"

# Run the setup script
gh copilot suggest "run setup script for marvin"

# Start MARVIN
gh copilot suggest "start marvin AI assistant"

Underneath, `.marvin/setup.sh` is what actually does the work: it handles prerequisites, creates the workspace, sets up the profile and installs shell aliases. Additional integrations get their own suggestion, such as configure marvin integrations. If you would rather read a shell script than trust a conversation to run the right commands, `.marvin/setup.sh` is the file to open first.

Commands for the shape of a working day

The daily loop is two commands with one checkpoint between them. `/start` produces a briefing covering priorities, deadlines and progress toward goals. You then work normally and the assistant carries context through the day. `/end` saves that context so the next session resumes rather than restarts.

`/update` is the in-between option, saving progress without ending the session, which matters on a long day when you close the laptop but want tomorrow's briefing to know where you got to.

The rest of the table is shorter than the headline implies. `/report` generates a weekly summary. `/commit` reviews and commits git changes. `/status` checks integration and workspace health, which is the command to reach for when a Google or Slack integration stops working. `/sync` pulls new features from the template into your workspace. `/help` lists everything available.

Two of those deserve a second look. `/commit` handing a language model a git commit is convenient and not free: it means review is optional unless you build it into your habits. `/sync` is the mechanism the whole template-versus-workspace design depends on, and it is worth running early rather than late so you find out how it behaves before you have months of data in the workspace.

None of these commands are documented beyond the one-line table. If you want to know what `/start` actually includes, open the file under `.claude/commands/` and read the prompt, which is possible precisely because the project is markdown all the way down.

Eight integrations, and what the secrets cost you

The integration list is the part that makes MARVIN useful day to day. Google Workspace covers Gmail, Calendar and Drive. Microsoft 365 covers Outlook, Calendar, OneDrive and Teams. Atlassian brings Jira and Confluence. Slack is for channel monitoring and posting. Linear handles issue tracking, Notion handles page reading and database queries, Telegram lets you talk to MARVIN from your phone, and Parallel Search adds web search.

Each one lives in its own directory under `.marvin/integrations/` with its own setup instructions, and that per-integration pattern is what keeps the project from becoming a monolith. It is also where the security guidance lives: the contribution guidelines point at `.marvin/integrations/CLAUDE.md` for patterns and security requirements, which tells you the author expects people adding integrations to think about permissions rather than just wiring up a client library.

The `.env.example` shows what you are signing up for. Google needs `GOOGLE_OAUTH_CLIENT_ID` and `GOOGLE_OAUTH_CLIENT_SECRET`, obtained from the Google Cloud Console. Notion, Linear and Slack each want an API key or bot token. There is also an `OPENAI_API_KEY` for skills that need one.

What strikes you about the file is the split between key-based and CLI-based auth. Atlassian is marked as using browser auth with no keys in the file, and the CLI section notes that tools like `gws`, `gh` and `npx` handle their own authentication, with the example `gws auth login -s gmail,calendar,drive`. The header comment is the important line: the frontend receives only the site address, all keys stay on the backend, and `.env` should not be committed to git. With OAuth credentials for Google plus a Slack bot token sitting in a plain env file, that last instruction is the security boundary this project has, and there is no vault behind it.

Why the workspace and the template are two directories

This is the design decision that separates marvin-template from a folder of prompts someone copies. The README draws it as two trees: your workspace at `~/marvin/` holding your profile in `CLAUDE.md`, your goals and priorities in `state/`, and your daily session logs in `sessions/`, and the template at `~/marvin-template/` holding setup scripts and integration definitions in `.marvin/` and command and agent templates in `.claude/`.

Your data lives in the workspace. The template supplies updates. Running `/sync` from the workspace pulls new features across without overwriting your data. That is the git-workflow answer to a problem most personal assistant setups hit within a month, which is that you cannot upgrade the tool without losing the thing you built with it.

The top-level tree shows the same shape as directories: `content/`, `meetings/`, `reports/`, `research/`, `sessions/`, `state/`, `skills/` and `docs/` sit alongside `.claude/` and `.marvin/`. A repository whose primary language is Shell and whose output directories are named after meeting notes and weekly reports is telling you what it produces.

Extension follows the same convention. Commands in `.claude/commands/` are workflows you invoke with a slash command, agents in `.claude/agents/` are subagents MARVIN spawns for delegated work, and skills in `.claude/skills/` are reusable capabilities invoked contextually. Templates exist for each type, and the intended workflow is conversational: ask it to create a skill for X and it writes the file. Nothing prevents you from editing those files by hand, which for most people is the more predictable path.

Migration path, and what to check before trusting it with your inbox

Earlier versions ran out of the template directory itself, and there is a migration script for people who started that way:

cd marvin-template
./.marvin/migrate.sh

The script copies your profile, goals, sessions, reports and custom skills into a new workspace. The README is careful about how it describes this: nothing is deleted from the old installation, and you are told to verify the new workspace works before cleaning up the old one. That is the right order of operations for a tool holding years of notes, and it is worth noting that the copy-then-verify pattern is left to you rather than automated.

Before wiring up email or chat, three things deserve attention. First, the secrets are yours: a `.env` with Google OAuth credentials and a Slack bot token, protected only by a gitignore and your own discipline. Second, `/commit` means an agent can write history, so decide now whether you want it to and add a review step if you do not. Third, nothing in the repository describes how the assistant decides what to write into `state/` or `sessions/`, so the practical guard is to read those files after the first week rather than assume they contain what you expected.

The contribution policy is worth a mention because it signals what kind of project this is. It asks for new integrations following the documented patterns and security requirements, extensions to the commands, agents and skills, and bug fixes with a test case, with all contributions reviewed. Five open issues and a last push on 2026-08-18 suggest a small active project rather than a busy one.

Editorial conclusion

The idea worth taking from marvin-template is the split between template and workspace, because it is the difference between a tool you can upgrade and one you cannot. Your profile, goals and session logs live in `~/marvin/`, the reusable commands and integration definitions live in the template, and `/sync` moves improvements across without touching your data. The cost is that you are running a documented convention rather than a supported product: the setup is shell scripts under `.marvin/`, the secrets are yours to manage in `.env`, and nothing forces the agent to behave consistently once your context grows large. The right first move is the clone, the `claude` launch and the phrase help me set up MARVIN, then read the `/start` and `/end` commands before wiring up any integration that touches your mail.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. SterlingChin/marvin-template on GitHub