New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Obsidian Services

by aidenlx in aidenlx/zotlit

Service architecture patterns for the Obsidian plugin. An agent skill from aidenlx/zotlit.

AGPL-3.0Auto-check passedDevelopment

Install Obsidian Services

skills CLI
$ npx skills add aidenlx/zotlit --skill obsidian-services -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install aidenlx/zotlit obsidian-services --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/aidenlx/zotlit.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/obsidian-services .claude/skills/obsidian-services && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
obsidian-services
GitHub stars
1k
Token cost
~2.2k tokens
SKILL.md length
932 words
Files
1
Skills in repo
16
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Service architecture patterns for the Obsidian plugin. An agent skill from aidenlx/zotlit.

  • Works in 8 steps: Open… → Open apps/obsidian/src/zt-main.ts before… → For a new service, create… → …
  • Wiring services in apps/obsidian/src/services/
  • SKILL.md covers Canonical Files, Workflow, Service Rules and Container Notes, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Obsidian Services is an agent skill from aidenlx/zotlit. Service architecture patterns for the Obsidian plugin. Use when creating, modifying, or wiring services in apps/obsidian/src/services/ or editing zt-main.ts lifecycle code.

Its SKILL.md is about 2.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Software architecture. It works with Obsidian. The repository describes itself as: Bring your Zotero library into Obsidian. Create literature notes, insert citations, and annotate PDFs without leaving your vault. The licence is AGPL-3.0.

When your agent uses it

  • Wiring services in apps/obsidian/src/services/
  • Editing zt-main.ts lifecycle code

Example prompts

  • “/obsidian-services”

Workflow steps

8 steps, taken from the first numbered list in SKILL.md.

  1. Open apps/obsidian/src/services/service-base.ts first for Service/ServiceContainer/ServiceInitError definitions and JSDoc. Open…
  2. Open apps/obsidian/src/zt-main.ts before changing plugin load/unload behavior. Keep it a thin lifecycle shell.
  3. For a new service, create apps/obsidian/src/services//service.ts.
  4. Co-locate the service deps interface with the service class. Use concrete class types via import type for upstream services.
  5. Register the service in buildServices with one keyed .use(...) entry. Let the accumulated service type come from the container chain.
  6. Pass plugin, plugin.app, upstream services, and optional deps explicitly through deps objects as needed. Avoid module-global service…
  7. Use apps/obsidian/src/lib/disposables.ts helpers when adapting Obsidian or DOM registrations into Disposable values for stack.use(...).
  8. Run the Obsidian package typecheck after edits.

What it can do on your machine

Read from SKILL.md and the folder at commit 27f5752. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are typescript).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Obsidian Services loads about 2.2k tokens when it runs. Until then it costs about 48 tokens; SKILL.md has 932 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~48
When it runs · the whole SKILL.md, loaded when a task matches
~2.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from aidenlx/zotlit at commit 27f5752, republished under its AGPL-3.0 licence (© aidenlx). 932 words, ~2,194 tokens.

Download SKILL.mdSave it as .claude/skills/obsidian-services/SKILL.md (or your agent's skills folder).
name
obsidian-services
description
Service architecture patterns for the Obsidian plugin. Use when creating, modifying, or wiring services in apps/obsidian/src/services/ or editing zt-main.ts lifecycle code.

Service Architecture

Use the source as the canonical reference. Do not copy service/container/plugin-shell snippets out of this skill; read the current implementation before editing so examples cannot drift from real code.

Canonical Files

  • apps/obsidian/src/services/service-base.ts: Service (abstract base class), ServiceContainer, and other utils.
  • apps/obsidian/src/services/build.ts: buildServices wiring.
  • apps/obsidian/src/zt-main.ts: plugin lifecycle ownership, await using, stack.move(), cleanup, and debug service access.
  • apps/obsidian/src/lib/disposables.ts: Disposable helpers for stack.use(...).

Workflow

  1. Open apps/obsidian/src/services/service-base.ts first for Service/ServiceContainer/ServiceInitError definitions and JSDoc. Open apps/obsidian/src/services/build.ts to see how buildServices wires services through container.use(...). Treat both as authoritative.
  2. Open apps/obsidian/src/zt-main.ts before changing plugin load/unload behavior. Keep it a thin lifecycle shell.
  3. For a new service, create apps/obsidian/src/services/<service-name>/service.ts.
  4. Co-locate the service deps interface with the service class. Use concrete class types via import type for upstream services.
  5. Register the service in buildServices with one keyed .use(...) entry. Let the accumulated service type come from the container chain.
  6. Pass plugin, plugin.app, upstream services, and optional deps explicitly through deps objects as needed. Avoid module-global service lookups.
  7. Use apps/obsidian/src/lib/disposables.ts helpers when adapting Obsidian or DOM registrations into Disposable values for stack.use(...).
  8. Run the Obsidian package typecheck after edits.

Service Rules

  • Services extend Service from services/service-base.ts. The base class owns [Symbol.asyncDispose] and the await ready → disposeAsync ordering; subclasses must not override [Symbol.asyncDispose].
  • Service is generic in the ready resolve type. Use plain extends Service for startup-only services whose ready resolves to void; use extends Service<State> when #load() returns loaded resources/state.
  • Do not introduce an Obsidian Component subclass, a DI library, or any other runtime dependency for service wiring.
  • Constructors call super(), store deps, and start startup by assigning ready (typically this.ready = this.#load()). They must not synchronously acquire resources or throw after startup begins.
  • Registration factories should normally be direct constructor calls. Do not construct a service and then run fallible setup before returning it.
  • Resource acquisition belongs in startup work guarded by a local await using stack = new AsyncDisposableStack(), then handed to the base via this.commit(stack.move()) on the success path. commit() should be the last meaningful side effect before returning the ready state; avoid fallible work after commit. commit() throws on double-commit or commit-after-dispose; in those guard-failure paths it also fires off disposeAsync() on the passed stack so resources don't leak through the throw (disposal errors there are intentionally swallowed).
  • ready is startup-only and must always settle. Do not await long-lived/post-load signals such as workspace.onLayoutReady inside ready — disposal awaits ready, so a non-settling ready hangs cleanup.
  • Service startup waits only for upstream dependency ready promises. There is no global readiness gate or scheduler.
  • Store deps as private fields instead of reaching through another service to its deps.
  • Keep services constructable in isolation with plain mocked deps; lifecycle is driven through ready and the base class disposer.
  • Sync-only services extend Service and initialize ready = Promise.resolve(). They do not call commit() and do not need a constructor unless they have deps.
  • Avoid dependency cycles. If a lazy reference is unavoidable, do not await the lazy target during startup in a way that can create a mutual ready dependency.

Container Notes

  • ServiceContainer.use() accepts exactly one service entry and rejects duplicate keys.
  • The service key is the object property name in the registration entry.
  • The container verifies factory return values with instanceof Service; a non-Service return is a typed error at registration time.
  • Startup failures are wrapped in ServiceInitError (original error preserved as cause) and reported per service. The wrapped rejection — not the original — is what cascades to dependent services that await this service's ready.
  • buildServices(plugin, stack) wires services only; lifecycle ownership remains with the caller's stack in zt-main.ts.
Show full SKILL.md (336 more words)Show less

Plugin Shell Notes

  • Keep zt-main.ts focused on lifecycle wiring, action/menu/view registration, and cleanup.
  • Use the await using plus stack.move() pattern already implemented there for rollback-safe startup.
  • Do not treat the plugin services getter as normal dependency access. It is an escape hatch/debug surface; services should receive deps through buildServices.
  • Wire Obsidian views by closure-capturing the needed services in the registerView factory.

External Signals

Pass layout or UI readiness signals as deps when needed, but schedule post-load work instead of making ready wait on those signals. Disposal waits for ready, so a non-settling ready can hang cleanup.

Example: Service Subclass

The shape below shows the required surface of a Service subclass. It is a structural template, not a snippet to copy verbatim — always read existing services in apps/obsidian/src/services/ before authoring a new one, since real services carry their own dep types and resource patterns.

Async service with deps and acquired resources:

ts
import { Service } from "../service-base";
import type { SettingsService } from "../settings/service";

interface DatabaseState {
  conn: Connection;
}

interface DatabaseServiceDeps {
  plugin: ZotLitPlugin;
  settings: SettingsService;
}

export class DatabaseService extends Service<DatabaseState> {
  readonly #plugin;
  readonly #settings;
  ready: Promise<DatabaseState>;

  constructor(deps: DatabaseServiceDeps) {
    super();
    this.#plugin = deps.plugin;
    this.#settings = deps.settings;
    this.ready = this.#load();
  }

  async #load(): Promise<DatabaseState> {
    await this.#settings.ready;

    await using stack = new AsyncDisposableStack();
    const conn = stack.adopt(
      await openDatabase(),
      async (conn) => await conn.close(),
    );
    await this.#runMigrations(conn);

    this.commit(stack.move());
    return { conn };
  }

  async query(sql: string): Promise<Result> {
    const { conn } = await this.ready;
    return conn.query(sql);
  }
}

Sync-only service (no deps, no acquired resources):

ts
export class TimeService extends Service {
  ready = Promise.resolve();

  now(): number {
    return Date.now();
  }
}

Sync-only service with deps:

ts
interface ClockServiceDeps {
  plugin: ZotLitPlugin;
}

export class ClockService extends Service {
  readonly #plugin;
  ready = Promise.resolve();

  constructor(deps: ClockServiceDeps) {
    super();
    this.#plugin = deps.plugin;
  }
}

Notes the shape encodes:

  • extends Service, never implements Service (no interface) and never a custom base.
  • super() first in any explicit constructor.
  • Deps stored in readonly private (#) fields; no public dep fields, no reach-through. Omit the type annotation on the field — let TypeScript infer it from the constructor assignment (readonly #app; not readonly #app: App;).
  • ready is a mutable instance field. Declare it as ready: Promise<State> and assign in the constructor when load is async and returns state; use ready: Promise<void> for async startup with no state; initialize as ready = Promise.resolve() when load is sync. Do not mark it readonly — the container reassigns it to attach ServiceInitError wrapping.
  • All resource acquisition lives inside #load() under a local await using stack, handed off with this.commit(stack.move()) only on the success path. Treat commit() as the last meaningful side effect before returning the ready state.
  • Resources acquired during load are returned from #load() as the ready resolve value; accessors do const { ... } = await this.ready; instead of storing nullable resource fields.
  • No [Symbol.asyncDispose] in the subclass — the base owns it.

© aidenlx, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/obsidian-services of aidenlx/zotlit.

Open the folder on GitHubat commit 27f5752

Compare with similar skills

Obsidian Services next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Obsidian Services compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Obsidian Services this skillaidenlx/zotlit1k—~2.2kAutomated safety check: PassAGPL-3.0
Qmdbreferrari/obsidian-mind5k—~1.7kAutomated safety check: PassMIT
Archify Diagramstt-a1i/archify81k—~2.9kAutomated safety check: PassMIT
JSON Canvasheyitsnoah/claudesidian2.6k18 repos~3.5kAutomated safety check: PassMIT
Electron Multi-Process ArchitectureiOfficeAI/AionUi33k1 repos~1.8kAutomated safety check: PassApache-2.0
Backend Code Reviewlanggenius/dify158k—~676Automated safety check: PassCustom licence

Similar skills

  • Qmd

    breferrari/obsidian-mind

    Search the vault using QMD semantic search. An agent skill from breferrari/obsidian-mind.

    5k GitHub stars~1.7k tokensUpdated 3 days ago
    Agent WorkflowsAuto-check passed

  • Archify Diagrams

    tt-a1i/archify

    Creates interactive architecture, workflow, sequence, data-flow and lifecycle diagrams as standalone HTML with inline SVG, themes and image or video export.

    81k GitHub stars~2.9k tokensUpdated today
    DevelopmentAuto-check passed

  • JSON Canvas

    heyitsnoah/claudesidian

    Create and edit JSON Canvas files (.canvas) with nodes, edges, groups, and connections.

    2.6k GitHub starsUsed in 18 repos~3.5k tokens
    DevelopmentAuto-check passed

  • Electron Multi-Process Architecture

    iOfficeAI/AionUi

    Tells the agent where new code belongs in an Electron multi-process project and which APIs each process may use, with rules for new bridges, services, agents and workers.

    33k GitHub starsUsed in 1 repo~1.8k tokens
    DevelopmentAuto-check passed

  • Backend Code Review

    langgenius/dify

    Reviews backend code under api/ for concrete, reproducible defects, routes to rule packs for architecture, schema, repositories and SQLAlchemy, and ranks findings from P0 to P3.

    158k GitHub stars~676 tokensUpdated today
    DevelopmentAuto-check passed

  • Dark Architecture Diagram Builder

    Cocoon-AI/architecture-diagram-generator

    Creates dark-themed system, cloud, security and network architecture diagrams as self-contained HTML files with inline SVG and CSS.

    7.4k GitHub starsUsed in 1 repo~2.1k tokens
    DevelopmentAuto-check passed

More from aidenlx/zotlit

All 16 skills in this repo

  • I18n UI Text

    aidenlx/zotlit

    Obsidian house style for the wording of user-facing UI strings — command names, setting labels, button text, notices, modal copy.

    1k GitHub stars~2.8k tokensUpdated today
    Auto-check passed

  • Obsidian CSS

    aidenlx/zotlit

    Style Obsidian plugin UI with Tailwind + native components. An agent skill from aidenlx/zotlit.

    1k GitHub stars~4.8k tokensUpdated today
    Auto-check passed

  • Arkregex

    aidenlx/zotlit

    Typed regex authoring with arkregex in this repo. An agent skill from aidenlx/zotlit.

    1k GitHub stars~952 tokensUpdated today
    Auto-check passed

  • Changelog Entry

    aidenlx/zotlit

    Write a user-facing changelog entry under apps/docs/content/changelog/.

    1k GitHub stars~1.6k tokensUpdated today
    Auto-check passed

  • Discord Announcement

    aidenlx/zotlit

    Draft a Discord announcement from a changelog entry. An agent skill from aidenlx/zotlit.

    1k GitHub stars~604 tokensUpdated today
    Auto-check passed

  • Inlang I18n

    aidenlx/zotlit

    Define ZotLit UI messages in the Inlang Message Format and consume them through the generated JSON Language Pack facade.

    1k GitHub stars~1k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Obsidian Services

What does Obsidian Services do?

Service architecture patterns for the Obsidian plugin. An agent skill from aidenlx/zotlit. Obsidian Services is an agent skill from aidenlx/zotlit. Service architecture patterns for the Obsidian plugin.

When should I use Obsidian Services?

Obsidian Services fits situations like: wiring services in apps/obsidian/src/services/; editing zt-main.ts lifecycle code.

How do I install Obsidian Services in Claude Code?

Run `npx skills add aidenlx/zotlit --skill obsidian-services -a claude-code`. Or copy the skill folder (.agents/skills/obsidian-services in aidenlx/zotlit) into .claude/skills/obsidian-services in your project. Claude Code loads it when a task matches its description.

How do I install Obsidian Services in Codex?

Run `npx skills add aidenlx/zotlit --skill obsidian-services -a codex`. Or copy the skill folder (.agents/skills/obsidian-services in aidenlx/zotlit) into .agents/skills/obsidian-services in your project. Codex loads it when a task matches its description.

Can I use Obsidian Services in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add aidenlx/zotlit --skill obsidian-services -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/obsidian-services, .gemini/skills/obsidian-services, .github/skills/obsidian-services and .opencode/skills/obsidian-services in your project.

What does Obsidian Services need to run?

SKILL.md names no scripts, command-line tools or credentials: Obsidian Services is instructions for the agent only.

Does Obsidian Services access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Obsidian Services safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Obsidian Services use?

Obsidian Services is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Obsidian Services use?

About 2.2k tokens (SKILL.md is roughly 8.8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Obsidian Services?

Skills that share tags, products or a category with Obsidian Services: Qmd (breferrari/obsidian-mind, 5k stars), Archify Diagrams (tt-a1i/archify, 81k stars), JSON Canvas (heyitsnoah/claudesidian, 2.6k stars) and Electron Multi-Process Architecture (iOfficeAI/AionUi, 33k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Obsidian Services?

aidenlx (a GitHub user) maintains it in aidenlx/zotlit, which has 1,028 GitHub stars. The repository holds 16 skills in this directory. The repository was last updated on October 9, 2026.

Source: aidenlx/zotlit on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.