How I Built Two Obsidian Plugins While Kiro AI Did Most of the Work

For the first Obsidian plugin I wrote with AI, I used Claude desktop and already had a Python script that did most of what I needed the plugin to do. I just needed AI to convert it to an Obsidian plugin. Then I used Jules to fix the final bugs.

But I have been moving away from the chaos of vibe coding so I can get results that look more like the vision I have in my head. This started when I rolled my project management system with Claude Code and a bunch of markdown files. Then I found out that Backlog.md could make my vibe coding projects go more smoothly.

But along the way, Kiro came out and had a spec-driven development feature. So I figured I’d try it building even more Obsidian plugins. Why two, though? Well, the first one was more complex, and the more complex a project, the more things AI leaves behind that you have to clean up. The second one was actually simple enough that I am currently prepping it to release it officially.

Table of Contents

• What is Kiro and Why I’m Using It
• Plugin #1: Daily Note Prompts - The Spec-Driven Experience
  • Requirement 1
• My Obsidian Development Process
• Plugin #2: Joplin Portal - When AI Tools Hit a Wall
• Lessons Learned
  • Spec-driven development workflow
  • When to trust AI vs when to investigate yourself
  • Managing AI tool limitations and daily limits
  • The value of simple projects for learning new tools
• Conclusion

What is Kiro and Why I’m Using It

Kiro is an AI coding tool that takes a different approach than most of the tools I’ve been testing. Instead of just throwing code at you, it starts with what they call “spec-driven development.” You give Kiro an idea, and it creates three files: requirements.md, design.md, and tasks.md.

Kiro breaks down your project into digestible chunks before writing a single line of code. No more “let’s see what happens” coding sessions that end with you staring at a pile of TypeScript wondering how you got there.

But here’s the real reason I’m going all-in on Kiro right now: it’s completely free. No credits, no tokens, but there is a daily limit that cuts you off for 24 hours, but I can deal with that.

So I’m testing Kiro on every coding project I can think of before the free tier disappears. Obsidian plugins are perfect for this because I use Obsidian daily, I have a constant stream of plugin ideas, and I can see the results of mine and Kiro’s efforts quickly.

Plugin #1: Daily Note Prompts - The Spec-Driven Experience

I used to write daily. I had a morning practice where I woke up, meditated, read, and then wrote. But who has all that time? Actually, I’m kicking myself because I had a three-year streak, and it only took one missed day for me to give that up. The “streak” gurus never tell you about that part.

And for a while, I was doing it in Obsidian using Daily Notes. Now I wanted a plugin to nag me about it and give me a prompt to start with. So that was the start of the idea. Here’s how I fleshed it out:

• Prompt packs in JSON format can be imported and exported with these attributes: - Type: ‘Sequential’, ‘Random’, ‘Date’ - Prompt: Link, String, or Markdown - Date: For Date type like devotionals - Order: For Sequential type that have to be done in order
• Set Reminder/Alert with System or Obsidian notification.
• Launches daily note with prompt
• Automatically go into zen mode

And that is basically what I gave Kiro in the first prompt. You can actually still “vibe code” with Kiro. You just have to select that option.

And Kiro built the three spec files in order, waiting after each file for my approval or for me to request changes.

The requirements file has entries that look like this:

Requirement 1

User Story: As an Obsidian user, I want to create and manage prompt packs with different delivery modes, so that I can organize my writing prompts according to my preferred workflow.

Acceptance Criteria

1. WHEN a user creates a new prompt pack THEN the system SHALL allow them to specify the type as ‘Sequential’, ‘Random’, or ‘Date’
2. WHEN a user adds prompts to a pack THEN the system SHALL support prompts as links, strings, or markdown content
3. WHEN a user creates a Sequential prompt pack THEN the system SHALL allow them to define the order of prompts
4. WHEN a user creates a Date-based prompt pack THEN the system SHALL allow them to assign specific dates to prompts
5. WHEN a user creates a Random prompt pack THEN the system SHALL randomly select prompts without repetition until all are used

The design file specifies things like data models, service interfaces, and other architectural details.

The final file it creates is the tasks file which look like a basic list of nested to dos in markdown:

But when it is loaded in the Kiro IDE, it adds a Start task link you can click on to have Kiro to start working on it.

I am not sure whether adding a command to the trust list was buggy, or I just didn’t know how to use it. It would seem that you could just click the play triangle once and the double play triangle to trust the command in the future, but that didn’t seem to work all the time. Then I realized that the list of commands below the paragraph were also buttons and I had more success with those, but not every time. And like I said, it could be user error, but they didn’t make it easy to figure out. And who want’s to read documentation, anyway? No one’s got time for that.

In the end, I clicked Start task over and over for about four hours while doing other things, finished all the tasks, and decided it was too late to even attempt testing it that night. I know how that goes. So, I tested the next day.

And it actually went pretty well. There were two or three minor bugs. For example, the time field for notification needed debouncing. It was basically working after about a half an hour of bug fixing. But there is a lot of weirdness. For example:

• It rolled its own Zen mode, and it does not work quite right. It removed the sidebars and other things. But I couldn’t figure out a way back to normal mode. I just reloaded Obsidian.
• It has global settings that should be overridden by the settings of each prompt pack, but nothing happens to a prompt in a prompt pack if I don’t set the child settings. So, I think most of the global settings do nothing.
• It doesn’t track progress.

I am testing it currently and making notes on the changes I need, and once I think I have them all, I’ll start working on it again. I am actually using it, but it is not finished.

Here’s the repo: Obsidian Daily Note Prompts

The other Obsidian plugin idea was much simpler, so I could finish that one.

My Obsidian Development Process

After building my fourth Obsidian plugin (3 using AI), I have a process that works really well:

• I will use Kiro for now while it’s free, because it’s free and I could get results with both plugins before I hit the daily limit.
• I have a Test vault and keep all my plugin repos in the .obsidian/plugins folder of the vault.
• I test the plugin in that vault and keep notes on the improvements and changes I want to make in a note in that vault rather than sending one-off prompts to Kiro.
• When I think I have found enough for another spec in Kiro, I just paste what I’ve been collecting into another Kiro spec chat. A chat interface makes me anxious, to tell the truth, because it requires interaction. This allows me to deal with responding on my time. It also means I can plan changes even when I’ve been cut off.

Plugin #2: Joplin Portal - When AI Tools Hit a Wall

With this plugin, I simply wanted to access Joplin from Obsidian and be able to import notes from Joplin directly from the plugin. I know I can copy and paste the note or export notes from Joplin, but a plugin will make things easier.

These are the notes I gave Kiro:

• Name: Joplin Portal
• A way to access my notes in Joplin from Obsidian so I don’t have to junk up my vault
• Use the Joplin Web Clipper API to interact with Joplin: Joplin Data API | Joplin
• Add a sidebar panel that searches Joplin notes either by full text or by tag
• Also import and convert Joplin notes as Obsidian notes (template, default folder, etc) probably using the same search functionality, with a checkbox to check if you want to import that result.

This project went about the same way. Kiro created the requirements, design, and task files, and I clicked Start task over and over for 3-4 hours (while doing other things) until I discovered that there is a limit to Kiro usage and I hit it. And from what I can tell online, it’s a 24-hour break. And there was one task left, so I actually had Jules finish that task.

And it worked relatively well. The biggest issue was that the plugin was pulling in the Joplin notes as is, and Joplin references images in the note with a Joplin ID. So, unlike the screenshot above, the images were not showing. So in my next Kiro session, I worked on that.

In trying to fix this, I relearned a lesson about using AI for development. If it takes the tool more than two tries to fix something, provide the AI tool more information.

So after about 8 tries and 2 days, I gathered the information it needed myself because depending on how the note was created in Joplin, embedded images showed up in one of three formats. Then I found the function that created the preview and the function that imported the note into Obsidian. I told Kiro about all of this, and once it had that, it fixed the issue in both functions.

And it was pretty close to done, but I wanted to clean up the UI a little and give the important things a little more space. So I started another spec chat on that, and Kiro created a new set of three files called ui-improvements.

Then, to prep for submitting to the community, I had it look up the rules for plugin submission and create some specs for that as well. Now that I know I can keep adding new specs as a project grows, I might try using Kiro with something bigger than an Obsidian plugin.

Here’s the repo: Obsidian Joplin Portal

Lessons Learned

Spec-driven development workflow

Turns out there’s something to be said for planning before you code. What a concept! The three-file system is genuinely useful. When I hit a wall or need to explain a bug to Kiro, I can reference the original specs instead of trying to reverse-engineer what sleep-deprived-me was thinking at 2 AM last Tuesday.

Also, no more scope creep disguised as “quick features.” When everything is specced out upfront, it’s obvious when you’re adding random shit that doesn’t belong. That is if you pay attention instead of accepting everything as if it were only terms and conditions.

When to trust AI vs when to investigate yourself

Give any AI tool exactly two chances to fix a complex problem. After that, you’re just feeding prompts to a very expensive random number generator.

The Joplin image rendering issue taught me this lesson yet again. I spent hours watching different AI tools chase their own tails, generating increasingly elaborate solutions to a problem they didn’t understand. When I all I had to do was stop, investigate what was happening for less than an hour, and give Kiro the details.

AI tools are great at implementing solutions. They’re terrible at debugging complex integration issues that require understanding context they don’t have access to. It remains to be seen when I will actually remember this earlier.

Managing AI tool limitations and daily limits

Treat daily limits like sprint deadlines. Plan your work in chunks that can be completed within the limit, and always end each session by documenting exactly where you are. Nothing sucks more than hitting your limit mid-debugging session and forgetting what the hell you were trying to fix.

Also, don’t game the system by splitting complex tasks into tiny prompts. You’ll just confuse the AI and waste your allocation on back-and-forth clarifications.

The value of simple projects for learning new tools

Complex projects are terrible for learning new AI tools. You spend too much time fighting edge cases and not enough time understanding the tool’s strengths and weaknesses. The Joplin Portal plugin was simple enough that I could focus on Kiro’s workflow instead of drowning in business logic. The Daily Note Prompts plugin had a more going on.

Start simple. Learn the tool. Then tackle the hard stuff when you’re not also learning how to communicate with an AI that may or may not understand what a TypeScript interface is. Simple projects also fail faster and more obviously, which means you spend less time wondering if the AI is broken or if your requirements were just garbage to begin with.

Conclusion

Kiro’s free tier is basically a coding assistant on steroids with no monthly subscription guilt. While it lasts, I’m going to get my money’s worth, even though it’s not costing me any money.

The spec-driven approach works well. Having an AI that plans before it codes instead of just eyeballing everything and hoping for the best is a game changer. But… I was already building my own tool to do this before I heard of Kiro, so I know it’s not “magic.” And I also suspect that it consists mainly of system prompts.

But while it’s free… So if you see a bunch of random Obsidian plugins with my name on them over the next few months, you’ll know why. I’m not building them because the world desperately needs another note-taking plugin. I’m building them because there’s a free AI coding assistant that won’t be free forever, and I plan to learn everything I can while the learning is cheap.

And while I get side-tracked and my own AI software is not ready yet, my next post should be about using AI to build that software. The process I have works really well, and I am building a public GitHub template repository to recreate it.