Obsidian review system & quality score¶

Why this page exists. In May 2026 Obsidian launched a new Community hub with automated reviews and a source‑code quality score for every plugin and theme. This page explains how that system works and how ZettelFlow reaches (and keeps) the maximum score. It is the reference behind the obsidian-plugin-quality harness skill and the obsidian-plugin-reviewer agent (see CLAUDE.md).

1. Why Obsidian now scores plugins¶

The community directory grew to thousands of plugins installed inside people's most private notes. To protect users and reward well‑maintained projects, Obsidian moved from a one‑time, manual submission review to a continuous, automated review of every version. The goals are:

• Safety — detect malware, remote code execution, hidden telemetry and known vulnerabilities before users install an update.
• Transparency — users see, before installing, what a plugin accesses (network, file system, clipboard…) and how healthy its code is.
• Trust & signal — a visible score and scorecards let good plugins stand out and nudge every author toward the official guidelines.

2. How the review works¶

Every submitted version goes through an automated pipeline that checks three things:

1. Policy compliance — the Developer policies: no hidden telemetry, no remote code execution, no auto‑updating code outside normal releases, no collecting vault contents / personal data without consent, no deceptive patterns or spam.
2. Code quality — the source is linted against the official Plugin guidelines using the rule set from eslint-plugin-obsidianmd.
3. Security — dependency/known‑vulnerability scanning plus malware scanning for potentially malicious additions.

Around that pipeline:

• Scorecards are shown on each project page and summarise the automated checks. Obsidian has announced they will grow to include disclosures (network / file system / clipboard / other capabilities), privacy labels, artifact attestation, manual review results and app‑capability adoption.
• Manual review still happens for popular or flagged extensions.
• Verified authors — a trust label for developers who pass extra verification and stay in good standing.
• The score — community reporting describes the code‑quality result as a rating from 1 to 100, derived from how well the source follows the guidelines above. Fewer guideline violations ⇒ higher score. Older projects that fail automated checks get a temporary exception but may eventually be removed from the directory.

Takeaway for us: the score is essentially "how clean is the code against eslint-plugin-obsidianmd + the developer policies + the submission requirements". We can reproduce almost the entire check locally.

3. What the score measures — the checklist¶

The automated grade maps to concrete, fixable rules. The tables below group the official eslint-plugin-obsidianmd rules (and the plugin guidelines behind them) into the categories that drive the score.

3.1 Security & DOM construction¶

3.2 Resource management & lifecycle¶

3.3 Commands & settings UI¶

3.4 Vault & workspace API usage¶

3.5 Styling¶

3.6 Mobile & cross‑platform¶

3.7 Repository hygiene¶

4. Submission requirements (manifest & release)¶

Beyond code style, the directory enforces submission requirements:

• manifest.json — valid id, name, version (semver), minAppVersion, description, author. Optional authorUrl, fundingUrl (only if you accept donations), isDesktopOnly.
• Description — ≤ 250 chars, ends with a period, starts with an action verb, does not start with "This is a plugin", no emoji, correct capitalisation of proper nouns.
• versions.json — maps each plugin version to its required minAppVersion so Obsidian serves the right build to each app version. Required for the release workflow.
• Release artifacts — a GitHub release whose tag equals the manifest version (no v prefix) containing main.js, manifest.json and, if present, styles.css.
• Repo — public, with LICENSE and a README.md that documents usage.

5. How to self‑check locally¶

The single highest‑leverage action is to run the same linter Obsidian runs:

# one-off, no install
npx eslint-plugin-obsidianmd   # via an eslint flat config, see below

Add it as a dev dependency and an ESLint flat config (eslint.config.mjs):

import tsparser from "@typescript-eslint/parser";
import { defineConfig } from "eslint/config";
import obsidianmd from "eslint-plugin-obsidianmd";

export default defineConfig([
  ...obsidianmd.configs.recommended,
  {
    files: ["src/**/*.ts", "src/**/*.tsx"],
    languageOptions: { parser: tsparser, parserOptions: { project: "./tsconfig.json" } },
  },
]);

Then wire an npm run lint:obsidian script and run it in CI on every PR and release. The obsidian-plugin-quality harness skill automates this audit; see CLAUDE.md.

6. ZettelFlow compliance snapshot¶

The single record of where this repository stands against the checklist above, re-run by the obsidian-plugin-quality skill before each release. It replaced a second, older snapshot that sat forty lines higher and contradicted it on every row — two accounts of the same thing is one too many, and the stale one is always the one somebody quotes.

Remaining pre-launch item lives in the last launch epic: design by subtraction (#320, E5).

Sources¶

• The future of Obsidian plugins — obsidian.md
• Obsidian launches Community hub with automated plugin reviews — AlternativeTo
• obsidianmd/eslint-plugin (official guideline rules)
• Plugin guidelines — Obsidian Developer Docs
• Submission requirements for plugins — Obsidian Developer Docs
• Developer policies — Obsidian Developer Docs