Automate Your AI Second Brain with Devin

Turn an Obsidian vault into a synced Devin-powered daily knowledge system.

Introduction

30 Second Summary

Your notes can hold valuable ideas while your day still begins with scattered priorities. The useful signal often stays buried until you know what to look for.

In this project, you will turn your existing Obsidian vault into a daily operating system powered by Devin CLI. The finished workflow carries useful context from capture to planning to reflection without discarding the knowledge structure you already built.

What You'll Build

You run /briefing in the morning and see a focused plan shaped by your priorities, recent vault activity, and live Notion context.

By the end of this project, you'll have:

A /query command that delivers source-backed answers from your existing wiki with citations to the relevant pages.
A selective capture workflow that brings chosen Notion pages into raw/notion/ for human review before they influence your wiki.
A repeatable morning and evening loop that records briefings plus debriefs in wiki/log.md while a private GitHub repository preserves the history.
Secret Mission: Schedule a local-only weekday briefing with macOS launchd while your Mac is logged in.

Are there any prerequisites?

You will need macOS plus a completed Part 1 vault containing CLAUDE.md, raw/, and wiki/. You will also need a Devin Free account.

A Notion account can be created during the project. The main workflow uses free plans plus local tools.

Before We Start

Your completed Part 1 Obsidian vault already holds the knowledge structure you built. This step protects that foundation by locking in the daily decision support you want before any hands-on work.

Meet Devin in Your Existing Vault

Your completed Part 1 Obsidian vault already contains the notes and rules that shape your second brain. Preserving that structure gives the daily workflow a trusted foundation.

The vault still lacks the morning workflow this project promises. In this step, you will prove that Devin CLI can read the real vault before you test that missing command for yourself.

In this step, get ready to:

Verify the Part 1 vault files and Git installation.
Install the pinned Devin CLI build and authenticate your account.
Let Devin inspect the vault before testing the missing briefing command.

Verify the vault and Mac tools

The macOS Terminal gives Devin direct access to your local vault. Apple Command Line Tools supply Git, which later preserves every vault change.

Press Cmd+Space to open Spotlight.
Type Terminal into Spotlight.
Press Enter to open Terminal.

Move into your existing vault by running this command:

cd ~/Documents/second-brain

What does this command do?

The cd command changes Terminal's current location to ~/Documents/second-brain. Commands you run next can now work with the real Part 1 vault.

List the vault contents by running this command:

ls

What does this command do?

The ls command prints the files and folders in your current location. This makes the existing vault structure visible without changing it.

You should see CLAUDE.md, raw/, and wiki/ in the output. These items confirm that Terminal is inside the completed Part 1 vault.

Vault files missing?

Check that the path in Terminal is spelled ~/Documents/second-brain.
Confirm that CLAUDE.md sits at the top level of your Part 1 vault.
Return to your Part 1 project if the vault was saved in another location.

Still missing the vault? Help me locate my completed Part 1 second-brain vault on macOS.

Git provides the version history that protects your vault later in the project. The next check confirms whether Apple's developer tools already provide a working Git executable.

Check your Git installation by running this command:

git --version

What does this command do?

The command asks the installed Git executable for its version. A version number confirms that Git is available in Terminal.

✔️ I see a Git version

Good. Git is installed and ready to preserve future vault changes.

ⓧ Git is unavailable

Apple provides Git through its Command Line Tools installer. The installation can take a few minutes while macOS adds the required developer tools.

Start Apple's Command Line Tools installer by running this command:

xcode-select --install

What does this command do?

The command opens Apple's official installer dialog for Command Line Tools. That package supplies the Git executable used in this project.

Complete the installer dialog shown by macOS.
Return to Terminal after the installation finishes.
Verify Git again by running this command:

git --version

What does this check confirm?

The repeated check confirms that Terminal can now find the newly installed Git executable. You should see a Git version number.

Install and authenticate Devin CLI

Devin CLI works directly with files in the current Terminal directory. This project uses build 3000.11.3 so every documented command behaves consistently.

Check the installed Devin CLI build by running this command:

devin version

What does this command do?

The command prints the installed Devin CLI build. Compare the result with the pinned build 3000.11.3 before continuing.

✔️ I see the pinned build

Your terminal shows build 3000.11.3. Devin CLI is ready for authentication.

ⓧ I see an older build

The stable installer refreshes the existing Devin CLI installation. Give the installer a moment to download the pinned build.

Update Devin CLI by running this command:

curl -fsSL https://cli.devin.ai/install.sh | bash

What does this installer do?

The command downloads Devin's official macOS installation script over HTTPS. The script installs the current stable Devin CLI build.

Close the current Terminal window after the installer finishes.
Press Cmd+Space to reopen Spotlight.
Type Terminal into Spotlight.
Press Enter to reopen Terminal.
Check the updated build by running this command:

devin version

What does this check confirm?

The command confirms that the refreshed Terminal session can find Devin CLI. You should now see build 3000.11.3.

ⓧ Command not found

The official installer adds Devin CLI to your local user environment. The download may sit quietly for a moment before installation output appears.

Install Devin CLI by running this command:

curl -fsSL https://cli.devin.ai/install.sh | bash

What does this installer do?

The command downloads Devin's official macOS installation script over HTTPS. The installer links the Devin executable into ~/.local/bin/devin.

Close the current Terminal window after the installer finishes.
Press Cmd+Space to reopen Spotlight.
Type Terminal into Spotlight.
Press Enter to reopen Terminal.
Verify the installation by running this command:

devin version

What does this check confirm?

The command confirms that your refreshed Terminal session can find Devin CLI. You should see build 3000.11.3.

Still missing the pinned build?

Confirm that the installer finished without a network failure.
Check that the installed executable exists at ~/.local/bin/devin.
Restart Terminal after the installation so the refreshed environment can find Devin CLI.

Need another pair of eyes? Help me troubleshoot my Devin CLI installation.

The next command opens a browser sign-in for your Devin Free account. Your account details stay out of the command you type in Terminal.

Start the Devin authentication flow by running this command:

devin auth login

What does this command do?

The command begins Devin CLI authentication. Your browser handles the account sign-in before Terminal receives the completed session.

Complete the browser sign-in with your Devin Free account.
Return to Terminal after the browser confirms the sign-in.
Check the authenticated session by running this command:

devin auth status

What does this check confirm?

The command reports the current Devin authentication state. An authenticated result confirms that the CLI can use your Devin Free account.

That is the account setup complete. Devin CLI can now work inside your local vault.

Starting Devin from the vault root makes that folder its workspace. Normal permission mode automatically allows read-only inspection inside the current directory while keeping write operations behind your approval.

Return to the vault root by running this command:

cd ~/Documents/second-brain

Why return to the vault root?

Devin uses the current Terminal directory as its workspace. Starting from ~/Documents/second-brain gives it access to the existing vault rules and notes.

Start the interactive Devin session by running this command:

devin

What happens now?

The command starts an interactive Devin session inside the current vault. The session takes over this Terminal window until you exit it.

Keep Normal as the permission mode.
Ask Devin to inspect the existing rules by entering this prompt:

Summarize the vault structure and the four sections of CLAUDE.md without changing any files.

Why use this prompt?

The prompt gives Devin a read-only inspection task. A useful summary proves that the session can find CLAUDE.md and understand the Part 1 vault structure.

You should receive a summary of the vault structure and the four sections in CLAUDE.md. No vault files should be changed.

Devin cannot read the vault?

Confirm that the Devin session started from ~/Documents/second-brain.
Check that CLAUDE.md remains at the top level of the vault.
Keep the session in Normal permission mode for this inspection.

Still blocked? Help me understand why Devin cannot summarize CLAUDE.md from my vault.

Expose the missing briefing workflow

Devin's summary proves that local vault access works. A direct command check now reveals whether the promised morning workflow exists in the current project.

Before you run the next command, do you think the Part 1 vault already knows how to create a morning briefing?

Test the morning workflow by entering this command in the Devin session:

/briefing

Why is the command unknown?

You should see a response explaining that the command is unknown. This shortfall is intentional.

Part 1 created /ingest, /query, /lint, and /log. The morning workflow has no command yet.

Press Ctrl+D on an empty input line to exit the Devin session.

Before you run the inventory check, do you expect it to show a Devin-native briefing Skill?

Record the current project Skill inventory by running this command:

devin skills list

What does this inventory show?

The command lists the Skills currently available to Devin. This output becomes your baseline before the vault receives Devin-native project Skills.

The inventory and unknown-command response confirm the same gap. Devin can read your vault, while the daily briefing workflow is still absent.

Skill inventory command failed?

Confirm that the interactive Devin session has closed.
Check the installed build again if Terminal cannot find the Devin command.
Rerun the inventory check from ~/Documents/second-brain.

Need help reading the result? Help me interpret my current Devin Skill inventory.

Your authenticated Devin session can read the real vault, and you have captured the missing morning workflow as a visible baseline. Next, you will give the vault native rules and reusable Skills.

Create Devin-Native Skills

You have already proved that Devin CLI can read your existing vault. You also saw that the daily workflow is missing.

This step gives Devin a native rule entry point. You will also recreate the four working Part 1 commands as project-scoped Devin Skills while preserving your personalized CLAUDE.md and .claude/commands/ files.

In this step, get ready to:

Add an AGENTS.md bridge for Devin-native project rules.
Port the ingest, query, lint, and log workflows into project Skills.
Validate the Skills and prove that /query cites your wiki without editing it.

Bridge your existing vault rules

Devin reads AGENTS.md automatically as the native project-rule file. The bridge keeps your personalized CLAUDE.md in charge of the vault schema.

Create AGENTS.md beside CLAUDE.md using your editor's file sidebar.

You should see the empty AGENTS.md file at the top level of second-brain.

Fill AGENTS.md by copying this content into the empty file:

# Devin Second Brain Rules

- Treat `CLAUDE.md` as the canonical vault schema and preserve its personalized Domain Context.
- Keep original source material in `raw/`. Maintain compiled, cross-linked knowledge in `wiki/`.
- Use the project Skills in `.devin/skills/` for ingest, query, lint, log, source capture, briefing, and debrief workflows.
- Read `priorities.md` at the start of every briefing and debrief.
- Prioritize signals tied to Projects and Areas. Use Resources as supporting context. Ignore Archive items unless the user asks about them.
- Never place secrets, OAuth tokens, or personal MCP credentials in committed files.
- Ask before deleting source notes or creating a new wiki page that changes the vault taxonomy.

What do these rules protect?

The first rule preserves the personalized Domain Context already stored in CLAUDE.md.
The storage rules keep original material in raw/. They reserve wiki/ for compiled knowledge.
The workflow rule points Devin toward the project Skills in .devin/skills/.
The final rules protect credentials and require approval before destructive taxonomy changes.

Save AGENTS.md.
Confirm AGENTS.md remains beside CLAUDE.md in the vault's file sidebar.

Can't see AGENTS.md?

Check that you created the file directly inside second-brain.
Check that the filename is exactly AGENTS.md.
Keep CLAUDE.md in place because the bridge depends on it.

Still stuck? Help me check where AGENTS.md belongs in my Devin project.

Port the ingest and query workflows

Each Skill stores its instructions in a project-scoped SKILL.md file. Its YAML frontmatter gives Devin a trigger plus a focused set of tools and permissions.

The first pair covers knowledge promotion and evidence-based answers. Both workflows preserve the distinction between source material in raw/ and compiled knowledge in wiki/.

Create .devin/skills/ingest/SKILL.md inside second-brain using your editor's file sidebar.

You should see SKILL.md nested beneath the new .devin/skills/ingest/ path.

Define the ingest workflow by copying this content into .devin/skills/ingest/SKILL.md:

---
name: ingest
description: Promote selected raw notes into the cross-linked wiki
argument-hint: "[maximum files]"
allowed-tools:
  - read
  - grep
  - glob
permissions:
  allow:
    - Read(raw/**)
    - Read(wiki/**)
    - Write(wiki/**)
  deny:
    - exec
triggers:
  - user
---

Ingest source material from `raw/` into `wiki/` while following `CLAUDE.md` and `AGENTS.md`.

1. If `$ARGUMENTS` contains a positive number, process no more than that many unprocessed source files. Otherwise process all unprocessed source files.
2. Preserve every file in `raw/`. Never delete or rewrite source material.
3. Search `wiki/` before creating a page. Update an existing page when the topic already exists.
4. For each created or updated wiki page, use YAML frontmatter with `title`, `type`, and `last-updated`, use Title Case headings, add relevant `[[Wiki Links]]`, and cite the source file paths.
5. Ask before creating a page when its destination or taxonomy is ambiguous.
6. Append one timestamped ingest entry to `wiki/log.md` with the processed source paths and the wiki pages created or updated.
7. Report the processed count, skipped count, and changed wiki pages.

How does the ingest Skill work?

The argument-hint shows that the learner can limit the number of source files processed.
The permission rules allow reads from raw/ and wiki/.
The write permission is limited to wiki/.
The workflow preserves every original source before updating cited wiki pages.

Save .devin/skills/ingest/SKILL.md.
Confirm the file remains inside .devin/skills/ingest/.

Ingest Skill in the wrong place?

Check that the file is named SKILL.md with uppercase letters.
Check that ingest has its own folder beneath .devin/skills/.
Keep the opening and closing frontmatter markers on separate lines.

Need another pair of eyes? Help me check my ingest Skill path and frontmatter.

Create .devin/skills/query/SKILL.md inside second-brain using your editor's file sidebar.

You should see a second SKILL.md beneath .devin/skills/query/.

Define the read-only query workflow by copying this content into .devin/skills/query/SKILL.md:

---
name: query
description: Answer a question from the vault with page citations
argument-hint: "<question>"
allowed-tools:
  - read
  - grep
  - glob
permissions:
  deny:
    - edit
    - write
    - exec
triggers:
  - user
---

Answer the user's question: `$ARGUMENTS`.

1. If no question was supplied, ask for one and stop.
2. Search `wiki/` first. Search `raw/` only when the wiki lacks enough evidence.
3. Do not modify any file.
4. Cite every substantive claim with the wiki page title and path. If a claim comes only from raw material, label it as raw and cite that path.
5. Separate confirmed evidence from inference. Say when the vault does not contain an answer.

How does the query Skill stay trustworthy?

The denied tools prevent the Skill from editing files or running commands.
The search order checks wiki/ before using evidence from raw/.
The citation rule attaches a page title and path to every substantive claim.
The final rule separates vault evidence from Devin's inference.

Save .devin/skills/query/SKILL.md.
Confirm the file remains inside .devin/skills/query/.

Query Skill missing its safeguards?

Check that edit, write, and exec remain under deny.
Check that the search order names wiki/ before raw/.
Check that the filename uses uppercase SKILL.md.

Want help comparing the safeguards? Help me inspect my read-only query Skill.

Switch back to the Terminal session at the second-brain vault root.
Validate the first two Skills by running these commands:

devin doctor
devin skills list

What do these checks prove?

The first command diagnoses malformed agent configuration and Skill frontmatter.
The second command shows the project Skills Devin currently discovers.

The diagnostic should complete without a malformed frontmatter problem. The Skill inventory should now include ingest and query.

Don't see both Skills?

Return to the path named by the diagnostic.
Compare the frontmatter markers with the matching code block above.
Rerun both checks after saving the corrected file.

If the inventory still looks wrong, help me diagnose why Devin cannot discover my ingest and query Skills.

Add checks and prove the migration

The remaining Skills cover vault health and concise activity records. The lint workflow stays read-only while the log workflow receives one narrow write permission.

Create .devin/skills/lint/SKILL.md inside second-brain using your editor's file sidebar.

You should see SKILL.md beneath the new .devin/skills/lint/ path.

Define the read-only vault checker by copying this content into .devin/skills/lint/SKILL.md:

---
name: lint
description: Report structural and linking problems in the wiki
allowed-tools:
  - read
  - grep
  - glob
permissions:
  deny:
    - edit
    - write
    - exec
triggers:
  - user
---

Inspect `wiki/` without changing files.

Check every Markdown page for:

1. Missing YAML frontmatter keys: `title`, `type`, or `last-updated`.
2. Empty pages or pages containing only a heading.
3. `[[Wiki Links]]` whose target page cannot be found.
4. Duplicate page titles.
5. Source claims that do not cite a file from `raw/`.

Return a health report with totals, affected paths, and the smallest suggested fix for each issue. End with either `PASS: no issues found` or `FAIL: <number> issues found`.

What does the lint Skill inspect?

The denied permissions keep the inspection read-only.
The checks cover required frontmatter and empty pages.
The checks also find unresolved links and duplicate titles.
The source check flags claims that lack a citation from raw/.

Save .devin/skills/lint/SKILL.md.
Confirm the file remains inside .devin/skills/lint/.

Lint Skill not read-only?

Check that edit, write, and exec remain under deny.
Check that the inspection target is wiki/.
Check that all five health checks remain numbered.

Need help checking the restrictions? Help me verify my lint Skill is read-only.

Create .devin/skills/log/SKILL.md inside second-brain using your editor's file sidebar.

You should see the final SKILL.md beneath .devin/skills/log/.

Define the scoped logging workflow by copying this content into .devin/skills/log/SKILL.md:

---
name: log
description: Append a concise timestamped note to the wiki log
argument-hint: "<entry>"
allowed-tools:
  - read
permissions:
  allow:
    - Write(wiki/log.md)
  deny:
    - exec
triggers:
  - user
---

Append a new entry to `wiki/log.md`.

- Use `$ARGUMENTS` as the entry text.
- If `$ARGUMENTS` is empty, ask the user what should be logged and wait for the answer.
- Add a local timestamp heading in `YYYY-MM-DD HH:mm` format.
- Preserve all existing log content.
- Keep the entry concise and confirm the exact heading that was added.

How is the log Skill scoped?

The write permission targets only wiki/log.md.
The denied execution permission prevents shell commands.
The timestamp format keeps entries ordered by local date and time.
The preservation rule protects every existing log entry.

Save .devin/skills/log/SKILL.md.
Confirm the file remains inside .devin/skills/log/.

Log permission too broad?

Check that the only write target is wiki/log.md.
Check that exec remains denied.
Check that the workflow preserves existing log content.

If the scope looks different, help me tighten my log Skill permissions.

Before you run the final checks, which four Skill names do you expect Devin to discover?

Switch back to the Terminal session at the vault root.
Validate the complete migration by running these commands:

devin doctor
devin skills list

What does the final check confirm?

The diagnostic checks the complete set of rules and Skill frontmatter.
The inventory confirms that Devin discovers all four project Skills.

The diagnostic should complete without a malformed frontmatter problem. The Skill inventory should show ingest, query, lint, and log.

Still missing a Skill?

Match the missing Skill name to its folder beneath .devin/skills/.
Confirm its file is named SKILL.md.
Use the diagnostic output to locate malformed frontmatter.

For a focused check, help me diagnose the missing Devin Skill.

Start Devin from the existing vault-root Terminal session by running:

devin

Why start Devin here?

Starting Devin from the vault root makes second-brain the active workspace. Devin can now load AGENTS.md and the four project Skills from that workspace.

Before you submit the test query, do you expect Devin to search wiki/ or raw/ first?

Replace <a topic already in your wiki> with a topic covered by one of your existing wiki pages.
Test the migrated query Skill by entering this prompt in Devin:

/query <a topic already in your wiki>

What should the query Skill do?

The Skill searches wiki/ before consulting raw/.
The answer cites the wiki page title and path for each substantive claim.
The Skill labels any claim supported only by raw material.
The denied permissions keep every vault file unchanged.

You should receive an answer grounded in your existing wiki with page titles and file paths. That result proves the Claude-shaped workflow now runs as a Devin-native Skill.

Query missing citations?

Confirm your chosen topic appears in at least one Markdown file beneath wiki/.
Compare the query Skill's search order with the code above.
Confirm the citation instruction still requires both the page title and path.

If the response remains unsupported, help me troubleshoot why my query Skill is not citing wiki pages.

✔️ Awesome, I've got everything!

Your rule bridge and four native Skills are saved. Devin can discover them and answer from your wiki with citations.

ⓧ I'd like to double check the full code

Compare each saved file with the complete references below.

# Devin Second Brain Rules

- Treat `CLAUDE.md` as the canonical vault schema and preserve its personalized Domain Context.
- Keep original source material in `raw/`. Maintain compiled, cross-linked knowledge in `wiki/`.
- Use the project Skills in `.devin/skills/` for ingest, query, lint, log, source capture, briefing, and debrief workflows.
- Read `priorities.md` at the start of every briefing and debrief.
- Prioritize signals tied to Projects and Areas. Use Resources as supporting context. Ignore Archive items unless the user asks about them.
- Never place secrets, OAuth tokens, or personal MCP credentials in committed files.
- Ask before deleting source notes or creating a new wiki page that changes the vault taxonomy.

---
name: ingest
description: Promote selected raw notes into the cross-linked wiki
argument-hint: "[maximum files]"
allowed-tools:
  - read
  - grep
  - glob
permissions:
  allow:
    - Read(raw/**)
    - Read(wiki/**)
    - Write(wiki/**)
  deny:
    - exec
triggers:
  - user
---

Ingest source material from `raw/` into `wiki/` while following `CLAUDE.md` and `AGENTS.md`.

1. If `$ARGUMENTS` contains a positive number, process no more than that many unprocessed source files. Otherwise process all unprocessed source files.
2. Preserve every file in `raw/`. Never delete or rewrite source material.
3. Search `wiki/` before creating a page. Update an existing page when the topic already exists.
4. For each created or updated wiki page, use YAML frontmatter with `title`, `type`, and `last-updated`, use Title Case headings, add relevant `[[Wiki Links]]`, and cite the source file paths.
5. Ask before creating a page when its destination or taxonomy is ambiguous.
6. Append one timestamped ingest entry to `wiki/log.md` with the processed source paths and the wiki pages created or updated.
7. Report the processed count, skipped count, and changed wiki pages.

---
name: query
description: Answer a question from the vault with page citations
argument-hint: "<question>"
allowed-tools:
  - read
  - grep
  - glob
permissions:
  deny:
    - edit
    - write
    - exec
triggers:
  - user
---

Answer the user's question: `$ARGUMENTS`.

1. If no question was supplied, ask for one and stop.
2. Search `wiki/` first. Search `raw/` only when the wiki lacks enough evidence.
3. Do not modify any file.
4. Cite every substantive claim with the wiki page title and path. If a claim comes only from raw material, label it as raw and cite that path.
5. Separate confirmed evidence from inference. Say when the vault does not contain an answer.

---
name: lint
description: Report structural and linking problems in the wiki
allowed-tools:
  - read
  - grep
  - glob
permissions:
  deny:
    - edit
    - write
    - exec
triggers:
  - user
---

Inspect `wiki/` without changing files.

Check every Markdown page for:

1. Missing YAML frontmatter keys: `title`, `type`, or `last-updated`.
2. Empty pages or pages containing only a heading.
3. `[[Wiki Links]]` whose target page cannot be found.
4. Duplicate page titles.
5. Source claims that do not cite a file from `raw/`.

Return a health report with totals, affected paths, and the smallest suggested fix for each issue. End with either `PASS: no issues found` or `FAIL: <number> issues found`.

---
name: log
description: Append a concise timestamped note to the wiki log
argument-hint: "<entry>"
allowed-tools:
  - read
permissions:
  allow:
    - Write(wiki/log.md)
  deny:
    - exec
triggers:
  - user
---

Append a new entry to `wiki/log.md`.

- Use `$ARGUMENTS` as the entry text.
- If `$ARGUMENTS` is empty, ask the user what should be logged and wait for the answer.
- Add a local timestamp heading in `YYYY-MM-DD HH:mm` format.
- Preserve all existing log content.
- Keep the entry concise and confirm the exact heading that was added.

Your existing vault now has a Devin-native rule bridge and four reusable Skills. Next up, you will protect this work with a private GitHub backup and connect a controlled Notion inbox.

Back Up the Vault and Connect Notion

Your four Skills now let Devin CLI work with the knowledge in your existing vault. The vault still has a single point of failure on your Mac.

A private GitHub repository gives your vault off-device history. Obsidian can synchronize each change through Git.

A controlled Notion connection adds live context through the Model Context Protocol. You will authorize one safe inbox for Devin to read.

In this step, get ready to:

Create a private GitHub backup of your vault.
Configure Obsidian Git to synchronize your changes.
Authorize a controlled Notion inbox for Devin.

Create the private GitHub backup

Git records snapshots of your vault so you can trace changes over time. GitHub CLI creates the private remote repository without requiring a personal access token.

Check your installed GitHub CLI version by running:

gh --version

What should I see?

The command prints the installed GitHub CLI version. This guide uses version 2.102.0.

✔️ I see the required version

Your GitHub CLI is ready if the output shows 2.102.0 or higher.

ⓧ I see an older version

Upgrade GitHub CLI with the verified macOS installer for version 2.102.0.

Open the official GitHub CLI release in your browser.
Download gh_2.102.0_macOS_universal.pkg from the release assets.
Double-click gh_2.102.0_macOS_universal.pkg in your Downloads folder.
Complete the macOS installer.
Return to Terminal after the installation finishes.
Confirm the upgraded version by running:

gh --version

What should I see?

The output should now show GitHub CLI version 2.102.0 or higher.

ⓧ Command not found

Install GitHub CLI with the verified macOS package for version 2.102.0.

Open the official GitHub CLI release in your browser.
Download gh_2.102.0_macOS_universal.pkg from the release assets.
Double-click gh_2.102.0_macOS_universal.pkg in your Downloads folder.
Complete the macOS installer.
Restart Terminal after the installation finishes.
Verify the installation by running:

gh --version

What should I see?

The command should now print GitHub CLI version 2.102.0 or higher.

The browser authentication flow keeps your GitHub password out of Terminal. GitHub CLI can store the resulting HTTPS credentials in your system credential store.

Plan to select GitHub.com when the host prompt appears.
Plan to select HTTPS when the protocol prompt appears.
Start the GitHub authentication flow by running:

gh auth login

What does this command do?

This command starts GitHub CLI authentication. It hands the secure sign-in stage to your browser.

Create a GitHub account in the browser if you do not have one.
Complete the browser sign-in with your GitHub account.
Allow GitHub CLI to configure Git credentials.
Return to Terminal when authentication completes.

Did GitHub authentication fail?

Confirm that your browser completed the GitHub authorization page before returning to Terminal.
Check that you selected GitHub.com as the host.
Repeat the authentication command if the browser window was closed early.

Still stuck? Help me troubleshoot GitHub CLI browser authentication on macOS.

Every Git commit stores an author name and email address. Set these values to the identity you want attached to your vault history.

Replace Your Name with your GitHub commit name in the commands below.
Replace you@example.com with your GitHub commit email in the commands below.
Set your global Git identity by running the edited commands:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

What do these commands do?

These settings identify the author of future Git commits on your Mac. GitHub uses that metadata to associate commits with your account when the email matches.

Your vault contains local workspace state that does not belong in the remote repository. The .gitignore file keeps that state out of each commit.

Open or create .gitignore inside ~/Documents/second-brain by running:

nano ~/Documents/second-brain/.gitignore

What does this command do?

Nano opens the hidden .gitignore file in Terminal. It creates the file at the vault root when the file does not already exist.

Replace any existing content with these exact ignore rules:

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/
.devin/config.local.json
.devin/mcp_config.local.json
*.log

What do these rules protect?

The Obsidian workspace entries exclude device-specific interface state.
The .trash/ entry excludes locally deleted notes.
The Devin entries exclude local configuration files that may contain personal connection details.
The *.log entry excludes generated log files.

Save .gitignore using the shortcut shown at the bottom of nano.
Exit nano using its on-screen shortcut.

✔️ Awesome, I've got everything!

Your vault now has the six ignore rules needed for this project.

ⓧ I'd like to double check the full code

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/
.devin/config.local.json
.devin/mcp_config.local.json
*.log

What should I compare?

Your file should contain these six lines in this order. Keep the local Devin configuration entries because the Notion connection is added later in this step.

Return to the vault root by running:

cd ~/Documents/second-brain

What does this command do?

This makes ~/Documents/second-brain the current Terminal location. The repository commands now apply to the complete vault.

Initialize the vault on the main branch by running:

git init -b main

What does this command do?

This creates the local Git repository metadata. The -b main option names the first branch main.

Pause for a prediction about which vault files Git can see after applying .gitignore.

Inspect the new repository state by running:

git status

What should I see?

Git should report that you are on the main branch. Your vault files should be available for the first commit without the ignored local state.

Create the initial vault snapshot by running:

git add .
git commit -m "Migrate second brain to Devin"

What do these commands do?

The first command stages the vault files allowed by .gitignore. The second command records that snapshot with the message Migrate second brain to Devin.

Uploading personal notes deserves a careful pause. The next command creates the repository as private before it pushes your commit.

Create the private second-brain repository by running:

gh repo create second-brain --private --source=. --remote=origin --push

What does this command do?

The repository name becomes second-brain.
The --private option restricts access to authorized GitHub users.
The --remote=origin option connects the local vault to the new repository.
The --push option uploads the existing main branch.

Open the repository link printed in Terminal.
Confirm the repository header shows Private.
Confirm the latest commit is Migrate second brain to Devin.
Keep the note contents closed until you have confirmed the private status.

That is the first safety net in place. Your existing rules and Skills now have versioned off-device storage.

Did the repository push fail?

Confirm that GitHub CLI authentication completed with the same account you are checking in the browser.
Check that the repository name second-brain is not already used by another repository in your account.
Confirm that the initial commit completed before the repository creation command ran.

Need help? Help me diagnose why my private second-brain repository was not created or pushed.

Set up automatic Obsidian synchronization

The private repository protects only the changes that reach GitHub. The Git community plugin lets Obsidian commit local edits before pulling and pushing the latest history.

Press Cmd+Space to open your macOS search bar.
Type Obsidian and press Enter.
Return to your existing second-brain vault.

Why use the Git plugin?

The plugin turns the Git workflow into Obsidian commands and scheduled synchronization. Your Markdown files remain ordinary files with normal Git history.

Open Obsidian's settings.
Go to the community plugin browser.
Search for Git.
Select the plugin named Git by Vinzent.
Install the selected plugin.
Enable the selected plugin.
Confirm the plugin details show version 2.40.0.

Open the Git plugin's Automatic settings.
Set Auto commit-and-sync interval (minutes) to 10.
Enable Auto commit-and-sync after stopping file edits.
Open the plugin's Sync settings.
Enable Pull on startup.
Enable Push on commit-and-sync.
Enable Pull on commit-and-sync.

A manual sync gives you immediate evidence that the plugin can reach the private repository. You will make one harmless log edit for that test.

Select wiki/log.md in your existing vault.
Append the line Obsidian Git sync test. to the file.
Press Command-P to open the Obsidian command palette.
Run Git: Commit-and-sync.
Return to the private second-brain repository in your browser.
Confirm a fresh commit appears in the repository history.

Pause for a prediction about whether the local branch should have any pending changes after commit-and-sync completes.

Switch back to Terminal at the vault root.
Check the synchronized repository state by running:

git status

What should I see?

Git should report the main branch with no pending vault changes. This confirms the plugin committed the edit before pushing it.

Your automatic backup loop is working. Future edits can reach GitHub every ten minutes or after you stop editing.

Did commit-and-sync miss GitHub?

Confirm that Push on commit-and-sync remains enabled.
Confirm that the local repository still has an origin remote.
Check the plugin output inside Obsidian for an authentication or pull conflict message.

Need a hand? Help me troubleshoot why Obsidian Git did not push my commit-and-sync test.

Connect a controlled Notion inbox

A fixed inbox gives Devin a narrow place to find live source material. The connection uses OAuth so you can authorize access through Notion without placing credentials in the vault.

Sign in to Notion in your browser.
Create a Notion Free workspace if you do not already have one.
Create a top-level page named Second Brain Inbox.
Create a direct child page named Project Check-In beneath Second Brain Inbox.
Enter Draft next steps. in Project Check-In.
Create a direct child page named Reading Queue beneath Second Brain Inbox.
Enter Review one saved article. in Reading Queue.

Why use a fixed inbox?

The fixed Second Brain Inbox page creates a clear boundary for later source capture. The two child pages provide safe test data without exposing unrelated workspace content.

The OAuth screen deserves a careful pause because this connection can act with your Notion permissions. Keep the authorization limited to the workspace content intended for this project.

Return to the Terminal window at ~/Documents/second-brain.
Add Notion's hosted MCP server by running:

devin mcp add notion https://mcp.notion.com/mcp

What does this command do?

This registers the hosted Notion MCP endpoint under the name notion. Devin stores the local connection configuration in .devin/mcp_config.local.json.

Your .gitignore excludes that local configuration file from GitHub. The connection details stay outside the committed vault history.

Start the Notion OAuth flow by running:

devin mcp login notion

What does this command do?

This opens the browser authorization flow for the configured notion server. Devin receives access only after you approve the connection.

Complete the Notion sign-in in your browser.
Authorize only the workspace content intended for this project.
Return to Terminal after the OAuth flow confirms the connection.

Start Devin from the vault root by running:

devin

What happens next?

Devin starts with ~/Documents/second-brain as its workspace. It can now use the authorized Notion connection when your request requires live content.

Pause for a prediction about whether Devin will return the same two child-page titles you created in Notion.

Ask Devin to read the controlled inbox with this prompt:

Find the Second Brain Inbox page in Notion and list the titles of its child pages without changing Notion.

What should I see?

Devin should return Project Check-In and Reading Queue from the real Notion page. The request explicitly keeps this test read-only.

You now have both sides of the safety system working. GitHub preserves the vault while Devin reads current context from your controlled Notion inbox.

Can Devin not find the inbox?

Confirm that the parent page is named exactly Second Brain Inbox.
Confirm that both test pages are direct children of the inbox page.
Repeat the MCP login flow if the wrong Notion workspace was authorized.

Still blocked? Help me troubleshoot why Devin cannot read my authorized Notion inbox.

Your vault now has private versioned backups and a controlled source of live context. Next, you will turn that connection into a selective capture flow guided by your priorities.

Capture Sources and Set Priorities

Your private backup protects the vault you built. Your authorized Notion connection brings live information within reach.

Live access still leaves the vault cold and unfiltered. In this step, you will give Devin a human-owned priorities file plus a selective capture gate that keeps low-value material out of your wiki.

In this step, get ready to:

Personalize a priorities file that steers daily decisions.
Add a source-capture Skill with narrow permissions.
Move selected Notion pages through capture, triage, and ingestion.

Write the steering document

A priorities file tells each workflow what deserves attention now. You will create it in the existing Obsidian vault so you remain in control of that judgment.

Switch back to the existing vault in Obsidian.
Create priorities.md inside second-brain by using the file creation control in the left file browser.

You should see priorities.md at the same level as AGENTS.md and CLAUDE.md.

Add the priorities template by pasting this code into priorities.md:

<!-- Review weekly. Update Projects and Key People, and move completed or paused work to Archive. -->

# Priorities

## Projects

- Replace this line with a short-term deliverable and its target date.
- Replace this line with a second active deliverable and its target date.

## Areas

- Replace this line with an ongoing responsibility that has no end date.

## Resources

- Replace this line with a topic you are actively learning or referencing.

## Archive

- Move completed or paused Projects and Areas here.

## Key People

- Replace this line with a person's name, role, current focus, and related Project or Area.

How does this file steer Devin?

Projects hold short-term outcomes with target dates.
Areas hold responsibilities that continue without an end date.
Resources provide supporting knowledge for current work.
Archive keeps completed or paused work out of daily recommendations.
Key People gives each workflow the context needed for useful follow-ups.

Save priorities.md.
Switch to Obsidian's reading view to confirm all five section headings appear.

The file now separates active work from background context. That structure gives every later briefing the same decision frame.

Missing a section heading?

Confirm priorities.md sits at the top level of second-brain.
Check that each section starts with two hash characters followed by one space.
Compare the heading order with the reference file below.

Need another pair of eyes? Help me check the structure of my priorities file.

✔️ Awesome, I've got everything!

Your starting template is complete. Keep priorities.md open for the personalization pass below.

ⓧ I'd like to double check the full code

Compare your starting template with this complete reference before adding your own priorities.

<!-- Review weekly. Update Projects and Key People, and move completed or paused work to Archive. -->

# Priorities

## Projects

- Replace this line with a short-term deliverable and its target date.
- Replace this line with a second active deliverable and its target date.

## Areas

- Replace this line with an ongoing responsibility that has no end date.

## Resources

- Replace this line with a topic you are actively learning or referencing.

## Archive

- Move completed or paused Projects and Areas here.

## Key People

- Replace this line with a person's name, role, current focus, and related Project or Area.

How to compare this file

Check the heading order first. Then confirm each section contains its matching instructional bullet.

The template supplies the structure. Your own work now supplies the signal that makes the structure useful.

Replace the first Project placeholder with one active project that includes its deliverable plus target date.
Replace the second Project placeholder with another active project that includes its deliverable plus target date.

You should now see two concrete outcomes under Projects instead of instructional text.

Replace the Areas placeholder with one ongoing responsibility.
Replace the Resources placeholder with one topic you currently use for learning or reference.

Your continuing responsibility now sits apart from the reference material that supports it.

Move one completed or paused item into Archive.
Replace the Key People placeholder with one person whose role connects to a current Project or Area.

Your active work now has a clear boundary. Completed work remains available without competing for attention.

Save your personalized priorities.md.
Confirm no bullet beginning with Replace this line remains.
Open the existing AGENTS.md from the Obsidian file browser.
Confirm its rules prioritize Projects plus Areas.
Confirm its rules use Resources as supporting context.
Confirm its rules ignore Archive items unless you ask for them.

Your priorities now carry your decisions instead of generic prompts. Devin already has the matching rules it needs to respect them.

Add selective Notion capture

The existing MCP connection can read your inbox. A project-scoped Devin Skill turns that access into a repeatable capture workflow with a ten-page cap.

The Skill writes only to raw/notion/ plus wiki/log.md. It also checks each notion-url before writing so repeated runs skip duplicates.

Create a pull-sources folder inside the existing .devin/skills folder by using Obsidian's file browser.
Create SKILL.md inside .devin/skills/pull-sources by using the same file creation control.

You should see .devin/skills/pull-sources/SKILL.md alongside the four existing Skill folders.

Define the selective capture workflow by pasting this complete file into SKILL.md:

---
name: pull-sources
description: Capture selected Notion inbox pages into raw notes for triage
allowed-tools:
  - read
  - grep
  - glob
permissions:
  allow:
    - Write(raw/notion/**)
    - Write(wiki/log.md)
  deny:
    - exec
triggers:
  - user
---

Capture useful content from the configured `notion` MCP server into `raw/notion/`.

1. Find the Notion page titled `Second Brain Inbox`. If it is unavailable, explain the connection problem and stop without writing files.
2. Read, but never modify, its direct child pages. Process at most 10 pages in one run.
3. Before writing, scan existing files in `raw/notion/`. Treat a matching `notion-url` value as already captured and skip it.
4. Skip empty pages and pages whose only content is a title.
5. For each remaining page, write `raw/notion/YYYY-MM-DD-<kebab-case-title>.md` with this exact shape:

   `> notion: <page title>. <one-sentence summary>.`

   Then YAML frontmatter containing `source: notion`, `captured: YYYY-MM-DD`, `title`, and `notion-url`, followed by the useful page content in Markdown.
6. Append one timestamped entry to `wiki/log.md` with captured, skipped, and duplicate counts.
7. Remind the user to skim the triage headers, delete noise, and run `/ingest` on the survivors.

What does this Skill do?

The frontmatter limits the Skill to reading plus narrow vault writes.
The workflow reads direct child pages from Second Brain Inbox without changing Notion.
The notion-url field gives every captured page a stable deduplication key.
Each captured file starts with a triage header before its YAML metadata.
The ten-page limit keeps each review pass manageable.

Save .devin/skills/pull-sources/SKILL.md.
Return to the macOS Terminal session from earlier.
Validate the new Skill from the vault root by running:

devin doctor

What does this command check?

This diagnostic checks Devin's local configuration plus agent frontmatter. A clean result confirms the new Skill is structurally readable.

You should see the diagnostic finish without reporting malformed frontmatter for pull-sources.

Check that Devin discovered the new Skill by running:

devin skills list

What does this command confirm?

This lists the Skills available to the current project. The result proves Devin can discover the new folder plus its SKILL.md file.

You should see pull-sources alongside ingest, query, lint, and log.

Skill missing from the list?

Confirm the file path is exactly .devin/skills/pull-sources/SKILL.md.
Check that both frontmatter boundaries contain three hyphen characters.
Confirm the name field uses pull-sources.

Still missing? Help me debug why Devin cannot discover my pull-sources Skill.

✔️ Awesome, I've got everything!

The new Skill passes validation. Devin can now invoke it as /pull-sources.

ⓧ I'd like to double check the full code

Compare your complete Skill file with this reference.

---
name: pull-sources
description: Capture selected Notion inbox pages into raw notes for triage
allowed-tools:
  - read
  - grep
  - glob
permissions:
  allow:
    - Write(raw/notion/**)
    - Write(wiki/log.md)
  deny:
    - exec
triggers:
  - user
---

Capture useful content from the configured `notion` MCP server into `raw/notion/`.

1. Find the Notion page titled `Second Brain Inbox`. If it is unavailable, explain the connection problem and stop without writing files.
2. Read, but never modify, its direct child pages. Process at most 10 pages in one run.
3. Before writing, scan existing files in `raw/notion/`. Treat a matching `notion-url` value as already captured and skip it.
4. Skip empty pages and pages whose only content is a title.
5. For each remaining page, write `raw/notion/YYYY-MM-DD-<kebab-case-title>.md` with this exact shape:

   `> notion: <page title>. <one-sentence summary>.`

   Then YAML frontmatter containing `source: notion`, `captured: YYYY-MM-DD`, `title`, and `notion-url`, followed by the useful page content in Markdown.
6. Append one timestamped entry to `wiki/log.md` with captured, skipped, and duplicate counts.
7. Remind the user to skim the triage headers, delete noise, and run `/ingest` on the survivors.

How to compare this file

Check the frontmatter first. Then compare all seven numbered workflow rules in order.

Capture, triage, and ingest

The capture gate keeps source material separate from compiled knowledge. You decide which local copies survive before ingest can update the wiki.

Start Devin from the existing vault root by running:

devin

Why start Devin here?

The current folder becomes Devin's workspace. Starting at the vault root gives the Skill access to the project rules plus the folders named in its permissions.

The session opens with your existing project rules plus the new Skill available.

Before you run the capture, do you expect a repeated Notion page to create a second local file?

Review the Notion read request when Devin presents it.
Approve the read request for the authorized inbox content.
Review the write request for raw/notion/ when Devin presents it.
Approve the scoped vault write.
Capture the useful direct child pages by running:

/pull-sources

What happens during capture?

Devin finds the direct child pages beneath Second Brain Inbox.
It skips empty pages plus previously captured URLs.
It writes at most ten useful files beneath raw/notion/.
It appends captured, skipped, and duplicate counts to wiki/log.md.

You should see a capture summary without any change to the source pages in Notion. A repeated notion-url is skipped instead of creating a duplicate.

Capture stopped early?

Confirm the existing notion connection can still access Second Brain Inbox.
Check that the test pages are direct children of the inbox page.
Confirm you approved writes only within the paths requested by the Skill.

Need help with the failed run? Help me diagnose why pull-sources could not capture my Notion inbox pages.

Deleting a captured file only removes the local copy. The original child page remains in your authorized Notion workspace.

Switch back to the existing vault in Obsidian.
Expand raw/notion/ in the left file browser.
Open the first captured Markdown file.
Read its one-line > notion: triage header.
Delete one low-value captured file that should not influence future briefings.

The deleted item disappears from raw/notion/ while its Notion source remains available. This is your human review gate in action.

Open each retained captured file.
Confirm its filename follows the YYYY-MM-DD-<kebab-case-title>.md pattern.
Confirm its frontmatter contains source: notion.
Confirm its frontmatter contains a captured date.
Confirm its frontmatter contains a title.
Confirm its frontmatter contains a notion-url value.

Before you ingest the survivors, which existing wiki topic do you expect the retained sources to strengthen?

Return to the active Devin session.
Ingest no more than three retained sources by running:

/ingest 3

What does this ingestion run do?

The existing Skill searches wiki/ before creating a page. It updates relevant knowledge with source citations plus Wiki Links while preserving every retained file in raw/notion/.

You should see a report naming the processed sources plus the wiki pages it changed.

Switch back to Obsidian.
Open the wiki pages named in the ingestion report.
Confirm the new material cites its retained raw/notion/ source paths.
Confirm relevant Wiki Links appear in the updated knowledge.
Open wiki/log.md.
Confirm it contains a timestamped Notion capture entry.
Confirm it contains a timestamped ingestion entry.

That is the full loop working: live material entered through a narrow gate. Your review decided what became durable knowledge.

Wiki pages not updated?

Confirm at least one retained source remains inside raw/notion/.
Check the Devin response for a skipped count that explains why a source was not processed.
Confirm the retained source contains useful body content beneath its frontmatter.

Still no update? Help me trace a retained Notion source through ingest into my wiki.

Your vault now knows what matters plus what deserves capture. Next, you will turn those signals into a repeatable morning plan and evening review.

Run Your Daily Briefing Loop

Your retained Notion sources now feed useful context into your wiki. Your personalized priorities give that context a clear direction.

The missing /briefing workflow from Step 1 still blocks the daily routine. In this step, you will add two Devin Skills that turn your vault into a morning planning tool plus an evening feedback loop.

In this step, get ready to:

Add the briefing Skill plus the debrief Skill to your existing vault.
Run a morning briefing plus both debrief modes.
Synchronize the new daily history to your private GitHub repository.

Create the briefing and debrief Skills

The briefing Skill gathers priorities plus recent activity into one focused plan. Its permissions allow a single vault change because every completed brief is appended to wiki/log.md.

Switch back to the vault editor you used for your existing Skills.
Expand .devin/skills/ in the file sidebar.
Create a folder named briefing inside .devin/skills/.

You will see the new .devin/skills/briefing/ folder beside your existing project Skills.

Create SKILL.md inside .devin/skills/briefing/.
Fill .devin/skills/briefing/SKILL.md by copying this code:

---
name: briefing
description: Generate and log a prioritized morning brief
argument-hint: "[local-only]"
allowed-tools:
  - read
  - grep
  - glob
permissions:
  allow:
    - Write(wiki/log.md)
  deny:
    - exec
triggers:
  - user
---

Generate today's briefing.

1. Read `priorities.md`, the last three entries in `wiki/log.md`, and wiki pages linked to active Projects.
2. If `$ARGUMENTS` contains `local-only`, do not call MCP tools. Otherwise, if the `notion` MCP server is available, read up to five useful pages beneath `Second Brain Inbox` without modifying Notion.
3. Produce these sections in this order:
   - `Today's Schedule`: list dated commitments from priorities and available local context. State `No calendar connector configured` when no calendar data exists.
   - `Active Threads`: summarize unresolved work tied to Projects or Areas.
   - `Priority Reminders`: highlight deadlines, blockers, and people who need follow-up.
   - `Suggested Actions`: give three concrete next actions in priority order.
4. Keep the brief under 400 words and distinguish facts from suggestions.
5. Append the complete brief to `wiki/log.md` under a local timestamp heading and add the line `type: briefing` beneath the heading.
6. Print the same brief in the conversation and confirm that it was logged.

What does this Skill do?

The argument-hint advertises the optional local-only mode used for unattended runs.
The tool list permits local context searches without shell execution.
The numbered workflow fixes the briefing section order plus the maximum length.
The type: briefing line makes each morning entry easy to identify in wiki/log.md.

Save .devin/skills/briefing/SKILL.md.
Switch back to the terminal from earlier.
Validate the Skill configuration plus its discovery by running these commands:

devin doctor
devin skills list

What do these checks prove?

The first command checks the local Devin configuration plus Skill frontmatter. The second command shows which project Skills Devin can invoke.

You should see a successful configuration check. The Skill inventory should include briefing with its [local-only] argument hint.

Briefing Skill missing?

Check that the file path is exactly .devin/skills/briefing/SKILL.md.
Confirm the opening plus closing frontmatter markers each contain three hyphens.
Compare the indentation beneath allowed-tools plus permissions with the reference below.

Still stuck? Help me find why my briefing Skill is missing from the Devin Skill inventory.

✔️ Awesome, I've got everything!

Your briefing Skill is valid. Keep .devin/skills/briefing/SKILL.md saved in the vault.

ⓧ I'd like to double check the full code

---
name: briefing
description: Generate and log a prioritized morning brief
argument-hint: "[local-only]"
allowed-tools:
  - read
  - grep
  - glob
permissions:
  allow:
    - Write(wiki/log.md)
  deny:
    - exec
triggers:
  - user
---

Generate today's briefing.

1. Read `priorities.md`, the last three entries in `wiki/log.md`, and wiki pages linked to active Projects.
2. If `$ARGUMENTS` contains `local-only`, do not call MCP tools. Otherwise, if the `notion` MCP server is available, read up to five useful pages beneath `Second Brain Inbox` without modifying Notion.
3. Produce these sections in this order:
   - `Today's Schedule`: list dated commitments from priorities and available local context. State `No calendar connector configured` when no calendar data exists.
   - `Active Threads`: summarize unresolved work tied to Projects or Areas.
   - `Priority Reminders`: highlight deadlines, blockers, and people who need follow-up.
   - `Suggested Actions`: give three concrete next actions in priority order.
4. Keep the brief under 400 words and distinguish facts from suggestions.
5. Append the complete brief to `wiki/log.md` under a local timestamp heading and add the line `type: briefing` beneath the heading.
6. Print the same brief in the conversation and confirm that it was logged.

The debrief Skill closes the loop. It supports a guided reflection plus a quick-summary mode for days when the important signals are already clear.

Create a folder named debrief inside .devin/skills/.

You will see the new .devin/skills/debrief/ folder in the same Skill collection.

Create SKILL.md inside .devin/skills/debrief/.
Add the debrief frontmatter by copying this first block:

---
name: debrief
description: Capture the day's signal and update the vault log
argument-hint: "[quick summary]"
allowed-tools:
  - read
  - grep
  - glob
permissions:
  allow:
    - Write(wiki/log.md)
    - Write(wiki/**)
    - Write(priorities.md)
  deny:
    - exec
triggers:
  - user
---

How is the debrief scoped?

The [quick summary] hint shows that the command accepts an optional summary.
The write permissions cover the log plus durable wiki updates plus approved priority changes.
The denied execution permission keeps this reflection workflow away from shell commands.

Complete .devin/skills/debrief/SKILL.md by adding this workflow below the frontmatter:

Capture an evening debrief.

1. Read `priorities.md` before processing the day.
2. If `$ARGUMENTS` is empty, ask these questions one at a time and wait after each answer:
   - What did you accomplish?
   - What conversations mattered?
   - Did any priorities shift?
   - What idea or unresolved issue should carry forward?
3. If `$ARGUMENTS` is present, use it as the quick summary and skip the questions.
4. Append an entry to `wiki/log.md` with a local timestamp heading, the line `type: debrief`, and three to five bullets containing only what shifted, what blocked progress, and what should carry forward. Do not paste a transcript.
5. Update an existing wiki page only when the debrief clearly adds durable knowledge. Ask before creating a new wiki page.
6. If priorities changed, propose the exact edit to `priorities.md` and ask before applying it.
7. End with one sentence that summarizes the day.

What does this workflow protect?

Interactive mode asks four focused questions one at a time.
Quick mode converts one supplied summary into the same structured log format.
Each entry keeps only three to five carry-forward signals.
Priority changes require your approval before Devin edits priorities.md.

Save .devin/skills/debrief/SKILL.md.
Switch back to the terminal from earlier.
Validate both daily-loop Skills plus their argument hints by running these commands:

devin doctor
devin skills list

What should the inventory confirm?

The configuration check confirms both files have valid frontmatter. The inventory should show briefing with [local-only] plus debrief with [quick summary].

Both daily commands are now discoverable. That completes the Devin-native structure for your manual morning plus evening routine.

Debrief Skill missing?

Check that the file is saved at .devin/skills/debrief/SKILL.md.
Confirm the workflow starts below the closing frontmatter marker.
Check that each permission entry remains indented beneath allow.

Need another pair of eyes? Help me diagnose why my debrief Skill fails Devin validation.

✔️ Awesome, I've got everything!

Both daily-loop Skills are valid. Make sure the two SKILL.md files remain saved.

ⓧ I'd like to double check the full code

---
name: debrief
description: Capture the day's signal and update the vault log
argument-hint: "[quick summary]"
allowed-tools:
  - read
  - grep
  - glob
permissions:
  allow:
    - Write(wiki/log.md)
    - Write(wiki/**)
    - Write(priorities.md)
  deny:
    - exec
triggers:
  - user
---

Capture an evening debrief.

1. Read `priorities.md` before processing the day.
2. If `$ARGUMENTS` is empty, ask these questions one at a time and wait after each answer:
   - What did you accomplish?
   - What conversations mattered?
   - Did any priorities shift?
   - What idea or unresolved issue should carry forward?
3. If `$ARGUMENTS` is present, use it as the quick summary and skip the questions.
4. Append an entry to `wiki/log.md` with a local timestamp heading, the line `type: debrief`, and three to five bullets containing only what shifted, what blocked progress, and what should carry forward. Do not paste a transcript.
5. Update an existing wiki page only when the debrief clearly adds durable knowledge. Ask before creating a new wiki page.
6. If priorities changed, propose the exact edit to `priorities.md` and ask before applying it.
7. End with one sentence that summarizes the day.

Run both sides of the daily loop

The two Skills now share the same steering document. The briefing turns current context into a plan while the debrief records only the signals worth carrying forward.

Start Devin from the existing second-brain vault by running these commands:

cd ~/Documents/second-brain
devin

Why start from the vault?

The first command makes the vault root your active directory. The second command starts Devin with access to the project rules plus project-scoped Skills.

You will see the Devin session ready inside ~/Documents/second-brain.

Devin session not starting?

Confirm the terminal path ends with Documents/second-brain.
Check that your Devin authentication from Step 1 remains active.
Wait for your Free plan quota to reset if the account has temporarily exhausted its agent allowance.

Still blocked? Help me diagnose why Devin will not start in my second-brain vault.

Before you run the morning command, which priorities plus recent wiki signals do you expect Devin to surface?

Generate your morning plan by entering this command in the Devin session:

/briefing

You should see Today's Schedule followed by Active Threads. You should also see Priority Reminders followed by Suggested Actions.

How does the briefing choose context?

The Skill starts with priorities.md plus the last three entries in wiki/log.md. It also reads wiki pages linked to active Projects.

An available Notion MCP connection can contribute up to five useful inbox pages. Supplying local-only disables that external read for unattended automation.

The completed brief is appended to wiki/log.md beneath type: briefing. Your morning plan now exists in both the conversation plus the vault history.

Briefing command not working?

Exit the Devin session if the command is unknown.
Rerun the Skill inventory check from the previous substep.
Confirm .devin/skills/briefing/SKILL.md remains saved before starting a fresh session.

Need help with the output? Help me troubleshoot why my briefing Skill is unavailable or missing one of its four sections.

The morning half is working. Your vault can now turn priorities plus recent activity into a focused plan.

Start the guided evening reflection by entering:

/debrief

Devin asks what you accomplished first. It waits for your answer before moving to the next question.

Answer the first question with what you accomplished today.
Answer the second question with the conversations that mattered.
Answer the third question with any priority shift.
Answer the fourth question with the idea or unresolved issue that should carry forward.

You should see a concise closing sentence after the fourth answer. A new type: debrief entry containing three to five signal bullets is now stored in wiki/log.md.

Quick mode covers days when the signal already fits in one short summary. It skips the four-question exchange while preserving the same structured log shape.

Test quick-summary mode by entering:

/debrief Shipped the migration; Notion capture worked; refine tomorrow's priorities

You should see another concise summary. A second type: debrief entry is now appended with three to five carry-forward signals.

Who controls priority changes?

The quick summary identifies a possible change to tomorrow's priorities. Devin must propose the exact edit to priorities.md before applying it.

Approve a proposed change only when it reflects your intended plan. This keeps the steering document human-owned.

Debrief looks like a transcript?

Confirm rule four limits the entry to three to five bullets.
Check that rule four explicitly excludes the raw transcript.
Rerun the debrief after saving the corrected Skill file.

Need help tightening the result? Help me diagnose why my debrief entry contains a transcript or misses the carry-forward signals.

Sync and verify the daily history

The daily loop becomes durable once its log entries leave your Mac. Your existing Obsidian Git setup can commit plus synchronize these changes without exposing the private vault publicly.

Return to Obsidian from earlier.
Press Command-P to open the command palette.
Enter Git: Commit-and-sync in the command palette.
Select Git: Commit-and-sync from the results.

Obsidian Git commits the new Skill files plus the updated log. It then synchronizes that commit with your private remote.

Before you inspect the remote file, how many new daily-loop entry types do you expect to find?

Return to the private second-brain repository on GitHub.
Select the wiki folder in the repository file list.
Select log.md.

You should find one recent type: briefing entry. You should also find two recent type: debrief entries.

Open the remote file history for wiki/log.md.

You should see the latest synchronized revision containing the briefing plus both debrief entries. This proves the daily loop survives outside the terminal.

That completes your manual daily operating loop. Your morning plan plus evening signals now remain searchable in the vault and protected in the private repository.

Secret mission

Schedule a Local Weekday Briefing

Your morning brief currently waits for you to start it. This mission adds a local weekday schedule that runs the briefing automatically at 08:00 while your Mac is logged in.

Clean Up Your Resources

Your setup uses free plans plus local tools, so it has no ongoing project charges. Choose a cleanup option based on whether you want the daily loop available now.

Resources you used:

Your existing Devin rules in AGENTS.md plus all seven project Skills inside .devin/skills/.
Your personalized priorities.md plus retained captures in raw/notion/.
Your updated knowledge pages plus daily entries in wiki/.
Your local Git history plus the private second-brain repository on GitHub.
The Git community plugin in Obsidian with automatic synchronization enabled.
The authorized read-only Notion MCP connection plus the Second Brain Inbox page.
The loaded launchd agent named ai.nextwork.devin-morning-briefing plus its automation files.
The unattended-run log at ~/Library/Logs/devin-second-brain.log.

Keep everything running

No action needed. Choose this if you want your attended workflows plus weekday briefing automation to remain available.

The LaunchAgent continues running /briefing local-only at 08:00 from Monday through Friday while your Mac is logged in.
The Notion connection remains available for attended Devin sessions.
Obsidian continues synchronizing vault changes with the private GitHub repository.
Your existing Part 1 notes plus every project addition remain in ~/Documents/second-brain.

Pause - I'll come back to this later

Pause the external connection plus automatic jobs while preserving every local file. This frees the workflow from background activity without removing your notes.

Disable the attended Notion connection by running this command:

devin mcp disable notion

What This Pauses

The connection remains configured. Devin cannot use it while disabled.

The Second Brain Inbox stays unchanged in Notion.

Confirm the command completes without reporting a failure.
Unload the weekday LaunchAgent by running this command:

launchctl unload ~/Library/LaunchAgents/ai.nextwork.devin-morning-briefing.plist

What Unloading Changes

The LaunchAgent stops scheduling weekday briefings for your logged-in account. Its property list plus runner script remain available for later use.

Confirm the command completes without reporting a failure.
Disable the Git community plugin from Obsidian's community plugin settings.

Your vault plus local Git history remain intact. The private GitHub repository also remains available.

Delete - I don't want to use this again

Remove the active integrations plus remote copies while preserving your local notes by default. Your original Part 1 vault stays untouched until the final optional deletion action.

Protect Your Existing Notes

Your Part 1 vault plus this project's additions share ~/Documents/second-brain. Deleting that folder also erases the original notes.

Preserve a separate copy before choosing the final local deletion action.

Remove the configured Notion connection from Devin by running this command:

devin mcp remove notion

What This Removes

The command removes the configured local connection. It leaves the Second Brain Inbox plus its child pages in Notion.

Confirm the command completes without reporting a failure.
Skip the next command if you already unloaded the LaunchAgent in the Pause tab.
Unload the weekday LaunchAgent by running this command:

launchctl unload ~/Library/LaunchAgents/ai.nextwork.devin-morning-briefing.plist

Why Unload Before Deleting

Unloading removes the active schedule for your logged-in account. You can then delete its installed property list without leaving the job loaded.

Confirm the command completes without reporting a failure.
In Finder, navigate to ~/Library/LaunchAgents.
Move ai.nextwork.devin-morning-briefing.plist to Trash.

The user scheduler now has no installed property list for the weekday briefing.

In Finder, navigate to ~/Documents/second-brain/.devin.
Move the automation folder to Trash.
In Finder, navigate to ~/Library/Logs.
Move devin-second-brain.log to Trash.

The scheduled runner plus its local output are now removed.

Open the community plugin settings in Obsidian.
Uninstall the Git community plugin.
Open the private second-brain repository on GitHub.
Open the repository settings.
Use the repository deletion control to remove second-brain.

Your remote backup is now removed. The local Git history remains inside the vault.

Open the Second Brain Inbox page in Notion.
Use the page menu to move the inbox to Trash if you no longer need its test content.

The remaining vault files cost nothing to keep. They preserve your Part 1 notes plus the Devin workflows you created.

In Finder, navigate to ~/Documents only if you intend to erase the complete second brain.
Move second-brain to Trash to remove the vault plus its local Git history.

Nice Work!

You did it! You transformed your completed Part 1 Obsidian vault into a Devin-powered daily operating system with versioned history in GitHub.

What you learned:

Built a native rules bridge plus seven reusable Devin Skills that preserve your personalized Part 1 vault structure.
Created a selective capture flow that pulls authorized Notion pages through MCP for human triage before wiki ingestion.
Ran a daily briefing and debrief loop that writes structured entries to wiki/log.md before Obsidian Git synchronizes them to your private GitHub repository.
Completed the optional Secret Mission by scheduling a local-only weekday briefing with macOS launchd.

Ready to quiz yourself?