reza.rosli
← All cards

Tools & ideas

From a shared brain to a Jekyll connectome

Static publishing for connected notes

It started as a shared brain

The starting point was not a website generator. It was the idea behind Making a shared brain with my GenAI buddy: could I work with an AI collaborator to organise ideas as small, connected notes rather than forcing everything into one long document or backlog?

That changed how I approached the content of this site. Experiences, projects, practices, tools, learning, and current questions could each become a note with its own identity. The value was not only in the individual note, but in explaining why one note leads to another. A role can point to a project; a project can point to the technology used; an idea can connect several periods of work without pretending they are the same thing.

Those notes became the connected cards. Together they form the connectome: a map of the practice that can be explored as a network or browsed by category.

The content model now makes a sharper distinction: a card should carry one idea that can stand alone and connect to other ideas; a page can organise, list, or structurally compose several things. The homepage, category directory, and changelog are pages. The ideas they point towards are cards.

Jekyll gave the notes a durable form

I wanted the cards to remain ordinary, inspectable files. Jekyll collections provided the right structure: every card could live as a Markdown document with front matter for its title, stable address, category, résumé reference, and authored connections. Layouts and includes could turn those files into a consistent site without hiding the source inside a database.

The site now derives incoming links and prose mentions from those files, checks the relationships, and rejects broken internal destinations during a full build. Stable permalinks keep existing card addresses intact even when a title changes. The public result is still static HTML: following a connection does not depend on an AI service, database, or application server.

The connected-notes implementation explains the relationships and backlinks in more detail. The category guide explains why roles, projects, practices, tools, and current explorations remain distinct even when they connect.

The AI assistant works with the same visible material

My AI tools now act as an intelligent assistant around this file-based system. They can help me create a card, find related notes, propose a connection, update a template, or run the build checks. Because the content and rules are visible in the repository, I can inspect the exact change rather than accepting an opaque update to a remote CMS.

That does not hand editorial responsibility to the tool. A suggested relationship is not automatically true, and fluent copy is not evidence that a project happened. I still decide what belongs, check the source material, review the diff, and own what is published. How I use AI describes that working relationship and its boundaries.

From files to a visual content studio

Direct editing and coding assistants are useful, but the card system has enough structure to deserve an interface of its own. I am building a local visual content studio with Vue 3 and Fastify. The aim is to browse the rendered site, select supported content, edit structured fields, inspect a source diff, and rebuild the preview without replacing the Markdown, YAML, Jekyll, or Git workflow underneath.

The studio and a local MCP server share one semantic content service. Relationship suggestions remain proposals until a person reviews and applies them, and every write checks the source revision so an external edit cannot be silently overwritten. The experiment is local authoring infrastructure, not part of the public site or a second source of truth.

The original shared-brain card still provides the organising idea: small notes gain meaning through explicit connections. The existing build and link validation remain the final guardrail, while the studio makes the structured parts—slugs, categories, relationship targets, reasons, and résumé anchors—more visible to work with.

Jekyll builds; Cloudflare publishes

Jekyll is the content and build layer. It turns the notes, metadata, layouts, and relationships into portable static files. Cloudflare is the publishing layer for this site, serving the generated output through Workers Static Assets.

Keeping those responsibilities separate matters. I can change the authoring interface, work with a different AI assistant, or move the generated site to another static host without changing what a card is. The shared brain is in the notes and their connections; Jekyll gives it form, the assistant helps me work with it, and Cloudflare gives the result a public address.

Inside Markdown, Liquid includes keep internal addresses stable. For example, [Connected notes]({% include card-url.html slug='connected-notes' %}) asks Jekyll for the card’s canonical URL instead of hard-coding it. A page can also use loops, includes, and HTML when it needs to assemble a larger structure; that freedom is intentionally different from a card’s editorial focus.

For the implementation details, read Building Jekyll for Cloudflare Workers. To explore the result rather than the machinery, open the connectome.

Browse the connectome Jekyll collections documentation

Immediate connections

Explore the cards directly connected to this one.

Connected cards

Follow links in either direction, or find cards that mention this one.

Show