@mpstaton what platform did you use to make your plugins? I’ve never been able to get AI to do anything useful for me so would love to know.
Hey, was curious if you ever figured this out. I am in a very similiar spot at the moment. I’ve tried as many differerent things to re-summon the review bot as possible. I feel like I must just be missing a very obvious thing.
What PR?
1 Like
PR-8888
I’m nearly positive this is something I’m doing wrong, but I can’t for the life of me figure out what it is. Please let me know if there’s anything I can do, appreciate any help! 
The underlying issue should be fixed now, you just got a new review
I see it now, thank you! Appreciate the help!
If you had the code scan skipped via the /skip command, is there a way to have it scanned again?
I was arguing with the bot that my plugin was using proper sentence case. Eventually I just decided to skip the scan, as that was its only gripe, but ultimately decided to cave to make the bot happy to get green lights to hopefully not have the plugin lost in a backlog of “changes requested” “additional review required”.
If it’s helpful - my pull request:
I want to express my sincere gratitude for all the hard work you’ve been putting in 
.
With the developer guidelines an LLM one-shotted my plugin (almost). Which is HUGE. The plugin template is excellent and prevents the-blank-list problem. Code entities are carefully documented, which helps a lot. The integration with Svelte and TypeScript has significantly reduced many problems. Thanks for setting up the GitHub action; it’s almost perfect. The PR bot can be a bit noisy, but that’s just the way things work.
As a plugin developer, the only concern I have is the release cycle time. If there are any issues in production, I won’t be able to fix them quickly due to the moderation process. However, on the positive side, this means I have more time to further improve the plugin’s quality.
It would be great if the bot could provide an estimated time to completion based on the statistics of closed and approved PRs, as well as the time spent on each PR. I’ve noticed that the timing from opening a PR to approval is currently around 2-3 months.
In case anyone finds this - I released a new version to GitHub, which seemed to re-engage the auto-validation bot.
Last year I submitted two Obsidian plugins for review. The second, GitHub Tasks, went fairly smoothly. I think it took a couple of months from submission to release. Partly this is because I learned from the first, but it is also a very simple plugin.
The first, Co-Intelligence AI (PR #6690), was submitted June 10, and is still in limbo. The last actions were:
- ObsidianReviewBot finds no issues with the code, marks it for manual review (October 24)
- joethei assigned ObsidianReviewBot and unassigned joethei on Dec 3, 2025
- joethei removed the Changes made label on Dec 3, 2025
No further communication, no indication that I’m supposed to do anything, no indication of what to expect.
Before, this, on Oct 17, joethai apparently tried to merge the plugin, which presumably means it was accepted, but there was a mismatch between the plugin’s description in the PR and the repo. I fixed that immediately, and since then I’ve been waiting.
To be clear, I don’t begrudge that Obsidian has a small team or that plugin review is a slow process. I’m just frustrated at the lack of communication and transparency.
If you could code up an automation (@ObsidianTeam) to say in our PRs just how backlogged you are, then that would add some clarity to the uncertainty.
1 Like
I want to have a frank conversation about the state of the plugin review pipeline, because what’s happening right now is unsustainable, and some of the ideas being floated to address it are, frankly, offensive to the people keeping this ecosystem alive.
I submitted my plugin roughly seven to eight months ago. It has not been reviewed. Not rejected — not given feedback — not even looked at by a human being, as far as I can tell. I am not alone. The current review queue on the repo sits at approximately 58 pages deep, and by all appearances, it has not meaningfully moved in months. That is not a backlog. That is abandonment.
Developers who submitted plugins in good faith — who read the docs, followed the guidelines, wrote the code, tested it, and submitted a PR — are sitting in a queue that functionally does not move. There is no transparency about review timelines, no escalation path, no communication, and no indication that this is being treated as the crisis it actually is.
What makes this worse is the suggestion raised that developers should be charged for the privilege of publishing free plugins to the Community Marketplace.
I want to be very precise about why this is a problem, because I don’t think the weight of it has landed.
Obsidian is a note-taking app. It is a good note-taking app — but strip away the plugin ecosystem and it is competing with a dozen other markdown editors, many of them free and open source. What separates Obsidian from the pack — what makes it the tool people recommend, the tool people pay for with Sync and Publish subscriptions — is the extraordinary breadth and depth of its community plugin ecosystem. That ecosystem is built entirely by volunteer developers, contributing their time, expertise, and ongoing maintenance labor for free.
We do not get paid. We do not get revenue sharing. We do not get priority support. Most of us don’t even get a “thank you.” And that’s fine — that is the open source social contract, and most of us entered into it willingly.
But now the suggestion is that we should pay for the privilege of giving away our work — work that directly drives Obsidian’s adoption and, by extension, its revenue?
The hubris required to even float that idea is staggering.
Let me reframe this in case the dynamic isn’t clear: Plugin developers are not consumers of a service Obsidian provides. We are contributors to the product Obsidian sells. The review process is not a favor being done for us. It is the bare minimum curation responsibility that comes with operating a marketplace that your business model depends on.
Instead of finding ways to extract money from the people propping up your ecosystem, here’s what a healthy response to a 58-page backlog looks like:
Hire reviewers. If the team cannot handle the volume, that is a staffing problem, not a developer problem. Use some of the Sync and Publish revenue that our plugins help generate.
Implement automated pre-screening. Static analysis, linting checks, and sandboxed testing can flag common issues and reduce the burden on human reviewers without charging anyone a dime.
Establish community reviewers. Trusted, experienced plugin developers could be given review privileges — a model that works across countless open source ecosystems.
Communicate. Even a simple status dashboard or estimated review window would go a long way. Silence for eight months is not acceptable.
At an absolute minimum, acknowledge the problem publicly and commit to a timeline.
Developers are not going to wait forever. Some have already walked away. Others will publish plugins outside the marketplace, which fragments the ecosystem and increases security risk for users — the exact outcome the review process is supposed to prevent.
If Obsidian wants to continue benefiting from one of the most vibrant plugin ecosystems in the productivity space, it needs to start treating the developers who build it as partners, not as supplicants waiting in line for a gatekeeping process that has ground to a halt.
Charging us for the privilege would not just be tone-deaf. It would be pulling the rug out from under the very thing that makes Obsidian worth using.
4 Likes
You’re absolutely right. I also waited long time and in the end I decided close the commit and just updating for my plugin in the plugin’s repo. It’s not practical for users. For the update plugin they should: go to repo → update plugin manually, they also should constantly check if plugin is updating.
At the same time, part of plugins in the community list are abandoned.
Obsidian is amazing app, but plugins its core, its heart and currently system of adding plugins need rework.
I really feel for the plugin reviewers (looks like there are only about 3–4 of them right now?). Every day they wake up, they’re staring at 1,600+ new plugin submissions (60+ pages), and maybe more than two-thirds are AI-generated. I can barely stand looking at AI-generated code even in my own projects, but they have to go review this stuff every single day, that is exhausting.
And to be honest, I don’t quite get why the review process is so strict, since it seems like once a plugin gets merged, later versions don’t go through the same level of review. I think most of plugins that are already published (and have updated versions) probably wouldn’t even pass the current review standards again. Isn’t that a bit unnecessary?
As an Obsidian user, I’ve also noticed that plugin updates have definitely slowed down over the past year. Every time I open the marketplace hoping to see something new, I usually just find plugins that were published a week or two ago, and quite a few of them are AI agents or assistants built with AI.
At this point, all we can really do is hope Obsidian figures out a way to fix the situation soon.
2 Likes
Hello developers,
Recently I find that the pull requests are getting commented and merged by the account Fevol.
Anyone knows him/her?
They are one of the part time plugin reviewers.
2 Likes
If the situation really is that dire, then it seems only reasonable that they raise the barrier of entry to stem the tide a bit. Maybe a $5-10 plugin submission fee - just enough to deter junk (or cause them to make more effort up front) while remaining low enough to be worth it for genuine submissions.
Lately, I can’t help but wonder what is even the point of plugin reviews and the official community plugins list besides the convenience.
Plugins can be installed before reviews from GitHub or via BRAT/VERA and can be totally rewritten from scratch by the developer after reviews. Users can’t openly comment on their quality either so there’s no visible community review either. In the end, it will never be any less riskier to install a plugin.
The reviewer only checks one version of the plugin, but there is no way to tell which version that was and I can not select and install that given version from inside Obsidian anyway.
On the other hand reviewers are overwhelmed by the work and plugins have to wait months to get approved.
Maybe you could just allow every plugin on the list and randomly review their code and then add a flag to that given version and let me install that one, a kind of “LTS” version.
Maybe show some GitHub stats in the community plugins so I can tell how experienced and active the developer, whether they vibe-coded the plugin with Claude, etc., so I can make an informed choice. A list of all their other plugins would be useful too.
What I do now is search for plugins on external sites Obsidian Stats and SimilarPlugins that give me better search results, then check the repo where I have all the necessary info and then use BRAT to install the exact version I checked and freeze it.
I know community plugins are a difficult problem to tackle, while also being one of the driving force of the users. Now with around 3000 plugins, maybe it’s time to rethink the whole implementation of it.
The Gnome Software for comparison:
2 Likes
That’s a play on words.
The plugin is a citation tidy-up set of commands, plus the feature of promoting some sources in any one file to a cannonical source that can be referenced with the same hex-code everywhere vault-wide. We use it to enable functionality on our Astro content-driven website which now has over 4500 pages managed through Obsidian.
One angle worth adding: an optional accountable-publisher path. Not a shortcut around review, but a way to surface more context up front for plugins with an identifiable, reachable maintainer or publisher.
Right now there does not seem to be a structured way to share basic context: who the publisher is, who to contact for security issues, and what data the plugin actually accesses.
That information exists for many maintained plugins, but it is not visible to reviewers in a consistent way. A simple opt-in form could help reviewers triage submissions with clearer trust signals, especially with the current volume of AI-assisted submissions.
This connects to the earlier ideas about a submission fee and giving users more information on plugin pages. Same direction, just from the maintainer side. These ideas could coexist.
We are in that situation with AICHE Voice. We submitted PR #9425 in January, and users currently install through BRAT. That works for technical users, but it is still a wall for many normal users. We would be happy to provide whatever verification helps reviewers separate maintained plugins from less clear submissions.
Add basic queue visibility on top, such as queued / blocked / waiting on author, and Obsidian becomes much easier to plan around for maintainers with users without changing the review bar itself.
Just adding one piece to the discussion. Thanks for the work.
1 Like