escoffier-labs/brigade/note

/note - Create Obsidian-Formatted Notes

Create an Obsidian-formatted markdown note and place it in ~/notes/. Tell the user the exact file path and confirm the sync.

If the user provided a topic argument after /note, use it as the topic. Otherwise, review the conversation to identify the topic.

When to use

Two distinct modes. Pick the right one before you start writing.

Common triggers:

• Troubleshooting sessions - issues, errors, and the fix that worked
• System concepts - how things work on Linux, networking, services, frameworks
• Coding knowledge - languages, libraries, patterns, gotchas
• Development workflows - tools, commands, configurations
• Architecture decisions - what was chosen and why

Process

1. Decide which mode applies. If unclear, ask: "Should I write this verbatim (reproducible) or summarize the concept?"
2. Review the conversation to identify the topic and pull the relevant commands, errors, paths.
3. Write the .md file to ~/notes/<topic-slug>.md.
4. Sync to the configured Obsidian inbox (see "Sync target" below).
5. Tell the user the exact file path and confirm the sync.

Note format

YAML frontmatter

Every note MUST start with YAML frontmatter:

---
tags:
  - tag1
  - tag2
created: YYYY-MMM-DD
---

• 3-5 relevant tags. Lowercase, hyphenated for multi-word.
• Date format YYYY-MMM-DD (e.g. 2026-Jan-24).
• Add mode: verbatim or mode: concept if you want the mode visible in frontmatter.

Structure: verbatim fix

## The problem
 
> [!bug] Title
> Brief symptom. Paste the actual error string verbatim.
 
Context. What was the system doing. What changed recently.
 
## The fix
 
> [!success] Title
> The exact command(s) that worked.
 

verbatim commands

 
## How it works
 
Explain *why* the fix works. Link to docs if relevant. Note any preconditions.
 
## Gotchas
 
> [!warning] Title
> Anything that almost bit you. Stale state, ordering dependencies, version constraints.

Structure: summarize / concept

## Overview
 
What this is and why it matters. One paragraph.
 
## How it works
 
Core concepts and mechanics. Diagrams or bullet lists are fine; prose is better when the order matters.
 
## Example
 

practical example, runnable

 
## Tips and gotchas
 
> [!tip] Title
> Useful patterns.
 
> [!warning] Title
> Things that can break or surprise you.

Callout types

Use sparingly. The note should be mostly prose; callouts highlight the critical bits.

Callout syntax

> [!tip] Optional title
> Callout content goes here.
> Can span multiple lines.

Sync target

The note skill writes to ~/notes/ and syncs to the user's Obsidian vault inbox. The exact sync command depends on how the user's Obsidian vault is wired.

Common shapes (pick what matches the user's setup, document it in TOOLS.md):

# Google Drive via rclone (most common):
rclone copy ~/notes/<topic-slug>.md "gdrive:My Drive/<VaultPath>/<Inbox-folder>/"
 
# Local Obsidian vault on disk:
cp ~/notes/<topic-slug>.md ~/Obsidian/<Vault>/<Inbox-folder>/
 
# Bisync timer (already running): just write to ~/notes/ and the next sync fires

If the user has not configured a sync target, leave the file in ~/notes/ and tell them where it landed.

Quality rules

• Prose is the backbone. Headings, paragraphs, lists, code blocks.
• Callouts highlight the critical bits (key fix, warning, gotcha). They are not paragraph wrappers.
• A good note is mostly regular text with callouts around the parts that matter.
• Include specific commands, paths, config values, error messages. Vague notes are useless three weeks later.
• Code blocks use language tags for syntax highlighting.
• Reference-friendly, not narrative.
• Write for future-you who has zero context about this session.
• No em dashes. No AI-attribution trailers. Match the user's voice rules from SOUL.md.

Output

Tell the user:

Wrote note: ~/notes/<topic-slug>.md
Synced to: <sync target>

If sync failed, surface the error and leave the file in ~/notes/.