Vault Boot — Teslasoft Cowork Session Loader

This skill eliminates the multi-step cold-start problem when beginning a new Cowork session. Instead of 10+ sequential tool calls to piece together vault state, this procedure loads everything in two parallel batches and renders a single status briefing.

When to Use

Session start: Every new Cowork session involving the Teslasoft vault
Context recovery: After a long pause or context window rotation
Status check: When the user asks "was steht an?" or wants a project overview
Before deep work: To orient yourself before diving into a specific project

When NOT to Use

Mid-session when context is already loaded (just re-read specific files)
For Jarvis-specific commands (use /jarvis skill instead if drone is running)
For git operations or file modifications

Prerequisites

The Obsidian MCP server must be connected and serving the Teslasoft vault. If obsidian_get_file_contents calls fail, fall back to direct file reads from the vault root directory.

Procedure

Step 1 — Parallel Core Load (single tool-call turn)

Fire ALL of these obsidian_get_file_contents calls in one parallel batch:

#	File	Purpose
1	`TASKS.md`	Active/waiting/someday tasks
2	`PROJECT_STATE.md`	Goal status, active projects, KRs, constraints
3	`AGENTS.md`	Vault conventions, PARA structure, edit rules
4	`coordination/harness-control.md`	Thread control, active threads, CI-001
5	`coordination/improvement-queue.md`	Pending improvements, recent implementations
6	`coordination/policies/policies.index.yaml`	Active policy catalog

That is 6 parallel calls in a single message. This is the most important optimization — it replaces 6 sequential round-trips with 1.

Step 2 — Parallel Extended Load (single tool-call turn)

After Step 1 completes, fire these calls in parallel:

#	Call	Purpose
7	`obsidian_list_files_in_dir("coordination/threads")`	Active thread specs
8	`obsidian_list_files_in_dir("coordination/agent-state")`	Agent state files
9	`obsidian_list_files_in_dir("00_Inbox")`	Inbox item count
10	`obsidian_get_file_contents("Dashboard.md")`	Dataview queries reference

Step 3 — Open Dashboard

Open the dashboard in the default browser using a platform-appropriate command:

In Claude Code sessions (WSL), use:

cmd.exe /c start "" "$(wslpath -w '00_Dashboard/dashboard.html')"

In Windows Shell, use:

Start-Process "00_Dashboard\dashboard.html"

If neither is available, note the path 00_Dashboard/dashboard.html for manual opening.

This is non-blocking and takes <1 second. Do NOT wait for Chrome tab context or navigate via Chrome MCP — the shell approach is faster and more reliable.

Step 4 — Render Status Briefing

Compile the loaded data into this exact template. Keep it concise — the user can drill down into any area on request.

## Teslasoft Vault — Status ({date})

**Goal Q1 2026:** {goal_description}
| KR | Status | Project |
|----|--------|---------|
| {kr1} | {status} | {project_link} |
| {kr2} | {status} | {project_link} |
| {kr3} | {status} | {project_link} |

**Active Tasks:**
{render each active task from TASKS.md as a bullet}

**Blocked:** {list blocked tasks with reason}

**Harness:** {master_switch on/off}, {N} active threads, {N} archived
**Inbox:** {N} items
**Improvements:** {N} pending, {N} implemented this week
**Policies:** {N} active ({list key policy IDs})

**Dashboard:** Opened in browser

Step 5 — Ready Prompt

End with a brief ready message in the user's language (German for Christian):

Kontext geladen. Womit moechtest du weitermachen?

If active threads or P0/P1 alerts exist, surface them prominently before the ready prompt.

Fallback Strategy

If Obsidian MCP is unreachable or timing out:

Try direct reads: Read files from the vault root directory with timeout 10s
Partial boot: If some files fail, render what you have and note which sections are missing
Never block: A partial briefing is better than no briefing. Present what loaded and offer to retry failed sections.

Performance Target

The entire boot procedure should complete in 2 tool-call turns (Steps 1+2 as parallel batches) plus 1 turn for the dashboard + rendering. Total wall time target: < 15 seconds, down from ~60 seconds with sequential loading.

Internals for Context

These are facts about the vault that help you interpret the loaded data correctly. You don't need to present these to the user, but they inform your understanding.

PARA structure: 00_Inbox, 10_Goals, 20_Projects, 30_Areas, 40_Resources, 50_Collab, 60_Science, 70_Skills, 90_Archive
Language convention: Goal/project names are German, technical content English
Thread IDs: Format T-P{project}-{role_initial}{N} (e.g., T-P38-T9)
Session numbering: monotonically increasing across all projects
Drone service: localhost:3737 (may not be running in Cowork context)

vault-boot