Obsidian Bases
Atmosphere/atmosphere
Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries.
Patterns for registering commands (action modules) and building context menus (menu segments) in the Obsidian plugin.
$ npx skills add aidenlx/zotlit --skill obsidian-actions -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install aidenlx/zotlit obsidian-actions --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/aidenlx/zotlit.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/obsidian-actions .claude/skills/obsidian-actions && rm -rf skills-srcUse ~/.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/
Install the "obsidian-actions" agent skill from https://github.com/aidenlx/zotlit/tree/main/.agents/skills/obsidian-actions into .claude/skills/obsidian-actions/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "obsidian-actions", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/aidenlx/zotlit/tree/main/.agents/skills/obsidian-actionsType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add aidenlx/zotlit --skill obsidian-actions -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install aidenlx/zotlit obsidian-actions --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/aidenlx/zotlit.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.agents/skills/obsidian-actions .agents/skills/obsidian-actions && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "obsidian-actions" agent skill from https://github.com/aidenlx/zotlit/tree/main/.agents/skills/obsidian-actions into .agents/skills/obsidian-actions/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "obsidian-actions", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add aidenlx/zotlit --skill obsidian-actions -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install aidenlx/zotlit obsidian-actions --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/aidenlx/zotlit.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.agents/skills/obsidian-actions .cursor/skills/obsidian-actions && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "obsidian-actions" agent skill from https://github.com/aidenlx/zotlit/tree/main/.agents/skills/obsidian-actions into .cursor/skills/obsidian-actions/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "obsidian-actions", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/aidenlx/zotlit.git --path .agents/skills/obsidian-actions--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add aidenlx/zotlit --skill obsidian-actions -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install aidenlx/zotlit obsidian-actions --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/aidenlx/zotlit.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.agents/skills/obsidian-actions .gemini/skills/obsidian-actions && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "obsidian-actions" agent skill from https://github.com/aidenlx/zotlit/tree/main/.agents/skills/obsidian-actions into .gemini/skills/obsidian-actions/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "obsidian-actions", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install aidenlx/zotlit obsidian-actionsInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add aidenlx/zotlit --skill obsidian-actions -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/aidenlx/zotlit.git skills-src && mkdir -p .github/skills && cp -r skills-src/.agents/skills/obsidian-actions .github/skills/obsidian-actions && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "obsidian-actions" agent skill from https://github.com/aidenlx/zotlit/tree/main/.agents/skills/obsidian-actions into .github/skills/obsidian-actions/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "obsidian-actions", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add aidenlx/zotlit --skill obsidian-actions -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install aidenlx/zotlit obsidian-actions --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/aidenlx/zotlit.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.agents/skills/obsidian-actions .opencode/skills/obsidian-actions && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "obsidian-actions" agent skill from https://github.com/aidenlx/zotlit/tree/main/.agents/skills/obsidian-actions into .opencode/skills/obsidian-actions/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "obsidian-actions", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
obsidian-actionsPatterns for registering commands (action modules) and building context menus (menu segments) in the Obsidian plugin.
Obsidian Actions is an agent skill from aidenlx/zotlit. Patterns for registering commands (action modules) and building context menus (menu segments) in the Obsidian plugin. Use when adding commands, menu items, context menu logic, or wiring action/menu code in apps/obsidian/src/services/. Also use when a service needs to expose functionality to the user via the command palette or right-click menus.
Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
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.
Read from SKILL.md and the folder at commit 27f5752. It shows what the files ask for, not the result of running them.
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.
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.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Obsidian Actions loads about 2.6k tokens when it runs. Until then it costs about 91 tokens; SKILL.md has 664 words of instructions outside code blocks.
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.
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.
The full file from aidenlx/zotlit at commit 27f5752, republished under its AGPL-3.0 licence (© aidenlx). 664 words, ~2,583 tokens.
.claude/skills/obsidian-actions/SKILL.md (or your agent's skills folder).Two separate concerns for exposing service functionality to users:
Both close over service deps. Both colocate with their feature domain. For the underlying service architecture, see the obsidian-services skill.
Each domain owns its action module. No centralized ActionService. Each feature exports an add*Actions(plugin, deps) function as the entry point convention. Internally, action modules are free to organize however makes sense: define command descriptors, register disposables via plugin.register(...), set up repeat-key handlers, etc. The convention is the entry point shape, not the implementation.
Colocate with the service: services/<domain>/actions.ts
// services/database/actions.ts
export function addDatabaseActions(
plugin: ZotLitPlugin,
deps: { db: DatabaseService },
) {
plugin.addCommand({
id: "zotlit:refresh-db",
name: "Refresh Zotero database",
callback: async () => {
try {
await deps.db.ready;
await deps.db.refresh();
} catch {
new Notice("Database is not available");
}
},
});
}Command handlers check service.ready at invocation time. If the backing service failed to init, the command shows a notice rather than crashing:
try {
await deps.db.ready;
// ... do work
} catch {
new Notice("Database is not available");
}onError (in ServiceContainer) handles detailed error reporting. Consumers only need to know whether the service is available.
For commands that only apply in certain editor contexts, use editorCheckCallback. The checking parameter separates visibility from execution:
plugin.addCommand({
id: "zotlit:update-literature-note",
name: "Update literature note",
editorCheckCallback(checking, _editor, ctx) {
if (!ctx.file || !isLiteratureNote(ctx.file, plugin.app)) return false;
if (checking) return true;
void (async () => {
try {
await deps.db.ready;
const itemKey = getItemKeyOf(ctx.file!, plugin.app.metadataCache);
if (!itemKey) {
new Notice("Cannot get Zotero item key from file");
return;
}
// ... update logic
} catch {
new Notice("Database is not available");
}
})();
},
});Action modules are called unconditionally in onload() after buildServices:
addDatabaseActions(this, { db: services.db });
addNoteActions(this, { db: services.db, noteIndex: services.noteIndex });
addCitationActions(this, { db: services.db, settings: services.settings });No wrapper around Menu. Obsidian's imperative-declarative API (.addItem(i => i.setTitle(...).onClick(...))) is already clean enough. The only abstraction is a shared function signature and a unified context type.
A segment is a function that may add zero or more items to a menu based on context. No class, no interface beyond this. Returns true if it rendered any items, false otherwise — composites use this to skip separators or avoid empty submenu wrappers:
type MenuSegment = (menu: Menu, ctx: ItemMenuContext) => boolean;Different menu events provide different raw data. ItemMenuContext normalizes them into a discriminated union separating event kind from menu source:
type PaneMenuSource = 'more-options' | 'tab-header' | 'sidebar-context-menu';
type ItemMenuContext = {
file: TFile | undefined;
itemKey: string | undefined;
isLitNote: boolean;
} & (
| { kind: 'editor'; source: 'editor' }
| { kind: 'file'; source: string }
| { kind: 'pane'; source: PaneMenuSource }
);kind distinguishes event origin for routing; only routing logic should inspect it. source carries the Obsidian-provided source string (especially useful for pane menus). Domain fields (file, itemKey, isLitNote) are resolved once — feature segments inspect these, never raw event args.
Converts raw Obsidian event args into ItemMenuContext:
function resolveItemContext(
app: App,
ctx:
| { kind: 'editor'; file: TFile | null | undefined }
| { kind: 'file'; file: TAbstractFile; source: string }
| { kind: 'pane'; source: PaneMenuSource; file: TFile | null | undefined },
): ItemMenuContext {
const file = ctx.file instanceof TFile ? ctx.file : undefined;
const base = {
file,
itemKey: file ? getItemKeyOf(file, app.metadataCache) : undefined,
isLitNote: !!file && isLiteratureNote(file, app),
};
switch (ctx.kind) {
case 'editor': return { ...base, kind: 'editor', source: 'editor' };
case 'file': return { ...base, kind: 'file', source: ctx.source };
case 'pane': return { ...base, kind: 'pane', source: ctx.source };
}
}To add a new context dimension (e.g., editor selection state), extend the relevant union branch — segments gain access automatically.
Each feature exports a factory that closes over deps and returns a MenuSegment. File placement: services/<domain>/menu.ts
// services/note-index/menu.ts
import type { DatabaseService } from "../database/service";
import type { NoteIndexService } from "./service";
interface NoteMenuDeps {
db: DatabaseService;
noteIndex: NoteIndexService;
}
export function noteMenuSegment(deps: NoteMenuDeps): MenuSegment {
return (menu, ctx) => {
if (!ctx.itemKey) return false;
menu.addItem((item) =>
item
.setSection("zotlit")
.setTitle("Open in Zotero")
.setIcon("external-link")
.onClick(async () => {
try {
await deps.db.ready;
// ...
} catch {
new Notice("Database is not available");
}
}),
);
if (ctx.source !== "tab-header") {
menu.addItem((item) =>
item
.setSection("zotlit")
.setTitle("Update literature note")
.setIcon("refresh-cw")
.onClick(async () => {
try {
await deps.db.ready;
// ...
} catch {
new Notice("Database is not available");
}
}),
);
}
return true;
};
}Visibility logic (the if checks) lives inside the segment — the feature decides what to show where. The segment returns false when irrelevant, so composites can react to empty contributions without pre-filtering.
Menu construction is synchronous. Never await during segment execution. Obsidian builds menus in one tick. Only onClick handlers may be async.
Use setSection() with a consistent section key on all items so they cluster together regardless of insertion order.
Return the boolean. false when the segment adds nothing (e.g., no itemKey). Composites depend on this.
Visibility uses sync state only. Services may provide a synchronous readiness accessor (e.g., a getter or method) that reflects whether init has completed, failed, or is still pending — implementation is up to the service. If a service is still loading, disable the item with a placeholder title (e.g., "Loading…") using that synchronous state — don't await inside the segment body.
Segments are composed into a single callable. Ordering is explicit:
// services/menu.ts
export function buildMenuSegments(services: Services): MenuSegment {
const segments = [
noteMenuSegment({ db: services.db, noteIndex: services.noteIndex }),
citationMenuSegment({ db: services.db, settings: services.settings }),
templateMenuSegment({ db: services.db, settings: services.settings }),
];
return (menu, ctx) => {
let rendered = false;
for (const seg of segments) {
if (seg(menu, ctx)) rendered = true;
}
return rendered;
};
}Registration happens in onload(). Custom workspace events and DOM-based menu hooks also live in onload() for now; extract to a dedicated service if the wiring grows complex.
const zotlitMenu = buildMenuSegments(services);
this.registerEvent(
this.app.workspace.on("editor-menu", (menu, _editor, info) => {
zotlitMenu(menu, resolveItemContext(this.app, { kind: "editor", file: info.file }));
}),
);
this.registerEvent(
this.app.workspace.on("file-menu", (menu, file, source) => {
zotlitMenu(menu, resolveItemContext(this.app, { kind: "file", file, source }));
}),
);For view onPaneMenu (not a workspace event — called by Obsidian on the view instance). The view receives the composite segment via deps (closure capture in registerView factory):
onPaneMenu(menu: Menu, source: string) {
super.onPaneMenu(menu, source);
this.#zotlitMenu(menu, resolveItemContext(
this.app, { kind: "pane", source: source as PaneMenuSource, file: this.file },
));
}Action modules and menu segments are separate concerns that may share the same underlying operation. Menu items may call app.commands.executeCommandById() to reuse command logic, but direct invocation is also fine when the menu handler needs different args or flow.
Shared context resolution (e.g., "which item is the current note about?") lives in utility functions (getItemKeyOf, isLiteratureNote), not a service — it's stateless frontmatter lookup.
Views also check service.ready at open time:
async onOpen() {
try {
await this.#db.ready;
// render normally
} catch {
// render unavailable state
}
}© 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
Just SKILL.md in .agents/skills/obsidian-actions of aidenlx/zotlit.
Open the folder on GitHubat commit 27f5752
Obsidian Actions 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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Obsidian Actions this skillaidenlx/zotlit | 1k | — | ~2.6k | Automated safety check: Pass | AGPL-3.0 | |
| Obsidian BasesAtmosphere/atmosphere | 3.8k | 22 repos | ~3.2k | Automated safety check: Pass | Apache-2.0 | |
| Knap Markdown Templateskepano/obsidian-skills | 49k | 2 repos | ~986 | Automated safety check: Pass | MIT | |
| JSON Canvasheyitsnoah/claudesidian | 2.6k | 18 repos | ~3.5k | Automated safety check: Pass | MIT | |
| Obsidian MarkdownAtmosphere/atmosphere | 3.8k | 20 repos | ~1.3k | Automated safety check: Pass | Apache-2.0 | |
| Obsidian CLIAtmosphere/atmosphere | 3.8k | 13 repos | ~795 | Automated safety check: Pass | Apache-2.0 |
Atmosphere/atmosphere
Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries.
kepano/obsidian-skills
Renders Markdown notes from Knap templates and JSON data on the command line, including notes built from Defuddle web page output.
heyitsnoah/claudesidian
Create and edit JSON Canvas files (.canvas) with nodes, edges, groups, and connections.
Atmosphere/atmosphere
Create and edit Obsidian Flavored Markdown with wikilinks, embeds, callouts, properties, and other Obsidian-specific syntax.
Atmosphere/atmosphere
Interact with Obsidian vaults using the Obsidian CLI to read, create, search, and manage notes, tasks, properties, and more.
axtonliu/axton-obsidian-visual-skills
Create Obsidian Canvas files from text content, supporting both MindMap and freeform layouts.
aidenlx/zotlit
Obsidian house style for the wording of user-facing UI strings — command names, setting labels, button text, notices, modal copy.
aidenlx/zotlit
Style Obsidian plugin UI with Tailwind + native components. An agent skill from aidenlx/zotlit.
aidenlx/zotlit
Typed regex authoring with arkregex in this repo. An agent skill from aidenlx/zotlit.
aidenlx/zotlit
Write a user-facing changelog entry under apps/docs/content/changelog/.
aidenlx/zotlit
Draft a Discord announcement from a changelog entry. An agent skill from aidenlx/zotlit.
aidenlx/zotlit
Define ZotLit UI messages in the Inlang Message Format and consume them through the generated JSON Language Pack facade.
Works with
Patterns for registering commands (action modules) and building context menus (menu segments) in the Obsidian plugin. Obsidian Actions is an agent skill from aidenlx/zotlit. Patterns for registering commands (action modules) and building context menus (menu segments) in the Obsidian plugin.
Obsidian Actions fits situations like: adding commands; context menu logic; wiring action/menu code in apps/obsidian/src/services/; A service needs to expose functionality to the user via the command palette.
Run `npx skills add aidenlx/zotlit --skill obsidian-actions -a claude-code`. Or copy the skill folder (.agents/skills/obsidian-actions in aidenlx/zotlit) into .claude/skills/obsidian-actions in your project. Claude Code loads it when a task matches its description.
Run `npx skills add aidenlx/zotlit --skill obsidian-actions -a codex`. Or copy the skill folder (.agents/skills/obsidian-actions in aidenlx/zotlit) into .agents/skills/obsidian-actions in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add aidenlx/zotlit --skill obsidian-actions -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-actions, .gemini/skills/obsidian-actions, .github/skills/obsidian-actions and .opencode/skills/obsidian-actions in your project.
SKILL.md names no scripts, command-line tools or credentials: Obsidian Actions is instructions for the agent only.
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.
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.
Obsidian Actions 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.
About 2.6k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with Obsidian Actions: Obsidian Bases (Atmosphere/atmosphere, 3.8k stars), Knap Markdown Templates (kepano/obsidian-skills, 49k stars), JSON Canvas (heyitsnoah/claudesidian, 2.6k stars) and Obsidian Markdown (Atmosphere/atmosphere, 3.8k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
aidenlx (a GitHub user) maintains it in aidenlx/zotlit, which has 1,029 GitHub stars. The repository holds 16 skills in this directory. The repository was last updated on October 10, 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.