Hello —
I’m a community plugin author (export / capture tooling). Two practical friction points keep coming up for me and, I suspect, for other maintainers. Sharing them as concrete product asks.
1. Please publish the Automated Review rule set (even a checklist is enough)
Today, the main way to learn what Automated Review will reject is to go through the online Preview / scan loop: push a release, wait for the pipeline, read the report, fix, re-release, wait again. That loop is slow, expensive in attention, and easy to get wrong on small API/style issues (setCssProps vs static styles, createEl, deprecated Setting helpers, CSS !important, and so on).
Those checks are mechanical. They do not need to be discoverable only after a store submission.
Ask: Please publish, in any durable form:
- the lint / ESLint plugin rules Automated Review actually runs, or
- an official local validation script / CLI, or at minimum
- a versioned checklist of Error / Warning / Recommendation IDs with short “do this instead” guidance
Ideally something we can run in CI (pnpm verify / pre-commit) before cutting a store build.
Local reproduction would help authors ship cleaner PRs, reduce Review round-trips for everyone, and make “Accepted” vs “must fix” decisions explicit in plugin repos.
2. Failing Automated Review has a harsh store side effect
As of 2026-07-23, when Automated Review does not pass, a published community plugin can effectively drop out of the Community Plugins market listing — in particular, it becomes hard or impossible to find via search, even if the GitHub release exists and manual install still works.
That turns a lint / style gate into a discoverability outage for end users. Authors then race to fix mechanical findings while the listing is dark.
Publishing the rules (ask #1) would not remove the gate — it would move most of the work off the store pipeline and into the developer’s machine, where it belongs. Separately, it may be worth reconsidering whether a pure Automated Review failure should hide an already-listed plugin from search without a clearer grace path or “under review” state.
3. First-class mobile save / share for export-style plugins
A second ask, related but distinct: please provide a supported API for saving or sharing files on mobile (e.g. write a PNG/JPEG/PDF/ZIP into Photos / Files / the system share sheet).
For export plugins this is extremely common:
- save a rendered note image
- share a multi-page export ZIP
- hand a file to another app without inventing brittle platform workarounds
Today authors cobble together vault writes, limited mobile bridges, or undocumented paths. A small, documented surface (“save blob”, “share file”, with permission UX Obsidian owns) would make mobile export plugins safer and more consistent.
Summary of asks
- Publish Automated Review rules / a local check script / at least a checklist so authors can preview-scan offline.
- Soften or clarify the store side effect when Automated Review fails (search/listing disappearance as observed on 2026-07-23).
- Add a first-class mobile save / share file API for export-style plugins.
Happy to help test a preview CLI or draft rule IDs from recent Review reports if that is useful.
Thanks for considering this.