jorgex-stack 1.1.2 → 1.2.1

package/stack/skills/mcp-builder/reference/evaluation.md

@@ -381,16 +381,13 @@ After creating your evaluation file, you can use the provided evaluation harness
 
 ## Setup
 
-1. **Install Dependencies**
+1. **Prepare a locked Python environment**
 
-   ```bash
-   pip install -r scripts/requirements.txt
-   ```
-
-   Or install manually:
-   ```bash
-   pip install anthropic mcp
-   ```
+   Use a project-managed virtual environment whose complete transitive lock and
+   hashes have already been reviewed. The requirements file records the direct
+   versions expected by the harness, but it is not a complete lock and this
+   skill must not install from it. If the environment is unavailable, stop and
+   return control to the user.
 
 2. **Set API Key**
 
@@ -550,12 +547,8 @@ Here's a complete example of creating and running an evaluation:
 </evaluation>
 ```
 
-2. **Install dependencies**:
-
-```bash
-pip install -r scripts/requirements.txt
-export ANTHROPIC_API_KEY=your_api_key
-```
+2. **Activate the pre-provisioned locked environment**, then provide the API key
+   through the project's normal secret-management workflow.
 
 3. **Run evaluation**:
 
@@ -599,4 +592,4 @@ If tasks are timing out:
 - Use a more capable model (e.g., `claude-3-7-sonnet-20250219`)
 - Check if tools are returning too much data
 - Verify pagination is working correctly
-- Consider simplifying complex questions
+- Consider simplifying complex questions

package/stack/skills/mcp-builder/reference/node_mcp_server.md

@@ -901,16 +901,19 @@ Always build your TypeScript code before running:
 
 ```bash
 # Build the project
-npm run build
+pnpm run build
 
 # Run the server
-npm start
+pnpm start
 
 # Development with auto-reload
-npm run dev
+pnpm run dev
 ```
 
-Always ensure `npm run build` completes successfully before considering the implementation complete.
+Always ensure `pnpm run build` completes successfully before considering the
+implementation complete. These commands must resolve the project's declared
+dependencies through its lockfile; do not fetch an unpinned tool while
+working on the server.
 
 ## Quality Checklist
 
@@ -963,8 +966,8 @@ Before finalizing your Node/TypeScript MCP server implementation, ensure:
 - [ ] Return types are consistent across similar operations
 
 ### Testing and Build
-- [ ] `npm run build` completes successfully without errors
+- [ ] `pnpm run build` completes successfully without errors
 - [ ] dist/index.js created and executable
 - [ ] Server runs: `node dist/index.js --help`
 - [ ] All imports resolve correctly
-- [ ] Sample tool calls work as expected
+- [ ] Sample tool calls work as expected

package/stack/skills/mcp-builder/scripts/requirements.txt

@@ -1,2 +1,2 @@
-anthropic>=0.39.0
-mcp>=1.1.0
+anthropic==0.39.0
+mcp==1.1.0

package/stack/skills/playwright-cli/SKILL.md

@@ -345,13 +345,13 @@ playwright-cli kill-all
 If the global `playwright-cli` command is not available, use the pinned release with pnpm:
 
 ```bash
-pnpm dlx @playwright/cli@0.1.17 --version
+pnpm dlx @playwright/cli@0.1.18 --version
 ```
 
 For a global command, install the pinned release:
 
 ```bash
-pnpm add --global @playwright/cli@0.1.17
+pnpm add --global @playwright/cli@0.1.18
 ```
 
 ## Example: Form submission

package/stack/skills/playwright-cli/references/test-generation.md

@@ -153,11 +153,10 @@ test -f playwright.config.ts || test -f playwright.config.js
 pnpm exec playwright --version
 ```
 
-If there is no Playwright install, bootstrap one and let the user pick the defaults:
-
-```bash
-pnpm create playwright
-```
+If there is no project-local Playwright install, stop and return control to the
+user. This skill does not bootstrap packages or change the dependency graph;
+the project must provision a reviewed exact version through its normal locked
+dependency workflow before planning or generating tests.
 
 ### 1.2 Prerequisite: seed test
 
@@ -290,12 +289,12 @@ Goal: take a spec file and produce Playwright test files. Optionally update the
 
 ### 2.2 Generate one scenario
 
-For each target scenario, in sequence (never in parallel — scenarios share the seed session):
+For each target scenario, run the CLI actions in sequence within its own seed session. Never run actions in parallel within one attached session; a seed session is single-threaded.
 
 ```bash
 PLAYWRIGHT_HTML_OPEN=never pnpm exec playwright test <seed-file> --debug=cli   # background
 playwright-cli attach tw-XXXX
-# resume
+playwright-cli resume
 ```
 
 **Do not** just open the app url with playwright-cli, always go through the test to capture any custom setup done there.
@@ -349,7 +348,7 @@ Rules:
 
 ### 2.3 Generate multiple scenarios
 
-Loop 2.2 over the targeted scenarios one at a time, restarting the seed between each so every test starts from a clean page. This is safe to parallelise due to unique generated session names - just make sure each test run is stopped.
+Loop 2.2 over the targeted scenarios, restarting the seed between each so every test starts from a clean page. Scenarios may run in parallel only when each has its own seed process and unique generated session name; never share a session or attach two scenario flows to the same seed. When isolation is uncertain, run scenarios serially. Stop every test run before moving on.
 
 ### 2.4 Run generated tests
 

package/stack/skills/react-doctor/SKILL.md

@@ -10,10 +10,21 @@ Scans your React codebase for security, performance, correctness, and architectu
 
 ## Usage
 
+Run the project-pinned binary through the project's package manager:
+
 ```bash
-npx -y react-doctor@latest . --verbose --diff
+pnpm exec react-doctor . --verbose --diff
 ```
 
+`pnpm exec` resolves the binary from the current project's declared
+dependencies or workspace. It does not fetch an ad-hoc release and this skill
+does not modify `package.json`, the lockfile, or any global tool directory.
+
+If the command is unavailable, stop and return control to the user with a
+clear message that the project dependency is missing. The user can review and
+provision an exact project version through the normal dependency workflow,
+then rerun this skill.
+
 ## Workflow
 
 Run after making changes to catch issues early. Fix errors first, then re-run to verify the score improved.

package/stack/skills/skill-creator/LICENSE.txt

@@ -187,7 +187,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright [yyyy] [name of copyright owner]
+   Copyright 2026 Anthropic, PBC.
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
@@ -199,4 +199,4 @@
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
-   limitations under the License.
+   limitations under the License.

package/stack/skills/supabase/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: supabase
-description: "Use when doing ANY task involving Supabase. Triggers: Supabase products (Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, Queues); client libraries and SSR integrations (supabase-js, @supabase/ssr) in Next.js, React, SvelteKit, Astro, Remix; auth issues (login, logout, sessions, JWT, cookies, getSession, getUser, getClaims, RLS); Supabase CLI or MCP server; schema changes, migrations, security audits, Postgres extensions (pg_graphql, pg_cron, pg_vector)."
+description: "Use for any Supabase task: Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, Queues, clients, CLI/MCP, schema/migrations/declarative schemas, RLS/security, debugging, errors, troubleshooting, or logs."
 metadata:
   author: supabase
   version: "0.1.2"
@@ -88,7 +88,7 @@ supabase <group> <command> --help  # Flags for a specific command
 
 - `supabase db query` requires **CLI v2.79.0+** → use MCP `execute_sql` or `psql` as fallback
 - `supabase db advisors` requires **CLI v2.81.3+** → use MCP `get_advisors` as fallback
-- When you need a new migration SQL file, **always** create it with `supabase migration new <name>` first. Never invent a migration filename or rely on memory for the expected format.
+- In imperative migration projects, create new hand-authored migration files with `supabase migration new <name>` first. Never invent a migration filename or rely on memory for the expected format. Declarative schema projects generate migrations from `supabase/schemas/`; see "Making and Committing Schema Changes" below.
 
 **Version check and upgrade:** Run `supabase --version` to check. For CLI changelogs and version-specific features, consult the [CLI documentation](https://supabase.com/docs/reference/cli/introduction) or [GitHub releases](https://github.com/supabase/cli/releases).
 
@@ -118,16 +118,42 @@ Before implementing any Supabase feature, find the relevant documentation. Use t
 
 ## Making and Committing Schema Changes
 
-**To make schema changes, use `execute_sql` (MCP) or `supabase db query` (CLI).** These run SQL directly on the database without creating migration history entries, so you can iterate freely and generate a clean migration when ready.
+Choose one project-level schema workflow before editing. Do not mix declarative schema files and hand-authored migrations for the same change.
 
-Do NOT use `apply_migration` to change a local database schema — it writes a migration history entry on every call, which means you can't iterate, and `supabase db diff` / `supabase db pull` will produce empty or conflicting diffs. If you use it, you'll be stuck with whatever SQL you passed on the first try.
+### Option A: Declarative schemas
 
-**When ready to commit** your changes to a migration file:
+Use this when `supabase/schemas/` exists or `[db.migrations].schema_paths` is configured. The schema files are the source of truth; do not make the change directly in Studio, the SQL editor, or through `execute_sql`.
 
-1. **Run advisors** → `supabase db advisors` (CLI v2.81.3+) or MCP `get_advisors`. Fix any issues.
-2. **Review the Security Checklist above** if your changes involve views, functions, triggers, or storage.
-3. **Generate the migration** → `supabase db pull <descriptive-name> --local --yes`
-4. **Verify** → `supabase migration list --local`
+1. Edit the desired state in `supabase/schemas/`.
+2. Generate a migration from that state → `supabase db diff -f <descriptive-name>`.
+3. Review the generated migration for one incremental change and any destructive SQL.
+4. Verify the full chain → `supabase db reset` (or apply pending migrations to a running local database with `supabase migration up`).
+5. Commit the schema files and generated migration together.
+
+`supabase db diff` does not read the live database. Changes made directly to a database are not captured by the declarative diff. DML and other documented schema-diff limitations belong in a versioned imperative migration instead. See the [Declarative database schemas guide](https://supabase.com/docs/guides/local-development/declarative-database-schemas).
+
+### Option B: Imperative migrations
+
+Use this when the project does not use declarative schemas.
+
+1. Create the migration → `supabase migration new <descriptive-name>`.
+2. Add the SQL to the generated file; never invent a migration filename or rely on memory for its format.
+3. Verify the full chain → `supabase db reset` (or use `supabase migration up` when applying pending migrations to a running local database).
+4. Run advisors, review the Security Checklist above when applicable, and commit the migration.
+
+For an interactive experiment, target the local development database explicitly (for example, use `supabase db query` in the local project). Do not use the stack's default remote Supabase MCP for local iteration. If a local DDL experiment is the intended change, capture it with `supabase db diff -f <descriptive-name>` and review the migration; DML must be written explicitly into a versioned imperative migration because schema diff does not capture it. Otherwise reset or discard the experiment before starting the migration. Do not use `supabase db pull` for local changes. `supabase db pull` is for pulling a linked remote schema into a local migration.
+
+Do NOT use `apply_migration` to change a local database schema — it writes a migration history entry on every call, which prevents iterative work and can leave the migration history inconsistent. If you use it, you are stuck with whatever SQL you passed on the first try.
+
+When a migration is ready, `supabase db advisors` (CLI v2.81.3+) or MCP `get_advisors` can check the resulting database. Fix findings before committing, then use `supabase migration list --local` when you need to compare local and remote migration history.
+
+## Debugging
+
+When you get an error on a Supabase-related request, for example an error code from the Supabase REST API, Postgres database, or PostgREST, an empty result, getting blocked by RLS unexpectedly, or an error from a Supabase service like Auth, Realtime, Edge Functions, or Storage, you **must** fetch Supabase's [Monitoring and Debugging](https://supabase.com/docs/guides/monitoring-and-debugging.md) documentation before diagnosing or proposing a fix, rather than working from memory. The same docs also cover performance optimizations, such as slow queries and missing indexes.
+
+If the documentation or MCP is unavailable (offline or unauthenticated), explicitly label the result as an **offline fallback**. Use only checked-in guidance, local project evidence, and commands confirmed with `supabase --help`; do not guess version-specific behavior or run an unverified mutation. If the available evidence is insufficient, stop and ask for the missing context.
+
+Before inspecting, querying, or sharing logs and errors, redact API keys, access tokens, JWTs, cookies, authorization headers, connection strings, and sensitive request or user payloads. Never print or paste secrets.
 
 ## Reference Guides
 

package/stack/skills/supabase-postgres-best-practices/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: supabase-postgres-best-practices
-description: Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.
+description: "Use for Postgres work: schema design, migrations, declarative schemas, RLS, queries, performance, indexes, locks, triggers, functions, jobs, pgvector, imports/restores, or diagnosing timeouts and connection issues."
 license: MIT
 metadata:
   author: supabase

package/stack/skills/tdd/SKILL.md

@@ -47,6 +47,10 @@ Use the cheapest seam that can fail for the real regression:
 
 “Integration-style” is not inherently stronger. A broad test full of mocks may be weaker than a focused rule test, while a regex over SQL text is weaker than executing the database behavior it claims to protect.
 
+## Anti-pattern: tautological tests
+
+Do not let an assertion recompute the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, or a constant asserted equal to itself). It passes by construction and can never disagree with the code. Expected values must come from an independent source of truth: a known-good literal, a worked example, or the spec.
+
 ## Anti-pattern: horizontal slices
 
 Do not write all tests first and then all implementation. This outruns what has been learned and encourages tests of imagined shapes.

package/stack/skills/to-issues/SKILL.md

@@ -19,6 +19,8 @@ Work from whatever is already in the conversation context. If the user passes an
 
 If you have not already explored the codebase, do so to understand the current state of the code. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
 
+Look for opportunities to prefactor the code to make the implementation easier. If a prefactoring is useful but optional, record it explicitly in the plan; if selected, publish it as its own issue before the slices that depend on it. "Make the change easy, then make the easy change."
+
 ### 3. Draft vertical slices
 
 Break the plan into **tracer bullet** issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
@@ -28,9 +30,21 @@ Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an
 <vertical-slice-rules>
 - Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
 - A completed slice is demoable or verifiable on its own
+- Each slice is sized to fit in a single fresh context window
 - Prefer many thin slices over few thick ones
+- Any selected prefactoring should be completed first and block the dependent slices
 </vertical-slice-rules>
 
+Give each issue its **blocking edges**: the other issues that must complete before it can start. An issue with no blockers can start immediately. Keep the same edges in the project plan and the issue tracker.
+
+**Wide refactors are the exception to vertical slicing.** A **wide refactor** is one mechanical change (for example, renaming a column or retyping a shared symbol) whose **blast radius** fans across the codebase, so a single edit breaks many call sites at once and no vertical slice can land green. Sequence it as **expand–contract**:
+
+1. **Expand:** add the new form beside the old so nothing breaks.
+2. **Migrate:** move call sites in batches sized by blast radius (for example, per package or directory), each as its own issue blocked by the expand issue, keeping the project green batch to batch while the old form still exists.
+3. **Contract:** delete the old form once no caller remains, in an issue blocked by every migration batch.
+
+When even the migration batches cannot stay green alone, keep the sequence but use an integration branch that all batches block, followed by a final integrate-and-verify issue; green is promised only there.
+
 ### 4. Quiz the user
 
 Present the proposed breakdown as a numbered list. For each slice, show:
@@ -43,7 +57,7 @@ Present the proposed breakdown as a numbered list. For each slice, show:
 Ask the user:
 
 - Does the granularity feel right? (too coarse / too fine)
-- Are the dependency relationships correct?
+- Are the blocking edges correct: does each slice only depend on issues that genuinely gate it?
 - Should any slices be merged or split further?
 - Are the correct slices marked as HITL and AFK?
 

package/upstreams.json

@@ -1,5 +1,5 @@
 {
-  "$comment": "Terceros gestionados por `jorgex-stack update`: fuente, versión conocida y política. `commit` = pin del upstream en la última revisión aceptada (2026-06-11, auditoría de seguridad): update --check compara el HEAD del repo contra el pin y avisa si se movió; cualquier actualización de la copia vendorizada se hace con diff manual y re-pin deliberado, nunca a ciegas. El pin es del repo completo (no por path): en monorepos activos un pin movido no implica que la skill cambiara — el diff lo confirma. Las skills 'modified: true' tienen cambios locales respecto al upstream — update debe hacer diff/aviso, NUNCA reemplazo ciego (PRD §7.3). Skills propias sin upstream (no se actualizan desde fuera): agent-delegation, work-lifecycle. `path` = ruta dentro del repo upstream donde vive la skill (para diff/descarga quirúrgica). `kind: \"release\"` = la actualización se compara contra tags de release en vez de HEAD (e.g. paquetes Python sin SKILL.md en repo).",
+  "$comment": "Terceros gestionados por `jorgex-stack update`: fuente, versión conocida y política. `commit` = pin del upstream en la última revisión aceptada (2026-06-11, auditoría de seguridad): update --check compara el HEAD del repo contra el pin y avisa si se movió; cualquier actualización de la copia vendorizada se hace con diff manual y re-pin deliberado, nunca a ciegas. El pin es del repo completo (no por path): en monorepos activos un pin movido no implica que la skill cambiara — el diff lo confirma. Las skills 'modified: true' tienen cambios locales respecto al upstream — update debe hacer diff/aviso, NUNCA reemplazo ciego (PRD §7.3). Skills propias sin upstream (no se actualizan desde fuera): agent-delegation, lean-code, orchestrator, work-lifecycle y xreview. `path` = ruta dentro del repo upstream donde vive la skill (para diff/descarga quirúrgica). `kind: \"release\"` = la actualización se compara contra tags de release en vez de HEAD (e.g. paquetes Python sin SKILL.md en repo).",
   "tools": {
     "engram": {
       "kind": "binary",
@@ -14,84 +14,87 @@
       "path": "skills/playwright-cli",
       "package": "@playwright/cli",
       "binary": "playwright-cli",
-      "version": "0.1.17",
-      "commit": "793cfb32572733cbcb401e6f28d05a7a914ce408",
+      "version": "0.1.18",
+      "commit": "2f85a94b7b885dbf4a5d34462f253a8746a690c9",
       "license": "Apache-2.0",
-      "modified": true
+      "modified": true,
+      "note": "bundle release firmado 0.1.18 en ca196c297169a494ee5517584883eada60dc8d0e; el pin commit es el HEAD revisado del repo"
     },
     "deploy-to-vercel": {
       "source": "github:vercel-labs/agent-skills",
       "path": "skills/deploy-to-vercel",
       "version": "3.0.0",
-      "commit": "f8a72b9603728bb92a217a879b7e62e43ad76c81",
+      "commit": "dd089a8c752c966dee8bf0f27cb625ba193ffd9e",
+      "modified": true,
       "note": "por diseño empaqueta el proyecto entero (tarball) y lo sube a un endpoint de Vercel para desplegarlo; excluye .env/.env.*/.git/node_modules"
     },
     "diagnose": {
       "source": "github:mattpocock/skills",
       "path": "skills/engineering/diagnosing-bugs",
-      "commit": "694fa30311e02c2639942308513555e61ee84a6f",
-      "note": "upstream renombró la carpeta diagnose → diagnosing-bugs; mantenemos el nombre local 'diagnose'. El pin sigue en la última revisión aceptada hasta hacer diff y re-pin deliberado del contenido nuevo."
+      "commit": "5b15a47f2d7150f545fbcacbfe381787fc0230dc",
+      "modified": true,
+      "note": "upstream renombró la carpeta diagnose → diagnosing-bugs; mantenemos el nombre y las adaptaciones locales sobre el HEAD revisado"
     },
     "find-skills": {
       "source": "github:vercel-labs/skills",
       "path": "skills/find-skills",
-      "commit": "be0dd25b4a8665894a56f45ef582cc02ca802c39"
+      "commit": "435076e78988e1e6ec40d00b0b1d76bdbbc5419a",
+      "modified": true,
+      "note": "la copia vendorizada se limita a descubrir skills; no acepta ni ejecuta instalación, actualización o inicialización de contenido upstream"
     },
     "mcp-builder": {
       "source": "github:anthropics/skills",
       "path": "skills/mcp-builder",
-      "commit": "57546260929473d4e0d1c1bb75297be2fdfa1949",
-      "license": "Apache-2.0"
-    },
-    "obsidian-cli": {
-      "source": "github:kepano/obsidian-skills",
-      "path": "skills/obsidian-cli",
-      "commit": "a1dc48e68138490d522c04cbf5822214c6eb1202"
-    },
-    "obsidian-markdown": {
-      "source": "github:kepano/obsidian-skills",
-      "path": "skills/obsidian-markdown",
-      "commit": "a1dc48e68138490d522c04cbf5822214c6eb1202"
+      "commit": "3b3fad96af16a10759d930941b4520ba0c40edae",
+      "license": "Apache-2.0",
+      "modified": true
     },
     "react-doctor": {
       "source": "github:millionco/react-doctor",
       "path": "skills/react-doctor",
-      "commit": "a48fb06ffbe7221655e18529fcc954ecae17a22f"
+      "commit": "e183c3519010599d929ed14d99a18bf1f8f8a44c",
+      "modified": true
     },
     "skill-creator": {
       "source": "github:anthropics/skills",
       "path": "skills/skill-creator",
-      "commit": "57546260929473d4e0d1c1bb75297be2fdfa1949",
-      "license": "Apache-2.0"
+      "commit": "3b3fad96af16a10759d930941b4520ba0c40edae",
+      "license": "Apache-2.0",
+      "modified": true
     },
     "supabase": {
       "source": "github:supabase/agent-skills",
       "path": "skills/supabase",
       "version": "0.1.2",
-      "commit": "1356046015476711a769601079262b5635929427"
+      "commit": "8331f910845103c08d51f6ca1d86ebb7d1f745e3",
+      "modified": true
     },
     "supabase-postgres-best-practices": {
       "source": "github:supabase/agent-skills",
       "path": "skills/supabase-postgres-best-practices",
-      "commit": "1356046015476711a769601079262b5635929427",
-      "license": "MIT"
+      "commit": "8331f910845103c08d51f6ca1d86ebb7d1f745e3",
+      "license": "MIT",
+      "modified": true
     },
     "tdd": {
       "source": "github:mattpocock/skills",
       "path": "skills/engineering/tdd",
-      "commit": "694fa30311e02c2639942308513555e61ee84a6f",
+      "commit": "5b15a47f2d7150f545fbcacbfe381787fc0230dc",
       "modified": true
     },
     "to-issues": {
       "source": "github:mattpocock/skills",
-      "path": "skills/engineering/to-issues",
-      "commit": "694fa30311e02c2639942308513555e61ee84a6f"
+      "path": "skills/engineering/to-tickets",
+      "commit": "5b15a47f2d7150f545fbcacbfe381787fc0230dc",
+      "modified": true,
+      "note": "upstream renombró to-issues → to-tickets; conservamos el nombre y las adaptaciones locales sobre el HEAD revisado"
     },
     "to-prd": {
       "source": "github:mattpocock/skills",
-      "path": "skills/engineering/to-prd",
-      "commit": "694fa30311e02c2639942308513555e61ee84a6f",
-      "modified": true
+      "path": "skills/engineering/to-spec",
+      "commit": "5b15a47f2d7150f545fbcacbfe381787fc0230dc",
+      "modified": true,
+      "note": "upstream renombró to-prd → to-spec; conservamos el contrato D9 v2 local sobre el HEAD revisado"
     }
   }
 }

package/stack/skills/obsidian-cli/SKILL.md

@@ -1,106 +0,0 @@
----
-name: obsidian-cli
-description: Interact with Obsidian vaults using the Obsidian CLI to read, create, search, and manage notes, tasks, properties, and more. Also supports plugin and theme development with commands to reload plugins, run JavaScript, capture errors, take screenshots, and inspect the DOM. Use when the user asks to interact with their Obsidian vault, manage notes, search vault content, perform vault operations from the command line, or develop and debug Obsidian plugins and themes.
----
-
-# Obsidian CLI
-
-Use the `obsidian` CLI to interact with a running Obsidian instance. Requires Obsidian to be open.
-
-## Command reference
-
-Run `obsidian help` to see all available commands. This is always up to date. Full docs: https://help.obsidian.md/cli
-
-## Syntax
-
-**Parameters** take a value with `=`. Quote values with spaces:
-
-```bash
-obsidian create name="My Note" content="Hello world"
-```
-
-**Flags** are boolean switches with no value:
-
-```bash
-obsidian create name="My Note" silent overwrite
-```
-
-For multiline content use `\n` for newline and `\t` for tab.
-
-## File targeting
-
-Many commands accept `file` or `path` to target a file. Without either, the active file is used.
-
-- `file=<name>` — resolves like a wikilink (name only, no path or extension needed)
-- `path=<path>` — exact path from vault root, e.g. `folder/note.md`
-
-## Vault targeting
-
-Commands target the most recently focused vault by default. Use `vault=<name>` as the first parameter to target a specific vault:
-
-```bash
-obsidian vault="My Vault" search query="test"
-```
-
-## Common patterns
-
-```bash
-obsidian read file="My Note"
-obsidian create name="New Note" content="# Hello" template="Template" silent
-obsidian append file="My Note" content="New line"
-obsidian search query="search term" limit=10
-obsidian daily:read
-obsidian daily:append content="- [ ] New task"
-obsidian property:set name="status" value="done" file="My Note"
-obsidian tasks daily todo
-obsidian tags sort=count counts
-obsidian backlinks file="My Note"
-```
-
-Use `--copy` on any command to copy output to clipboard. Use `silent` to prevent files from opening. Use `total` on list commands to get a count.
-
-## Plugin development
-
-### Develop/test cycle
-
-After making code changes to a plugin or theme, follow this workflow:
-
-1. **Reload** the plugin to pick up changes:
-   ```bash
-   obsidian plugin:reload id=my-plugin
-   ```
-2. **Check for errors** — if errors appear, fix and repeat from step 1:
-   ```bash
-   obsidian dev:errors
-   ```
-3. **Verify visually** with a screenshot or DOM inspection:
-   ```bash
-   obsidian dev:screenshot path=screenshot.png
-   obsidian dev:dom selector=".workspace-leaf" text
-   ```
-4. **Check console output** for warnings or unexpected logs:
-   ```bash
-   obsidian dev:console level=error
-   ```
-
-### Additional developer commands
-
-Run JavaScript in the app context:
-
-```bash
-obsidian eval code="app.vault.getFiles().length"
-```
-
-Inspect CSS values:
-
-```bash
-obsidian dev:css selector=".workspace-leaf" prop=background-color
-```
-
-Toggle mobile emulation:
-
-```bash
-obsidian dev:mobile on
-```
-
-Run `obsidian help` to see additional developer commands including CDP and debugger controls.