My Obsidian + Claude Cowork Routine
How I turned ClaudeAn AI assistant made by Anthropic. Claude Desktop is the app; Cowork mode lets it read/write files on your computer and connect to tools like Gmail and Slack. into my work operating system, across email, meetings, docs, and chat.
By Tao Tao · Last updated June 2, 2026 · Send Feedback
Who is this for
You don't need to code, but you need to be comfortable tinkering with files and prompts. This is built for people managing 10+ parallel topics across fragmented tools — too many meetings to connect, too much email to process, multiple workstreams across different people and teams, and others who depend on you to synthesize it all. If that sounds familiar, this will help.
What It Does
The system runs on skillsA markdown file with instructions Claude follows when you say certain trigger phrases. Write it once, Claude executes it every time.: some I trigger in conversation, some run on a scheduleSomething Claude does automatically on a schedule (e.g. "every weekday at 6pm, scan my email"). You set the schedule and instructions, Claude runs it in the background. in the background. Every skill is just a markdown fileA plain text file with simple formatting (like **bold** and # headings). Human-readable in any text editor. All skills in this system are markdown files.. No coding required. I add new ones weekly. I've been iterating on this for about three months. What you see below is a snapshot, not a fixed system.
Thinking
Skills for research, synthesis, and strategic work. A skill is a markdown file that describes what Claude should do when triggered. Any repeated workflow can become a skill. Here are some of mine — yours will look completely different. Click any card to see how it works.
The skill I use most. I say things like "what's the latest on [topic]?" or "what did [person] say about [project]?" and Claude searches across: vaultWhat Obsidian calls a folder of notes. Just a regular folder on your computer containing markdown files. You can browse it in Finder or Explorer. topic notesA markdown file in your vault tracking one strategic topic (e.g. "Growth Strategy"). Claude keeps it updated with your latest thinking, decisions, and open questions., meeting transcripts, Gmail, Slack, and Google Docs. It cites every claim back to its source. The skill has a source authority hierarchy: published docs rank highest, then anything I sent (emails or Slack messages, treated equally as my real-time positions), then meeting notes, then inbound messages from others (emails or Slack DMs from key people, treated equally as inputs). Confluence ranks lowest. Yours might be different. You control the hierarchy. For meeting prep, it runs a multi-step process: pull the relevant topic note, check recent emails from attendees, scan Granola for prior meetings with the same people, and surface open questions I haven't addressed yet.
People & Meetings
Skills for the human side of the job: prepping for meetings, debriefing 1:1s and interviews, and generating on-brand decks.
Weekly Review Pipeline
Five skills that run in sequence at the end of each week, each building on the one before. The system first reviews itself, then reconciles every open commitment, runs a short development check-in, challenges my thinking for blind spots, and finally generates the briefing I share with my team.
Meta & System
The self-improving layer. A nightly task that keeps the system fed with fresh data, and a skill that tests the system's own quality and proposes fixes. More meta skills (audit, documentation, memory) are in the Skill READMEs appendix below.
What Does a Typical Week Look Like?
This changes often, but the pattern stays the same: automated tasks keep the system current, on-demand skills give you leverage in the moment. Here's the gist.
Automated (evening): Claude scans all my emails, meetings, and Slack from the day. Writes a dated log entry to my vault. Sends me a digest email with action items and signals I might have missed. Without this, everything else gets stale.
On-demand (throughout): "Catch me up on [topic]." Meeting prep before calls. Stakeholder update critiques. Co-writing sessions. 1:1 debriefs after meetings. Ad-hoc queries. This is where most of the value lives.
Automated: Claude reads every Google Doc linked to my topics, checks what changed since last week, and updates my topic notes. I get an email summary of what moved.
A five-step pipeline I run in sequence.
System review: File and skill health, stale project detection, system self-improvement.
Commitments: Reconcile every open loop, triage what's overdue, draft the nudges.
Development + self-challenge: A short coaching check-in, then the devil's-advocate pass that hunts for contradictions, blind spots, and positions I've stated but not acted on.
Top of Mind: A prioritized briefing for my team and leadership. Takes 2 minutes, used to take 30.
How to Get Started
Initial setup takes about an hour: install the app, point it at a folder, hand Claude a file with setup instructions. Getting the system to actually work well — connecting tools, writing your first topic notes, tuning skills — takes a few weeks of iteration. That's normal.
- Install Claude Desktop and enable Cowork modeA feature in Claude Desktop that gives Claude access to a folder on your machine, so it can read/write files, run scheduled tasks, and interact with your notes.. Open Claude Desktop → click the menu icon (top left) → Settings → scroll to Cowork mode and turn it on. If you're on a company laptop, you may need IT to approve the install or set up a Claude for Work plan first — ask your IT team.
- Create your vaultJust a regular folder on your computer containing plain text files. You can browse it in Finder or Explorer like any other folder. folder. Create a folder somewhere easy to find — e.g.
~/Documents/SecondBrainon Mac orDocuments\SecondBrainon Windows. This is just a regular folder where all your notes, skills, and scheduled tasks will live as plain text files. Every time you start a Cowork session, Claude asks you to select a folder — always pick this one. Optionally, install ObsidianA free app for browsing and editing your notes. Since everything is just plain text files on your computer, Obsidian is optional — you could swap it for any text editor and nothing would break. (free, obsidian.md) and open this folder as a vault — it gives you a nice interface to read and edit your files directly, plus search, backlinks, and a graph view. The system works without Obsidian (Claude reads the files regardless), but Obsidian makes it much easier to see what's in your vault and tweak things by hand. - Give Claude the starter kit. Click the button below to download a small text file. This file tells Claude how to build a second brain for you — it's a set of instructions Claude follows, not something you need to read yourself. Open a Cowork session, select your vault folder, drag the file into the chat, and say something like "read this and walk me through setting up my system." Claude will ask about your role, your topics, and your tools, then create everything — folder structure, skills, scheduled tasks — as plain text files you can edit or delete anytime. Takes about 30 minutes. This file reflects my system and design principles. It's the fastest way to get started, but nothing it creates is permanent.
- Connect your tools. In Claude Desktop, go to Settings → ConnectorsBuilt-in integrations in Claude Desktop that let Claude access Gmail, Google Calendar, Google Drive, Slack, etc. Set up once in Settings — no coding required.. Add Gmail, Slack, and Google Calendar first (just sign in with your accounts). These give Claude the most context. Your meeting note tool is next if you use one (e.g., Granola, Otter). Each connector is a one-click sign-in, no coding required.
- Test it. Ask Claude "what's the latest on [your first topic]?" or "prep me for my next meeting." If it returns useful answers with citations, you're up and running. The system gets better every week as you add skills for workflows you repeat and delete what you don't use.
Things to try once you're set up
- ✓Ask a cross-topic question. "What are the connections between [topic A] and [topic B]?" Tests whether the system can synthesize across your vault.
- ✓Create your own skill. Pick a repeated workflow (weekly update, vendor email, interview debrief) and ask Claude to help you write it. Just say "help me create a skill for [your workflow]" and Claude will create the markdown file and put it in the right place in your vault.
- ✓Set up a scheduled task. Tell Claude "create a scheduled task that [does X] every [frequency]" and it will set one up for you. Good first candidates: a daily email digest, a weekly review, or a docs scan.
- ✓Try co-writing mode. Feed Claude a messy collection of notes, emails, and meeting snippets. Ask it to synthesize a position. See what blind spots it surfaces.
- ✓Prep for a real meeting. Before your next 1:1 or review, ask Claude to pull all context on the topic and the person. Compare it to what you'd have prepared manually.
Under the Hood: Architecture & Principles
You don't need this section to get started. This is for people who want to know why the system is designed the way it is.
Two architectural choices define this system. Everything else follows from them.
Choice 1: Files on disk as the state layer
Claude is stateless. Every session starts with no memory of what came before — no knowledge of last week's decisions, ongoing projects, or who said what in which meeting. This isn't a flaw; it's how AI sessions work. A stateless compute layer means each session is fresh: no compounding errors from previous sessions, no drift, no hallucinated "memories" bleeding in. The tradeoff is that continuity has to live somewhere else.
That somewhere else is the vault. A folder of plain text files on your machine that persists between sessions. Each session reads state from it, does work, writes back. Claude is the compute; the vault is the memory. Keeping them separate means either can change independently — swap AI models, swap note apps, neither side breaks the other.
The choice is where that state lives. Plain markdownA simple way to format text using plain characters. **bold**, # headings. Human-readable in any text editor. files on disk is the simplest possible answer: no database, no cloud service, no proprietary format. ObsidianA free app for browsing and editing notes. Adds backlinks, search, and graph view on top of plain text files. Optional — any text editor works. is just the best interface for browsing and editing those files — but the files work without it. The AI reads them directly.
Why this matters: no proprietary format, no cloud dependency, no vendor lock-in. If you switch AI tools tomorrow, your entire system comes with you. Nothing to export, nothing to migrate. Same if you switch note apps: move the folder, done.
Obsidian adds a lot on top of plain files: backlinks between notes, graph view to see how topics connect, fast full-text search, and a plugin ecosystem. But none of that is required. You could browse and edit the vault in VS Code or Finder and everything would still work. The AI reads the files directly.
The alternative would be building this inside a cloud tool (Notion, Google Docs, a purpose-built AI app). The problem: you're one pricing change, one API deprecation, or one acquisition away from losing access to your own thinking. With markdown on your laptop, that can't happen.
But one question remains: what goes in the vault? Not everything — that's Choice 2.
Choice 2: Search, don't sync
The second decision was not putting everything in the vault. The intuitive approach would be to sync emails, meeting notes, and docs into Obsidian and search locally. I tried that. It doesn't work. You end up with a stale, bloated copy of data that already lives somewhere better.
Instead, the system is search-based: the vaultJust a regular folder on your computer containing plain text files. You can browse it in Finder or Explorer like any other folder. holds only synthesis (topic notesA markdown file tracking one strategic topic (e.g. "Growth Strategy") — your current position, decisions, and open questions., positions, key decisions — not everything I think, just the things worth preserving). Everything else (emails, docs, meeting transcripts) stays in its source system and gets queried live at the moment Claude needs it. This matters for three reasons:
Freshness. When Claude reads my Gmail, it gets today's emails. A synced vault would be hours or days behind.
No duplication drift. If an email thread gets more replies, the source system has the full thread. A synced copy would need re-syncing, conflict resolution, dedup.
Privacy. My vault is plain markdown on my work laptop — no cloud sync, no third-party database. When Claude queries Gmail or Slack, it processes that data through its connectorsBuilt-in integrations in Claude Desktop that let Claude access Gmail, Calendar, Drive, Slack, etc. One-click sign-in, no coding. to answer your question, but nothing gets permanently copied or stored elsewhere. The key distinction: your data is accessed on demand, not synced into another system.
The knowledge graph
Think of it as a graph, not layers. The vault is the only node Claude can read and write. Sometimes it's a table of contents — pointers to where the real information lives in Gmail, Docs, or meeting notes. Sometimes it's the source of truth itself — your stated position on a topic, a decision you've made, an open question you're tracking. Either way, Claude queries your external tools live every time, so the vault never needs to be a copy of your data. This is where the design principles below come in: rules like "recency over age" and "your voice over others' voices" tell Claude how to weigh what's in the vault against what it finds live.
My design principles (yours should be different)
These are the rules I programmed into my system. They reflect how I think about information and decision-making. The point isn't to copy mine; it's to be intentional about what rules your AI follows.
How this works in practice: Each principle is written as a plain-English instruction inside my skill files. For example, "Recency over age" appears in my query skill as: "If two sources conflict, the newer one is more likely correct. Flag the conflict." Claude reads these instructions every time it runs a skill and follows them. The "About Me" file in my vault also contains behavioral rules, things like "don't be sycophantic" and "challenge my assumptions." You're literally writing a job description for your AI in markdown.
- 1 Query across sources, don't centralize. Data stays where it lives. The vault holds synthesis only. This keeps it small, fast, and never stale.
- 2 Recency over age. Newer content always supersedes older. Claude flags stale information rather than serving it confidently.
- 3 Your voice over others' voices. My sent emails and docs are source of truth for my positions. Others' input is context, not authority.
- 4 Evolve, don't accumulate. Topic notes get rewritten to reflect current state. The daily log preserves the timeline. Two different jobs, two different strategies.
- 5 Self-improvement is the #1 objective. The system makes my thinking sharper, faster, and more connected. That's why it evaluates and improves itself every week.
- 6 Verify before acting. Claude can hallucinate citations, misattribute quotes, and confidently serve stale context. Anything high-stakes gets checked manually. The system is good enough to dramatically reduce context-switching, not good enough to trust blindly.
Easter egg: my weekly review also includes an AGI check. Claude scans the week's AI news and assesses whether anything meaningfully changes what I should be building into this system. It's basically a trigger for me to add new skills or rethink existing ones based on what just became possible.
Operational Lessons
These are patterns I've landed on after a few weeks of iteration, not universal truths. My routine changes every week based on what works and what doesn't. The single most important habit is to keep iterating: try something, see if it helps, adjust or kill it. That matters more than any specific technique below.
Sharing these in case they save you some trial-and-error, but your system should reflect how you think, not how I think.
After about a month, I realized I hadn't written a single email or document from scratch. Every piece of writing now starts as a skill-generated first draft: meeting prep, stakeholder emails, weekly briefings, strategy docs. The blank page is gone. But the deeper insight isn't about saving time. It's about what the system selects for. When the mechanical work (structuring, drafting, pulling context, formatting) is handled, what's left is the part that actually matters: having good ideas, exercising judgment on the output, and staying curious enough to keep pushing the system into new territory. That's the job now. Ideas, judgment, curiosity. Everything else is infrastructure.
Don't cram everything into one giant markdown file. Each skill, each task, each topic note should be its own file with a single job. Claude has a context window (the amount of text it can process at once), so the more focused each file is, the better it can follow the instructions. A 50-line skill that does one thing well beats a 500-line file that does five things poorly. My vault (the folder of markdown files that makes up the entire system: topic notes, skills, tasks, config) has ~30 separate files, each under 200 lines.
As your system grows, Claude needs a map. I maintain a MANIFEST file that lists every topic (with status and file path), every skill, every task, and their relationships. Think of it as a boot-up file: every skill and task starts by reading the manifest first, so Claude always knows what exists and where to find it. This prevents it from missing context or working with stale information.
When Claude makes a recurring mistake, don't just correct it in conversation. Add it to a standing corrections list that gets read on every run. Mine includes things like "don't treat email pre-reads as metadata, follow the linked docs" and "speaker attribution from in-person meetings is unreliable." After a few weeks you'll have a list of 5-10 corrections that dramatically improve quality.
My overnight improvement task runs autonomously but never modifies live files. It reads eval results, diagnoses failures, and generates fix proposals with exact diffs, but saves them to a report file for me to review Sunday morning. This is important: you want your system to get smarter, but you also want to stay in the loop. Autonomous read + proposed write is the sweet spot.
I keep a change log (every modification, dated) and a growth log (weekly meta-summary of what improved). This sounds like overhead, but it's what turns your system from a static tool into a living one. After a month, you can see what's working, what plateaued, and what to invest in next. My system averaged 18 changes/day in week one, settling to about 5/day at steady state.
Not every topic in your vault needs the same depth. I split mine into topics I own (drive strategy, make decisions) and topics I monitor (watch, unblock, stay informed). This changes how Claude handles them: owned topics get deep synthesis and devil's advocate challenges; monitored topics get lighter-touch tracking. It keeps the system focused on where your attention actually matters.
Not all information is equal. I have an explicit hierarchy: published Google Docs > my sent emails > meeting transcripts > others' emails > Slack. Within each tier, recency wins. This prevents Claude from confidently quoting a stale Slack message when a more authoritative Google Doc exists. Write this hierarchy into your skills so Claude follows it every time.
The system gets significantly more powerful with each tool you connect. I connected Things (my task manager) so Claude can read my priorities and incorporate them into the weekly briefing. Slack, Jira, Confluence, Notion: anything with a connector or MCP integration becomes another data layer Claude can query live. Start with the tools where you spend the most time, then expand. Each new integration makes every existing skill smarter because Claude has more context to work with.
FAQ
Do you write in Obsidian or Google Docs?
Isn't searching Gmail every time slow?
Does this work with ChatGPT / Gemini / other models?
Why do I even need the vault? Can't I just use skills and connectors to search my tools directly?
Three things that only work because the vault exists:
Continuity across sessions. Claude has no memory between sessions. Without the vault, every session starts cold — "who are the key people on this topic?" "what did we decide in January?" The vault is the persistent memory layer.
Your own thinking. Half-formed positions, evolving frameworks, things you've concluded but haven't published anywhere — none of that is in Gmail or Slack. If you don't write it down, it doesn't exist for Claude.
Speed on complex questions. Searching 4 tools live every time you ask "where does Category Expansion stand?" is slow and noisy. A topic note gives Claude a synthesized starting point in one read; it only falls back to live search for what's happened since the last update.
The vault isn't a data store — it's where meaning accumulates. Skills and connectors are the pipes. You need both.
Why are the weekly reviews manual skills instead of scheduled tasks?
The design principle: automate data collection, keep synthesis interactive. If the system can do it without my input, schedule it. If it needs my judgment, make it a skill I trigger when I'm ready to engage.
Glossary
Some of the terms on this page may not be familiar if you haven't spent time in this world. Here's a plain-English cheat sheet.
- Claude
- An AI assistant made by Anthropic. Think ChatGPT but from a different company. Claude Desktop is the app you install on your computer; Cowork mode is a feature within it that lets Claude read and write files on your machine and connect to tools like Gmail, Slack, and Google Drive. That's what makes this whole system possible — Claude can access your actual work data, not just what you paste into a chat window. Download at claude.ai/download.
- Obsidian
- A free app for browsing and editing notes on your computer. Think of it as a nice interface on top of a folder of plain text files — it adds backlinks, search, and a graph view. Since everything underneath is just text files on your machine, Obsidian is entirely optional. Alternatives that work the same way: Logseq, VS Code, Nota, or any text editor. Download Obsidian at obsidian.md.
- Markdown (.md files)
- A simple way to format text using plain characters. For example,
**bold**makes text bold, and# Headingcreates a heading. Markdown files (.md) are just text files. You can open them in any text editor, Obsidian, or even Notepad. They're human-readable even without special software, and all the skills and tasks in this system are markdown files. - Vault
- What Obsidian calls a folder of notes. It's just a regular folder on your computer containing markdown files. Nothing magical. You could browse it in Finder or Windows Explorer. The "Second Brain" vault in this guide is a vault with a specific folder structure and naming conventions.
- Claude Desktop / Cowork mode
- Claude Desktop is Anthropic's app for using Claude on your computer (as opposed to the web browser). Cowork mode is a feature within it that gives Claude access to a folder on your machine, so it can read and write files, run scheduled tasks, and interact with your notes. Think of it as giving Claude a workspace on your laptop.
- Connectors
- Built-in integrations in Claude Desktop that let Claude access external tools like Gmail, Google Calendar, or Google Drive. You set them up once in Settings (just sign in with your account) and then Claude can search your email, read your calendar, etc. No coding or technical setup required.
- Granola
- A meeting note tool that records transcripts and lets you search past meetings. It sits in the background during calls and captures what was said. Used in this system as a data source for meeting prep, 1:1 debriefs, and the daily log. Alternatives include Otter and Fireflies. Learn more at granola.ai.
- Skill
- A markdown file with instructions that Claude follows when you say certain things. For example, when I say "prep me for my meeting," Claude reads the meeting prep skill file and follows its step-by-step instructions. Think of it as a reusable recipe: you write it once, and Claude executes it every time you trigger it.
- Scheduled task
- Something Claude does automatically on a schedule, like "every weekday at 6pm, scan my email and write a daily summary." You set the schedule and the instructions, and Claude runs it in the background without you needing to ask. Similar to a recurring calendar event, but for Claude.
- Topic note
- A markdown file in your vault that tracks one strategic topic you're working on (e.g., "Growth Strategy" or "AI & Automation"). Claude keeps it updated with your latest thinking, decisions, and open questions. It's a living document, not a static summary, but your evolving position on that topic.
Skill READMEs
These are not the skills themselves, but portable README files for each one. Use them as a blueprint to build something similar for your setup. Each README includes what the skill does, how it works, what triggers it, dependencies, and an adaptation guide.
1. Catch Me Up — Central query engine for your knowledge vault
What it does
Central query engine for a knowledge vault (Obsidian-based or similar). Searches across topic notes, daily logs, email, meeting notes, Google Docs, and Slack to answer questions about your work. Also handles system modifications like updating the query log or changing priorities.
How it works
(1) Log every query to a Query Log file for later evaluation.
(2) Search vault layers in priority order: synthesized topic notes first, then daily logs, then live tool searches (email, meetings, docs, Slack).
(3) For people queries, search vault + email + meetings + Slack for that person's context and history.
(4) Cite all sources explicitly so the user can verify.
(5) Flag stale information (e.g., "last mentioned 6 months ago, may be out of date").
Triggers
"what's the latest on X", "catch me up on X", "what did X say about Y", "what's my position on Z", "search my notes for X", "who have I talked to about X"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Gmail | Search email threads for context | Optional but recommended |
| Google Drive | Search shared docs for context | Optional but recommended |
| Granola | Pull meeting notes and transcripts | Optional but recommended |
| Slack | Search channel history for context | Optional |
| Google Calendar | Meeting context and timing | Optional |
| Atlassian (Jira/Confluence) | Search issues and wiki docs | Optional |
Vault structure expected
• Topic Notes folder (your synthesized knowledge by project/area)
• Daily Log (dated entries)
• MANIFEST registry (index of all topics and their purposes)
• Query Log file (append-only log of all queries)
• Personal/About Me file (for context gates and preferences)
Cross-skill dependencies
• tao-life-update (fires if personal information surfaces in queries)
• brain-skill-eval (uses Query Log to evaluate system quality)
Adaptation guide
To build your own:
• Replace folder paths with your vault structure (e.g., "Work/Topics" instead of "Topic Notes")
• Adjust MCP connectors to match your tools (Slack instead of email, Notion instead of Google Docs)
• Define your own search priority order (what matters most to find first)
• Update person-name pre-check logic if you want special handling for certain people
• Add a consent gate if your Personal folder contains sensitive information
• Customize the "stale" threshold (6 months, 1 year, etc.)
Minimal viable version
Must-have: Vault search logic, query logging, source citing
Nice-to-have: Gmail/Granola integration, person-specific context, stale flagging
Can-skip: Slack integration, cross-tool people search, system modification commands
2. Memo Co-Writing — Deep strategic thinking partner
What it does
A strategic co-writing partner that absorbs raw context dumps (notes, emails, meeting snippets, half-formed ideas) and synthesizes them into a structured strategic document. Works in three modes: Full (think-then-write) for complex synthesis, Assembly (structure provided, just execute) for speed, and Decision-doc, which runs a short triage and routes to a decision-brief template when the goal is a decision rather than a memo.
How it works
(1) Absorb context without premature synthesis or filtering.
(2) Ask framing questions and cross-reference vault topics to understand scope.
(3) Run a Challenge Round: audit assumptions, challenge framing, ask tough questions, consider stakeholder lenses. In Decision-doc mode, a short triage replaces this step and selects a decision-brief template.
(4) Synthesize: identify blind spots, map options and trade-offs, recommend a path, present devil's advocate view.
(5) Iterate based on feedback.
(6) Save session memory and working notes for continuity across sessions.
Triggers
"let's co-write", "co-writing mode", "let's draft this document", "help me think through this", or raw context dumps that need synthesis
Dependencies
| Connector | Used for | Required |
|---|---|---|
| None | Vault-only skill | — |
Vault structure expected
• Topic Notes folder (for cross-referencing related work)
• MANIFEST registry (to understand project landscape)
• Co-writing Temp folder (for session drafts and working notes)
Cross-skill dependencies
• query-second-brain (to pull topic context during synthesis)
Adaptation guide
To build your own:
• Replace vault folder paths with your structure
• Customize the Challenge Round framework (what angles matter for your work)
• Define output voice/style rules (formal memo, conversational doc, structured bullets)
• Choose document format preferences (HTML, Markdown, DOCX)
• Adjust writing style (numbered sections heavy vs. prose-forward, table-heavy vs. narrative)
• Decide on session memory protocol (save working notes, save only final output, save feedback)
Minimal viable version
Must-have: Context absorption, Challenge Round framework, synthesis loop
Nice-to-have: Vault topic cross-referencing, session memory, multiple output formats
Can-skip: Assembly mode, devil's advocate view, stakeholder lens variations
3. Meeting Prep — 1-page context brief for non-routine meetings
What it does
Generates a 1-page context brief for any non-routine meeting: partner meetings, conference encounters, cross-functional syncs, external calls. Includes relationship history, talking points, questions to ask, and a framework for what to push for, what to learn, and what to watch out for.
How it works
(1) Classify meeting type (external partner, conference, cross-functional, board, etc.).
(2) Run person/company lookup across vault, Google Drive, email, and meeting history.
(3) Check calendar for meeting details, duration, attendees, and adjacent events.
(4) Map to relevant vault topics (projects, decisions, history with this person/company).
(5) Synthesize relationship history and prior interactions.
(6) Check Meeting Queue file for pre-saved talking points relevant to this person.
(7) Generate structured prep brief with all context.
Triggers
"prep me for my meeting with X", "I have a meeting with X tomorrow", "what should I discuss with X", "sitting next to X at [event]", "meeting prep"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Gmail | Email history with person/company | Recommended |
| Google Drive | Search docs related to person/company | Recommended |
| Granola | Prior meetings with this person | Recommended |
| Google Calendar | Meeting details and context | Required |
Vault structure expected
• MANIFEST registry (project and topic index)
• Topic Notes (for mapping to relevant work)
• Meeting Queue file (pre-saved talking points)
• Daily Log (recent events and decisions)
Cross-skill dependencies
• exec-email (for follow-up drafts after the meeting)
• query-second-brain (person and company lookup logic)
Adaptation guide
To build your own:
• Define your meeting type taxonomy (what categories matter for your role)
• Customize prep brief format and sections (what you actually need to know)
• Move Meeting Queue file to your vault location
• Adjust what constitutes a "provocative angle" or "smart question" for your domain
• Modify relationship history synthesis approach (how far back to look, what matters)
• Add company-specific context sources if needed
Minimal viable version
Must-have: Calendar lookup, email history search, vault topic mapping
Nice-to-have: Meeting Queue lookup, Granola meeting history, multi-person context
Can-skip: Company research, relationship timeline, provocative angle generation
4. Strategic Review — Three-mode skill for recurring strategic reviews
What it does
Three-mode skill for recurring strategic reviews. PREP mode: deep context gathering and deck analysis before QBRs/board meetings. POST mode: captures commitments and updates state after meetings. CRITIQUE mode: lightweight structured critique of any stakeholder update.
How it works
PREP: (1) Read state file from prior cycle. (2) Ingest and analyze the deck or document. (3) Generate pre-read briefing with constraint analysis, cross-connections, and accountability check. (4) After user reads deck, synthesize their comments into priorities.
POST: (1) Collect meeting notes and user feedback. (2) Update state file with commitments and assessment.
CRITIQUE: (1) Read update document against critique rubric. (2) Cross-reference vault for context. (3) Output gaps table with probing questions.
Triggers
"QBR prep", "board prep", "review the quarterly deck", "debrief the meeting", "critique this update", "spot the gaps"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Google Drive | Access deck or document | Recommended |
| Gmail | Email thread context | Optional |
| Granola | Meeting notes and transcript | Optional |
Vault structure expected
• MANIFEST registry (topic reference)
• Topic Notes (cross-connections and context)
• State files per review series (QBR state, board state, etc.)
• Daily Log (recent activity)
Cross-skill dependencies
• co-writing (for creative strategic thinking after prep)
• query-second-brain (to pull topic context and history)
Adaptation guide
To build your own:
• Define your meeting type taxonomy (QBR, board, initiative review, investor review)
• Create objective templates per meeting type (what success looks like)
• Customize critique rubric (what constitutes a good update)
• Update state file format (what you need to track between reviews)
• Integrate Theory of Constraints or other frameworks specific to your role
• Adjust deck analysis depth (high-level summary vs. slide-by-slide critique)
Minimal viable version
Must-have: Context gathering, deck analysis, state tracking
Nice-to-have: Pre-read briefing generation, cross-connection mapping, critique mode
Can-skip: Theory of Constraints integration, complex state management, multi-cycle comparison
5. Interview Debrief — Post-interview candidate assessment using the Who Method
What it does
Post-interview candidate assessment using the Who Method (Topgrading, a structured interview assessment framework). Generates a structured scorecard with competency scoring, topgrading timeline analysis (career progression and reasons for leaving), red and green flags, and a hire/no-hire recommendation with confidence level.
How it works
(1) Load role profile with required competencies and must-haves.
(2) Collect Granola interview notes and transcript, plus interviewer's pros and cons.
(3) Score each competency against the profile using Who Method criteria.
(4) Analyze topgrading timeline: career progression, reasons for leaving, gap analysis.
(5) Map red flags (concerning behavior, inconsistencies) and green flags (strength signals).
(6) Generate hire/no-hire recommendation with confidence level and key decision factors.
(7) Save scorecard to vault for future reference.
Triggers
"interview debrief", "score the interview", "candidate review for [name]", "how did X do", "debrief" (after an interview)
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Granola | Interview notes and transcript | Recommended |
Vault structure expected
• Work/Projects/Interviews/ folder (role profiles and scorecard outputs)
• MANIFEST registry (to track open roles)
Cross-skill dependencies
None.
Adaptation guide
To build your own:
• Replace Who Method scoring with your preferred framework (Topgrading, Structured Assessment, custom rubric)
• Define competency framework (what competencies matter for your roles)
• Customize scorecard format (numeric scores, traffic-light ratings, narrative only)
• Adjust recommendation confidence thresholds (when to be decisive vs. uncertain)
• Decide how interviewer gut-feel is weighted (heavily vs. as tie-breaker only)
• Update timeline analysis approach (topgrading depth, what you're looking for)
Minimal viable version
Must-have: Competency scoring, timeline analysis, hire/no-hire recommendation
Nice-to-have: Red/green flag detection, confidence levels, topgrading timeline
Can-skip: Complex Who Method details, multiple scoring frameworks, interviewer weighting
6. Review Panel — Autonomous document iteration with simulated reviewers
What it does
Autonomous document iteration loop. Takes or generates a document, runs it through simulated reviewers with defined personas, scores against success criteria, and iterates until pass threshold is met. Outputs: polished document, scorecard, and changelog showing what changed.
How it works
(1) Determine if starting from existing document or generating fresh.
(2) Define reviewer panel (archetypes like "exec sponsor" or "skeptical peer", or real people enriched from vault).
(3) Set success criteria and pass threshold (e.g., "all reviewers score 4+ out of 5").
(4) Generate V1 if needed.
(5) Run each reviewer against the document, collect feedback and scores.
(6) Auto-iterate: apply feedback, re-score, repeat until pass or max iterations reached.
(7) Deliver final document, scorecard with per-reviewer feedback, and changelog of changes.
Triggers
"review panel", "iterate on this doc", "run it through reviewers", "stress test this document", "make this bulletproof"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| None | Vault context optional | — |
Vault structure expected
• Topic Notes (optional, for enriching real-person reviewer personas)
• Co-writing Temp folder (optional, for input documents)
Cross-skill dependencies
• co-writing (often produces the input document)
Adaptation guide
To build your own:
• Define your reviewer archetypes (what personas matter for your role: CEO, skeptic, engineer, customer)
• Create scoring rubric with specific evaluation criteria
• Set pass threshold based on your needs (unanimous 5s vs. average 4+)
• Decide max iteration count (prevent infinite loops)
• Choose output format (HTML, Markdown, DOCX)
• Define scoring scale (1-5, traffic light, numeric)
• Add optional real-person personas from your vault (pull their communication style for authenticity)
Minimal viable version
Must-have: Generation, reviewer simulation, iteration loop, pass/fail scoring
Nice-to-have: Real-person reviewer enrichment, changelog generation, scorecard detail
Can-skip: Multiple iteration strategies, complex feedback application, multi-format output
7. System Health — Weekly knowledge system health check
What it does
Weekly system health check for your knowledge system. File health audits, task manager sync check, stale project detection, narrative candidate review, lightweight skill audit, growth metrics logging, and one concrete improvement suggestion. Think of it as DevOps for your personal knowledge system.
How it works
(1) Check vault file health: orphan files, broken links, oversized files.
(2) Compare task manager state against vault topics for sync mismatches.
(3) Flag stale projects (no activity in 4+ weeks).
(4) Review emerging narrative candidates (themes surfacing in daily log).
(5) Run lightweight skill audit (quick pattern scan).
(6) Log system growth metrics (new topics, query volume, skill usage).
(7) Suggest one concrete improvement action.
Triggers
"weekly review 1", "system review", "system health", "vault health"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| None | Vault-only | — |
Vault structure expected
• MANIFEST registry (topic index)
• Topic Notes folder (all topics)
• Daily Log (for narrative candidates)
• Things Snapshot (task manager integration)
• Narrative Candidates file
• Change Log
• Skill files (for skill audit)
Cross-skill dependencies
• skill-audit (lightweight version runs here)
• brain-skill-eval (references eval history)
Adaptation guide
To build your own:
• Replace "stale" threshold (4 weeks is default, adjust for your pace)
• Define file health checks specific to your vault structure
• Update task manager integration (Things3 specific in original; use Todoist, Notion, etc.)
• Choose which growth metrics to track (new topics, query volume, skill usage frequency)
• Customize improvement suggestion framework (what types of fixes to suggest)
• Adjust narrative candidate detection (what patterns indicate emerging themes)
Minimal viable version
Must-have: File health check, task manager sync, stale project detection
Nice-to-have: Narrative candidates, growth metrics, improvement suggestion
Can-skip: Lightweight skill audit, complex health scoring, growth metrics tracking
8. Self-Challenge — System challenging its owner
What it does
Weekly Review 4 in the pipeline. The system challenges me across five fixed sections: topic flags (meta-patterns across topics, not per-topic status), blind spots, a time audit, my top 3 for next week with any mismatch against where my time actually went, and a merged Challenge section (devil's advocate, open questions, and one genuinely hard thinking prompt). It reads the commitment state produced by Weekly Review 2 read-only; it does not re-reconcile commitments, and it does not cover "what moved last week," which the Top of Mind briefing owns.
How it works
(1) Read the commitment state from Weekly Review 2's output (read-only) plus vault context: daily log, topic notes, and the time-tracking snapshot.
(2) Surface topic flags: meta-patterns across topics, not a per-topic status check.
(3) Detect blind spots for the week.
(4) Run a time audit on where the week actually went.
(5) Ask for my top 3 for next week and flag any mismatch against the audit, closing with a "will not let slip" line.
(6) Deliver the merged Challenge: devil's advocate, open questions, and one genuinely hard thinking prompt.
Triggers
"weekly review 4", "self review", "weekly review self", "challenge me"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Gmail | Sent email analysis (optional) | Optional |
| Granola | Meeting review (optional) | Optional |
Vault structure expected
• MANIFEST registry
• Topic Notes
• Daily Log
• Things Snapshot
• Development diary (optional, for tracking growth)
Cross-skill dependencies
• weekly-review-3-development (runs before this)
• weekly-review-5-top-of-mind (runs after this; owns "what moved last week")
• weekly-review-2-commitments (supplies the commitment state this skill reads, read-only)
Adaptation guide
To build your own:
• Customize question framework (what you actually want to reflect on)
• Define what "blind spots" means for your role (strategic vs. operational vs. interpersonal)
• Choose development areas tracked (leadership, technical skills, soft skills)
• Adjust tone: how aggressively should the system challenge (gentle vs. blunt)
• Customize thinking prompt style (philosophical vs. practical, personal vs. professional)
• Add optional email/meeting analysis for time audit accuracy
Minimal viable version
Must-have: Structured question prompts, priority challenge, analytical review
Nice-to-have: Time audit, blind spot detection, thinking prompt
Can-skip: Email analysis, meeting review, development feedback
9. Top of Mind Briefing — Weekly briefing for sharing with leadership
What it does
Weekly Review 5, the final step. Generates my weekly "Top of Mind" briefing as three artifacts: a confidential exec briefing and a public briefing, both written in Slack-ready markdown, plus a sanitized Confluence page created fresh each week. Each briefing follows a fixed format: what moved, my focus, commitments, a signal section, recognition, and a closing line. A sensitivity gate handles named individuals carefully, and the public version has hard drops and sanitization applied.
How it works
(1) Read MANIFEST and the task snapshot for current state.
(2) Read all context: daily log, topic notes, meeting notes, Google Docs, and the outputs of Weekly Reviews 1-4.
(3) Detect what changed since last week.
(4) Run the sensitivity gate: flag named individuals in sensitive contexts and ask how to handle each.
(5) Generate the exec briefing (confidential) and the public briefing (hard drops and sanitization applied), both as Slack-ready markdown.
(6) Publish a sanitized Confluence page as a new child page for the week.
Triggers
"weekly review 5", "top of mind", "generate my briefing", "weekly update"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Google Drive | Published thinking docs | Optional |
| Granola | Meeting context | Optional |
| Google Calendar | Next week deadlines | Optional |
Vault structure expected
• MANIFEST registry
• Topic Notes
• Daily Log
• Things Snapshot
• Weekly Top of Mind archive (folder for past briefings)
• Outputs from Weekly Reviews 1-4 (the briefing builds on them)
Cross-skill dependencies
• weekly-review-1-system, weekly-review-2-commitments, weekly-review-3-development, weekly-review-4-self (all run before this and feed it)
• co-writing (for style and format consultation)
Adaptation guide
To build your own:
• Customize briefing structure (exec summary length, sections to include)
• Define project table format (columns: progress/problems/plans, decisions, commitments with IN/OUT prefix)
• Set sensitivity gate rules (what types of situations require asking)
• Customize exclusion rules for public version (what gets redacted)
• Choose where the sanitized version is published (a wiki page, a doc, or an email)
• Decide which sections are optional (self-criticism, appendix, theme analysis)
• Adjust frequency: weekly vs. bi-weekly vs. monthly
Minimal viable version
Must-have: Top 3 priorities, project table, context gathering
Nice-to-have: Sensitivity gate, public version generation, wiki/Confluence publishing
Can-skip: Detailed theme analysis, self-criticism, published thinking appendix
10. Skill Audit — Pattern detector for workflow automation opportunities
What it does
Recurring pattern detector that scans usage data to identify workflows that should be automated as skills. Analyzes query logs, task manager, daily logs, and session transcripts for repetition, then suggests new skills or improvements ranked by estimated time savings. Also produces a Skill Health Dashboard showing which existing skills work, which have friction, and which are dormant.
How it works
(1) Scan 5 data sources for patterns: query log, task manager, daily log, session transcripts, existing skill files.
(2) Compute Skill Health Dashboard: usage frequency, average turns per skill, retry rate per skill.
(3) Cluster and deduplicate patterns found across sources.
(4) Score each automation opportunity: frequency x time savings x consistency x buildability.
(5) Present top 5 suggestions with build specifications.
(6) Execute on "build it now" choices with draft skill scaffolding.
Triggers
"skill audit", "suggest skills", "what should we automate", "recurring patterns", "skill health"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| None | Reads vault files only | — |
Vault structure expected
• Query Log file
• MANIFEST registry
• Daily Log
• All SKILL.md files (for health dashboard)
• Session transcripts (optional, for pattern detection)
Cross-skill dependencies
• All skills (reads them for gap analysis)
Adaptation guide
To build your own:
• Adjust scoring weights (frequency, time savings, consistency, buildability ratios)
• Update health thresholds (when a skill is "dormant" vs. "healthy")
• Customize data sources to scan (add/remove sources as needed)
• Define what counts as "recurring" (3+ occurrences is default)
• Update build vs. extend logic (when to create new skill vs. improve existing)
• Adjust output format (detailed specs vs. quick bullet points)
• Configure output folder for skill suggestions
Minimal viable version
Must-have: Pattern detection, opportunity scoring, top suggestions
Nice-to-have: Skill Health Dashboard, build specifications, multi-source scanning
Can-skip: Session transcript analysis, detailed health metrics, build scaffolding
11. Skill Eval — Self-improvement engine for the knowledge system
What it does
Self-improvement engine for the knowledge system. Runs structured evaluations against the query skill using test queries and a 9-criteria scoring rubric, proposes and applies fixes, tracks improvement over time, and evolves the test bank based on real usage patterns.
How it works
(1) Run 3 test queries from rotating test banks.
(2) Grade each against 9 criteria (C1-C9: relevance, citation, stale flagging, etc.).
(3) Compare scores to historical benchmarks.
(4) Present results with A/B/C/D action choices.
(5) If "Apply fix": read current skill, implement fix, re-test to verify.
(6) If "Evolve test bank": analyze real Query Log to find coverage gaps, propose new test categories.
(7) Save eval results to history.
Triggers
"run a skill eval", "eval my second brain", "test the skill", "how can the system be better", "A/B/C/D" (referencing eval results)
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Gmail | Email scorecard (optional) | Optional |
Vault structure expected
• Eval History file (scorecard archive)
• MANIFEST registry
• Query skill file (the skill being improved)
• Query Log (real usage patterns)
• Change Log (tracking improvements)
• Task prompt files (skill configuration)
Cross-skill dependencies
• query-second-brain (the skill being tested)
Adaptation guide
To build your own:
• Customize test query banks (what queries matter most)
• Define 9-criteria rubric specific to your system's goals
• Update grading scale (1-5, traffic light, numeric)
• Change eval history format (how you store results)
• Redefine what "fix" means for your system (prompt tuning, structure changes, tool changes)
• Adjust test bank evolution logic (what patterns indicate coverage gaps)
• Choose cadence: scheduled (weekly eval) vs. on-demand (run when asked)
Minimal viable version
Must-have: Test query execution, scoring rubric, action choices
Nice-to-have: Historical tracking, automated fix application, test bank evolution
Can-skip: 9-criteria scoring, re-test verification, detailed change logs
12. Life Update — Background maintenance for persistent memory
What it does
Background maintenance skill that silently updates a personal profile file (About Me) after conversations that reveal new personal details, preferences, life events, tool changes, or behavioral patterns. Gives the AI persistent memory across sessions without interrupting the conversation.
How it works
(1) Detect if the conversation revealed something worth persisting (new tool, preference change, life update, behavioral pattern).
(2) Read existing About Me file.
(3) Determine which section to update (Basics, Work Context, Tools, Communication, Interests, Life Updates, Quirks, Relationships).
(4) Write the update: dated entries for Life Context section, in-place edits for other sections.
(5) Tell user what was added and why, so there's transparency.
Triggers
"remember this", "add this to my profile", "update my about me", or fires automatically at session end if new information surfaced
Dependencies
| Connector | Used for | Required |
|---|---|---|
| None | Vault-only | — |
Vault structure expected
• Personal/About Me.md (the file being maintained)
Cross-skill dependencies
• query-second-brain (consent gate for reading personal files)
Adaptation guide
To build your own:
• Replace About Me file path with your personal profile location
• Customize file structure and sections (what categories matter for you)
• Define what's worth persisting vs. ephemeral (preferences, not one-off mentions)
• Choose consent model for personal data (always silent, ask before updating, explicit approval)
• Set file size management thresholds (when to archive old entries)
• Update trigger conditions (what types of changes warrant an update)
• Adjust frequency (per-session vs. weekly rollup)
Minimal viable version
Must-have: About Me file reading, detection logic, update writing
Nice-to-have: Multiple section types, dated entries, transparency reporting
Can-skip: File size management, complex consent model, archival logic
13. 1:1 Debrief — Post-1:1 extraction into the Second Brain
What it does
After a 1:1 meeting, pulls the Granola transcript, maps insights to active strategic topics, updates topic notes and People files, flags data corrections and new topic candidates. Two modes: Quick (auto-route, no questions) and Deep (user's gut-feel color + full debrief).
How it works
(1) Pull the most recent meeting transcript from Granola with the named person.
(2) Ask gut-feel questions in Deep mode (what surprised you, what changed, what's unresolved).
(3) Map each insight to an existing topic note or flag it as a new topic candidate.
(4) Update the People file with relationship context, preferences, and open items.
(5) Update commitment statuses: mark fulfilled commitments as Done, capture new commitments, adjust due dates for changed ones.
(6) Flag any contradictions between what was said and what's in the vault.
(7) Save the debrief summary to the daily log.
Triggers
"debrief my 1:1 with X", "process my meeting with X", "extract from my 1:1", "what came out of my chat with X"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Granola | Pull meeting transcripts | Recommended |
Vault structure expected
• Topic Notes folder (active strategic topics)
• People folder (per-person context files)
• Daily Log (dated entries for debrief summaries)
• MANIFEST registry (topic index for routing)
Cross-skill dependencies
• query-second-brain (for topic context lookup during routing)
• tao-life-update (if personal details surface)
Adaptation guide
To build your own:
• Replace vault paths with your folder structure
• Customize the gut-feel questions for Deep mode (what matters to you after a 1:1)
• Define your People file format (what you track per person)
• Adjust topic-routing logic based on your topic taxonomy
• Choose between Quick and Deep as default (or let the skill ask)
Minimal viable version
Must-have: Transcript pull, topic routing, People file updates
Nice-to-have: Contradiction flagging, daily log integration, Deep mode questions
Can-skip: New topic candidate detection, cross-skill calls
14. Commitment Reconciliation — Weekly sweep that closes accountability loops
What it does
Weekly Review 2 in the pipeline. Aggregates every open commitment from topic notes, the daily log, and my team Slack channel, triages what's overdue, confirms or discards the commitments the system auto-captured during the week (marked unconfirmed), and flags any topic with no active commitment. It writes the confirmed changes back to the topic notes and produces one document: a status table plus ready-to-paste nudge text for the items I still owe. It does not send anything itself; I copy the nudge text out when I'm ready.
How it works
(1) Read every topic note's Commitments section and collect all open, due, and overdue items; pull recent commitments from the daily log and the team Slack channel.
(2) Triage overdue items and split the ledger by direction: outbound (I owe someone) and inbound (someone owes me).
(3) Confirm or discard the auto-captured (unconfirmed) commitments from the week.
(4) Flag any non-backlog topic with no active commitment as a structural gap.
(5) Write the confirmed status changes back to the topic notes.
(6) Produce one doc: a status table plus copy-paste nudge text for the outbound items, and offer to email it to me.
Triggers
"weekly review 2", "commitment reconciliation", "commitment nudges", "close the loop", "who owes me what", "what did I promise"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Slack | Read the team channel for open commitments | Optional |
| Gmail | Optionally email the finished doc to yourself | Optional |
Vault structure expected
• Topic Notes with "Commitments" section (What / Who / When / Direction / Status)
• MANIFEST registry (topic index)
• Principles.md (commitment lifecycle model: Open / Due / Overdue / Done / Dropped)
• About Me file (communication preferences, relationship context)
Cross-skill dependencies
• weekly-review-1-system (upstream: runs first in the pipeline)
• weekly-review-4-self (downstream: reads this skill's commitment state, read-only)
• weekly-review-5-top-of-mind (downstream: surfaces commitments in the briefing)
Adaptation guide
To build your own:
• Point it at wherever your commitments live (topic notes, a task manager, chat history)
• Customize message templates (tone, length, level of directness)
• Define your commitment tracking structure (what fields to track per commitment)
• Adjust channel defaults per relationship type (DM vs. email vs. in-person)
• Set rules for when to skip nudges (e.g., "discussed in a meeting this week")
• Customize the commitment lifecycle states if needed
Minimal viable version
Must-have: Topic notes with commitment fields, message drafting, approval gate
Nice-to-have: Reading commitments from chat history, per-person nudge text, status write-back
Can-skip: Emailing the doc to yourself, meeting-based skip detection, complex templates
15. Skill README — Portable documentation generator for skills
What it does
Generates a portable README for any skill so others can understand and adapt it to their own setup. Reads the target skill's file, identifies all dependencies (vault paths, MCPs, tools, cross-skill references, personal customizations), and produces a clean markdown document with an adaptation guide.
How it works
(1) Read the target skill's SKILL.md file.
(2) Parse out all dependencies: vault paths, MCP connectors, cross-skill references, hardcoded values.
(3) Categorize each dependency as required, recommended, or optional.
(4) Generate a README with: description, how it works, triggers, dependency table, adaptation guide, minimal viable version.
(5) Save to vault or output for sharing.
Triggers
"skill readme for X", "readme for the X skill", "make X shareable", "export X skill", "document the X skill"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| None | Vault-only skill | — |
Vault structure expected
• Skills directory (where SKILL.md files live)
Cross-skill dependencies
None. Reads other skills but doesn't call them.
Adaptation guide
To build your own:
• Customize the README template format (what sections matter to your audience)
• Adjust dependency detection patterns for your skill naming conventions
• Define "minimal viable version" criteria for your context
Minimal viable version
Must-have: Skill file reading, dependency detection, README generation
Nice-to-have: Cross-skill reference mapping, adaptation guide
Can-skip: Automated dependency categorization
16. Skill Editor — The skill that updates other skills
What it does
This is a meta-skill: it edits other skills. When I say "update the co-writing skill to always start with a stakeholder map," Claude reads the current SKILL.md, applies the change, and writes it back. It also generates a .skill install package I can share or reinstall.
Why it exists
Without this skill, Claude tries to write directly to the skills directory, fails because it's read-only in Cowork's sandbox, then retries in a loop, sometimes for several attempts before giving up or corrupting the output. This skill short-circuits that behavior: it forces Claude to use Cowork's present_files mechanism instead, which generates the updated SKILL.md and presents it to you as a file you can save to the correct location with one click. No loops, no failed writes, no wasted turns.
How it works
(1) Identify which skill to update from the user's request.
(2) Read the current SKILL.md file.
(3) Apply the requested changes (add steps, modify logic, update triggers, change behavior).
(4) Present the updated file via present_files so the user can save it to the skills directory.
(5) Optionally generate a .skill package for sharing.
Triggers
"update the skill", "edit the skill", "change the skill", "fix the skill", "the skill needs to say...", "add this to the skill"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Cowork present_files | Deliver updated SKILL.md to the user's file system | Built into Cowork |
Vault structure expected
• Skills directory (where SKILL.md files live)
Adaptation guide
To build your own:
• This skill is mostly about prompt engineering: teaching Claude how to read, modify, and rewrite a SKILL.md without breaking its structure
• The key instruction is: read the full file first, apply only the requested change, preserve everything else
• Add validation rules if you want (e.g., require trigger phrases, enforce naming conventions)
• The present_files delivery mechanism is built into Cowork, so no setup needed there
Minimal viable version
Must-have: Skill file reading, targeted editing, present_files delivery
Nice-to-have: .skill package generation, diff preview before saving
Can-skip: Validation rules, automated testing after update
17. Brand Presentations — On-brand PowerPoint generation from a company template
What it does
Generates polished PowerPoint presentations using your company's official template with correct fonts, colors, and layouts. Picks slides from the template library, duplicates them, replaces placeholder content with real data from your vault and meetings, and exports a ready-to-present .pptx.
How it works
(1) Start from your company's brand template and its approved layouts (cover, agenda, content, stats, charts, section dividers).
(2) Choose the layouts that fit the content brief.
(3) Pull content from topic notes, meeting transcripts, and anything you provide.
(4) Fill the layouts with the real content, keeping the brand fonts, colors, and spacing.
(5) Run a QA pass on font consistency, color accuracy, and layout alignment.
(6) Export the final .pptx.
Triggers
"make a deck", "create a presentation", "build slides for", "GYG deck", "work presentation", or any request to create slides for a meeting, review, or update
Dependencies
| Connector | Used for | Required |
|---|---|---|
| None | Vault + template files only | — |
Vault structure expected
• Brand template .pptx file (stored in the skill's assets folder)
• Brand guidelines skill (for color/font reference)
• Topic Notes (for content to pull into slides)
Cross-skill dependencies
• Brand guidelines skill (enforces visual identity: colors, typography, logo usage)
• A slide-generation skill that renders the deck from your template (via template editing or programmatic generation)
• query-second-brain (optional, for pulling topic context into slides)
Adaptation guide
To build your own:
• Replace the template .pptx with your company's official template
• Update the color palette and font mappings to match your brand
• Define your slide layout library (which template slides to use for what purpose)
• Customize content-pull logic based on your vault structure
• Add chart/data slide support if your template includes data visualization layouts
Minimal viable version
Must-have: Template duplication, slide selection, text replacement, .pptx export
Nice-to-have: Brand color enforcement, QA pass, vault content pull
Can-skip: Chart generation, multi-template support, slide reordering UI
18. Daily Log — Automated end-of-day activity digest
What it does
Runs every weekday at 6pm as a scheduled task. Scans all sent and received emails, Slack messages, and meeting transcripts from the day. Writes a dated summary to the vault and sends an email digest with action items, key decisions, and signals you might have missed. This is the system's heartbeat: without fresh daily data, every other skill gets stale.
How it works
(1) Scan Gmail for all sent and received emails from today.
(2) Scan Slack for messages in relevant channels.
(3) Pull meeting transcripts from Granola for today's meetings.
(4) Categorize everything: action items, decisions made, information received, commitments given.
(5) Write a dated Daily Log entry to the vault.
(6) Cross-reference with active topic notes and flag anything relevant.
(7) Send an email digest summarizing the day.
Triggers
Runs automatically on a schedule (weekdays, 6pm). Can also be triggered manually: "run the daily log", "what happened today", "daily digest"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Gmail | Scan sent and received emails | Recommended |
| Slack | Scan channel messages | Optional |
| Granola | Pull meeting transcripts | Optional |
| Resend (or email API) | Send the nightly digest email | Optional |
Vault structure expected
• Daily Log folder (dated entries, one per day)
• Topic Notes (for cross-referencing activity against active topics)
• MANIFEST registry (to know which topics are active)
Cross-skill dependencies
• query-second-brain (uses Daily Log entries as a search layer)
• weekly-review skills (aggregate Daily Logs into weekly patterns)
• send-email skill (for delivering the digest)
Adaptation guide
To build your own:
• Choose your data sources (email, Slack, meetings, calendar, or a subset)
• Define your categorization framework (action items, decisions, FYIs, or your own)
• Set the schedule that fits your workday (6pm, end of last meeting, etc.)
• Customize the email digest format (plain text, HTML, bullet list, narrative)
• Adjust topic cross-referencing based on your vault structure
Minimal viable version
Must-have: Email scan, dated vault entry, basic categorization
Nice-to-have: Slack/Granola integration, email digest, topic cross-referencing
Can-skip: Sentiment analysis, priority scoring, automatic follow-up scheduling
19. Development Reflection — Weekly self-coaching check-in (Weekly Review 3)
What it does
Step 3 in the weekly review pipeline. A short, structured check-in on your personal development priorities. For each priority it offers a nudge drawn from the week's logs and meetings, asks for a self-assessment, and captures the one change you're making plus a commitment for next week. It closes with a single strategic-thinking question.
How it works
(1) Read your development priorities from the vault.
(2) For each one, pull supporting evidence from the daily log and recent meeting notes.
(3) Offer a nudge, then ask for your self-assessment and the change you'll make.
(4) Record each answer back to a development diary in the vault.
(5) Close with one capstone question on how you think, not just what you did.
Triggers
"weekly review 3", "development review", "development reflection"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| None | Vault files only (daily log + development diaries) | — |
Adaptation guide
To build your own:
• Define your own development priorities (3–5 is plenty)
• Decide where evidence comes from (logs, meetings, peer feedback)
• Keep it interactive: the value is your self-assessment, not the system's read
• Store answers in a dated diary so you can see the trend over months
Minimal viable version
Must-have: Priority list, per-priority prompt, written record
Nice-to-have: Evidence nudges from logs, capstone question
Can-skip: Trend charts, cross-linking to annual review goals
20. Decision Doc — SCORE decision briefs published to Confluence
What it does
Turns a decision you need to make into a structured brief using the SCORE framework — situation, criteria, options, recommendation, and the trade-offs (effects) of each option. It pulls context from your topic notes and publishes the finished brief to Confluence for the people who need to weigh in.
How it works
(1) Capture the decision and pull related context from the vault.
(2) Lay out the situation and the criteria that actually matter.
(3) Build the options and score each against the criteria.
(4) State a recommendation with the trade-offs made explicit.
(5) Publish to Confluence and tag the approvers.
Triggers
"decision doc for X", "SCORE template", "write up a decision", "we need to decide on X", "should we go with A or B"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Confluence | Publish the finished decision brief | Optional (or any doc tool) |
Adaptation guide
To build your own:
• Pick a decision framework you trust (SCORE, or a simpler options table)
• Make the trade-offs explicit — that's the part most decision docs skip
• Swap Confluence for whatever your org reads (Google Docs, Notion, email)
• Always include a recommendation; a doc that only lists options pushes the work back on the reader
Minimal viable version
Must-have: Situation, options, recommendation, trade-offs
Nice-to-have: Vault context pull, scored criteria, auto-publish
Can-skip: Approver tagging, templated formatting
21. Trim — Cull long writing without losing the evidence
What it does
An editing pass for long writing. It tightens a memo or briefing without gutting it: it removes filler, repetition, and hedging but protects the specific numbers, sources, and examples that make the argument credible. Built for strategy memos, exec briefings, and reports — not slides.
How it works
(1) Read the draft and identify its load-bearing evidence (figures, citations, examples).
(2) Cut restated points, filler, and hedging language.
(3) Preserve the protected evidence verbatim.
(4) Report the before/after word count and what was removed.
Triggers
"trim this", "tighten this up", "make this sharper", "this is too long", "compress this"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| None | Operates on text in the conversation or a vault file | — |
Adaptation guide
To build your own:
• Define what counts as protected evidence so the model never cuts it
• Write the rules in your own voice (what filler looks like for you)
• Keep it format-aware: prose and slides need different logic
• Report the diff so you stay in control of what was removed
Minimal viable version
Must-have: Filler/repetition removal, evidence protection rule
Nice-to-have: Word-count report, list of cuts
Can-skip: Format detection, multiple compression levels
22. OKR Review — Flags missing updates and off-track results
What it does
Reads a quarterly OKR tracking sheet and flags two things: key results whose update is past due, and any initiative marked off-track or at-risk. It checks every result across all tabs so you walk into the review already knowing where the problems are.
How it works
(1) Fetch the OKR sheet data from the authenticated session.
(2) For each key result, check the last-updated date against its cadence.
(3) Flag anything past due, plus any result marked off-track or at-risk.
(4) Report the flags grouped by tab, with owner and gap to target.
Triggers
"review OKRs", "OKR status", "any OKRs off track", "OKR health check", "who hasn't updated their OKRs"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Google Sheets (via browser) | Read the OKR tracking spreadsheet | Required |
Adaptation guide
To build your own:
• Point it at your tracker (Sheets, a database, or a planning tool)
• Define your staleness rule (e.g., no update in 7+ days)
• Match your status labels (off-track, at-risk, on-track)
• Keep the output to flags only — the review is for problems, not a full read-out
Minimal viable version
Must-have: Sheet read, stale-update detection, status flagging
Nice-to-have: Owner attribution, gap-to-target
Can-skip: Multi-tab handling, trend over quarters
23. Performance Check-In — Structured mid-cycle review for a direct report
What it does
Runs a structured performance check-in for a direct report between annual reviews. It loads the latest annual review and any prior check-ins, walks you through each growth area and strength with a trend and a rating, captures your own observations, and produces a shareable check-in document saved to that person's People folder.
How it works
(1) Load the person's latest annual review and any prior check-ins.
(2) Walk through each growth area and strength, asking for a trend and rating.
(3) Capture your open observations and surface additional signals from the People file.
(4) Generate a shareable check-in doc and save it to the People folder.
Triggers
"performance check-in for X", "perf check-in for X", "let's do a performance check-in on X"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| None | Vault files only (People folder + prior reviews) | — |
Vault structure expected
• People folder with one file per direct report
• Latest annual review and any prior check-in docs for each person
Adaptation guide
To build your own:
• Anchor on the last formal review so the check-in tracks against real goals
• Make it interactive — your rating and observations are the substance
• Keep growth areas and strengths balanced so it's not only corrective
• Save the output where you'll find it before the next 1:1
Minimal viable version
Must-have: Prior-review load, per-area prompt, shareable doc
Nice-to-have: Trend tracking, People-file signal surfacing
Can-skip: Rating scales, auto-scheduling the conversation
24. Meeting Debrief — Debrief any meeting into the Second Brain
What it does
The generalized version of 1:1 Debrief. Works for any meeting format — 1:1s, group sessions, panels, workshops, skip-levels. Pulls the Granola notes, routes insights into topic notes and People files, flags data corrections and new topic candidates, and routes development signals into a set of development-area diaries. Two modes: Quick (auto-route, no questions) and Deep (gut-feel color + full debrief).
How it works
(1) Find the meeting in Granola and pull the summary or transcript.
(2) Scan the notes for inline @Claude: directives (ignore, confidential, only [person], no top of mind) and apply them before anything else.
(3) Load context: person pre-check across vault, Drive, Gmail, and Slack; map which active topics are touched.
(4) Extract development signals and map each to the relevant development area.
(5) In Deep mode, ask 2-3 targeted gut-feel questions.
(6) Present a routing plan and wait for confirmation before writing anything.
(7) Apply updates to topic notes, People files, commitments, and development diaries, then note it for the daily log.
Triggers
"debrief my meeting with X", "process my meeting with X", "what came out of my session with X", "long meeting with X just now"
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Granola | Pull meeting notes and transcripts | Recommended |
| Gmail, Slack, Drive | Person pre-check and post-meeting follow-ups | Optional |
Vault structure expected
• Topic Notes folder (active strategic topics)
• People folder (per-person context files)
• Development diaries (one file per development area)
• Daily Log and a MANIFEST registry for routing
Cross-skill dependencies
• query-second-brain (shared person pre-check and routing logic)
• meeting-prep (upstream — prep before, debrief after)
• weekly-review-5-top-of-mind (honors the "no top of mind" directive)
Adaptation guide
To build your own:
• Start from a 1:1 debrief and widen it to handle group attribution (laptop mics mostly catch your own voice — treat other speakers with caution)
• Define inline note directives so you can override behavior from inside your notes
• Decide which development areas you track and route signals to them
• Always present a routing plan before writing, so you stay in control
Minimal viable version
Must-have: Note pull, topic routing, People file updates, routing-plan confirmation
Nice-to-have: Development-signal routing, inline directives, Deep mode questions
Can-skip: New topic detection, multi-source person pre-check
25. What's Shipped Reader — Turns a recurring product newsletter into a short pre-read
What it does
Reads a long, recurring product or status newsletter and turns it into a five-minute pre-read. It produces a ranked list of big wins, a per-team red/amber/green “say-do” rating (did the team ship what it planned in the previous edition), the strategic learnings grouped by theme, and draft inline comments. The comments are never posted automatically.
How it works
(1) Resolve the target edition — from a link you paste, or by finding the latest one — and identify the previous edition to compare against.
(2) List your active topics and projects so “big for you” is judged against what you actually care about.
(3) Hand both editions to a subagent that holds the full text outside the main session, so the token budget stays intact.
(4) The subagent matches the previous edition’s “planned” items against this edition’s “shipped” items per team and returns each say-do row with an evidence trail, an over-inclusive big-win candidate list, and pre-clustered learning themes.
(5) The main session makes the final “big for me” cut, drafts comments in an ask-don’t-assert register, and assembles one markdown brief.
(6) A team that silently drops a commitment scores worse than one that openly flags the change, so transparency is rewarded. Comments are posted to the source only if you approve them one by one.
Triggers
“read the what’s shipped”, “brief me on what’s shipped”, “analyze the shipped newsletter”, “big wins from the newsletter”, or pasting a link to the newsletter
Dependencies
| Connector | Used for | Required |
|---|---|---|
| Confluence (or wherever the newsletter lives) | Fetch the current and previous editions | Required |
| Vault (topic/project folders) | Judge “big for me” against your active work | Recommended |
Vault structure expected
• Active projects/topics folder (to weight big wins toward what you care about)
• An output folder where each brief is saved and dated
Cross-skill dependencies
• query-second-brain (supplies the active-topic context used to weight big wins)
• okr-review (overlaps on off-track and at-risk signals)
Adaptation guide
To build your own:
• Point it at whatever long, recurring update you receive — a product newsletter, an ops review, a board pack
• Define the say-do rule for your source: match what was planned last time against what was delivered this time
• Keep the heavy extraction in a subagent so the full document never enters the main session
• Keep the final judgment and the writing voice in the main session, where your priorities live
Minimal viable version
Must-have: Fetch the edition, rank big wins, produce one markdown brief
Nice-to-have: Say-do red/amber/green rating, inline draft comments with jump-to anchors
Can-skip: The subagent split (only needed once the document is large enough to threaten the token budget)