Coder Legion - Recent posts tagged obsidian

Obsidian Plugin Error Logging Without Telemetry

Sat, 17 Oct 2026 16:43:33 +0000

Crash reporting feels like a solved problem until your distribution platform says the obvious solution is not allowed.

Quick solution:

type ErrorRecord = {
  timestamp: string;
  level: "error" | "warning";
  source: string;
  message: string;
  stack?: string;
};

const MAX_RECORDS = 50;

function appendRecord(
  records: ErrorRecord[],
  next: ErrorRecord
): ErrorRecord[] {
  return [...records, next].slice(-MAX_RECORDS);
}

Check the current Obsidian community-plugin developer policies before adding any reporting path; this design keeps capture local until the user chooses to share it.

For Obsidian community plugins, that boundary is explicit. The current developer policies state that community plugins must not include client-side telemetry. Network use and server-side telemetry also require disclosure.

That rules out the usual "just add a crash SDK" answer for a plugin intended for the official directory.

You still need production diagnostics, especially for startup and mobile failures. The solution is to separate capture from transmission.

Capture locally. Redact aggressively. Let the user decide whether anything leaves the device.

Start with the policy boundary

The goal is not to imitate a remote crash service secretly.

The goal is to preserve enough local evidence that a user can report a reproducible failure.

A compliant design should have these properties:

no automatic error upload;
no hidden analytics endpoint;
no third-party crash SDK;
bounded local storage;
explicit secret redaction;
user-visible controls to inspect, copy, clear, or report;
network transmission only after a deliberate user action.

If you are publishing to the Obsidian community directory, read the current developer policies before designing observability.

Use a bounded local ring buffer

A log that grows forever becomes its own reliability problem.

For a plugin, the useful window is usually recent failures, not months of historical console noise.

Store the log in the plugin's own configuration area rather than scattering debug files through user notes.

Serialize writes

Mobile and startup errors often happen close together. Multiple asynchronous writes can race and overwrite each other.

A tiny write queue is enough:

let writeChain = Promise.resolve();

function persist(records: ErrorRecord[]) {
  writeChain = writeChain.then(() =>
    savePluginData({ errorLog: records })
  );
  return writeChain;
}

This is not a database. It simply makes "append error A, then error B" deterministic.

On startup:

load the existing local log;
append any new error;
cap it;
persist the new snapshot.

A restart should not destroy the exact failure you are trying to diagnose.

Redact before storage, not before upload

If the log is supposed to stay local, it may be tempting to postpone redaction until the user presses Report.

That leaves secrets sitting unmasked on disk.

Redact before the record enters the buffer.

Your redactor should cover values your plugin knows about and common credential shapes:

function redact(input: string, secrets: string[]): string {
  let output = input;

  for (const secret of secrets) {
    if (secret) output = output.split(secret).join("[REDACTED]");
  }

  output = output.replace(
    /Bearer\s+[A-Za-z0-9._~+/=-]+/gi,
    "Bearer [REDACTED]"
  );

  output = output.replace(
    /github_pat_[A-Za-z0-9_]+/g,
    "[REDACTED_GITHUB_TOKEN]"
  );

  return output;
}

Do not log note bodies, full sync payloads, or arbitrary request content just because they are available.

The safest diagnostic is usually structural:

operation name;
error class;
status code;
sanitized message;
timestamp;
plugin version;
platform category.

Test the redactor like a security boundary

An untested redactor is a promise, not a control.

Write tests for:

exact known secret values;
Authorization headers;
token-like patterns;
stack traces containing query parameters;
multiline messages;
empty strings;
already redacted values.

Also test that ordinary technical context survives. A redactor that turns every path, SHA, and URL into "[REDACTED]" produces a safe but useless report.

Aim for minimum useful evidence, not maximum logging.

Capture global errors carefully

Plugin-specific try/catch blocks are valuable, but some failures escape them.

Where the host lifecycle allows it, register handlers for:

error;
unhandledrejection.

Normalize those events into the same ErrorRecord shape.

Just as important: unregister or bind them through the plugin lifecycle so hot reloads and plugin disable/enable cycles do not create duplicate listeners.

The global hook is a safety net, not a replacement for contextual error handling. A caught sync error can say "failed while fetching remote tree"; a global rejection may only know that a promise failed.

Give the user inspection controls

A local log becomes trustworthy when the user can see and erase it.

A small settings section can provide:

View recent errors;
Copy sanitized report;
Clear log;
Report issue.

Make the retention policy visible. If you keep 50 entries, say so.

This is especially important for privacy-oriented tools. Users should not have to reverse engineer where diagnostic data lives.

Reporting should be user initiated

A practical reporting flow can open a prefilled GitHub issue URL after letting the user preview the sanitized text locally:

const params = new URLSearchParams({
  title: "Bug report",
  body: buildSanitizedReport(records),
});

window.open(
  "https://github.com/example/project/issues/new?" + params.toString()
);

The plugin has not submitted anything at this point. It opened a browser page.

The user can:

review the text;
delete anything they do not want to share;
add reproduction details;
press Submit.

That human-in-the-loop boundary is fundamentally different from background telemetry.

A local logger cannot capture everything.

If the plugin fails before its code initializes, its own global handlers may never run. A corrupted manifest or syntax error during loading can occur outside the logger's lifetime.

Document that limitation.

Useful fallback guidance can tell advanced users how to capture the Obsidian developer console when the plugin does not load far enough to show its own report UI.

Reliability improves when a system has a known boundary rather than claiming parity with a full remote crash platform.

Keep network behavior separate from diagnostics

A plugin may legitimately use the network for its main feature. That does not mean diagnostics should piggyback on those requests.

Keep these concerns separate:

feature network request
    !=
error reporting transport

If the plugin syncs files, calls an API, or uses an AI service, disclose that according to platform rules. The local error buffer should not silently convert those connections into a telemetry channel.

The same privacy principle matters for richer workflows: users need to understand when data stays local and when a feature intentionally sends it elsewhere.

Verification and execution checklist

Read the current directory policy to ensure compliance with telemetry rules.
Store errors locally only without automatic upload paths.
Cap the buffer and serialize writes to prevent race conditions during startup.
Redact secrets before persistence and test the redactor against credentials.
Verify that issue reporting requires explicit user interaction and review.

Turning YouTube Videos Into Obsidian Notes — and What Shipping the Plugin Taught Me

Fri, 18 Sep 2026 01:29:36 +0000

Every so often I'd watch a 90-minute conference talk, close the tab, and realise the only trace it left in my vault was a URL in a list called "watch later (again)".

So I built an Obsidian plugin that turns a video into an actual note. It's been in the community directory since September and is on 0.3.0 now. This is what it does, and — more usefully — the handful of decisions and review rules I'd want to know before building another one.

What lands in the vault

One command, one link, and you get a note:

a TL;DR callout and key insights
an embedded player at the top — timestamps seek it in place, without leaving the note
chapters as timestamped bullets
optional summary (several templates), quiz, and full transcript in a collapsed callout
frontmatter with title, source, channel, language and tags, shaped for Dataview

Plus a right-sidebar chat panel scoped to the note you're reading, and a command that turns the quiz into Spaced Repetition cards.

Now the parts that were actually decisions.

The plugin holds no model keys

An Obsidian plugin runs on the user's machine. You can't ship an API key in it, and asking every user to paste their own is both friction and a support queue you will personally staff forever.

So the plugin generates nothing. It sends a video link and an account token to a server, and writes down what comes back. That's the whole client.

The honest trade-off: this means the plugin needs an account, which is a real cost to the user and something I put in the README under a Before you install heading rather than burying. A plugin that silently requires a signup is a plugin that gets one-starred.

The connect handshake, and the one line that makes it safe

Settings → Connect opens the browser at /connect/obsidian?state=…&vault=…. You sign in, the server mints a token, and the page bounces you back via obsidian://svt-connect?token=…&state=….

The state is generated by the plugin and checked when the redirect comes home. Without that check, any web page could deep-link a token into your vault — the obsidian:// scheme is open to anyone. It's four lines of code and it's the difference between a handshake and a hole.

Server side the token is stored as a sha256 hash. Client side it lands in .obsidian/plugins/<id>/data.json, which is worth saying out loud in your docs: if the user syncs their vault, that file goes with it.

One note format, two producers

The website also has an Export → Obsidian button. That's two code paths producing "the same" Markdown, which in my experience drift apart within about a week.

So the Markdown is assembled in exactly one place — a server endpoint — and the plugin writes whatever it receives verbatim. The website button and the plugin produce identical notes because they are, literally, the same function call.

Re-running a command must not eat the user's writing

People add their own notes under the generated stuff. Refreshing a note has to be non-destructive or nobody will ever press it twice.

The generated region is fenced:

%% svt:start %%
…everything the server produced…
%% svt:end %%

## My notes
whatever you wrote, untouched

Refresh replaces only what's between the markers. Frontmatter is the subtler half: the server returns an ownedKeys list alongside the note, so the plugin overwrites the keys it owns and leaves every key you added alone. Writes go through vault.process rather than read-then-write, which is also what the community review expects.

`requestUrl` doesn't stream

Obsidian's requestUrl sidesteps CORS, which you want, because your plugin isn't an origin anyone will whitelist. What it doesn't do is stream.

My summary endpoint is server-sent events. So the plugin waits for the whole response and parses the event stream after the fact. You lose the progressive typewriter effect; you keep mobile support and never fight a preflight. Worth knowing before you architect around a stream that won't arrive.

Flashcards, and only appending

0.3.0 turns the quiz into a card note: multi-line format, the right answer and its explanation on the back, and a timestamp link to the moment the question came from.

Run it again after new questions appear and only the missing cards are appended. Existing cards, their  review schedules, and any cards you wrote yourself are never touched. Rewriting a review schedule is the fastest way to lose a user who has been reviewing for six months.

What the community directory review actually checks

Submitting is no longer a PR against obsidian-releases. You log in at community.obsidian.md, link GitHub, and an automated reviewer runs. Mine came back with a list. The useful items:

No inline styles. Anything you'd reach for as el.style.foo = bar belongs in styles.css. My auto-growing textarea became the CSS field-sizing: content instead of a resize handler, which is a better implementation anyway.
Settings must use the declarative 1.13 API (getSettingDefinitions() with groups, getControlValue / setControlValue). That forced minAppVersion up to 1.13.0, because the no-unsupported-api rule rejects 1.13 APIs while you claim to support older versions. Pick a lane; you can't straddle.
Attest your build. actions/attest-build-provenance in the release workflow, with id-token and attestations write permissions. gh attestation verify main.js --owner <you> exiting 0 with no output is what success looks like.
The tag must match the manifest version, and npm version writes tags with a v prefix that Obsidian doesn't want. git tag -d v0.2.2 && git tag 0.2.2.

One false alarm worth pre-empting: right after I re-cut a release, the checker insisted "No release matches your manifest version." It had scanned during the draft window and cached that. Re-scan, it passes. Don't go rewriting your workflow like I nearly did.

Three Obsidian CSS facts that cost me an evening

.view-content ships with padding: 12px 12px 32px. If your custom view's layout looks mysteriously inset, that's why. Zero it with a same-specificity selector: .workspace-leaf-content[data-type="…"] .view-content.your-class.
On desktop the status bar is position: fixed, 27px tall, and floats over the bottom of the right sidebar. Leave it room or your input box is permanently half-covered.
button:not(.clickable-icon) picks up Obsidian's background and shadow. For a text link, use an <a>.

Links

Plugin: community.obsidian.md/plugins/summarize-video-to-text
Source (MIT): github.com/diaozxin007/obsidian-summarize-video-to-text
Setup walkthrough: summarizevideototext.com/obsidian-plugin

If you're building something that writes into other people's vaults, the markers-and-ownedKeys pattern is the piece I'd steal. Everything else was replaceable; that one is what makes a destructive command safe to press twice.

Your AI second brain has a security problem

Mon, 29 Jun 2026 08:45:00 +0000

Everyone is connecting Obsidian to Claude via MCP. Nobody is asking what's actually in their vault.

API keys in old notes. Connection strings. Client names. Tokens saved "temporarily." All of it now accessible in a single AI conversation.

The risk is indirect prompt injection. A web clip with hidden text, a shared markdown file with embedded instructions, a template from GitHub with poisoned metadata. Your AI reads it, follows the instruction, surfaces your credentials.

This isn't theoretical - Unit 42 documented these attacks in production in March 2026.

Before connecting:

grep -r "sk|aws|ghp_|Bearer |password:" /path/to/vault/
Set read-only MCP access
Check web clips in a plain text editor for content you didn't write

Building on RAG beyond personal use? Test against real attacks first Secra Simulate 64 adversarial prompts, 10 categories, free.

Build the second brain. Just audit it first.

AI Coding Tip 020 - Create a Second Brain

Sun, 17 May 2026 14:35:33 +0000

Build a Persistent Memory Layer Your AI Can Actually Use

TL;DR: Use Obsidian with Markdown notes, YAML metadata, and direct AI file access to build a Second Brain with LLMs that gives your tools persistent project context.

Common Mistake ❌

You paste a snippet of code or a problem description into an AI chat, get a good answer, and close the tab.

The next week you face the same problem again.

You search your chat history, find nothing useful, and paste the same snippet again.

Your AI starts fresh every session with zero memory of what you built, decided, or debugged before.

Problems Addressed

You repeat yourself constantly because context resets between sessions and your AI remembers nothing.
You lose architectural decisions, debugging notes, meeting commitments, and design rationale after each conversation ends.
Your AI gives generic answers because it lacks the specific context of your project and past decisions.
Mental load accumulates as you juggle multiple projects, notifications, and context switches simultaneously.
You lose track of decisions made weeks ago without a structured retrieval system.
As you age or face cognitive overload, you forget context between sessions, repeat past mistakes, and lose the thread of long-running projects.
Notification fatigue builds when every system demands your attention in real time instead of on your schedule and you forget what you were searching for.

How to Do It ️

Choose a local Markdown tool like Obsidian, Logseq, Foam, or Tolaria to store all your knowledge as plain .md files you own and control.
Organize your vault using the PARA system: Projects (active work with deadlines), Areas (ongoing responsibilities), Resources (reference material), and Archives (inactive items).
Write atomic Zettelkasten notes: one idea per file, with a unique identifier and explicit links that explain why two concepts relate, not just what they are.
Add YAML front matter to every note so your AI gets searchable, structured metadata it can query and filter:

---
title: "JWT Authentication Design"
type: architecture-decision
status: approved
component: auth-service
tags: [security, backend]
created: 2018-12-09
related: ["OAuth Flow", "Session Management"]
---

Use Dataview or Obsidian Bases to query your vault like a database and surface all tasks due today, pending decisions, or notes grouped by component with a single dynamic query; every note is a record with metadata and legible text.
Give your AI direct access to all your vault as local files so Claude, Devin, and Codex can read your entire codebase and notes simultaneously.
Create a AGENTS.md in each sub-project that points to the relevant vault sections, following the nested agents pattern from AI Coding Tip 014.
Dictate notes on the go using voice input and paste the transcript into your vault to capture context in real time without interrupting your flow.
Sync your vault to mobile and tablet using Obsidian Sync, Dropbox, OneDrive, or Syncthing so your Second Brain travels with you everywhere.
Set up OpenClaw or a local LLM (Ollama or LM Studio) to index your vault and answer questions via Telegram or WhatsApp, as a private assistant that never sends your data to the cloud.
Ask your AI to scan your vault periodically for orphaned notes, missing connections, and hidden patterns, acting as a tireless librarian that reorganizes your knowledge network over time without falling into vault-design paralysis.
Bootstrap your vault from your existing knowledge: ask ChatGPT, Claude, Grok, or Gemini to summarize and export your most relevant past conversations as Markdown notes, since you already have a Second Brain scattered across chat history waiting to be harvested.

Benefits

Persistent Context: Your AI starts every session knowing your architecture, past decisions, and current priorities instead of starting blank.
Pattern Discovery: The LLM finds connections between notes you wrote months apart and surfaces forgotten solutions to current problems.
Focus Protection: You capture every interruption into your inbox and process it on your schedule, eliminating notification fatigue.
Memory Extension: You can retrieve exact decisions and reasoning from months ago without relying on biological memory alone, making it especially valuable for senior developers, people with attention challenges, or anyone whose cognitive load has grown beyond what one brain can hold.
Privacy by Default: When you use local models like Ollama with OpenClaw, your notes, code, and queries never leave your machine.
Compounding Knowledge: Every note you add makes your Second Brain denser: the more you use it, the more valuable it becomes.
Mobile Access: You can query and update your knowledge base from any device, making your Second Brain available wherever you work.
Distraction-Free Writing: You work in plain text files with minimal formatting, much like zenware, so you stay focused on ideas instead of tools.
Visual Graph: You can open Obsidian's Graph View to see all your notes as a visual network where nodes are notes and edges are links, revealing clusters, hub concepts, and hidden connections at a glance.

Context

Tiago Forte's "Building a Second Brain" methodology introduced the CODE framework: Capture, Organize, Distill, Express.

For developers, this maps directly to how you learn, document, and reuse knowledge across projects.

Niklas Luhmann, a sociologist who wrote over 50 books, developed the Zettelkasten method using a physical slip box of interconnected atomic notes.

Your Obsidian vault is that slip box, and your AI can search, analyze, and extend it at any time.

LLMs have three types of memory: parametric (knowledge encoded during training), working (the current context window), and external (your files on disk).

Your Second Brain fills the external memory layer and gives the AI permanent access to your project-specific knowledge that survives every session reset.

Just as neural networks in LLMs store patterns in weights, your Second Brain stores patterns in linked Markdown files, extending the model's memory with your lived experience as a developer.

Andrej Karpathy captured this architecture in one sentence: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

The front matter you add to each note acts as structured metadata that significantly improves how AI retrieves and ranks relevant information.

RAG (Retrieval-Augmented Generation) pipelines embed your notes as vectors and return the most semantically similar ones when you ask a question, injecting them directly into the AI's context window.

I borrowed this idea many years ago from @Ernesto Kiszkurno and have written more than 500 technical articles since then.

Prompt Reference

Bad Article

Create a note about the movie
"Howl's Moving Castle".

Good Article

---
title: "Howl's Moving Castle"
type: movie-note
status: draft
director: Hayao Miyazaki
year: 2004
genre: [fantasy, animation, anti-war]
rating: 9/10
tags: [ghibli, miyazaki, adaptation]
related: ["Studio Ghibli", "Diana Wynne Jones"]
created: 2026-05-16
expected publish date: 2026-06-12
---

## Poster
_ _ _
IMPORT IMAGE Howls-moving-castleposter.jpg
_ _ _

## Summary
Two or three lines describing the plot without
spoiling the ending.

## Themes to Explore
Bullet list of ideas: anti-war message,
identity and transformation, Sophie's arc,
Miyazaki's pacifism compared to the novel.

## Characters
Use wikilinks: [Howl], [Sophie Hatter],
[Calcifer], [The Witch of the Waste].

## Article Ideas
Numbered list of angles for a critical article:
compare Miyazaki's changes from the Diana Wynne
Jones novel, analyze the anti-war allegory,
explore the feminist reading of Sophie's curse.

## Related Notes
[Studio Ghibli filmography]
[Diana Wynne Jones bibliography]
[War themes in animation]

Considerations ⚠️

Keep your notes in plain Markdown files, not HTML (despite current trends) or proprietary formats.

Markdown is readable by both humans and LLMs, diffs cleanly in Git, and works with every static site generator.

Don't use MCP connectors or remote APIs to give your AI access to your vault.

Point it directly at local files instead.

Direct file access is faster, cheaper, and requires no extra infrastructure.

The AGENTS.md files you create per project are part of your Second Brain, not separate from it.

If you have privacy concerns about cloud AI providers reading your notes, run a local model with Ollama or LM Studio through OpenClaw.

Your data never leaves your machine or private cloud.

Mind maps and Canvas diagrams in Obsidian help you visualize codebase architecture and sprint planning spatially, while the linked Markdown notes behind each node stay searchable by your AI.

Your files are local.

Nobody can see them, nobody can index them, and you can open any note with the simplest text editor in the world.

If you use a cloud AI model instead of a local one, you can add a guardrail to restrict what files the AI can read, so sensitive notes never leave your control.

Type

[X] Semi-Automatic

Limitations ⚠️

Large vaults with thousands of notes can slow down semantic search and local LLM indexing on low-end hardware.

Front matter requires discipline to maintain consistently: inconsistent metadata reduces query quality over time.

Local LLMs powerful enough to reason over a large vault require significant RAM (16 GB minimum, 32 GB recommended).

Tags ️

Knowledge Management

Level

[X] Intermediate

https://coderlegion.com/12537/ai-coding-tip-010-access-all-your-code

https://coderlegion.com/14016/ai-coding-tip-014-use-nested-agents-md-files

https://coderlegion.com/16461/ai-coding-tip-018-use-voice-driven-development

Conclusion

Your biological brain is for having ideas, not storing them.

Build a Second Brain from local Markdown files and give your AI direct access to it.

You get persistent context, pattern discovery, and a knowledge base that compounds every time you use it.

More Information ℹ️

https://zettelkasten.de/introduction/

https://obsidian.md

https://x.com/2039805659525644595

https://en.wikipedia.org/wiki/Book_design#Front_matter

https://blacksmithgu.github.io/obsidian-dataview/

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

https://foambubble.github.io/foam/

https://www.buildingasecondbrain.com/

https://ernestokiszkurno.blogspot.com/2021/08/second-brain.html

Also Known As

Personal-Knowledge-Management
AI-Memory-Extension
Developer-Second-Brain
Local-Knowledge-Base

Tools

Disclaimer

The views expressed here are my own.

I am a human who writes as best as possible for other humans.

I use AI proofreading tools to improve some texts.

I welcome constructive criticism and dialogue.

I shape these insights through 30 years in the software industry, 25 years of teaching, and writing over 500 articles and a book.

This article is part of the AI Coding Tip series.

https://coderlegion.com/12469/ai-coding-tips

Jules AI - The (Currently) Free Coding Assistant That Can't Follow Directions But Gets Shit Done

Tue, 15 Jul 2025 17:40:55 +0000

Jules is currently free, so I figured it was worth a try. Of course, I had to find out what I could break.

Each user gets these default limits:

5 concurrent tasks
60 total tasks per day
5 codecasts per day (still not sure what this means)

Sixty tasks a day for free? That’s really generous and it meant I didn’t have to worry about reading documentation or instructions the first time.

I Jumped in Feet First

My Obsidian plugin worked well enough for me to use it, but there were issues. Issues that I’d been ignoring because the damn thing worked and I had other shit to do. But I finally added issues to my GitHub repo.

Four issues. Nothing too crazy. Should be straightforward for an AI that can supposedly code.

I gave Jules access to the repo and told it: “I want you to work on the issues in this repository and create a feature branch for each fix. Start with the first one.”

Simple enough, right?

Jules Decides to Ignore My Instructions

Jules fetched the repo, cloned it into a VM, and read the README file. But then it discovered the “Future Enhancements” section I’d added to the README and decided that’s what it wanted to work on instead.

It completely ignored my instruction to work on the issues, the same issues that are listed right above the “Future Enhancements” section, and decided it would work on the “Interactive book selection dialog” instead.

Jules then asked me to approve the plan, but I didn’t see any way to reject it. It was going to auto-approve in about a minute anyway. I thought maybe clicking “Approve” would launch a modal where I could say “no, you illiterate AI, work on the issues I told you to work on.”

It did not.

So it started working on the wrong thing. I messaged “stop” and it replied: “I have stopped the current task. Is there something specific you would like me to do instead, or a different issue you’d like me to focus on from the README?”

It paused for a few seconds and then continued doing exactly what it was doing before.

Currently, as far as I can tell, the only way to reject a plan is to let it start, pause it manually, and then delete the entire task. User experience design at its finest.

Jules finished the feature and gave me the option to click a button to create a feature branch. So now I had a new feature to test before I could fix the actual issues I wanted fixed.

Testing the Feature that Jules Built While Ignoring My Prompt

So I pulled the branch down to the Obsidian vault I use for testing, the one with all the plugins I’m developing loaded up. There was one error in the code, in unit tests I never asked Jules to add:

tests/main.test.ts:160:35 - error TS2554: Expected 0 arguments, but got 1.
sortAnnotationsByCFI: jest.fn((ann: Annotation[]) => ann), // Simple pass-through

I just deleted the broken test.

It took me a while to figure out that the selection modal didn’t launch via the sidebar button like I expected. I had to hit Command+P and find the command to launch it. But you know what? It actually worked.

Since the feature worked, I merged the change and created a new release. Then I did some reading to figure out how to prevent Jules from going off on another tangent.

Back to Fixing Bugs (This Time With Feeling)

I thought maybe I should be more descriptive, but there wasn’t much to be descriptive about. There are issues. I added them to the repo. They’re also in the README that I know Jules can access. Most of the example prompts are very short, shorter than what I’d already tried.

So I tried again: “This github repo has 4 issues listed here: https://github.com/eristoddle/apple-books-annotation-import/issues. Give me a plan for fixing the first issue. If you have no access to these, let me know. Do not do anything else.”

This time it worked.

Both the accidental feature and the bug fix took very little time. I was actually surprised by the speed. But Jules created broken unit tests again. I figured maybe it was because I didn’t have my npm and node versions in the package.json, so I added those and deleted them again.

It actually fixed the bug and at least doubled the number of book covers I was getting.

The Great Color Mapping Mystery

The second issue was about finding annotation colors.

Me: “Fix this feature in the repo: https://github.com/eristoddle/apple-books-annotation-import/issues/5. Do not do anything else.”

I think “Do not do anything else” will be part of my prompt from now on.

Jules said: “The code changes have been reviewed for syntactical correctness and logical soundness. Direct testing with an Apple Books database is not possible, so final validation will be up to the user.”

Translation: “I changed some code and it compiles. Good luck!”

After testing, I told Jules: “Now it seems like there are no annotation color indicators at all in the md files. Before they were all just purple. Now they are just not there at all.”

The second attempt produced different colors, but they didn’t match the highlight colors in the Books app.

I mapped the colors Jules gave me to the actual colors and told it about the differences: “The color images are back and there are a variety of them, but they do not match the colors in the Books app. Here is how they differ (Books app color → markdown color): underline → both yellow and underline, purple → no icon at all, pink → red, yellow → purple, blue → blue, green → green.”

I even included the log showing the distinct annotation style values from my test database. So this bug took three interactions, but Jules finally got the color mapping right.

Taking It to the Big Leagues

My main Apple Books account has 4000 books and over 60 books with highlights. When I first worked on this plugin, the database structure was different, so I wanted to make sure everything worked in the wild before calling it done.

The plugin handled the larger database just fine. All the covers loaded correctly, and the color annotations matched what I saw in the Books app.

Everything I Fixed In This Change

It took about two hours total, not counting the issue Jules couldn’t fix. I let it code while I took notes for this article, worked on Obsidian cleanup, and checked out Reddit for a while.

Here’s what got implemented:

✅ New interactive ebook selection dialog: By accident when I was asking Jules to fix issues, but I’m counting it as a win.

✅ Fixed finding ebook covers: This was the original first issue. Jules doubled the number of covers the plugin could find.

✅ Fixed annotation color icons: Took three tries and some detailed feedback, but now the colors match what’s in the Books app.

✅ Fixed missing annotation dates: This needed a second attempt. I had to tell Jules: “I have include dates set to true and include citations set to false. There are no dates in the markdown files though.” But it got it right the second time.

❌ Did not fix gibberish in epub chapter names: This one turned into a nightmare. The TypeScript build error migrated from the tests that never worked. I tried to get Jules to fix it once and it failed. The second time it was thinking forever, so I tried Copilot in VS Code, and that fixed the build.

But then there was a runtime error I’d run into before when Claude Code tried to use a Node.js ebook parsing package. Something about not being able to access the file system in Electron. I went round and round with Jules on this one and finally gave up.

One thing I realized is that I could tell Jules to build the app to test the build and fix issues, but I had to make it a command. When I asked “Did you build the app to test it?” it said that wasn’t possible. But when I just told it to build the project, it did it.

So I let it churn through fixing the build errors for 30 minutes. When I tested the result, the chapters still weren’t fixed. But I didn’t expect this one to be easy without doing some research first.

I used 5 of my available 60 free tasks for the day.

Jules: Fast, Confused, but Generally Useful

Jules is fast. That surprised me. At least until there’s back and forth on changes, then the conversation slows down.

It was done with the next fix before I finished testing the previous one. I added one feature I didn’t plan on and fixed four issues in a little over an hour.

But Jules went off on a weird tangent when I gave it what I thought were specific instructions. There seems to be no real interaction other than the first message and accepting the plan. I was worried about fixing issues in a branch it created if something didn’t work.

Using a task like it was a chat and trying to fix more than one issue per task got confusing. Then I figured out I needed a different workflow:

1 chat per branch, but can do multiple related things
1 chat can be as big as 1 feature
Code review each branch
If there are issues, go back to the chat and have Jules fix them
If there are build errors, tell Jules specifically to build the app again, test, and fix any errors.
Pull and test again

I was used to my Claude Code process where everything happened in the branch I was on locally. The “Publish Branch” button in Jules seemed scary at first, but the second time I used it, it just pushed modifications to the existing branch. I was expecting merge conflicts or some other drama.

Most things I asked Jules to do worked well, except for the chapter names issue. I also didn’t ask it to create unit tests, but it kept creating broken ones anyway. It each branch it created, I ran them once and if they failed, I deleted them. They mainly failed because of TypeScript type issues.

The Future of Lazy Coding

Sixty tasks a day for free is generous. I’m planning to move everything I have to GitHub that isn’t already there and create issues for any feature ideas or bugs I encounter.

I could envision a process where:

A user puts in a support request
An issue gets created on the repo
I tell Jules to fix it
Jules fixes it, creates a custom build, and the user tests it (don’t know about this, but I can dream)
If the fix works, I merge it and create a new release

I’m not sure exactly how this process would work in practice, but the potential is there.

Verdict: Worth the Price of Free

Jules isn’t perfect. It ignored my initial instructions, created broken unit tests, and couldn’t fix the most complex issue I threw at it. But it’s fast, it’s free for now, and it actually solved most of the problems I needed solved.

In two hours, I got a new feature and fixed three out of four issues that had been sitting in my backlog. The fourth issue would have taken me some research into ePub structure even doing it manually.

I’m definitely planning to shift more of my “vibe coding” projects to Jules. At 60 free tasks per day, I can afford to let it work on the boring stuff while I focus on the interesting problems. In fact, to use 60 tasks a day, I might have to try running concurrent tasks and I can do 5 of those.

And if it goes off on another tangent and builds something I didn’t ask for? Well, sometimes the best features are the ones you never knew you needed.

️ Obsidian: Restaurant's rating

Mon, 24 Feb 2025 08:54:04 +0000

Obsidian: Restaurant's Ratings

I have a very bad memory, which is why I am so obsessed with having systems that make it easier for me to search for information. Many times, if I don't structure it very well, I won't remember how I saved it and will end up losing it anyway. This is a big part of why I like Obsidian so much as a tool; it allows me to structure things in a way very similar to how I do it mentally, meaning in relationships.

Due to this same lack of memory, I have encountered situations where, for example, I am someone who does not tolerate spicy food very well. So, when I go to a restaurant and want to order chilaquiles, I don't remember if last time I ordered the green ones and they were too spicy, or if they were fine, or if the red ones were better, etc. To solve this, as in many other areas of my life, I have a system that helps me organize this information so that I can revisit it easily the next time I go to the restaurant. This way, I can see if I liked something, what details it had, how much I liked it, etc.

Parts

My system consists of 3 parts:

Restaurant: The establishment or chain.
Dish: The specific dish I am going to rate.
Journal: This is usually linked thanks to the fact that in my Journal I log my meals.

The Restaurant

I create a note for the restaurant because this will be the note I visit when I return to that place. Additionally, I use this note so that, when creating a new dish, it can be linked to the restaurant it belongs to.

The structure is very simple. For this example, I will use my note about McDonald's.

General Structure

---
tags: 
- place 
- restaurant
---

#  McDonald's
## ⭐ Recommendations 

```dataview 
TABLE 
calificacion as "Rating" 
FROM [[]] 
WHERE calificacion 
```

##  Last Visit 
```dataview
LIST WITHOUT ID link(dateformat(file.cday, "dd-MM-yyyy")) 
FROM [[]] 
SORT file.cday DESC 
LIMIT 1
```

Example Note

Now let's break down each part of the note.

⭐ Recommendations

The recommendations are nothing more than a Dataview view that compiles all Dish notes, which we will see later, and displays them along with the rating I assigned. As shown in the image, I am a big fan of McDonald's.

Last Visit

Finally, this section simply searches for the most recent entry that references the establishment and shows me the corresponding note for that date.
This is one of the parts I like the least because it requires me to explicitly mention the establishment in my Journal note. I want to improve the query so that it detects when I reference a dish linked to the establishment, but I haven't had time to do so.

The Dish

This note refers to the dish itself. I use this note from the restaurant, linking the note to the restaurant in the title to later retrieve the rating, but also to store nutritional information about the dish. This is more related to the nutrition aspect, so I won’t cover it here.

General Structure

---
calificacion: 5
tags:
  - dish
---

#  McMuffin Regular from [[McDonald's]]

My opinion on the food. Any *detail* I should remember.

##  Nutritional Information 
[Calories:: 310 kcal] 
[Proteins:: 12 g] 
[Fats:: 13 g] 
[Carbohydrates:: 20 g] 
[Fiber:: 2 g] 
[Sugars:: 2 g]

The dish has the tag dish to make it easier to filter in queries. Additionally, I include the rating in the metadata on a scale from 1 to 5.

In the body of the note, I can include any relevant information, such as whether the food was too spicy, if I should order it without tomato, or anything I want to remember for my next visit.

✍ Journal

I won’t show my journal because it contains private information, and besides, there isn’t much complexity to it. It simply involves mentioning the restaurant note in my journal entry.
Once again, this is the part of the system that I like the least because it only works if it’s my first time at the place and I create dish notes, or if I make an explicit mention.
If you have a better idea on how to ensure that each time I mention a dish note in my meals section, it gets "logged" as a visit, I would be very grateful if you left me a comment.

Conclusion

This system in Obsidian has allowed me to improve my organization and memory regarding restaurants and dishes I have tried. Although it has some areas for improvement, such as automating the last visit, its modular structure has been quite useful. In the end, the important thing is to have a system that adapts to my needs and can evolve over time. If you have suggestions on how to improve this methodology, I would love to hear them. Thanks for your time!

Coder Legion - Recent posts tagged obsidian

Obsidian Plugin Error Logging Without Telemetry

Start with the policy boundary

Use a bounded local ring buffer

Serialize writes

Redact before storage, not before upload

Test the redactor like a security boundary

Capture global errors carefully

Give the user inspection controls

Reporting should be user initiated

Be honest about blind spots

Keep network behavior separate from diagnostics

Verification and execution checklist

Turning YouTube Videos Into Obsidian Notes — and What Shipping the Plugin Taught Me

What lands in the vault

The plugin holds no model keys

The connect handshake, and the one line that makes it safe

One note format, two producers

Re-running a command must not eat the user's writing

requestUrl doesn't stream

Flashcards, and only appending

What the community directory review actually checks

Three Obsidian CSS facts that cost me an evening

Links

Your AI second brain has a security problem

AI Coding Tip 020 - Create a Second Brain

Common Mistake ❌

Problems Addressed

How to Do It ️

Benefits

Context

Prompt Reference

Bad Article

Good Article

Considerations ⚠️

Type

Limitations ⚠️

Tags ️

Level

Related Tips

Conclusion

More Information ℹ️

Also Known As

Tools

Disclaimer

Jules AI - The (Currently) Free Coding Assistant That Can't Follow Directions But Gets Shit Done

I Jumped in Feet First

Jules Decides to Ignore My Instructions

Testing the Feature that Jules Built While Ignoring My Prompt

Back to Fixing Bugs (This Time With Feeling)

The Great Color Mapping Mystery

Taking It to the Big Leagues

Everything I Fixed In This Change

Jules: Fast, Confused, but Generally Useful

The Future of Lazy Coding

Verdict: Worth the Price of Free

️ Obsidian: Restaurant's rating

Obsidian: Restaurant's Ratings

Parts

The Restaurant

General Structure

Example Note

Tags

⭐ Recommendations

Last Visit

The Dish

General Structure

✍ Journal

Conclusion

`requestUrl` doesn't stream