- Reliability 8/20
- The README describes chat, inline-edit, slash commands, and MCP connectivity with a fairly detailed source tree, but no server manifest was cached and there is no visible evidence of unit tests, integration tests, or CI workflows. Claimed tool behaviors (file read/write, bash, multi-step workflows) cannot be verified against implementation from static material alone, and error handling/dependency control are undocumented. Per the static calibration rule, absence of executable evidence caps this score low.
- Security and permissions 13/20
- The Privacy & Data Use section is reasonably transparent: no telemetry, network activity limited to explicit provider/MCP calls, and destinations by provider are disclosed. The architecture lists a core/security (approval utilities) module and a Plan Mode that requires approval before execution, suggesting a confirmation mechanism exists by design. However, this plugin grants AI agents broad file read/write and bash execution over the entire vault, and the README does not specify default permission scope, whether every tool call requires explicit user confirmation, or how credentials for external MCP servers are managed. This is insufficient to confirm least-privilege and full data-flow disclosure, so it cannot score near the top, though nothing in the material indicates a red-line issue (hardcoded secrets, covert exfiltration, or unconfirmed destructive defaults).
- Maintenance 14/20
- The repo is not archived, uses the MIT license, and has a dedicated CONTRIBUTING.md with explicit PR standards (must explain the problem, solution, rationale, and validation; new-provider PRs are explicitly rejected), indicating clear governance boundaries. Release and community-plugin download badges suggest an ongoing release cadence, and sponsorship (Ke Holdings/BEIKE) implies resourced long-term maintenance. However, no changelog, security-response channel, or dependency-update policy is described in the README, and there is no evidence of response time on the 77 open issues.
- Documentation 15/20
- The README is layered: features, two install paths (community plugin and from-source), environment requirements, a substantial troubleshooting section (CLI-not-found, PATH conflicts, Windows-specific caveats), a privacy/data-flow disclosure, and an architecture tree. This covers install, dependency troubleshooting, and data-boundary concerns well. It lacks concrete tool/interface parameter documentation (e.g., MCP tool input/output schemas), a changelog or versioning history, and quantified cost guidance (only general mention of needing a subscription or API key), leaving hidden assumptions about the reader's CLI/Node familiarity.
- Setup experience 12/20
- Installing via the Obsidian community plugin marketplace is simple (search, install, enable), and the from-source path gives concrete commands. But actual functionality depends on a separately installed external CLI (Claude Code/Codex/Grok/OpenCode/Pi) being discoverable by a GUI app, and the README's extensive troubleshooting (spawn ENOENT, nvm/fnm conflicts, Windows .cmd/.exe distinctions, PATH vs. Node.js path mismatches) itself demonstrates this process is fragile and requires manual intervention. No automated verification (CI, tested example configs) demonstrates these steps are reproducible across platforms, and the static calibration rule caps the score accordingly.