Initialize any folder as a Bedrock-powered Obsidian vault. Creates entity directories, copies templates, configures language and domain taxonomy, scaffolds connected example entities, and checks dependencies. Use when: "bedrock setup", "bedrock-setup", "/bedrock:setup",
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/setup
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Initialize any folder as a Bedrock-powered Obsidian vault. Creates entity directories, copies templates, configures language and domain taxonomy, scaffolds connected example entities, and checks dependencies. Use when: "bedrock setup", "bedrock-setup", "/bedrock:setup",
📊 Stats
Stars83
Forks8
LanguageHTML
LicenseMIT
📦 Ships with bedrock
</> SKILL.md
setup.SKILL.md
---name: setup
description: >
Initialize any folder as a Bedrock-powered Obsidian vault. Creates entity directories,
copies templates, configures language and domain taxonomy, scaffolds connected example
entities, and checks dependencies.
Use when: "bedrock setup", "bedrock-setup", "/bedrock:setup", "initialize vault",
"setup vault", "create vault", "bootstrap vault", or when a user wants to start
a new Second Brain with Bedrock.
user_invocable: true
allowed-tools: Bash, Read, Write, Glob, Grep
---# /bedrock:setup — Vault Initialization
## Plugin Paths
Templates and entity definitions are in the plugin directory, not in the vault root.
Use the "Base directory for this skill" provided at invocation to resolve paths:
- Entity definitions: `<base_dir>/../../entities/`
- Templates: `<base_dir>/../../templates/{type}/_template.md`
- Plugin CLAUDE.md: `<base_dir>/../../CLAUDE.md` (auto-injected into context)
Where `<base_dir>` is the path shown in "Base directory for this skill".
---## Overview
This skill bootstraps any folder into a fully functional Bedrock-powered Obsidian vault
through an interactive guided flow. It creates directories, copies templates, configures
the vault, scaffolds example entities with bidirectional wikilinks, checks dependencies,
and guides the user through next steps.
**You are a setup agent.** Follow the phases below in order. Do not skip steps.
---
## Phase 0 — Idempotency Check
Check if the vault is already initialized:
```bash
ls .bedrock/config.json 2>/dev/null
```
**If `.bedrock/config.json` exists:**
1. Read and display the current configuration:
```
This vault is already initialized:
- Language: <language>
- Preset: <preset>
- Domains: <domains>
- Git strategy: <git.strategy or "commit-push" if absent>
- Initialized at: <date>
```
2. Check if this vault is registered in the global vault registry:
```bash
cat <base_dir>/../../vaults.json 2>/dev/null
```
If the registry exists, check if any entry has a `path` matching the current working directory.
- **If registered:** display "Registered as vault `<name>`" alongside the config above.
- **If NOT registered:** display "This vault is not yet registered in the global vault registry."
3. Ask the user:
> "This vault is already initialized. What would you like to do?"
> 1. **Reconfigure** — Update language, domains, git strategy, and regenerate vault CLAUDE.md (directories and entities are NOT touched)
> 2. **Register only** — Register this vault in the global registry (if not already registered) without changing configuration
> 3. **Skip** — Exit with no changes
- **Reconfigure**: proceed to Phase 1, but set `RECONFIGURE_MODE = true`. In Phase 3, skip directory creation (3.1), template copying (3.2), Obsidian configuration (3.5), and example entity generation (3.6). Phase 3.7 (vault registration) still runs.
- **Register only**: skip directly to Phase 3.7 (vault registration). If already registered, display "This vault is already registered as `<name>`. No changes made." and exit.
- **Skip**: exit with "No changes made. Vault is already initialized."
**If `.bedrock/config.json` does NOT exist:** proceed to Phase 1 with `RECONFIGURE_MODE = false`.
---
## Phase 1 — Language and Dependencies
### 1.1 Language Selection
Ask the user:
> "What language should vault content be written in?"
| GOOGLE_ACCESS_TOKEN | Bash: `test -n "$GOOGLE_ACCESS_TOKEN"` | Google Docs and Sheets ingestion via `/bedrock:learn` (API strategy). |
| claude-in-chrome MCP | ToolSearch: `select:mcp__claude-in-chrome__tabs_context_mcp` (succeeds = available) | **Optional.** Browser fallback for Confluence pages when API credentials are unavailable. |
### 1.2.1 Auto-install graphify if missing
If the graphify probe in the table above returns no file, attempt to install graphify silently before generating the dependency report. Execute this fallback chain in order, stopping at the first successful re-probe.
If Steps 1 and 2 were both unrunnable because `pipx`, `pip`, and Python 3.10+ are all missing, **warn the user explicitly before falling back:**
> ⚠️ Python 3.10+ is not available on this system. Falling back to manual skill install via `curl`. To receive graphify updates through the official installer, install Python 3.10+ and re-run `/bedrock:setup`.
If all prior steps failed (no network, upstream unavailable, or all tooling missing), print the graphify warning shown in Section 1.2.2 below. Do not abort — setup continues regardless.
**Note on package name:** The PyPI package is currently published as `graphifyy` — temporary while the upstream project reclaims the `graphify` name. When that flip happens, update Steps 1 and 2 to `pip install graphify && graphify install`.
**After the chain completes**, run one final `Glob: ~/.claude/skills/graphify/SKILL.md`. The graphify row in the dependency-report table (Section 1.2.2 below) MUST reflect this post-install status — `installed` if the file now exists, `NOT FOUND` otherwise. Proceed to Section 1.2.2 regardless of outcome. **Never block initialization.**
### 1.2.1.1 Auto-install docling if missing
If the docling probe (`command -v docling`) returns nothing, attempt a silent install using the same fallback chain as graphify. Emit a one-line status message before starting — no interactive prompt.
> docling not found — installing silently (one-time setup; first run may take several minutes to download ML models).
If both steps failed (no `pipx`/`pip`, no network, or a permissions error), print the docling warning shown in Section 1.2.2 below. Do not abort — setup continues regardless.
**After the chain completes**, run one final `command -v docling` probe. The docling row in the dependency-report table (Section 1.2.2 below) MUST reflect this post-install status — `installed` if the command is now on PATH, `NOT FOUND` otherwise. Proceed to Section 1.2.2 regardless of outcome. **Never block initialization.**
### 1.2.2 Report status
**Report format:**
```
## Dependency Check
| Dependency | Status | What it unlocks |
|---|---|---|
| graphify | installed / NOT FOUND | Extraction engine for /learn |
| docling | installed / NOT FOUND | Universal file → markdown converter for /learn |
| Confluence API credentials | configured / NOT SET | Confluence page ingestion (API) |
| Google API token | configured / NOT SET | Google Docs/Sheets ingestion (API) |
| claude-in-chrome MCP | available / NOT FOUND | Browser fallback for Confluence |
### Source availability summary
| Source type | Status | Requirements |
|---|---|---|
| Confluence | ready / partial / unavailable | API credentials or Chrome extension |
| Google Docs | ready / limited / unavailable | API token or public documents only |
| Google Sheets | ready / limited / unavailable | API token (all tabs) or public (first tab only) |
3. Ask: "Would you like me to generate example entities, or skip them?"
- If generate: ask for a team name, 2 people names, an actor name (or use generic defaults: `example-team`, `alice-example`, `bob-example`, `example-service`, `example-topic`, `example-project`)
- If skip: set `SKIP_EXAMPLES = true`
Build a custom preset object following the same structure as the named presets.
For fields not provided by the user, use sensible generic defaults.
### 2.4 Git Strategy Selection
Ask the user:
> "How should Bedrock handle git commits and pushes?"
>
> 1. **commit-push** *(default)* — Commit and push directly to `main` (trunk-based)
> 2. **commit-push-pr** — Commit to a branch, push, and open a pull request targeting `main`
> 3. **commit-only** — Commit locally without pushing (for offline or local-only vaults)
>
> Press Enter for default (commit-push).
Store the selected strategy as `GIT_STRATEGY`.
**If the user selects `commit-push-pr`:**
Check if the `gh` CLI is available:
```bash
which gh 2>/dev/null
```
If `gh` is not found, warn:
```
> ⚠️ The `gh` CLI is not installed. The `commit-push-pr` strategy requires it to create pull requests.
> Install it from https://cli.github.com/ before using /bedrock:preserve, /bedrock:compress, or /bedrock:sync.
>
> You can still select this strategy — skills will fall back to `commit-push` if `gh` is not available at runtime.
```
Proceed regardless — never block initialization for missing tools.
---
## Phase 3 — Scaffold
### 3.1 Create Entity Directories
> **Skip if `RECONFIGURE_MODE = true`.**
Create all 7 entity directories:
```bash
mkdir -p actors people teams topics discussions projects fleeting
```
If any directory already exists, this is a no-op (safe).
### 3.2 Copy Templates
> **Skip if `RECONFIGURE_MODE = true`.**
For each entity type, read the template from the plugin and write it to the vault:
1. Use Read to read the source file from the plugin directory
2. Use Write to write it to the vault directory
**Copy templates verbatim.** Do not translate or modify them.
If a `_template.md` already exists in the destination, **overwrite it** — templates should
always match the latest plugin version.
> **Fallback:** If a template file cannot be read (path resolution fails), report:
> "Could not copy template for `<type>`. You can manually copy it from the plugin's
> `templates/<type>/_template.md` directory."
### 3.3 Create `.bedrock/config.json`
Create the `.bedrock/` directory and write the configuration:
```bash
mkdir -p .bedrock
```
Write `.bedrock/config.json` with this schema:
```json
{
"version": "1.0.0",
"language": "<VAULT_LANGUAGE>",
"preset": "<selected preset name>",
"domains": ["<domain1>", "<domain2>", "..."],
"git": {
"strategy": "<GIT_STRATEGY>"
},
"initialized_at": "<today's date YYYY-MM-DD>",
"initialized_by": "init@agent"
}
```
**Field definitions:**
- `version`: Always `"1.0.0"` — schema version for future migrations
- `language`: The language code from Phase 1 (e.g., `"en-US"`, `"pt-BR"`)
- `preset`: The selected preset name (e.g., `"engineering"`, `"personal"`, `"custom"`)
- `domains`: Array of domain strings resolved from the preset
- `git.strategy`: The git strategy from Phase 2.3. Valid values: `"commit-push"`, `"commit-push-pr"`, `"commit-only"`. If omitted, defaults to `"commit-push"`.
- `initialized_at`: Today's date in `YYYY-MM-DD` format
- `initialized_by`: Always `"init@agent"`
### 3.4 Generate Vault CLAUDE.md
Write a `CLAUDE.md` file at the vault root with content tailored to the selected preset and language.
**IMPORTANT:** This file describes THIS SPECIFIC VAULT — its purpose, language, and conventions.
It does NOT duplicate the plugin's CLAUDE.md (which covers writing rules, entity types, tags, git workflow, and zettelkasten principles — all auto-loaded by Claude Code when the plugin is active).
**Template for vault CLAUDE.md:**
```markdown
# <Vault Name> — CLAUDE.md
> This vault is powered by the [Bedrock plugin](https://github.com/iurykrieger/claude-bedrock).
