dimeloper

mcp-per-project

Set up or fix per-project MCP isolation in Cursor and Claude Code, so concurrent agent sessions for different products (e.g. Acme vs Globex vs Initech) each get their own Railway, Postgres, Logfire, PostHog, etc. Use when the user mentions MCP bleed across projects, global mcp.json pollution, multiple Railway accounts/tokens on one machine, wants project-scoped MCP servers, or when onboarding a product repo (invoked from the onboard-repo skill).

check-follow-ups

Scan recent daily notes' Follow-ups sections and report what's still open, oldest first, leading with the ones for the repo you're in — plus anything ticked as dropped or handed off, which is closed without being finished. Read-only — walks back to the last real notes, so it survives a weekend, a holiday, or a vacation gap without missing anything, and it groups by repo rather than filtering, so nothing is hidden. Use when the user asks to check my tasks, check follow ups, what's pending, what do I still need to do, or any open items.

update-second-brain

Capture the current agent session's work into the Obsidian "second brain" vault and publish it: append to today's daily note, revise the project docs the session moved, propose and promote engineering practice notes, then commit and push. Runs from inside the working repo; the vault lives elsewhere. Use when the user says update second brain, update my second brain, capture this session, log this to second brain, second brain this, publish second brain, commit the vault, push practices, or backfill project docs.

onboard-repo

Onboard a Cursor repo into the hot-path/cold-path standards system: sync second-brain-workflow rules, add a thin always-apply onboarding rule, point at relevant second-brain practices, and wire project-scoped MCP (Railway / Postgres / Logfire / PostHog) — never global mcp.json. Use when the user says onboard repo, onboard this repo, set up cursor standards, sync rules into this project, or wire best practices into a new codebase. Covers quiet onboarding too — rendering into a repo you do not own, so the rules work locally and the remote never sees them: use when the user says render this quietly, keep it out of the remote, don't commit the rules, onboard someone else's repo, or local only.

obsidian-knowledge-base

Read the Obsidian vault and score current work against it — load this repo's project context, find the practice notes that apply to this stack, cite what was followed, and name drift and gaps. Read-only. Use before large or unfamiliar changes, when the user asks what the vault says about something or about this project, or as the review half of feature complete / wrap up the feature. Writing to the vault is the update-second-brain skill's job, never this one.

Data & Documents Listed

extract-product-context

Draft a project's context/ — audience, voice, brand — from a product repo's own files rather than from memory, daily notes or store copy. Read-only. Use when writing or revising context/ for a project doc, when asked who a product is for, what it sounds like, or where it stops, or before writing anything public about a product. Writing to the vault is the update-second-brain skill's job, never this one.

unrender-repo

Retire a repo from the standards system: remove the rule files a render put there, drop the local exclusion block, and forget the repo so doctor stops reporting it. Preview first, act only on --yes. Use when the user says unrender, un-onboard, retire this repo, remove the rendered rules, stop tracking this repo, take the standards out of here, or is abandoning a repo that doctor keeps naming. Not for deleting a repo — this leaves the repo intact and removes only what the engine put in it.