DEV Community

Stephan Miller
Stephan Miller

Posted on • Originally published at stephanmiller.com on

The Obsidian Plugin Collection I Built One Free Kiro Credit at a Time

Here’s the problem with Claude Code on the Pro plan: it’s enough to get you started and never enough to get you finished. You sit down on a Saturday with a real idea, you get the agent into a groove, the code is actually taking shape, and then the session cap stops you.

So, once a month, I’d take one idea for an Obsidian and I’d buid it. Not on Claude. On Kiro, AWS’s agentic IDE, whose free tier resets on a monthly cycle. One idea, one credit, one plugin. Tweak the spec over a week or two of note-taking, then hand the whole thing to Kiro and let it grind through its task list.

I’ve written about Kiro before, back when it built me my first two plugins in a weekend. This is where the weekend turned into a habit that turned into a handful of plugins. Some of these are real and polished. Some are working but rough. And not all of them were even built completely with Kiro, but for the most part I have been turning a month of free Kiro credits into one Obsidian plugin.

The Free Tier Economy of AI Coding Tools

I’m not paying $200 a month for a Max plan to ship a hobby plugin that twelve people will install. So I take advantage of free-tiers. Claude Code on Pro for the daytime stuff. Google’s AI Studio when you want a huge context window and want a quick opinion on an idea along with a rough plan before you start building something. Jules for fixing bugs in something that already exists. And Kiro for the building extensions, plugins, and the like.

The free tier is the hook: $0 a month, 50 credits, and, at the time I’m writing this, access to Claude Sonnet 4.5 inside it. The credits reset at the start of each billing month and you can use them up in one session.

Kiro’s whole pitch is spec-driven development. Instead of vibe-coding, it makes you write (or makes the agent write) a requirements doc, a design doc, and a tasks doc that breaks the build into a numbered checklist. Then it works the checklist. That structure is the entire reason I use it for Obsidian plugins specifically, and not for, say, a large web app.

Here’s why Obsidian plugins are the perfect shape for a free-tier:

  • Small surface area. It’s a TypeScript project with a manifest.json, a main.ts, and a documented API. There’s no backend, no auth, and Github Actions builds it for me.
  • Clear standards. Obsidian’s sample plugin repo and developer docs define exactly what “correct” looks like. An agent that follows documentation does well here.
  • You can ship before you’re done. BRAT lets anyone install a plugin straight from a GitHub repo, no community-store review required. So “done enough” is a real, useful state.

The Monthly Grind

I keep a running list of plugin ideas as plain notes. Over a week or two, the note stops being “wouldn’t it be cool if” and starts being an actual spec: what it does, what the settings are, where the edge cases live.

Then, when the note is ripe and the monthly credit is sitting there unspent, I open Kiro, point it at the notes, and tell it to build. Kiro turns that into its own internal task list. For Obsidian Cleaner, Kiro generated a tasks.md with 91 tasks. For the Notebook OCR plugin, it ended up spanning five separate specs with close to 280 tasks between them. The Daily Prompts build was 45. Even “small” Joplin Portal was 43 tasks in the main spec, before I made it add a 16-task spec later just to bring it up to Obsidian’s plugin guidelines.

I don’t read all 91 tasks. I read the design doc, I sanity-check the first few tasks, and then I let it run. When it finishes, I install the build into my test vault, poke at it, and sort it into one of three buckets: done messing with it, needs another pass, or back on the shelf. Most months land in the middle bucket. Some months produce a genuine mess I have to come back and fight with. It’s nice when the result works enough that I start using it all the time.

The Plugin List

This is everything that actually exists. If it’s installed in my test vault, I built it. Here’s the status of each one, including which ones Kiro built and which ones came from somewhere else.

Apple Books Annotation Import: the one that I started with

Obsidian Plugin: Apple Books Annotation Import

Repo: github.com/eristoddle/apple-books-annotation-import · Version: 1.0.22 · Status: working, most polished of the lot

Kiro had nothing to do with this one actually. It started life as a Python script that pulled annotations out of Apple Books’ SQLite databases, and I used Claude desktop to convert it into a plugin and Jules to fix the final bugs. It started the Obsidian plugin in an afternoon ritual.

It’s also the one that’s had the most love since. It pulls highlights and notes out of the macOS Books databases and turns them into formatted markdown: book metadata, ISBN, reading progress, highlight colors as emoji (🟡🟢🔵🟣🔴), chapter detection from EPUB CFI locations, the works. There’s an interactive picker so you choose exactly which books to import, with cover thumbnails and annotation counts. Turns out Apple’s annotation data is a labyrinth spread across separate SQLite files that aren’t meant to be touched. It’s macOS-only. I use it all the time.

Joplin Portal: the one Kiro broke, then fixed

Joplin Portal Obsidian Plugin

Repo: github.com/eristoddle/joplin-portal · Version: 1.0.18 · Status: working, has a real test suite

Joplin Portal gives you a sidebar panel in Obsidian that searches, previews, and selectively imports notes from a running Joplin server through Joplin’s Data API. It’s not a hack or a file-format conversion. It talks to Joplin’s actual REST endpoint with a token, debounces the search, caches results, and lets you cherry-pick what comes across.

This is the plugin where I learned exactly where Kiro’s limits are, and it’s the best story in the bunch, so it gets its own section further down. Short version: Kiro built the working thing in 43 tasks, then I asked it to fix one cosmetic bug and it broke a lot of things in the process.

Obsidian Cleaner: the one that suffered scope creep

Obisidian Attachement Cleaner Plugin

Repo: github.com/eristoddle/obsidian-cleaner · Version: 1.2.0 · Status: active, recently renamed

This one started as “Attachment Cleaner,” a single-purpose tool to find attachments nothing links to. Then I kept noticing other crap in my vault. Dropbox conflicted copies. Numbered duplicates from Web Clipper (Note 1.md, Note 2.md). Zero-byte markdown files. Empty folders. Tags that were one typo apart from each other. So I gave Kiro the bigger spec, watched it generate a 91-task checklist, and let it turn a one-trick tool into a seven-type vault-hygiene suite. Then I renamed the whole thing to Obsidian Cleaner because “Attachment Cleaner” no longer fit.

It walks you through a step-by-step modal: orphaned attachments, conflicted files, duplicates, empty markdown, empty folders, near-duplicate tags (edit distance ≤ 2), and a frontmatter-rule cleanup. Every single item gets its own accept/reject toggle before anything gets deleted. You pick the deletion mode too: system trash, Obsidian’s .trash, or permanent if you’re feeling brave. Started as a scalpel, ended as a Swiss Army knife. Scope creep, but the useful kind.

Daily Prompts: the one that’s almost there

Obisidian Daily Prompts Plugin

Repo: github.com/eristoddle/obsidian-daily-note-prompts · Version: 1.0.1 · Status: mostly working, notifications still flaky

Daily writing prompts delivered into your daily note, three ways: sequential (for structured courses), random (no repeats until the pack’s exhausted), or date-based (for seasonal stuff). Prompts live in JSON packs you can import and export, so you can share a pack or back one up. It’ll create or open the daily note when a prompt fires, optionally drop you into a distraction-free mode, and ping you with either a system notification or an Obsidian notice.

That notification system is exactly where it’s still rough. Timezone-aware scheduling and “catch up on missed prompts” are great on paper, and the persistence is the part that needs another Kiro credit. It’s 45 tasks of mostly-done. One of these months it’ll get the pass that finishes it.

Notebook OCR: the one that worked well and I stopped using

Obsidian OCR Plugin

Repo: github.com/eristoddle/obsidian-ocr-note-import · Version: 1.0.16 · Status: working

I carry a 3.5×5.5 field notebook everywhere, and for years the digital bridge was me typing my own handwriting back into Obsidian like an animal. This plugin kills that. You photograph the pages, it runs OCR (local Tesseract.js offline, or OpenAI Vision / Google Cloud Vision when you want it to actually read cursive), and then it routes the extracted text into your vault using regex pattern rules with capture groups. It even preprocesses multi-page notebook scans, splitting and rotating them before OCR, with presets for common pocket-notebook layouts.

Notebook OCR

This is the most over-engineered thing on the list (five Kiro specs, nearly 280 tasks total), and it already got its own full writeup.

YouTube Auto Video Summarizer: the one I forked

Repo: github.com/eristoddle/obsidian-auto-video-summarizer · Version: 1.2.3 · Status: forked and customized

Sometimes the best plugin is someone else’s that you make your own. This is a fork of mbramani’s video summarizer, which already pulls YouTube transcripts and summarizes them with an LLM: Gemini, OpenAI, or Anthropic, your key, your choice of model. What I added to my copy is the automatic part: it’ll summarize any YouTube URL you paste into the editor, or any new web clip whose source frontmatter is a YouTube link. Just a fork and a quick modification. Took about 15 minutes.

Tag Explorer 3D: the one that doesn’t have a git repo yet

Obsidian 3D Tag Explorer Plugin

Repo: none (never pushed) · Version: 1.0.0 · Status: built, never shipped

This lives in my test vault, rendering my hierarchical tags (#obsidian/plugin/idea) as an interactive 3D network graph with three.js and 3d-force-graph: orbit, zoom, hover-to-preview note contents, hierarchical and force-directed and radial layouts.

I could never decide whether a 3D tag graph is genuinely useful or just a very pretty answer to a question nobody asked. Sometimes you build things because they’re interesting, not because anyone needs them, and then you can’t quite bring yourself to delete them either.

What the Process Actually Looks Like (a Kiro Horror Story)

Let me show you a real month, with the mess included.

Joplin Portal worked. Kiro built the search, the preview, the import, all 43 tasks of it, and it was good. Then I noticed the panel’s icon wasn’t rendering right, which is a cosmetic nothing of a bug. So I asked Kiro to fix the icon.

This is where it went sideways. Instead of reading Obsidian’s icon documentation and using the one correct API call, Kiro started flailing. It wrote a registerJoplinIcon() function. The icon still didn’t render, so on the next pass it added a second function, registerJoplinIconEarly(), and called both. It started rendering image tags that looked like <img width="20" height="20" src="joplin-id:2f95b263..."/>, a made-up URL scheme that was never, ever going to resolve. It was guessing, and each guess piled another layer of garbage on top of the last one. The “fixing” produced a codebase that was worse than when it started.

So I did the thing you eventually learn to do with these tools: I stopped letting it improvise and put it on a leash. I went and did my own research, figured out the actual fix, and then wrote it a prompt that was less “please help” and more “here is your one job, do not deviate.”

This plugin needs to follow best practices. You have made it a mess trying to fix an issue with the icon rendering. See how many times you call this.registerJoplinIcon() and then the duplicate function this.registerJoplinIconEarly(). This is unnecessary, and whenever you catch yourself doing this, you should know you have taken a wrong turn. That was the only problem. Everything else worked and you have made a mess.

You MUST, MUST, MUST follow the documentation to do this right: https://docs.obsidian.md/Plugins/User+interface/Icons. Do not ever guess. Do not think you know unless you do. Do not make things up. You must also use this repo as reference for best practices: https://github.com/obsidianmd/obsidian-sample-plugin. And you must remember you are only fixing the mess with rendering the icon and bringing it back to standards. Nothing else.

What the Process Actually Looks Like (a Kiro Horror Story)

Its confidence is uncorrelated with its correctness, and when it doesn’t know something it will invent something that looks plausible and ship it. The duplicate function with the Early suffix is the tell: when an agent starts bolting “early” and “v2” and “final” onto its own helpers, it’s not solving the problem, it’s papering over the fact that it doesn’t understand it. Your job isn’t to write the code. Your job is to notice the tell, hand it the authoritative documentation, and fence the task down to exactly one thing so it can’t wander.

After that prompt, it fixed the icon. Then I had it add a 16-task spec to bring the whole plugin in line with Obsidian’s official guidelines, and that’s why Joplin Portal is the one on this list with an actual Vitest test suite.

The Real ROI

So what does “one free Kiro credit a month” actually get you? Let’s add it all up.

It got me eight things that run: two genuinely polished, three that are working-but-rough, one fork, and one that’s never been pushed.

There’s friction too. You hit session caps. You switch tools and lose context between them. The agent sets your icon-rendering code on fire and you spend a Saturday afternoon being its very firm manager. Some months produce a finished tool and some months produce a mess.

The constraint makes you good at scoping. When your AI tool can only finish work that fits inside one month’s free allotment, you’re forced to break ideas down until they’re small enough to actually ship. And a plugin idea you’ve sharpened to that point is one you understand. The vault notes that become the Kiro specs are a documentation trail I’d never have written otherwise. The real product of this whole ritual is the discipline of cutting work down to a finishable size, which is the one skill that survives no matter which AI tool you’re using this month.

Top comments (0)