Rewrite as user-agnostic "quicksilver" plugin
Rename echo-memory/ECHO -> quicksilver/Quicksilver throughout and make the plugin self-configuring per operator: - First-run flow: prompt for endpoint FQDN, API key, and operator name/role; verify; persist to a local config file (~/.quicksilver/quicksilver-config.json). - Two-layer setup detection: local config (is this install configured?) + in-vault marker (is the vault scaffolded?). Key never stored in the vault. - Replace hardcoded endpoint/key in all curl examples with $BASE/$AUTH loaded from the config file. - Genericize all "Jason"/"Bryan goldbrain"/MPM/wISP references to "the operator"; keep Jason as architect credit (README + plugin.json author). - Personalize memory to the configured operator (name/role seeded into operator-preferences and the vault marker). - Add echo-vault.md -> quicksilver-vault.md rename migration. - Rebuild packaged quicksilver.plugin; add docs/quicksilver-plan.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,98 @@
|
||||
# quicksilver
|
||||
|
||||
Persistent memory for Claude via a **Quicksilver** Obsidian vault, using the [Obsidian Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api).
|
||||
|
||||
Reads and writes notes across Claude/CoWork sessions using direct REST calls — no MCP server required. The plugin is operator-agnostic: each install is configured at first run for its own vault and operator.
|
||||
|
||||
*Architecture by Jason Stedwell.*
|
||||
|
||||
**The plugin is the single source of truth.** All control logic — bootstrap/repair, operating contract, taxonomy, frontmatter conventions, and the canonical note templates — ships inside this plugin under `skills/quicksilver/`. The vault itself holds **data only**: there are no `CLAUDE.md` / `BOOTSTRAP.md` / `STRUCTURE.md` / `index.md` control docs in it. This makes Quicksilver self-bootstrapping (point it at an empty Obsidian vault and it stands up the full structure), easy to update (update the plugin, not the vault), and portable to any other vault.
|
||||
|
||||
## What it does
|
||||
|
||||
- Loads operator preferences, current context, and relevant project notes at the start of substantive conversations
|
||||
- Writes facts, preferences, and decisions the operator asks Claude to remember
|
||||
- Logs working sessions so future conversations can pick up where they left off
|
||||
- **Bootstraps an empty vault from the bundled `scaffold/`** (folders, templates, anchor seeds, marker) and repairs/migrates an existing one — see `skills/quicksilver/references/bootstrap.md`
|
||||
|
||||
## First-run configuration
|
||||
|
||||
The plugin ships with **no endpoint or key baked in**. The first time the skill runs, it detects that this install is unconfigured and asks the operator for:
|
||||
|
||||
1. **API endpoint FQDN** — e.g. `https://obsidian.example.com` (the Obsidian Local REST API, typically behind a reverse proxy)
|
||||
2. **API key** — the Local REST API bearer token
|
||||
3. **Operator name + role** — used to personalize memory ("Alex prefers …")
|
||||
|
||||
It verifies the endpoint, then writes a **local config file** at:
|
||||
|
||||
```
|
||||
~/.quicksilver/quicksilver-config.json (macOS/Linux)
|
||||
%USERPROFILE%\.quicksilver\quicksilver-config.json (Windows)
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"schema": 1,
|
||||
"endpoint": "https://obsidian.example.com",
|
||||
"api_key": "<bearer-token>",
|
||||
"operator": { "name": "Alex Rivera", "role": "Network Engineer" },
|
||||
"configured_at": "YYYY-MM-DD",
|
||||
"verified_at": "YYYY-MM-DD"
|
||||
}
|
||||
```
|
||||
|
||||
This file is the install's "is this configured?" signal. It lives in the user home (outside the plugin and the vault), so it survives plugin reinstalls and is never committed. Once it exists, the skill loads silently with no further prompts.
|
||||
|
||||
**The API key is never written into the vault** — only into this local config file (per the vault's own safety rules). The in-vault marker `_agent/quicksilver-vault.md` records the schema version, bootstrap date, and operator name only.
|
||||
|
||||
## Vault layout (root-addressed)
|
||||
|
||||
```
|
||||
/vault/
|
||||
├── README.md ← thin human signpost (not read for routing)
|
||||
├── inbox/ (captures, imports, processing-log)
|
||||
├── journal/ (daily, weekly, monthly, templates)
|
||||
├── projects/ (active, incubating, on-hold, archived)
|
||||
├── areas/ (business, personal, learning, systems)
|
||||
├── resources/ (concepts, references, people, meetings, source-material)
|
||||
├── decisions/ (by-date)
|
||||
├── reviews/ (weekly, monthly, quarterly, annual)
|
||||
├── archive/ (notes, projects, imports)
|
||||
└── _agent/
|
||||
├── quicksilver-vault.md ← bootstrap marker (schema_version + date + operator)
|
||||
├── context/ ← task-scoped context bundles
|
||||
├── memory/ ← working / episodic / semantic
|
||||
├── sessions/ ← YYYY-MM-DD-HHMM-<slug>.md
|
||||
├── templates/ ← canonical note templates (seeded from the plugin's scaffold/)
|
||||
├── outputs/ ← briefs / drafts / summaries / synthesis
|
||||
├── skills/ ← active / archived
|
||||
└── heartbeat/
|
||||
```
|
||||
|
||||
Control logic and the master scaffold live in the plugin, not the vault:
|
||||
|
||||
```
|
||||
skills/quicksilver/
|
||||
├── SKILL.md ← operating procedure (authoritative)
|
||||
├── references/
|
||||
│ ├── operating-contract.md ← durable principles + safety
|
||||
│ ├── bootstrap.md ← first-run config / bootstrap / repair / migrate
|
||||
│ ├── vault-layout.md ← canonical layout + frontmatter
|
||||
│ ├── api-reference.md ← REST endpoint patterns + routing map
|
||||
│ └── session-log-template.md
|
||||
└── scaffold/ ← verbatim files the bootstrap writes into the vault
|
||||
├── README.vault.md quicksilver-vault.md
|
||||
├── templates/ (8 note templates)
|
||||
└── anchors/ (operator-preferences, current-context, inbox seeds)
|
||||
```
|
||||
|
||||
## Skills
|
||||
|
||||
| Skill | Triggers |
|
||||
|-------|----------|
|
||||
| `quicksilver` | "remember that", "save to memory", "what do you know about me", "load my profile", "check my notes", "log this decision", "add to my inbox" — and proactively at the start of substantive conversations |
|
||||
|
||||
## Requirements
|
||||
|
||||
- Obsidian running on the backend with the [Local REST API plugin](https://github.com/coddingtonbear/obsidian-local-rest-api) enabled
|
||||
- HTTPS access to the configured endpoint from the Claude/CoWork session environment
|
||||
Reference in New Issue
Block a user