Skip to main content
user@aqno:~$ cat from-logseq-notes-to-a-local-dashboard-someone-else-can-run.md

From Logseq Notes to a Local Dashboard Someone Else Can Run

Written by Giuseppe Aquino
Published on: 2026-07-29
logseq, markdown, workflow, ai, side-projects

I keep a lot of work context in Logseq: linked pages, properties, short history entries — the kind of structure that makes sense when you open a note and read it top to bottom. What it does not give you is a single screen where the same facts sort, filter, and answer planning questions without opening fifteen files.

So I built a small local dashboard on top of those notes. Think of it as a private overview page: columns, filters, a place to scan status at a glance. Notes stay the source of truth. A script reads them. A local HTML file becomes the view. No SaaS, no shared database, no accidental screenshot in a cloud folder.

Then I packaged the same idea as a plain folder a coworker could open on his data: notes, scripts, rules, and AI skills. Fitting his existing spreadsheet took one prompt to the assistant — a similar layout helped it understand what was going on. Twenty minutes in, he had his own dashboard and was already changing things through chat.

This post is about that pattern — not the sensitive contents of either dashboard.

The problem notes do not solve alone

Structured notes are excellent at provenance. You can see when something changed, who it refers to, and what you meant at the time. You can hand the same files to an AI assistant and get useful edits, which is the thread running through the Markdown bridge post and the Cursor / Claude writeback post.

They are weaker at overview. Planning work wants columns, totals, filters, and a calm place to scan status without reconstructing it from outline indentation. A spreadsheet can give you that overview — and then you live inside cells forever, with none of the narrative history or AI-editable structure I already had.

I did not want to abandon the vault. I wanted a disposable view over durable notes.

Loop one: vault notes → private HTML

Inside my Logseq vault, a subset of pages follows a consistent shape: typed properties, repeated section headings, and fields a person or an agent can update without inventing a new format each time. The sensitive ones stay encrypted at rest in Git. The generated dashboard never ships with the vault — it is rebuilt locally when I need it.

The pipeline is deliberately boring:

structured notes (source of truth)


parse + aggregate (Python)


single local HTML file (not committed to Git)

Regenerate after edits. Open the file. Sort and scan. Close it. The HTML is a snapshot, not a second database. If the parser and the notes disagree, the notes win — you fix the parser or the data structure, then rebuild.

That boundary matters. Visualization is allowed to be opinionated. The vault remains the place where history, wording, and review still live as text.

I will not walk the field list here. The useful claim is architectural: if your notes already have a consistent shape, rendering is mostly extraction plus a thin UI shell.

Loop two: hand someone a folder

A private vault tool helps one person. A coworker has no reason to adopt my Logseq layout, and I did not want the pitch to be “please start living in my note app.”

So the second step was not “share my dashboard file.” It was “give them a folder”: plain note files, a script that rebuilds the HTML, a few rules that describe the expected shape, and Cursor / Claude skills for common edits. Open the folder, point an assistant at it, work.

What they get is closer to a small local web app than to a spreadsheet — sortable HTML, filters, a toggle that hides sensitive numbers on screen — except the writing side is handled in chat. You say “add feedback…”, “edit numbers…”, “edit stuff…”; the assistant updates the note files; you regenerate and the view refreshes.

The folder ships with:

  • Plain YAML notes instead of Logseq markdown pages — same idea, fewer editor assumptions
  • Rules + skills so first-time setup and routine edits stay on the expected shape
  • Import helpers when someone already has data in a spreadsheet (map columns once; often one prompt if the layout is close)
  • Local HTML output, rebuilt from the notes, kept off Git

The sample data in the folder is fake on purpose. You replace it with your own when you start.

folder (notes + rules + skills + scripts)

        ├── chat edits the notes

        └── regenerate → local HTML (feels like a web app)

Logseq was the proving ground. The shareable version is the same loop without the vault: structured files in, dashboard out, assistant for the writes.

The twenty-minute coworker test

We tried it with a coworker’s own data — not the fake samples.

Rough shape of that session:

Step About
Fit existing data into the notes one prompt
Own dashboard open, working via chat ~20 minutes total

“Fit” meant turning his spreadsheet into the note files the dashboard knows how to read — matching columns, filling in a couple of labels, regenerating the page. Not rewriting how he plans. The sheet already looked close enough to what the folder expected that the assistant could map it without a long discovery loop. Once the notes existed, rebuilding the HTML was the same command I already use on my side. Chat worked because the folder already carries the rules and skills; the assistant did not have to invent a data model mid-conversation.

That is the part I care about for other domains. The hard work is not the chart library. It is agreeing on a data structure small enough to maintain and strict enough to parse — then packaging rules and skills so someone else can treat the folder like a spreadsheet that grew a web UI and an editor that talks back.

What this is not

  • Not a hosted multi-tenant app. Files stay on the machine that generated them.
  • Not a replacement for whatever system already owns the official records. It is an overview and planning layer over notes you maintain yourself.
  • Not a tutorial for cloning my private vault. The vault path is personal; the portable path is the shareable folder above.
  • Not a walkthrough of the domain data. The interesting part is the pattern, not the contents.

If you only remember one sentence: structured notes plus a regenerate step beat a dashboard that slowly becomes the source of truth.

Why the pattern travels

I keep returning to the same bet across projects: durable context in plain files, tools that read and write those files, UIs that can be thrown away and rebuilt.

A Logseq visualization proves the bet under real daily use. Handing a coworker the folder tests whether the bet survives contact with someone else’s data and habits. One prompt to fit, twenty minutes to a working chat-driven dashboard, is early evidence — not a universal benchmark — but it is the kind of evidence that comes from sitting next to real data instead of a slide about “knowledge graphs.”

Maybe this is how we share “spreadsheets” in a few years: not a grid file that forces everyone into the same cells, but a small folder of data plus enough rules and scripts that an assistant can grow a local app around it. The shape still needs refinement. Collaboration, versioning, and the boring parts of product polish will take real work.

Even now, though, it feels a little magical. Point an AI at structured data and get a private web-ish surface back — sortable, regenerable, editable through chat — without standing up a product team for every planning sheet. That alone is worth taking seriously.

EOF