DEV Community: Stephane Paquet

Markify, Markdown without the markup

Stephane Paquet — Mon, 05 Oct 2026 19:24:48 +0000

What I Built

Markify is a free native Markdown editor for macOS 26. It turns notes, specifications and agent reports into a clean page you can read and edit, while keeping the underlying files plain Markdown.

It’s built for developers and writers who want less friction between their thoughts and their documents. It currently has no dedicated outdoor feature.

Demo

Explore Markify and see screenshots: Markify (https://spaquet.github.io/markify/).

Code

spaquet / markify

A native Markdown editor for macOS with rendered and Markdown views in a single pane.

Markify

A quiet Markdown editor for macOS 26. Write on one rendered page, press ⌘/ to see the same text as plain Markdown, and let on-device Apple Intelligence proofread and rewrite. No split preview pane.

Website: spaquet.github.io/markify

The same document in the Rendered lens (left) and the Markdown lens (right).

Features

One page, two lenses: Edit in place with headings, tables, code, math and images rendered. ⌘/ crossfades to the Markdown source and keeps your caret and scroll position.
Format bar: Select text to get a floating glass bar for block style, bold, italic, strikethrough, code and links.
Slash menu: Type / to insert tables, task lists, code blocks, callouts, math, images, footnotes or frontmatter. Each row shows its Markdown shortcut.
GitHub-Flavored Markdown and more: Tables, task lists, callouts (> [!NOTE]), $…$ / $$…$$ math, footnotes and YAML frontmatter.
Library: A glass sidebar…

View on GitHub

The source is available under MIT with the Commons Clause.

How I Built It

Markify uses SwiftUI and TextKit 2. Two editable views share the same Markdown source: a rendered page and the Markdown itself.

Plugins let coding agents send reports into Markify. Its built in AI features use Apple Intelligence on the Mac; these are not open weight models.

Why Does Open Innovation Matter?

Plain Markdown keeps the documents portable. People and agents can read, edit and version the same files without depending on one service.

Source availability lets others inspect and adapt Markify. Its current AI implementation, however, does not demonstrate an advantage from open AI over a closed API.

How Markdown became the new programming language

Stephane Paquet — Mon, 05 Oct 2026 19:21:20 +0000

How Markdown became the new programming language

Do you remember Terminator 3: Rise of the Machines? Beyond Kristanna and Arnold making an entrance, what stayed with me was all that sophisticated technology. Machines taking over the world seemed to require some pretty impressive hardware.

It's 2026, and the machines in my working day can already read a project, write code and run commands. What tells them what to do? A bunch of Markdown files.

Rise of the Markdown. Somehow, I don't think that title would have sold as many tickets.

I certainly didn't expect those files to become such a big part of my job.

Two years ago, I was already using AI every day. I asked questions, pasted code into chat windows and accepted autocomplete suggestions. But I still opened the files, wrote the Swift and fixed the build.

Today, much of my work starts differently. I describe a feature, let an agent implement it, then read, test and question the result. I still care about the code. I just spend more time writing the instructions that produce it.

The file I keep coming back to is AGENTS.md.

The README started giving orders

For years, Markdown explained software after someone built it. Installation instructions. API documentation. The README we promised ourselves we would update later.

Now those same files can influence what gets built in the first place.

AGENTS.md gives coding agents a place to find project context, build commands and conventions. The Agent Skills format puts reusable instructions in a SKILL.md file, alongside any scripts or references a task needs.

By 2026, this is a very practical use for a format I once associated mostly with GitHub READMEs. A Markdown document can describe the project. Another can explain how to perform a task. A third can record the plan before the agent touches the code.

These files don't execute themselves. The agent reads them and turns their instructions into actions. That makes the quality of the writing matter in a way ordinary documentation rarely did.

Consider the difference between asking an agent to “improve the editor” and giving it this:

Both editing views share the same Markdown source. Changing how the document looks must never change its text. Preserve selection offsets and undo history. Run the editor tests before calling the task complete.

That paragraph describes constraints, names failure conditions and defines a check. It gives the agent something concrete to work with, and gives me something concrete to review.

Why this slightly awkward format?

Markdown was designed for readable text that could become HTML, not for directing machines. Yet its original appeal fits this new job surprisingly well.

A heading separates the goal from the constraints. A code block preserves the exact command. A link points to the design decision behind a rule. You can read it all in a terminal without needing the app that created it.

And it is still a file. Put it in Git and you can see who changed an instruction, discuss the change and recover the previous version.

I find that more useful than another clever prompt sitting somewhere in my chat history.

Files also give agents a place to recover context. A new session can read the decisions from the last one, provided the relevant documents are actually loaded. It isn't magical memory. Somebody still has to keep those notes accurate.

Writing becomes part of engineering

Calling Markdown a programming language is a stretch in the literal sense. There is no compiler checking whether “keep this simple” means the same thing to me and to the model.

That's exactly where the work gets interesting.

A vague specification leaves room for plausible mistakes. An outdated instruction can send several sessions down the same wrong path. A good plan makes those assumptions visible before they become hundreds of lines of code.

I've started treating these documents with more care: fewer vague requests, clearer constraints, explicit checks. The generated code still needs review and testing. Writing a convincing plan doesn't make its implementation correct.

Why I built Markify

Spending more time in Markdown also made me want a better place to read it.

An agent's long report is easier to think about as a document than as another wall of terminal output. The same goes for the specification I'm about to hand back to it.

That's part of why I build Markify, a free native Markdown editor for macOS 26. I can write on a rendered page, then press ⌘/ to see the Markdown underneath. Both views work on the same text, and the saved file stays ordinary Markdown that an agent or another editor can use.

For me, that is the useful middle ground: a comfortable page to think on, and a plain file to keep.

The rise of the machines has been less cinematic than I expected. In my working day, it looks like an agent waiting for me to explain what I mean.

Increasingly, I explain it in Markdown.

Which file gets more of your attention now: the implementation, or the instructions behind it?

The files I still write are Markdown

Stephane Paquet — Tue, 29 Sep 2026 05:00:00 +0000

A few months ago the editor that mattered was the IDE. Zed, VS Code, Vim, whatever let me move fast in code.

Most of my work now sits with coding agents. They write the change, they draft the review, they leave notes in the repo. What I still own by hand is the Markdown around that work: AGENTS.md, CLAUDE.md, READMEs, design notes, decision logs. Those files are the context and memory the next agent will read. If they are stale or messy, the agent gets a worse picture of the project than I do.

That shift is easy to miss because the files look small. They are not the product. They are the instructions sitting next to the product. Agents pick them up first. So do new contributors. So do I, three weeks later, when I have forgotten why a decision was made.

IDEs are fine at opening a .md file. I needed something better. Split preview. Syntax soup. A ribbon that has nothing to do with the document. A marketplace plugin that wants to become its own product inside the editor I already fight with.

I wanted something fast, local, and intuitive, switch to source when I need it and get back to the rendered page without fighting the tool. One last requirement: no plugin.

That last one matters more than it sounds. Plugins inherit the IDE's layout, its settings model, its update cycle. I did not want Markdown quality to depend on whether the right extension was installed on this machine today.

That is the gap I built Markify to fill. Native Mac app. Ordinary .md files. Rendered page and source as two views of the same text. The caret stays put when you flip. Git sees exactly what you typed.

It is not a second brain. It does not sync your life into a cloud vault. It opens the file, lets you read it as a page, and writes Markdown back to disk.

Source is on GitHub here:
https://spaquet.github.io/markify/

Gemtracker ❤️ CLI

Stephane Paquet — Sun, 12 Apr 2026 21:15:15 +0000

For those of you who prefer CLI or need to test their gems in a CI pipeline or AI workflow: Gemtracker offers CLI export features.

It supports 3 output formats: JSON, CSV and text. You can decide to have them exported to the terminal or to a file using the --output path/to/file.

GemTracker vs bundler-audit vs Trivy

Stephane Paquet — Sun, 12 Apr 2026 05:55:32 +0000

If you maintain Ruby apps, you already know the drill: run bundle outdated, then bundler-audit, maybe fire up Trivy for extra security, and still end up jumping between terminals, GitHub issues, and CVE databases just to feel confident about your dependencies.

I got tired of that dance. So I built GemTracker — a single terminal command that gives you everything in one interactive TUI.

Here’s a clear, up-to-date comparison (GemTracker v1.2.6) of the three tools developers actually use:

Feature	bundler-audit	Trivy	gemtracker
Interactive TUI	❌	❌	✅ (tab-based: Gems / Search / CVE + keyboard nav)
Vulnerability Scanning	✅	✅ (RubySec + NVD + others)	✅
Dependency Tree Visualization	❌	✅ (origin tree with `--dependency-tree` flag)	✅ (forward + reverse trees in Gem Details)
Group-Based Analysis (default/dev/test/prod)	❌	❌ (scans dev deps but no group visibility)	✅ (explicit Groups column + impact notes)
Outdated Gems Detection	❌	❌ (vuln-only)	✅
Gem Maintenance / Health Status	❌	❌	✅ (🟢 Healthy / 🟡 Warning / 🔴 Critical from RubyGems + GitHub)
Direct Links to RubyGems & GitHub	❌	❌	✅
Multiple Report Formats for CI/CD	✅ (text + JSON)	✅ (table / JSON / SARIF / CSV-like via template / SBOM)	✅ (text / CSV / JSON + `--report` + `--output`)
AI-Ready JSON + Workflow Integration	❌	✅ (JSON output usable for AI)	✅ (dedicated AI_GUIDE.md + Claude `gem-check` skill + JSON parsing examples)
Fix / Mitigation / Workaround Suggestions	✅ (solution field in output)	✅ (fixed version shown in table)	✅ (proposes via AI skill + vulnerability comments + recommendation decision trees)
Caching for Performance	❌	✅ (automatic DB + scan cache)	✅ (per-project cache in `~/.cache/gemtracker/`, auto-invalidated)
Project Sanity Checks (multiple versions, etc.)	❌	❌	✅ (version management + health + outdated + sanity indicators)
CI/CD Exit Codes & Pipeline Examples	✅	✅ (excellent native support + examples)	✅ (dedicated export mode + exit codes 0/1 + GitHub/CircleCI/GitLab examples)

Why GemTracker feels different in practice

You stop switching tools. Everything — outdated gems, CVEs, dependency impact, and health signals — lives in one fast, keyboard-driven interface.
You actually understand impact. Forward and reverse dependency trees show you exactly which parts of your app will be affected before you upgrade or patch anything.
You get real maintenance intelligence. The health indicators (Healthy / Warning / Critical) pull live data from RubyGems and GitHub so you can spot abandoned or risky gems at a glance.
You ship safer code faster. One command gives you clean reports for CI/CD, plus AI-ready JSON and ready-to-use Claude skills when you want to automate deeper analysis.

I didn’t set out to replace bundler-audit or Trivy. I just wanted a tool that finally gave me the complete picture without the friction. GemTracker is the result.

If you’re a Ruby developer who’s ever felt dependency anxiety, try it on your next project. You’ll probably wonder how you lived without it.

What do you think — does your current workflow still feel fragmented? Drop your experience in the comments.

How to Ensure Your Ruby Gems Stay Up-to-Date, Well-Maintained, and Secure

Stephane Paquet — Wed, 08 Apr 2026 10:52:17 +0000

The answer is simple: use gemtracker the missing TUI and now CLI tool to keep your gems in check.

Since v1.0.5, GemTracker has evolved into an even sharper tool for keeping your dependencies healthy.

The new release focuses on three core benefits every Ruby developer cares about: visibility into gem maintenance, smarter security insights, and frictionless integration into your workflow.

What’s new in v1.1.4

Live Gem Health Indicators

Instantly see which of your gems are 🟢 healthy, 🟡 at risk, or 🔴 critical — right in the main list. Full health details (last release, stars, issues, maintainers). No more guessing if a dependency is abandoned.
Claude Code Skill (/gem-check)

Get AI-powered analysis directly in Claude Code: prioritized vulnerability detection, smart upgrade recommendations, and practical migration advice — all security-first.
CI/CD-Ready Reports

One-command exports (text, CSV, JSON) with full vulnerability and outdated-gem data. Perfect for pipelines, compliance checks, or automated audits.
Broader Project Support

Now understands gems.locked, gems.rb, and .gemspec files (including runtime vs dev dependencies and version constraints). Works even when you don’t have a classic Gemfile.lock.
Polished Everyday Experience

Filter view is now a clean centered modal that keeps your gem list visible. Layout is rock-solid across every screen, and official releases include built-in error tracking for better reliability.

GemTracker remains the zero-config terminal app that gives you complete visibility into your Ruby project: outdated gems, security risks, dependency trees, project metadata, and now real-time maintenance health — all in a beautiful, keyboard-driven interface.

If you want to make sure the gems in your app are up-to-date, well maintained, and do not present any security risk, give v1.1.4 a try.

Links

GitHub: https://github.com/spaquet/gemtracker
Official site: https://gemtracker-website.spaquet74.workers.dev/

Feedback, stars, or issues are always welcome — they directly help shape the next improvements.

Happy bundling! 💎

Gemtracker v1.0.5 is here!

Stephane Paquet — Sun, 05 Apr 2026 02:30:38 +0000

Gemtraker is a terminal-based TUI (written in Go with BubbleTea) that makes it way easier to understand and manage your Ruby bundle.

Just run it in any project that has a Gemfile.lock and you instantly get:

Full visibility into every gem version (direct + transitive dependencies)
Outdated gem detection with latest version info
CVE/vulnerability highlighting so you can quickly spot risky transitive gems
Interactive dependency tree (forward & reverse)
Tabs for Gems, Search, CVEs, and detailed views with direct links to RubyGems & GitHub

It’s perfect for day-to-day dependency hygiene and compliance work (SOC 2, security audits, etc.) where you need to prove exactly what’s in your supply chain.If you work with Ruby or Rails projects, I’d love for you to give it a spin!

Test it, break it, share feedback, suggest features, or submit a PR — all contributions are very welcome. https://github.com/spaquet/gemtracker

Looking forward to your thoughts, support and contributions!

Introducing Listopia: Collaborative List Management with AI Magic

Stephane Paquet — Sat, 28 Jun 2025 15:27:56 +0000

I’m thrilled to share Listopia, the first open-source collaborative list management app with AI-powered multi-channel publishing (MCP) support, built on Rails.

Whether you’re organizing tasks, brainstorming ideas, or tracking projects, Listopia makes it seamless with natural language controls—manage your lists like you’re chatting with a friend!

Why Listopia?

Collaborate Effortlessly: Work together on lists in real-time.
AI-Powered: Use natural language to create and manage lists with MCP support.
Open Source: Free to use, extend, and contribute to!

Check it out at https://listopia-dhv.pages.dev and join the community on GitHub

I’d love your feedback, ideas, or contributions! What do you think about using AI to supercharge list management? Drop a comment below or star us on GitHub!

PS, we use Ruby LLM so you're not stuck with only one AI.

Startup Growth, AI, and Leadership: My Chat with Anna 🎙️🚀

Stephane Paquet — Fri, 27 Dec 2024 00:50:46 +0000

Had the privilege of being a guest on Anna's podcast! 🎙️ We talked about everything from AI transforming the workplace to scaling startups, growth strategies, and the founder's journey. 🚀

Anna brought so much energy and asked amazing questions that made for a truly engaging conversation.

Check it out if you're curious about how startups grow, innovate, and navigate challenges: https://youtu.be/u9Y-yAiskck

AI & Personas

Stephane Paquet — Thu, 12 Dec 2024 17:54:04 +0000

Yesterday I asked ChatGPT to generate tech predictions for the year 2025 in the style of Marc Andreessen.

Why Marc Andreessen? Well, Marc is one of the most successful VC in the Silicon Valley and a very prominent figure. He also post his own predictions about what the tech will look like in 1 year or more from now so I assumed that ChatGPT has enough knowledge about him, his style and vision of the tech scene.

Here is the result of this one time exercise with ChatGPT: https://medium.com/@spaquet/top-10-technology-trends-for-2025-f2dc56896947

I'm now going to ask Claude the exact same question, but will change the style to have answers from another prominent person in tech.

Happy Holidays 🎉

Mailcatcher for beginners

Stephane Paquet — Mon, 14 Mar 2022 21:46:29 +0000

When in need to troubleshoot email messages use Mailcatcher.

Mailcatcher is a simple SMTP server that you can run locally or remotely intercept emails during test and development phases.

Once captured by Mailcatcher emails can be rendered from within their web interface and exported to be opened in any mail client.

Mailcatcher web interface is refreshed in realtime when your app is using websocket otherwise every 30 seconds.

Mailcatcher is language agnostic and simple to use as you just have to redirect SMTP traffic to Mailcatcher smtp port 1025.

So, let's say that you have an application that uses an external SMTP provider and that you have Mailcatcher running locally, you just need to replace your third party provider by smtp://127.0.0.1:1025 and done!

To access Mailcatcher web interface, simply point to http://127.0.0.1:1080.

If for any reason your instance of Mailcatcher is using a different IP address, just adapt the above examples.

Over the years, I found it more convenient to not install Mailcatcher on my computer, but have it running in a docker image.

Here are few ways to have it up and running:

docker run --rm -p 1080:1080 -p 1025:1025 --name mailcatcher stpaquet/alpinemailcatcher Will delete the image once you are done using it. This could be interesting for a test environment.
docker run -d -p 1080:1080 -p 1025:1025 --name mailcatcher stpaquet/alpinemailcatcher Will launch the image as a daemon.
docker run -it -p 1080:1080 -p 1025:1025 --name mailcatcher stpaquet/alpinemailcatcher Will launch the image in interactive mode

Useful links:
Mailcatcher homepage: mailcatcher.me
Dockerfile and Docker Compose: https://github.com/spaquet/docker-alpine-mailcatcher
Dockerhub: https://hub.docker.com/r/stpaquet/alpinemailcatcher

Longer article can be found on Medium with Docker Compose basic configuration and more examples: https://medium.com/@spaquet/mailcatcher-to-the-rescue-4ba438dc98c2

Rails 7 + Devise + Log out

Stephane Paquet — Mon, 21 Feb 2022 19:41:47 +0000

A Quick and Dirty way to get the redirection working on Logout when using Devise in a Rails 7 app.

You probably have noticed that most of the redirects in Devise a somehow broken. This is due to the way Turbo interfere with them as it catches the 200 status code.

There are already a lot of posts explaining how to patch this while waiting for an official release. But, if your main issue is about the "redirect on log out" not working, then you can easily fix this.

Instead of calling destroy_user_session_path in a link_to, call it inside of a button_to

Here is the full code:

<%= button_to(
        "Log Out",
        destroy_user_session_path,
        method: :delete
      ) %>

And Voilà! This simple hack enables your users to be redirected to the root_path of your app in seconds.