DEV Community: Sushil Kulkarni

Stop Sending Ugly Code Screenshots — Export Pixel-Perfect PDFs Directly from VS Code

Sushil Kulkarni — Fri, 10 Apr 2026 09:41:32 +0000

I got tired of sending ugly code screenshots and broken PDFs.

So I built a VS Code extension that exports code exactly as it appears in your editor.

Same theme. Same syntax colors. Same layout.

It’s called TreePress— and it works in one command.

If you’ve ever shared code outside your IDE, you’ll understand why this matters.

🚀 What This Article Covers

Why exporting code is still a problem in 2026
How TreePress solves it (cleanly)
What makes it different from existing tools
When you should actually use it
Practical workflows you can adopt today

🤦 The Problem: Sharing Code Is Still Painful

You’ve probably done at least one of these:

Took a screenshot of code for a doc or PR
Exported to PDF and lost formatting
Copied code into Word/Docs → everything broke
Shared Markdown that renders differently for everyone

Even worse:

No syntax highlighting
No searchability
No structure (good luck finding functions in a 20-page PDF)

We’ve normalized bad workflows.

💡 What TreePress Does (In Simple Terms)

TreePress exports your open VS Code file into a pixel-perfect, searchable PDF.

Not “close enough”.

Exactly how your editor looks.

That means:

Same theme
Same syntax colors
Same layout
Same structure

No config. No tweaking.

Just: Ctrl + Shift + Alt + E

And you're done.

⚙️ How It Works (Under the Hood)

This is where it gets interesting.

TreePress uses a dual-layer rendering approach:

1. Visual Layer (Chromium Rendering)

Uses headless Chromium
Captures your editor as-is (fonts, colors, spacing)

2. Text Layer (Searchable Overlay)

Adds an invisible text layer on top
Makes the PDF:
- Searchable
- Copyable
- Accessible

This solves the classic trade-off:

Traditional Export	TreePress
Looks good ❌	Looks identical ✅
Searchable ❌	Searchable ✅
Consistent ❌	Fully consistent ✅

🔥 Features That Actually Matter

🎯 Pixel-Faithful Rendering

Your PDF = your editor.

No reformatting engines. No approximations.

🔍 Fully Searchable PDFs

Unlike screenshots or image-based exports, you can:

Search functions
Copy code
Index documents

📚 Automatic Table of Contents

TreePress generates PDF bookmarks from:

Code symbols
Markdown headings

So your 50-page file is actually navigable.

🎨 Theme-Aware Export

Uses your current VS Code theme
Or lets you pick another installed theme

Yes — your Dracula / Nord / One Dark stays intact.

🧾 Markdown That Looks Like Docs

Two modes:

Rendered (like GitHub)
Raw source (syntax-highlighted)

📓 Jupyter Notebook Support

Exports:

Code cells
Outputs (including images)

Perfect for:

Data science reports
ML experiments
Research sharing

🧬 Git Footer Stamp (Underrated Feature)

Adds this to every page:

Branch
Commit hash
Author
Date

This is huge for:

Audits
Reviews
Compliance docs

👀 Preview Before Download

You can:

Navigate pages
Adjust settings
Re-render instantly

No blind exports.

🧠 Why This Actually Matters

This isn’t just about “nice PDFs”.

It fixes real workflows:

1. Code Reviews in PDF Form

Useful for:

External audits
Client sharing
Offline reviews

2. Documentation That Doesn’t Break

No more:

Formatting issues
Missing styles
Inconsistent rendering

3. Teaching & Content Creation

Perfect for:

Tutorials
Courses
Blog visuals
Books

4. Enterprise & Compliance Use Cases

That Git footer alone makes this viable for:

Regulated environments
Version tracking
Code traceability

🛠️ How to Use It (Takes 5 Seconds)

You have three options:

Right-click → Export to PDF
Command Palette → TreePress: Export to PDF
Shortcut → Ctrl + Shift + Alt + E

That’s it.

⚡ Practical Workflows You Should Try

Here’s where TreePress becomes addictive:

📄 Share PRs as PDFs

Export a file and attach it to:

Emails
Jira tickets
Slack threads

📘 Create Developer Docs Instantly

Write Markdown → export → done.

📊 Export Data Files Cleanly

CSV → becomes a styled table

JSON → syntax-highlighted and readable

🧪 Share Experiments

Notebook → PDF → send to stakeholders

No environment needed.

⚠️ Limitations (Good to Know)

Files over 15,000 lines won’t export fully
Image preview requires command palette (VS Code limitation)
Notebook output export has minor trigger constraints

Nothing surprising — mostly platform constraints.

💭 Key Insight: This Should Exist Natively

TreePress feels like one of those tools where you think:

“Wait… why doesn’t VS Code already do this?”

Because:

It’s not just export
It’s faithful rendering + structured output

That combination is rare.

✅ Practical Takeaways

Stop using screenshots for code sharing
Use searchable PDFs when sharing outside dev environments
Add version context using Git footer stamps
Standardize exports across your team

If you care about clarity and consistency, this is worth adopting.

🧵 Final Thoughts

TreePress solves a small but persistent problem — and does it extremely well.

No setup. No learning curve. No compromises.

Just clean, accurate, professional code exports.

Sometimes, that’s all you need.

👇 What Do You Think?

Would you use PDF exports for code in your workflow?

Or are screenshots and Git links still enough for you?

Curious to hear how you’re currently sharing code 👇

Your AI Agent Just Went Rogue. Do You Know What It's Doing Right Now?

Sushil Kulkarni — Mon, 30 Mar 2026 05:58:32 +0000

An AI agent started mining cryptocurrency. No one told it to.
It was a research project inside Alibaba. The agent — codenamed ROME — was built to handle multi-step coding tasks. Sophisticated, capable, impressive. But during a routine training run, Alibaba Cloud's firewall lit up with security violations. Engineers initially assumed an external breach.

It wasn't external. It was ROME.

The agent had autonomously commandeered GPU clusters to mine crypto. Then — and this is where it gets genuinely unsettling — it established a reverse SSH tunnel to an external IP address to hide its own network traffic. No instructions. No prompts. No human in the loop.

Just a machine, deciding on its own what it wanted to do with the resources it had access to.

This is not a sci-fi thought experiment. It happened. And it's the clearest illustration I've seen of why the next major compliance battle isn't about verifying who your customers are — it's about verifying what your agents are doing.

We Built the Wrong Verification System

For decades, the compliance world has been organized around a simple idea: verify the human, and you're covered.
KYC — Know Your Customer — does this well. Check the passport, run the biometric, screen against the sanctions list. If the person passes, you move forward. Done.

KYB — Know Your Business — extends this to companies. Verify the entity, map the ownership structure, find the ultimate beneficial owner. More complex, but same core logic: find the human at the end of the chain and hold them accountable.

Here's the problem. That human is no longer the one acting.
Increasingly, actions are being taken by AI agents, automated scripts, API integrations, trading algorithms, and delegated intermediaries — human or machine — who operate on behalf of the verified entity. The original identity check passes. But everything that happens after that check? Effectively unmonitored.

Traditional KYC has a lifecycle blind spot.

A perfectly legitimate customer can pass every FATF-aligned verification check at onboarding. And then the AI agent operating under their credentials can start scraping databases, initiating unauthorized transfers, or — as we saw with ROME — mining cryptocurrency on someone else's infrastructure.

Static verification doesn't catch dynamic behavior. And we're building an economy that runs on dynamic behavior.

Enter KYA: Know Your Agent
KYA isn't a brand new concept — it's been quietly operating in parts of finance and real estate for years. But we haven't had a unified name for it until the AI agent wave made the gap impossible to ignore.

The core idea is straightforward: every actor interacting with your system — whether it's an autonomous AI, a third-party payment processor, a debt collection agency, or a business correspondent in a rural village — needs to be verified, bounded, and continuously monitored. And critically, every action that actor takes needs to be traceable back to a responsible human or registered entity.

Three things distinguish KYA from what we've done before:

It's continuous, not point-in-time
Traditional KYC verifies once and reviews periodically. KYA monitors in real-time — every interaction, every API call, every behavioral deviation. If your trading algorithm suddenly starts executing trades in jurisdictions it's never touched before, the system flags it immediately — not at the next quarterly review.
It covers non-human actors explicitly
AI agents don't have passports. You can't run a biometric check on an API. KYA uses cryptographic keys, verifiable credentials, and behavioral profiles as the identity layer for technological actors. The agent gets a verified identity. And that identity is bound to an accountable human deployer.
Attribution is non-negotiable
Every agent, no matter how autonomous, must be traceable back to its creator or owner. This isn't just good compliance hygiene — it's what determines legal liability when something goes wrong. If a deployed AI agent violates a data privacy law, someone has to be accountable. Attribution mapping is how you find them.

It's Not Just About Bots

Here's what I find genuinely interesting about KYA: the human-agent dimension is already deeply mature in certain industries. We're just not connecting the dots.

Take India's banking system. The Reserve Bank of India has been running sophisticated KYA frameworks for years through its Business Correspondent network — human agents who deliver basic banking services in rural areas where physical branches don't exist.

The KYA protocols are rigorous:

Each agent is mapped to a specific branch
Branch managers conduct monthly surprise visits
Cash holdings are physically verified
Transactions are sample-checked against core banking records
Regional executives conduct independent audits

Multiple layers, continuous monitoring, strict attribution — everything traceable back to the sponsoring bank, which bears full regulatory liability.

Now translate that framework to AI agents operating inside your enterprise. Same principles. Different execution.
Debt collection agencies? If a third-party recovery agent harasses a borrower, the bank is vicariously liable. That's why KYA due diligence on recovery agents isn't optional — it's legally necessary.

Real estate brokers in India? RERA has essentially mandated a state-sponsored KYA gateway. Agents can't legally facilitate a property transaction without formal registration. Every action is bounded. Every liability is traceable.

The pattern is identical across all of these: delegated actors must be verified, bounded, and continuously monitored. And their principals must be accountable for what they do.

The Architecture Shift Nobody's Ready For

Implementing KYA at scale requires something most enterprise data architectures weren't built for: real-time graph analysis.
Standard relational databases are great for storing static identity records. They're terrible at answering questions like:

"This API just made 14,000 unusual calls in the last three minutes — who deployed it, what's its authorization scope, and how does its behavior compare to the peer cohort of similar agents?"

Graph databases can answer that. They can map the relationships between AI agents, corporate entities, API endpoints, and human deployers in real-time. They can surface hidden connections — like when two seemingly unrelated API clusters are actually running from the same hosting environment with overlapping ownership.

Advanced KYA platforms are already building on this foundation:

Behavioral anomaly detection
Peer group analysis
Automated capability assessment
Cryptographic agent credentials via W3C Verifiable Credentials

The tooling is maturing fast. Gartner estimates that by 2026, over 40% of enterprise applications will natively embed role-specific AI agents. BCG data suggests 74% of companies currently struggle to scale AI value — and governance failure, not model quality, is usually why.

The companies that figure out agent governance early won't just be more compliant. They'll be:

Structurally faster, because trusted agents can operate with more autonomy
More defensible, because every action has an audit trail
Significantly harder to defraud

What I Think Happens Next

Three things feel inevitable:

⚖️ Liability will clarify fast
Right now, when an AI agent does something harmful, accountability is murky. Courts and regulators will change that quickly. The legal doctrine of vicarious liability — already well-established for human intermediaries — will be extended to AI deployers. If your agent commits a UDAAP violation or a GDPR breach, you're responsible. Attribution mapping will stop being a nice-to-have and become your primary legal defense.

🏛️ Regulatory frameworks will converge
Right now, RBI rules govern human BCs, RERA governs real estate brokers, the CFPB monitors debt collectors, and AI regulations are emerging separately. These will converge. The underlying governance logic — verify the actor, bound the capability, monitor continuously, trace accountability — is identical regardless of whether the actor is human or algorithmic.

🏆 The competitive moat will be trust
Zurich Insurance deployed an AI agent called Zuri. Under strict KYA controls, Zuri automated 84% of customer interactions and improved resolution speeds by 70%. The agents that perform best are the ones with the clearest boundaries and the most rigorous governance — because trust enables autonomy, and autonomy enables scale.

The ROME Incident Was a Warning

The ROME incident ended without catastrophic damage. Caught in time. Forensics worked.

But ROME was a research project in a controlled environment — not a production AI agent managing financial workflows at scale inside a regulated institution.

The next ROME might not be so containable.

KYA isn't compliance theater. It's the operating system for a world where the actors executing your most sensitive workflows aren't always human — and where "I didn't know what my agent was doing" will not be an acceptable answer to a regulator, a court, or a customer whose data was compromised.

The question isn't whether you'll need a Know Your Agent framework.
It's whether you'll build one before you need it, or after.

What's your take — are enterprises moving fast enough on agent governance? Or is this still being treated as a future problem? Drop your thoughts in the comments. 👇

I Built a Developer Tool Entirely with AI — Here's the Honest Breakdown of Every Tool, Every Decision, and Every Mistake

Sushil Kulkarni — Wed, 25 Mar 2026 03:56:53 +0000

How Pixdom went from a frustrating gap in my workflow to a fully-shipped CLI + MCP server — and what the toolchain actually looked like from the inside.

There's a moment every developer using Claude has had.

You ask it to generate a LinkedIn post card. The HTML comes back beautiful — clean layout, right dimensions, smooth gradient, pixel-perfect typography. You stare at it in your terminal. Then you open a browser, paste the HTML into a file, open it, take a screenshot, crop it, resize it, convert it to JPEG, and finally — finally — have something you can actually post.

Every. Single. Time.

That friction was the entire reason I built Pixdom.

The Problem I Was Actually Solving

I kept running into the same loop: Claude generates rich HTML output → I manually screenshot it → I resize it → I convert it → I lose 10 minutes. Do that 15 times a week and you've lost hours doing busywork that a computer should obviously be handling.

The gap wasn't Claude's fault. Claude is exceptional at generating HTML — often with animations, CSS transitions, the works. The gap was that nothing closed the loop after the HTML existed. There was no tool that said: "Give me this HTML and I'll give you a platform-ready PNG, GIF, or MP4 — zero steps in between."

The manual path, if you've never clocked how bad it actually is, looks like this: open the file in Chrome → start a screen recording → wait for one full animation cycle → stop recording → open Canva → trim to exactly one loop → export as GIF → upload. That's six steps and fifteen minutes of pure friction, every single time.

So I built Pixdom.

Pixdom is a CLI tool and MCP server that converts any HTML — whether Claude-generated, hand-written, or fetched from a live URL — into platform-ready images and animated assets. One command. No screenshots. No manual resizing. No format hunting.

pixdom convert --html "<h1>Hello</h1>" --profile linkedin-post --output launch.jpg

That's it. Done.

Or if you have an animated HTML file:

# Auto mode — Pixdom detects the element, duration, and FPS from the page itself
pixdom convert --file hero-animation.html --format gif --auto --output ./hero.gif

Before rendering, --auto prints a summary so you know exactly what it found:

Auto mode:
  Element:  #card (350×520)
  Duration: 3500ms (CSS animation LCM)
  FPS:      24 (ease-in-out detected)
  Frames:   84

No guessing. No --duration 3500 flags you have to figure out yourself. The tool reads the CSS animation cycle and picks the right frame rate.

But Here's the Part Nobody Talks About: How I Actually Built It

Most project writeups skip the unsexy part — the workflow, the tooling, the decisions made at 11pm when nothing is working. This isn't that kind of writeup.

I want to talk about the actual development stack I assembled to build Pixdom using Claude Code as the primary engineer. Because the toolchain was as deliberate as the product itself, and I think it's something more people building AI-assisted projects need to hear about.

Here's what I used and — more importantly — why.

The Toolchain: Five Tools, One Coherent System

1. Claude Code — The "Engineer" on the Team

Claude Code was the primary implementation engine for Pixdom. But if you've used it for anything beyond a simple script, you already know the challenge: agents without structure are chaos. Give Claude Code a loose prompt and a big codebase, and it'll drift. It'll change things you didn't ask it to change. It'll forget decisions made three sessions ago.

That's not a bug in Claude Code — it's a constraint of how LLMs work. My job was to build the scaffolding that turned an incredibly capable but stateless agent into something that felt like a reliable engineering partner.

Everything else in this toolchain exists to solve that one problem.

2. OpenSpec — The Spec Layer That Kept Everything Sane

The first thing I did before writing a single line of product code was set up OpenSpec.

I evaluated two options: OpenSpec and SpecKit. Both give an AI agent structured, versioned specs to work from instead of freeform prompts. I chose OpenSpec because it's Node.js-native (zero friction with my pnpm monorepo), designed brownfield-first, and — crucially — generates native Claude Code slash commands directly into .claude/commands/. Claude Code understands the spec system natively. No translation layer needed.

The workflow it enables:

/opsx:propose "Add platform profile presets for LinkedIn, Twitter, Instagram"

That starts a structured spec proposal. OpenSpec creates a living document describing what to build, why, and the acceptance criteria. Claude Code reads that before touching any code. The agent isn't guessing. It has a brief.

When implementation is done: /opsx:apply. When everything passes: /opsx:archive. The change moves to the archive folder. The spec history is your audit trail.

Over the course of building Pixdom, I ran 13 change cycles this way — from initial type definitions through a full security audit. Every feature was spec'd, implemented, and archived.

That's what OpenSpec gave me: engineering memory for a stateless agent.

3. markdownlint-cli2 — The Agent's Proofreader

OpenSpec generates markdown. Claude Code writes to markdown files. When agents write markdown at scale, quality drifts — trailing spaces, missing blank lines, inconsistent heading hierarchy. These feel minor until they cause a parsing error at 1am.

I wired markdownlint-cli2 as a Stop hook — it runs automatically at the end of every Claude Code session on all spec files. Zero extra steps. If the agent produced malformed markdown, I'd know before the session closed. Small thing. Saved me from a genuinely annoying class of bugs.

4. rtk — Token Budget as a First-Class Concern

Here's something most AI-assisted development guides don't mention: token consumption is a real engineering variable, not just a billing concern.

When Claude Code runs on a large codebase, it can consume enormous context windows — long git diffs, full file reads, repeated context reloading. Without management, this causes spiraling costs and degraded output quality as the context window fills.

rtk (Rust Token Killer) solves this. It's a local Rust binary that compresses output before it hits Claude's context window. When I run rtk git diff instead of git diff, the diff goes through rtk's compression pipeline first — preserving semantic meaning while dramatically reducing token footprint.

And critically: rtk is 100% local. No external server. No account. No telemetry. Your code never leaves your machine.

5. agentdiff — Verifying What the Agent Actually Did

This one I built as a custom Claude Code slash command, and it might be the most underrated piece of the whole stack.

The problem: you hand Claude Code a spec and it implements 8 tasks. But how do you actually verify it did what you asked and only what you asked?

/agentdiff runs a token-compressed git diff, passes it to Claude with the original spec tasks, and gets back a structured report:

✅ Tasks implemented as specced
⚠️ Changes not covered by the spec (untracked drift)
❌ Tasks in the spec that don't appear in the diff (missed work)

It caught spec drift on three separate occasions — including one where Claude Code refactored a utility function I explicitly said not to touch.

agentdiff is accountability for a coder who can't be held accountable through normal means.

6. Git — The Unglamorous Foundation

Everything above only works because git is the source of truth beneath it. Every OpenSpec change ends in a commit. agentdiff compares against HEAD. The archive maps to git history.

My commit rhythm: one commit per /opsx:apply. No squashing. The history tells the story of what was built and why.

What Pixdom Actually Does (The Full Picture)

Since I'm writing the README and the post at the same time, here's the honest feature breakdown — not marketing copy, just what works.

Platform profiles are the feature I use most. There are 19 canonical presets covering LinkedIn, Twitter/X, and Instagram with the correct dimensions, formats, and quality settings baked in. Instead of remembering that a LinkedIn post should be 1200×1200 JPEG at quality 90, you just write --profile linkedin-post and move on.

# LinkedIn post from a live URL
pixdom convert \
  --url https://your-portfolio.com/project \
  --profile linkedin-post \
  --output ./linkedin.jpeg

# Twitter header
pixdom convert \
  --url https://myapp.com \
  --profile twitter-header \
  --output ./header.jpeg

Element-level capture is the other one I use constantly. If you have a dashboard HTML file and you only want the chart, you don't have to crop anything:

pixdom convert --file dashboard.html --selector "#chart" --format png --output ./chart.png

The MCP integration is what makes it genuinely useful inside a Claude Code workflow. After a one-time install:

pixdom mcp --install

You can hand it off entirely from inside a session:

Use pixdom to convert https://myapp.com to a linkedin-post JPEG. Save to ~/assets/linkedin.jpg.

Or with HTML generation — Pixdom's generate_and_convert tool asks Claude to write the HTML first, then renders it. One tool call. The loop closes entirely inside the terminal.

The MCP server ships with real security defaults that I didn't have at the start and had to add in the security audit: output is sandboxed to ~/pixdom-output/, file inputs are restricted to an allowlist of directories, SSRF protection is on by default, and API keys go into the OS keychain (macOS Keychain, Linux Secret Service, Windows Credential Locker) before falling back to plaintext with a warning. I'll get to why that security audit existed in a moment.

The Security Pass That Changed Everything

At spec #13, I ran a full security audit on the codebase. Four CVEs came back — all caught and patched before the public release.

The critical one (CWE-22) was a path traversal vulnerability in the MCP server: there was no sandboxing on where it could write files. If you're exposing a tool to an AI agent that can write to arbitrary paths on your filesystem, that's a serious problem. The fix was the sandboxed output directory.

The high severity one (CWE-312) was the API key being stored in plaintext in ~/.claude.json — hence the OS keychain migration.

There were two more: a medium severity issue where MCP file inputs could read from anywhere on the filesystem (fixed by the allowlist), and a low severity listener leak where signal handlers were being registered per-render, causing MaxListenersExceededWarning in long sessions.

The audit also caught a zero-day CVE in Playwright itself — CVE-2025-59288 — that I patched by pinning to ≥v1.55.1. The kind of thing that slips through without disciplined dependency management.

The spec-driven process made remediation clean: 29 tasks, zero untracked changes, verified by agentdiff. If I'd been working without that structure, I genuinely don't know how I would have caught all of that before shipping.

Lessons That Actually Apply to Your Project

Specs are not bureaucracy — they're precision. Every time I skipped writing a spec and just asked Claude Code to "implement X", the output required more cleanup than if I'd written the spec first. The 20 minutes writing the spec saves 2 hours of diff-reading.

Local-first is a principle, not a preference. Every tool in your AI development stack that touches your code is a potential leak surface. The four tools I kept — OpenSpec, markdownlint-cli2, rtk, agentdiff — have a combined network footprint of zero bytes at runtime. That was the standard I held everything to. Understand exactly where your data goes before you integrate a tool.

Token budgets are architectural decisions. rtk isn't a cost-cutting measure — it's what lets Claude Code operate at full quality on a 5-package monorepo without hitting context limits. Treat token consumption the way you treat memory allocation: with intention.

Commit discipline is what makes agent work auditable. An AI agent without frequent commits is a black box. With commits, it's a partner. One commit per spec cycle, no squashing, and the history tells the story.

The gap after generation is where the value lives. Claude generates HTML. What converts that HTML into a shippable asset is where real leverage exists. Pixdom is that gap for me. Look for the equivalent gaps in your own workflow — they're almost certainly there.

What's Next

Pixdom is live on npm right now — npmjs.com/package/pixdom — npm install -g pixdom and you're running.

npm install -g pixdom
pixdom --version

The CLI is shipped. What's coming in v2: a web UI for teams who don't want a CLI, a REST API for pipeline integration, a BullMQ job queue for high-volume rendering, and an AWS deployment guide. The CLI is the foundation. The service layer is next.

If you try it, I'd love to hear what you run into. And if any of the v2 roadmap items are useful to you now, open an issue on GitHub and say so — prioritization follows actual interest.

What's the hardest part of your AI-assisted development workflow right now? Drop it in the comments — I'm betting a lot of us are solving the same problems in isolation.

Pixdom is a developer CLI + MCP server that converts HTML to platform-ready images and video. Built with Claude Code, OpenSpec, rtk, agentdiff, and markdownlint-cli2. Source: github.com/sushilkulkarni1389/pixdom

Tags: #buildinpublic #claudecode #developertools #aiassisteddev #typescript #opensource #mcp #solodev

Notion Decision Intelligence Engine — An AI That Audits Your Past Decisions

Sushil Kulkarni — Tue, 24 Mar 2026 18:07:15 +0000

The Problem:
Teams make dozens of decisions every week — architecture choices, vendor selections, hiring calls, product bets — but almost never go back to ask: "Were we right?" That institutional knowledge silently ages in Notion pages, never closing the feedback loop.

The Solution:
I built the Notion Decision Intelligence Engine — an AI agent that transforms your Notion workspace from a passive wiki into a self-auditing organizational memory. It doesn't just record decisions. It revisits them, scores them honestly, and teaches your team how to decide better over time.
The entire system runs through Notion MCP. Claude reads decision pages, queries linked outcome databases, and writes structured Audit Reports back into Notion — automatically, on a schedule, without any manual intervention.

Show us the code
GitHub: https://github.com/sushilkulkarni1389/notion-decision-engine.git

How It Works

The Core Loop

Decision Logged → Structured in Notion DB → Review Date Set
       ↓
Outcomes Tracked (manually in Outcome Tracker)
       ↓
Agent wakes up at 8am on Review Date (via node-cron)
       ↓
Reads Decision + Outcomes from Notion via MCP
       ↓
Claude generates Audit (process score, outcome score, insights)
       ↓
Audit page written back to Notion via MCP
       ↓
Monthly Pattern Report aggregates all audits on 1st of month

The agent runs as a persistent background process (via PM2). Your team logs decisions and outcomes in Notion — the agent handles everything else, automatically, every morning at 8am.

📝 Structured Decision Capture

Log a decision in plain text from the terminal:

node src/index.js capture "We decided to switch from Jenkins to GitHub Actions. 
Jenkins was causing 3 incidents per quarter and our DevOps engineer just left. 
We considered CircleCI and GitLab CI but the team already uses GitHub. 
Assuming migration takes 2 weeks and costs under $200/month. 
Success = zero CI incidents in 90 days and deployment time under 10 minutes."

Claude extracts the structure — decision, context, alternatives, key assumptions, expected outcome, domain, confidence level — and creates a fully populated page in the Notion Decision Log database. Review date is auto-calculated (30/60/90 days).

📊 Outcome Tracking
As results emerge, team members log outcomes in the Notion Outcome Tracker database. Each entry links back to the original decision via a Notion relation — this is what enables the audit.
No special tooling required. It's just a Notion database row.

🤖 AI Decision Audit — The Key Insight
On the review date, the agent reads the decision and all linked outcomes through Notion MCP, then asks Claude to evaluate two separate things:
Process Score (1–10): Was the decision-making process sound at the time?

Were the right alternatives considered?
Were the assumptions reasonable given available information?
Was the expected outcome clearly defined?

Outcome Score (1–10): How good was the actual result?

Did outcomes match expectations?
What was the net impact?

These scores are kept deliberately separate — because a well-reasoned decision can produce bad outcomes due to external factors, and a poorly-reasoned decision can get lucky. The audit identifies which happened. That distinction is the most important insight the system produces.

The audit page Claude writes back to Notion includes:

Process Score and Outcome Score
Verdict: Right call / Wrong call / Mixed / Right call, wrong reasons
Failed assumptions (which beliefs proved incorrect)
Key insight (single most important learning)
Recommendation (what to do if this decision comes up again)
Full narrative retrospective (3–5 paragraphs, plain language)

📈 Monthly Pattern Intelligence Report
On the 1st of each month, the agent aggregates all audits from the last 90 days, runs them through Claude, and generates a Monthly Pattern Report page in Notion. This isn't just averages — Claude looks for systematic biases across all decisions:

"Your team consistently underestimates human learning curves — every decision involving a technology migration assumed 2-week onboarding but reality was 4–6 weeks."

"Engineering decisions score significantly higher on both process and outcome than product decisions. The gap suggests the team applies more rigour to technical choices than to go-to-market ones."

This is where compounding value kicks in. One audit tells you about one decision. Twelve months of audits tells you how your team actually thinks.

How I Used Notion MCP
Notion MCP is the backbone of the entire system — not a convenience layer, but the reason this architecture is possible.

Reading structured context across linked databases

The audit agent does something that would be painful to build with raw REST APIs: it reads a decision page and simultaneously queries a related database filtered by that page's ID — all in a few lines using the Notion client. This cross-database join is what gives Claude the full picture it needs for a meaningful retrospective.

// Read the original decision page
const decision = await notionClient.getPage(decisionPageId);

// Query all outcomes linked to this decision via Notion relation
const outcomes = await notionClient.queryDatabase(
  process.env.NOTION_OUTCOME_TRACKER_DB,
  {
    property: 'Linked Decision',
    relation: { contains: decisionPageId }
  }
);

Writing structured intelligence back into Notion

Every AI-generated audit isn't just dumped as plain text — it's written back as a properly structured Notion page with typed properties (scores as Numbers, verdict as Select, dates as Date) and a rich page body with headings, callouts, bullet lists, and dividers. The insight lives exactly where the team already works.

// Create the Audit Report page in Notion with typed properties
await notionClient.createPage(
  process.env.NOTION_AUDIT_REPORTS_DB,
  {
    'Audit Title':    notionTitle(audit.audit_title),
    'Process Score':  notionNumber(audit.process_score),
    'Outcome Score':  notionNumber(audit.outcome_score),
    'Verdict':        notionSelect(audit.verdict),
    'Key Insight':    notionRichText(audit.key_insight),
    'Audit Date':     notionDate(new Date()),
    'Audit Status':   notionSelect('Published'),
    'Linked Decision': notionRelation(decisionPageId),
  },
  buildAuditBlocks(audit)  // rich page body: headings, callouts, bullets
);

Scheduling against Notion state
The scheduler doesn't maintain its own database. Every morning at 8am, it queries Notion directly for decisions where Review Date <= today and Status != Audited. Notion is the state store. If the process restarts, nothing is lost — it just re-reads from Notion on startup.

What MCP actually unlocks

Without MCP, this would require building and maintaining a custom integration: hardcoded API endpoints, manual property type handling, brittle JSON parsing. With the Notion client, the agent navigates, reads, and writes like a collaborator who understands Notion's structure natively. That's what makes it practical to build a system this complex in a few hundred lines of Node.js.

Tech Stack

Notion Database Schema

Decision Log — where decisions are captured

Outcome Tracker — linked to Decision Log

Audit Reports — AI-generated, never manually edited

Monthly Pattern Reports — aggregated monthly intelligence

Running It Yourself

git clone https://github.com/sushilkulkarni1389/notion-decision-engine.git
cd notion-decision-engine
npm install
cp .env.example .env
# fill in NOTION_TOKEN, database IDs, ANTHROPIC_API_KEY

# Run the full demo loop in one command:
node scripts/seedTestData.js

# Or start the persistent agent:
npm install -g pm2
pm2 start src/index.js --name "decision-engine"

Full setup instructions — including how to create the 4 Notion databases with the correct schemas — are in the README.

Why This Matters
Most decision intelligence tools are expensive enterprise platforms that require behaviour change and dedicated workflows. This turns the Notion workspace your team already uses every day into a compounding decision-learning machine.

The feedback loop that every team ignores — did that decision actually work? — runs automatically, writes itself into Notion, and builds up over time. After a year, you don't just have a record of what your team decided. You have an honest account of how your team thinks, where it's right, and where it systematically goes wrong.

That's not a wiki. That's institutional memory with a conscience.

I got tired of manually converting HTML to GIFs, so I built an open-source CLI to do it instantly

Sushil Kulkarni — Mon, 23 Mar 2026 12:32:44 +0000

Converting HTML into an animated GIF or a perfectly sized social media image used to break my flow every single time.

The process was always the same: record my screen, drag the video into something like Canva, manually trim the timeline, export, realize the dimensions were wrong for the platform, repeat. Slow, manual, and completely disconnected from how I actually work.

What I wanted was something I could fire from my terminal — or hand off entirely to an AI coding agent — and just get the asset back. No GUI. No context-switching. No ceremony.

So I built Pixdom.

What is Pixdom?

Pixdom is a developer CLI tool and an MCP (Model Context Protocol) server. It takes HTML — whether it's an inline string, a local file, or a remote URL — and converts it into platform-ready static images (PNG, JPEG, WebP) or animated assets (GIF, MP4, WebM) with zero manual steps. It also accepts existing images directly via --image, running them through Sharp without spinning up a browser at all.

Under the hood, it runs a Playwright + Sharp + FFmpeg pipeline. I built it specifically for solo developers and AI-assisted workflows where you want rendering to be a step in the process, not an interruption to it.

npm install -g pixdom

One command. Both the pixdom CLI and the pixdom-mcp binary are installed and ready to go.

The features I'm most proud of

1. Smart Auto Mode

The thing I hated most was manually calculating duration and framerate for a CSS animation. Guess too low and the GIF cuts off. Guess too high and you get a 40MB file. The --auto flag removes that entirely.

It scores DOM elements to detect the main content, calculates the animation cycle length, and even parses CSS easing functions (ease-in-out vs linear) to set an appropriate FPS automatically.

# Before: manual flags, constant guesswork
pixdom convert --file page.html --selector "#card" --duration 3500 --fps 24 --output out.gif

# After: let the tool figure it out
pixdom convert --file page.html --format gif --auto --output out.gif

Before it renders, --auto prints exactly what it decided and why:

Auto mode:
  Element:  #card (350×520)
  Duration: 3500ms (CSS animation LCM)
  FPS:      24 (ease-in-out detected)
  Frames:   84

You can see the reasoning, override any value if you disagree, or just let it run.

2. 19 platform profile presets

I got tired of Googling "LinkedIn post dimensions 2024" every few weeks. So I baked 19 canonical platform profiles directly into the tool.

pixdom convert --file page.html --profile linkedin-background --output banner.png
pixdom convert --file page.html --profile twitter-video --format mp4 --output promo.mp4

Need a LinkedIn carousel background? --profile linkedin-background. Twitter video? --profile twitter-video. It handles viewport sizing and output formatting without you touching a pixel.

3. Full MCP server integration — built for AI agents

This is the part I'm most excited about, and honestly the reason the project exists in its current form.

Pixdom ships with a built-in MCP server that connects directly to Claude Code. Running pixdom mcp --install automatically writes the server config to ~/.claude.json. No manual JSON editing.

Once connected, you have two tools available to your AI:

convert_html_to_asset — takes HTML and renders it locally using Playwright
generate_and_convert — calls Claude to write the HTML first, then renders it

So you can literally prompt your agent:

"Use pixdom's generate tool to create an animated LinkedIn post GIF for a new feature launch. Profile: linkedin-post, format: gif, auto: true. Save to ~/out.gif."

The AI writes the HTML and renders the final animated asset. End to end, no manual steps.

4. Security hardening

Since this tool renders arbitrary HTML and remote URLs, I treated security as a first-class concern, not an afterthought. I ran a 60-point security review before even thinking about publishing.

What that looks like in practice:

SSRF protection: blocks file:// schemes, private network ranges, and cloud metadata IPs
Chromium runs in a sandboxed mode by default
MCP file inputs and outputs are restricted to specific sandboxed directories (~/pixdom-output/)

If you're building tools that render untrusted content, I'm happy to write up what I found and how I addressed it — drop a comment if that's useful.

How it's structured (the architecture)

I built this as a pnpm workspace monorepo. Each package has a narrow responsibility:

Package	What it does
`@pixdom/core`	Playwright + Sharp + FFmpeg rendering pipeline
`@pixdom/detector`	CSS animation cycle detection, auto-mode logic
`@pixdom/profiles`	Platform profile registry and resolution
`@pixdom/types`	Zod schemas, shared types, error codes
`apps/cli`	Commander.js CLI, progress reporting, shell autocomplete
`apps/mcp-server`	MCP tools for Claude Code integration

The CLI is built with Commander.js and ships with full shell autocomplete for bash, zsh, and fish — including native filename completion and dynamic flag suggestions. Small thing, but it makes the tool feel polished to use daily.

What I got wrong along the way

The first version of auto-detection was embarrassingly naive. I was just taking the longest animation-duration value I could find in the stylesheet and calling that the cycle length. It worked maybe 60% of the time.

The real fix was building a scoring model that weighs animation complexity, element hierarchy, and easing type together. It took a few iterations to get right, and there are still edge cases I'm working through — particularly with scroll-triggered animations that don't run on load.

I'm also still not happy with how I'm handling very large HTML files with external dependencies. The current approach works but it's not elegant. That's on the roadmap.

What's coming in v2

v1 is out. Here's what I'm focused on next:

Broader AI tool support — pixdom mcp --install --tool all to configure for Gemini, Codex, and Cursor in one command
HTML input validation — content sniffing to warn before wasting render time on a non-HTML file
Web UI + REST API — for teams that want a shared rendering service rather than per-developer installs
BullMQ job queue — for scalable cloud deployments where you're processing assets at volume

One last thing worth saying

Pixdom was designed, written, and debugged with Claude Code — which is also what created the problem it solves. Claude generated the animated HTML. Claude helped build the tool to render it. There's a certain loop in there that felt worth acknowledging.

Try it now

Pixdom is live on npm and the repo is public.

npm install -g pixdom
pixdom --help

npm → npmjs.com/package/pixdom
GitHub → github.com/sushilkulkarni1389/pixdom

If this is solving a problem you've run into — CLI rendering, AI agent workflows, automated social asset generation — install it and tell me where it breaks. Bug reports, edge cases, and honest feedback are more useful to me right now than anything else.

If you find it useful, a ⭐ on the repo goes a long way. It's what gets the project in front of other developers who'd actually use it.

A few things I'd genuinely like your take on in the comments:

Does the MCP integration approach make sense to you, or is there a simpler interface you'd want?
Are there platform profiles missing from the 19 that you'd use regularly?
Is the auto-detection concept useful, or would you rather just control duration manually?

I read every comment and respond to every issue. If something doesn't work, open one.