DEV Community: Digital Craft Workshop

How I Wired Persistent Memory Into Every Claude Code Session

Digital Craft Workshop — Fri, 24 Jul 2026 15:06:27 +0000

A memory you have to remember to use is not memory. It is a database with a search bar.

That was the gap. After eight hours of a day job, on the evening shift where I do my own building, I never remembered the search bar was there. I gave Claude Code that memory last month: a mem0_search tool. Then I spent a month barely using it, because using it meant remembering it existed.

So I spent one evening wiring it into the session lifecycle itself. Now recall happens when a session opens and capture happens when it closes — both without me. Claude walks into every session already knowing what we decided last week, and closes it having written down what we decided today.

I have not typed "search your memory" in a month.

Three hooks do it. Here is the wiring.

TLDR: A Claude Code shell-command hook cannot call an MCP tool. It can only inject text. So my SessionStart hook does not do the recall — it injects an instruction telling Claude to do it, with the tools Claude already has. SessionEnd spawns a detached Python process that extracts the session's decisions with Gemini and writes them to Pinecone, after my terminal is already closed. Three scripts, around 250 lines, zero ongoing effort.

The realization: hooks inject, they don't execute

The first thing I got wrong was assuming a hook could run mem0_search itself and paste the result into context.

It can't — not the kind of hook I am using. A hook that is a shell command, which is what all three of mine are, cannot call an MCP tool. It has no MCP client. The only thing it can hand back is text: a small JSON object with an additionalContext field.

(Newer Claude Code does have an mcp_tool hook type that calls a tool directly. But a blind, unconditional tool call is not what I want here — I want Claude to decide whether and how to recall, with judgment. A command hook that injects an instruction gives me exactly that.)

That sounds like a wall. It is actually the design.

A shell-command hook does not perform the recall. It writes a prompt. It injects an instruction — "before you answer, search your memory for X" — and Claude, seeing that instruction sitting in context, runs the search with the mem0_search tool it already has. The hook is a prompt-writer. Claude is still the one doing the work, with full judgment about how to do it.

Once that clicked, all three hooks got simple. Two of them write recall instructions. One of them captures. None of them touch mem0 directly except the last — and even that one runs outside the session entirely.

Hook 1: recall the moment a session opens

SessionStart fires when I open Claude Code. My hook here is a bash script that does one cheap thing: look at the current directory, and if it is one of my projects, inject a recall instruction scoped to that project.

BASENAME=$(basename "$CWD")
# ...match BASENAME against my known project slugs, set $SLUG...

MSG="[session-context] cwd is project '$SLUG'. Before answering the
first prompt, call mem0_search with query=\"$SLUG\" for past
decisions, preferences, and in-flight work."

jq -nc --arg msg "$MSG" \
  '{hookSpecificOutput: {hookEventName: "SessionStart", additionalContext: $msg}}'

That is the whole mechanism. The JSON goes back to Claude Code, the additionalContext string lands in the session as if it had always been there, and because the instruction is explicit and imperative, Claude runs the search before it answers my first message. By the time I have typed anything, the recall results are already in context.

The scoping is deterministic on purpose. The script matches the folder name against a hard-coded list of my project slugs — no LLM call inside the hook, no latency, no cost. In a project folder it recalls that project. In a random folder it falls back to a generic recall keyed on the folder name. I gave the hook a five-second timeout, and it never comes close to it.

The payoff shows up as a kind of friction quietly disappearing. I no longer re-explain decisions I already made — which database a project uses, why an endpoint is shaped the way it is, the API quirk that cost me an evening last month. The recall puts those back in front of Claude before its first answer, so it builds on them instead of slowly reinventing them.

Side note: if you'd rather have this whole setup broken into a few short, copy-paste steps in your inbox, I turned it into The Claude Code Memory Starter — a free email series. Back to the hooks.

Hook 2: catch the project I name mid-conversation

SessionStart covers where I am sitting. But half my prompts mention a different project than the folder I am in — "wait, how did I handle inbound email in subhook?"

So the second hook runs on UserPromptSubmit, before each message reaches Claude. It reads the prompt text, lowercases it, and scans for any known project slug as a whole word.

for s in $HUB_SLUGS; do
  if echo "$PROMPT_LC" | grep -qE "(^|[^a-z0-9])$s([^a-z0-9]|\$)"; then
    MATCHED="$MATCHED $s"
  fi
done

The whole-word boundary in that regex is load-bearing. Without it, a short slug matches inside longer unrelated words and ordinary prompts trigger recalls all day. With it, only a real mention counts.

If a slug matches, the hook injects the same kind of recall instruction — pull context for that project before answering. If nothing matches, the hook exits silently and adds nothing at all. Most prompts hit the silent path.

This is the part I notice most in daily use. I name a project and Claude already has its history before it responds, even when that repo is three directories away from where I am actually working.

Hook 3: capture without making me wait

The first two hooks are reads. Reads are easy — they are fast, and a few hundred milliseconds at session start is invisible.

The third hook is the write, and writes are where this got ugly.

SessionEnd fires when I close a session. The work it wants to do is not fast: read the whole transcript, send it to an LLM to extract what actually mattered, dedupe each item against the vector store, write the survivors. That is several seconds of work. If the hook does it inline, my terminal hangs for several seconds every single time I close it. Not acceptable.

So the SessionEnd hook does almost nothing itself. It spawns a detached background process and returns immediately:

(
  "$PYTHON_BIN" "$SCRIPT_PATH" \
    "$TRANSCRIPT_PATH" "$SESSION_ID" "$HOOK_EVENT" "$CWD" \
    </dev/null > "$LOG_FILE" 2>&1 &
  disown
) >/dev/null 2>&1

The extraction runs after my terminal is already gone. I find out whether it worked by reading a log file later, never by waiting on it.

Three things bit me here. They are the reason this section is the longest one.

Parallel runs. At the end of an evening I close three or four sessions in a burst. Without a lock, that is three or four extractors hammering the vector store at once.

(My last memory article had a footnote about a "helpful" hook that once spawned seven parallel Claude instances. I have held a grudge against unguarded hooks ever since.) The fix is two locks: a global one created with mkdir — atomic because the filesystem either creates the directory or fails, with no gap between the check and the create, unlike testing for a lockfile and then writing it — plus a per-session lock with a 120-second cooldown so one session cannot double-fire.

Inherited environment. The extractor is a plain Python script, but spawned from inside Claude Code it inherits Claude Code's entire environment — ANTHROPIC_BASE_URL, an OAuth token, a dozen CLAUDE_CODE_* variables. That environment makes the subprocess behave as if it is still running inside Claude. The fix is one unset block before the Python runs, clearing every inherited Claude variable. This one cost me a confused hour.

Key source. The extractor needs API keys. I could hard-code them into the script. Instead it reads them straight out of ~/.claude.json — the same file the live mem0 MCP server already reads its own keys from. One source of truth. When I rotate a key I rotate it in one place, and both the hook and the server pick it up.

What the extractor actually keeps

The background script sends the transcript to Gemini 2.5 Flash Lite with a tight extraction prompt: keep architectural decisions and their reasoning, keep preferences, keep root causes of bugs, keep project-specific facts. Skip transient state, skip routine procedure. Flash Lite sits on the free tier, so a chatty day of building costs nothing — and transcript extraction is genuinely not a job that needs a frontier model. A small OpenAI model is wired in as a fallback for the days Gemini fails.

Each surviving item comes back as structured JSON — the fact, a project scope, and a category like decision or learning. In practice a memory looks like one short sentence: "subhook uses Postmark inbound for subdomain mail because Cloudflare Email Routing only forwards the apex on the free plan," tagged {project: subhook, category: decision}. Before writing anything, the script searches the vector store for that exact text and skips it if something already sits above 0.88 cosine similarity. That dedupe is the line between a memory that compounds and a memory that fills up with a hundred near-identical entries.

What survives gets written to Pinecone with infer=False — store the text verbatim. The extraction already happened, in the Gemini step. I do not want the vector store re-paraphrasing facts I already shaped into the form I wanted them in.

If you copy one idea from this

Not the project-slug list. Not Pinecone, not Gemini. Those are my plumbing, and yours will be different.

Copy this: a hook that injects an instruction beats a hook that runs a command. A hook that runs git status and returns the output hands Claude a fact. A hook that injects "before answering, check X and recall Y" hands Claude a task — carried out with the full toolset and judgment Claude already has. The first is static. The second is behavior.

Once I started seeing shell-command hooks as a place to write prompts instead of a place to run scripts, the memory wiring stopped looking like a hack and started looking like the obvious shape. Recall on the way in. Capture on the way out. And an evening-tired version of me who never has to think about either one.

If you want the layer this builds on, the same lifecycle thinking shows up in how I put a code reviewer in front of every git push with a Claude Code subagent — another small piece of glue that runs without me thinking about it.

External Sources

Claude Code hooks reference — official lifecycle event and JSON schema docs
mem0 on GitHub — the memory layer this builds on
Pinecone documentation — managed vector database getting-started guide
Gemini API documentation — Google's developer docs for Gemini models
Gemini cookbook — examples and guides for the Gemini API

If you want the starter version of this to land in your inbox, The Claude Code Memory Starter walks you through it over a few short emails — free. The memory layer this one builds on is the earlier article on adding persistent semantic memory to Claude Code.

Target publication: Generative AI (~50K followers) [PRIMARY for the AI/Claude Code angle] · Level Up Coding (~60K followers) [SECONDARY]

Tags: Claude Code · AI · Developer Tools · Programming · Productivity

I build small tools and kits for solo creators. You can find them here: https://danielrusnok.gumroad.com

How to Make Chrome Extension Iframes Transparent on Dark-Mode Sites (CSS color-scheme Fix)

Digital Craft Workshop — Wed, 22 Jul 2026 15:15:31 +0000

A customer of ours emailed: "Your Chrome extension shows me a blank white page on our dashboard." I checked. His site uses color-scheme: dark\. Ours doesn't set it. Our iframe was painting a solid white rectangle over his entire viewport — and I had no idea, because every site I test on is light-themed.

Same iframe, same transparent body — only the host's color-scheme differs.

The white rectangle nobody sees

Drop an iframe into a customer's page. Set background: transparent\ on its <body>\, its <html>\, even #root\. Check DevTools — every layer reports background-color: rgba(0, 0, 0, 0)\. The iframe should be see-through.

On most sites, it is.

On any site that sets color-scheme: dark\ on its <html>\ element, the iframe paints a solid white rectangle over everything underneath. Your transparent body is sitting on top of a white backdrop you didn't ask for and can't see in the computed styles panel.

---

Why Chrome does this

The CSS property responsible is color-scheme\. It tells the browser what theme a document expects — light\, dark\, or normal\. The browser uses this to pick the right shade for form controls, scrollbars, and a system color called Canvas.

Canvas\ is the default backdrop the browser paints behind any element with a transparent background. In light mode it's white. In dark mode it's near-black.

The spec detail that matters: color-scheme\ does not propagate across iframe document boundaries. Every iframe document defaults to color-scheme: normal\ (which resolves to light) regardless of what the parent page declares.

The CSS Color Adjustment spec calls this a color-scheme mismatch. The spec requires the user agent to substitute an opaque Canvas color matching the iframe document's resolved color scheme — light, in this case, which means white. Your transparent body is then composited on top of that opaque white backdrop, not on top of the dark parent page.

In practice, this means the browser inserts an opaque layer between your iframe document and the parent page before any of your own CSS gets a chance to run. There is no DOM node you can inspect for it. The computed background-color on every element in your iframe still reports rgba(0, 0, 0, 0)\. The Elements panel will not show you a white rectangle, because the white rectangle is not in the DOM — it is the user agent's substitute Canvas, painted by the compositor.

This is documented in Chromium issue 40157837 and the CSSWG drafts discussion. It is intentional, it is spec-compliant, and it has been breaking iframe overlays for years — one missing HTML tag has been killing social media traffic the same way for just as long. The web is full of these tiny spec gotchas.

Four layers — only the user agent's substitute Canvas is visible to the eye, and only when the parent is dark.

---

The two-line CSS fix

Tell the iframe element explicitly what color scheme to use, and make sure its body is transparent:

iframe.my-overlay {
    color-scheme: light;
    background: transparent;
}

That's it. color-scheme: light\ on the iframe element in the parent document tells Chrome "the iframe wants light scheme, same as you would assume by default." No mismatch, no Canvas backdrop. background: transparent\ makes sure the element itself doesn't paint either.

If you control the iframe document too, also add this in its CSS so it's transparent even before the inline style is parsed:

html, body, #root {
    background: transparent !important;
    color-scheme: light !important;
}

!important\ matters because some CSS resets and base layers (including configurations that add a body background) override your plain rule.

Small fixes like this are the kind of thing I collect in The Claude Code Memory Starter — a free email series you can join in one click.

---

The reusable React component

If you have one iframe, do the CSS-only fix. If you have ten — which is what I had across our flow editor — you need a wrapper so nobody can add an iframe and forget the rule.

import { forwardRef, IframeHTMLAttributes } from 'react';

export const SafeIframe = forwardRef<HTMLIFrameElement, IframeHTMLAttributes<HTMLIFrameElement>>(
    function SafeIframe({ style, ...rest }, ref) {
        return (
            <iframe
                ref={ref}
                {...rest}
                style={{
                    background: 'transparent',
                    colorScheme: 'light',
                    ...style,
                }}
            />
        );
    }
);

Two things to notice. The wrapper uses forwardRef\ so callers can still attach refs (you'll need that for getBoundingClientRect()\ and postMessage\ patterns common in overlay UIs). And the default style spread comes before ...style\, so any caller-provided style overrides the defaults — including setting colorScheme: 'dark'\ for the rare iframe that actually wants the dark backdrop.

Then a sed\ pass replaces native iframes with the wrapper:

for f in src/components/**/*.tsx; do
  sed -i '' 's|<iframe|<SafeIframe|g; s|</iframe>|</SafeIframe>|g' "$f"
done

Add the import in each touched file. Done. Every future iframe added to the project is transparent-by-default unless somebody actively opts out.

One sed pass plus four imports — sixteen iframes become one wrapper.

---

Make the iframe document transparent too

The wrapper fixes the iframe element. The CSS above fixes the iframe document. You want both, because each protects against a different failure mode.

The element-level fix breaks if a caller passes an explicit style={{ colorScheme: 'dark' }}\ override. The document-level fix breaks if the iframe is created somewhere outside your wrapper (a third-party library, a manual document.createElement('iframe')\).

Add the document-level CSS to your iframe app's root stylesheet:

html, body, #root {
    background: transparent !important;
    color-scheme: light !important;
}

If your iframe app is React-based and uses Tailwind, put this after @tailwind base\ so it overrides preflight defaults.

---

Why this bug is invisible on light-themed sites

If you don't test on a dark-themed host, you will never see this bug. The white Canvas blends into a light parent page — you see what looks like a transparent overlay, but it's actually a white rectangle on top of a white page.

The bug is identical on light and dark hosts. Only the visibility changes. My dev environment is light. The marketing site is light. Most customer playground apps are light. The bug existed for months, and nobody on the team saw it because the entire test surface looked clean. The customer who reported it ran a security product with a dark dashboard — as soon as the white rectangle had something to contrast against, the "blank page" complaints started. (Same shape as our Next.js app that crashed every 24 hours — silent production bug only outsiders ever noticed.)

---

How to test for it before customers do

Add this to your release checklist:

Open any of your iframe overlays on a host page that sets color-scheme: dark\ on its <html>\.
If you don't have such a customer, force it for testing: in DevTools, find the <html>\ of any site you're testing on, add style="color-scheme: dark"\ inline. The bug will appear immediately if it's there.
Or open Chrome DevTools → Rendering tab → set "Emulate CSS media feature prefers-color-scheme" to dark, then visit any site whose CSS respects the system preference.

If your overlay paints a visible rectangle, you have the bug. The fix is the two-line CSS rule above.

In DevTools the rectangle is solid white, the exact Canvas\ light-mode color — not off-white, not semi-transparent. It appears the instant the iframe element gets a layout box, before any of your iframe document's own CSS runs, so there is no flash-of-transparent-content moment to catch. To verify the fix is working, apply it, hard-reload the host page, and confirm the iframe area composites cleanly against the dark parent background with no white edge anywhere along its bounding box.

Force-trigger the bug from DevTools — Rendering panel emulates dark scheme on any site.

---

What we shipped

In our codebase, the fix touched four files, replaced sixteen native <iframe>\ elements with one SafeIframe\ wrapper component, added one CSS rule to the global stylesheet, and deleted around twenty inline colorScheme: 'light'\ hot-patches that I had been sprinkling around while hunting the bug.

The wrapper component is fifteen lines. The CSS rule is three lines. The entire fix is shorter than this paragraph.

The bug had no console error, no DevTools warning, no broken selector. I only found it because a customer's screen didn't match mine.

If you inject UI into customer pages, set up a dark-themed test host. I found mine had been broken on dark customers for months.

---

If this saved you a dark-mode debugging session, The Claude Code Memory Starter is a free email series where I share more fixes like it — one short email at a time.

How I Put a Code Reviewer in Front of Every git push to Main with a Claude Code Subagent

Digital Craft Workshop — Mon, 20 Jul 2026 15:09:48 +0000

Three Wednesdays ago I shipped a regression to production. The diff looked fine. CI was green. I ran the dev server, clicked through the happy path, pushed, and went to bed.

The next morning a real user emailed me to say my landing-page signup button did nothing.

The bug was obvious in hindsight. The AI had quietly removed an await from an analytics call, the call threw inside a try block, and the catch swallowed it along with the rest of the handler. Three minutes to revert. Took the rest of the morning to feel okay about it again.

I'm a solo builder. No senior engineer reads my PRs. Nothing sits between my keyboard and main. I let Claude Code write most of my code now — which means most of what hits main was written by something that doesn't know it shouldn't swallow exceptions.

Sidebar: this story is one piece of how I think about AI as a solo founder's tool — I have a 5-email series on the broader pattern if you want the bigger picture.

So I built the second pair of eyes. One Claude Code subagent, one 30-line pre-push hook, shared across every repo I own. It runs on every push to main, takes about 20 seconds, and has caught real bugs four times in three weeks.

Here's how it works.

The architecture

Three pieces, nothing exotic.

A subagent definition — a markdown file that tells Claude how to act when invoked as a reviewer. Lives in .claude/agents/code-reviewer.md.

A pre-push git hook — bash script that gathers the diff, fires up a headless Claude Code instance pointed at the subagent, and prints the verdict.

A .shared/ folder + symlinks — both files live once at the top of my foundary-tools/ monorepo and symlink into each child repo's .claude/ and .git/hooks/. One install script wires everything.

Three pieces because each one owns a different lifetime. The subagent definition is the slowest-changing — I edit it maybe once a week as I learn what false positives look like. The hook is the contract with git — set it up once, leave it alone. The symlinks are infrastructure — wired during install-hooks.sh and forgotten. Bundling them into one script would mean re-installing across nine repos every time I tweak a prompt rule. Keeping them separate means the prompt edits live in version control and propagate for free.

The reviewer only fires on pushes to main. Feature branches push freely. The cost is one Opus call per release-shaped push — pennies — and the upside is a 20-second sanity check before a regression goes live.

The whole thing fits in three files — and the most important one isn't the hook.

The subagent definition

The subagent is a plain markdown file with frontmatter. Claude Code reads the description, knows when to dispatch to it, and uses the body as the system prompt.

---
name: code-reviewer
description: "Reviews staged commits before push. Flags"
regressions, swallowed errors, removed awaits, broken
invariants, leaked secrets, and missing migrations.
model: opus

tools: Read, Grep, Glob, Bash

You are reviewing a diff that is about to land on main\.

Output exactly one of:

"APPROVE: "
"BLOCK: \n"

Block only for things that will break production or leak
secrets. Style nits, naming preferences, and "could be cleaner"
notes do not block. The author is a solo builder shipping
fast; assume they accepted any trade-off that isn't a bug.

Always check:

Removed await\ on async calls
New catch\ blocks that swallow without logging
Hard-coded URLs that look like prod endpoints
.env\ keys printed to logs
Schema changes without a matching migration file
console.log\ of request bodies (usually leaks PII)

The output contract is one line. No essay, no "great work, here are some thoughts." Either APPROVE: ... or BLOCK: .... The hook script greps for the prefix and acts on it.

The subagent commits to a verdict instead of hedging. Without this contract, every review came back as a four-paragraph essay that ended with "but ultimately, this is your call."

The block criteria are narrow. I don't want the reviewer to lecture me about my variable names or suggest I add comments. I want it to catch things that will page me in the morning.

The solo builder shipping fast line in the prompt is load-bearing. Without it, the reviewer was blocking pushes for things like "consider extracting this into a helper" — which is exactly the kind of advice I added the reviewer to ignore.

If you've ever fought with Claude over getting it to follow a strict output format, the same lesson applies here: give the model a verdict to commit to, not an essay to write.

The pre-push hook

The hook is a bash script at .git/hooks/pre-push. Git invokes it before talking to the remote and aborts the push if the script exits non-zero.

!/usr/bin/env bash

set -euo pipefail

REMOTE_BRANCH="$(git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null || echo "")"
[[ "$REMOTE_BRANCH" == */main ]] || exit 0

DIFF="$(git log --stat origin/main..HEAD; git diff origin/main..HEAD)"
[[ -n "$DIFF" ]] || exit 0

echo "Running code-reviewer subagent..."
VERDICT="$(echo "$DIFF" | claude \
--dangerously-skip-permissions \
--print \
--agent code-reviewer 2>&1)"

echo "---"
echo "$VERDICT"
echo "---"

if [[ "$VERDICT" == BLOCK:* ]]; then
printf "Override? [y/N] "
read -r REPLY </dev/tty
[[ "$REPLY" =~ ^[Yy]$ ]] || exit 1
fi

It only runs for pushes whose upstream tracks main. A push to a feature branch returns early. That's the difference between 20 seconds added to every push and 20 seconds added to releases.

Side note: if you're wiring Claude Code deeper into your own workflow, I put the setup I lean on into a short, free email series — The Claude Code Memory Starter — one small lesson at a time.

The script ignores git's ref-list stdin and recomputes the diff from origin/main..HEAD. The combination of git log --stat and git diff gives the reviewer commit messages plus the actual hunks — messages help it figure out intent when judging whether a deletion was deliberate.

--dangerously-skip-permissions is fine here because the subagent has read-only tools (Read, Grep, Glob, Bash). It can't edit anything or push.

The read -r REPLY </dev/tty is the one tricky line. Pre-push hooks get git's ref list on stdin, so you have to redirect from the controlling TTY to read the user. Without this, the prompt prints and immediately accepts an empty answer.

**One hook, one repo. The next part is how it became one hook across nine.**

Sharing one config across every repo

I have nine repositories in ~/foundary-tools/. I'm not going to copy a hook and a subagent definition into each one and then forget which is the canonical version after the third edit.

The fix is a .shared/ folder at the top of the monorepo.

foundary-tools/
├── .shared/
│ ├── agents/code-reviewer.md
│ ├── hooks/pre-push
│ └── install-hooks.sh
├── drippery/
├── article-forge/
├── grownote/
└── ...

install-hooks.sh walks every direct child directory and creates two symlinks per repo.

!/usr/bin/env bash

set -euo pipefail
SHARED="$(cd "$(dirname "$0")" && pwd)"

for repo in "$SHARED/.."/*/; do
[[ -d "$repo/.git" ]] || continue
mkdir -p "$repo/.claude/agents"
ln -sf "$SHARED/agents/code-reviewer.md" \
"$repo/.claude/agents/code-reviewer.md"
ln -sf "$SHARED/hooks/pre-push" \
"$repo/.git/hooks/pre-push"
chmod +x "$repo/.git/hooks/pre-push"
echo "wired: $(basename "$repo")"
done

**Run it once. Edit** `code-reviewer.md` **later and every repo picks up the change on the next push.** No copy, no drift.

If you have one repo, the symlink trick is overkill — just put the files directly in .claude/agents/ and .git/hooks/. The subagent and the hook are the part doing the work.

The harder problem isn't sharing the rule. It's making myself willing to obey it.

Soft warning, not hard block (and `--no-verify` still works)

The first version of the hook used exit 1 on BLOCK: and forced me to amend or escape-hatch. I rewrote it within a day.

I push during moments where stopping is expensive — the kid wakes up, the evening ends, the meeting starts in eight minutes. A hard block on a false positive doesn't help anyone; it just teaches me to disable the hook.

The soft warning works because it changes the default. Default is don't push. Pressing Enter aborts; pressing y proceeds.

I read the verdict, decide in two seconds, and either fix or override. Four times in three weeks, the verdict was right and I went back to fix. Roughly ten times the verdict was wrong and I pressed y and shipped.

If I had set hard block, I'd have disabled the hook by week two. The override is what keeps the hook installed.

This is the same lesson I learned with my pre-deploy script that refuses to add a staging environment: I keep using the tools that make the safe path easy without locking the risky path away.

git push --no-verify bypasses every git hook, including this one. I don't try to "fix" that. If I need to ship a hotfix at 11pm and the reviewer is hallucinating about a deleted file, I want one well-known flag to skip the check, not a fight with my own tooling.

The reviewer is a default-on layer. It's not a security gate. Security gates belong in CI, where I can't --no-verify past them. The reviewer's job is to catch the bugs I'd catch myself if I weren't tired.

What I deliberately do not ask the reviewer

I tried adding more checks at first. I removed most of them.

The first version flagged every function over 30 lines for "consider extracting a helper." By the third push it had blocked a 45-line tenant migration that I had no intention of splitting — the SQL was inherently sequential. I deleted that rule the same evening. Same story with "magic numbers" — the reviewer kept flagging timezone offsets and HTTP status codes. Out.

The reviewer does not:

Run tests (CI does)
Run the type checker (CI does)
Check formatting (prettier --check does)
Look for style violations (taste, not bugs)
Suggest refactors (different mode of work)

It checks the things a human reviewer would catch in a hurried PR scan — swallowed exceptions, dropped awaits, schema drift, leaked secrets — and stays out of everything else. That narrow scope is why it runs in 20 seconds and why I trust the verdict enough to act on it.

If it flags everything I stop reading it.

What this gets you

Three weeks in, the receipts:

Four real catches (two dropped awaits, one swallowed error, one debug console.log of a JWT)
Roughly ten false positives, all dismissed by pressing y
Zero "I disabled the hook because it was annoying" moments
A single canonical config across nine repos
About $0.40 in Opus calls

The JWT one was the closest to a real incident. I'd added a console.log(req.headers) while debugging a webhook signature mismatch, forgot to remove it, and went to push. The reviewer flagged the leaked token in five seconds. That alone earned the next year of the reviewer's existence.

The .shared/ symlink trick stops mattering when you only have one repo, but the subagent and the hook still work — just live in the repo directly.

If you're already using Claude Code, the whole setup is one subagent file, one hook script, and an install-hooks.sh if you have more than one repo. About 30 minutes from cold to first wired push.

This is the third Claude Code workflow I've shipped this month that ends up being a short script. The other two — a skill that turns an hour of project setup into 90 seconds and a memory layer that survives between sessions — follow the same pattern. Most of my wins lately are thirty lines of glue around something Claude Code already ships.

If this was useful, you might also like The Claude Code Memory Starter — a short, free email series on getting Claude Code to remember what matters between sessions.

My Own Content Pipeline Didn’t Have My Own Content. Here’s the Backfill That Fixed It.

Digital Craft Workshop — Sat, 18 Jul 2026 15:07:51 +0000

My Own Content Pipeline Didn’t Have My Own Content. Here’s the Backfill That Fixed It.

Three platforms, three different integration battles — and a parser bug that silently ate three of my articles.

Three platforms, three different ways to hand you back your own history. | Generated with ChatGPT

Not a member? Use this link.

60 articles lived in my analytics dashboard. 0 of them had actual content.

I built Article Forge to manage everything I publish — drafts, section-scoped AI edits, cross-posting from Medium to dev.to, analytics from all three platforms in one place.

The whole point is that my content lives in my own tool. But for months, only the posts I’d drafted inside Article Forge had their body text stored. Everything written before the tool existed was just a row in article_analytics with a URL and zero context.

One evening, I sat down to backfill. I expected one script. I wrote three.

Architecture diagram showing Article Forge | Generated with Claude

Dev.to — the platform that just works

Dev.to has a clean REST API. /api/articles/me/published paginates through everything you've ever shipped. The catch: the list endpoint returns metadata only. To get body_markdown, you fetch each article individually via /api/articles/{id}.

The script is twenty lines of “list, then loop and fetch detail.” I wrote a dedupe by publishedUrl so re-runs are safe, and linked to each new articles row back to the corresponding article_analytics row by externalId.

Twenty articles inserted, twenty analytics linked, zero failures. Five minutes of actual work.

This is the version of “content backfill” that fits in a tweet. Then there’s Substack and Medium.

Substack — the platform that wants your cookie

Substack doesn’t have a public published-list API for owners. Or rather, it does, but it’s behind cookie auth. The dashboard hits an endpoint called post_management/published that returns a paginated list of your posts, including drafts. It accepts your substack.sid cookie as the auth token.

I already had this plumbing — the analytics sync uses the same endpoint to read view/open counts. The backfill enumeration was free. What was missing was the post body. For that, you call https://{your-subdomain}.substack.com/api/v1/posts/{slug}, again with the cookie, and you get back full body_html, cover image, subtitle.

Ten new articles inserted, nine linked to existing analytics rows, seven skipped because they already existed in the DB.

The auth model is honest. You don’t pretend a cookie is an API key. It is what it is — a session, scoped to your account, that you paste into your tool’s settings page. Once you accept that, the API surface is decent.

Side-by-side comparison of three platform integration approaches | Generated with Claude

If you like reading about the small tools I build for my own workflow, I turned one of them into The Claude Code Memory Starter — a free email series you can follow along with.

Medium — the platform that hands you a zip file

Medium has no API for reading your own historical articles. You can pull the latest ten from the public RSS feed, and that’s it. If you want everything, you go to Settings → Security and apps → Download your information, wait for an email, click a link, and download a zip of HTML files.

I downloaded the zip. Eighty-eight HTML files. Three drafts (filenames start with draft_), about thirty short "responses" (Medium's name for comments — stored as posts in the export), and the rest were real articles.

I added node-html-parser as a dependency and wrote a parser. The Medium export structure is consistent — every file is an <article class="h-entry"> with <h1 class="p-name"> for the title, <section data-field="subtitle"> for the subtitle, <section data-field="body"> for the body, and <time class="dt-published"> for the date.

Dry-run reported: 53 articles to insert, 29 short responses skipped, 3 unparseable.

Three? On a stable, well-formed export format? With a parser I’d just verified worked on the other 53?

The silent bug

I opened one of the three files. The HTML was fine. Tag balance was fine. <article class="h-entry"> was right where I expected it. I dropped into a one-line node REPL:

const root = parse(html);  
console.log(root.querySelectorAll('article').length);  // 0  
console.log(root.querySelectorAll('h1.p-name').length); // 1

Zero articles. One title.

The title element is inside the article element. If the parser found one, it should find the other. Unless the parser thinks the article closed before the title.

I scanned for what might trip a permissive HTML parser. The three “broken” files all had something in common: code blocks. Long **<pre>** blocks containing JavaScript with template literals, comparison operators, JSX-ish snippets — all the things that produce raw < characters inside what should be opaque text.

node-html-parser doesn't fully escape < inside <pre>. When it scans, it sees what looks like a tag, applies its auto-closing rules, and silently decides that the wrapping **<article>** ended way earlier than it actually did. Outer selectors miss. Inner selectors that don't depend on the wrapping element still work.

The fix is one line. Instead of:

const article = root.querySelector("article.h-entry");  
const title = article?.querySelector("h1.p-name");

Do:

const title = root.querySelector("h1.p-name");

Query from the document root. Don’t assume the wrapping element is reliably reachable just because the source HTML is valid.

Re-ran the script. Three “unparseable” files dropped to zero. One was new content (got inserted), two were already in Article Forge as drafts and matched my title-fallback dedupe.

Simulated terminal output showing the dry-run results | Generated with Claude

The deduplication logic that saved me twice

I mentioned dedupe by publishedUrl earlier. That's the primary key — if a URL already exists in the articles table, skip it. Works for dev.to and Substack, where every published post has a stable URL.

Medium broke this assumption. I had eight articles already drafted in Article Forge before the backfill. They had no publishedUrl yet because they were still drafts. The ZIP export didn't know about my internal drafts, and my internal drafts didn't have Medium URLs.

The fallback: normalized title matching. Strip punctuation, lowercase, compare. It caught all eight. Not elegant, but it prevented eight duplicate rows that would have confused every downstream query.

If you’re building any kind of content sync, plan for the case where the same content exists on both sides with no shared identifier. URL-only dedupe works until it doesn’t.

What the unified data actually unlocked

Eighty-something rows added across three platforms in a few hours. The row count isn’t the point. Every analytics row now has a corresponding article row with the actual content sitting next to the view count.

The “related articles” feature in my AI-powered optimizer can finally see my entire archive instead of just the things I drafted in-tool. When I’m writing about background jobs, it knows I already published a deep dive on Inngest and can suggest an internal link.

The Medium → dev.to cross-post sync now has the full Medium body to compare against, not a 200-character RSS snippet. Drift detection between platforms actually works.

And the simplest win: I can search my own articles by content, not just by title. “Which article mentioned Promise.allSettled?" is now a database query, not a manual hunt across three browser tabs.

Three things I’ll keep doing

1. APIs aren’t the only data source. A zip of HTML is a perfectly good integration if it’s the only thing the platform offers. Write a parser, handle edge cases, and move on.

2. Dedupe by URL with a title fallback. URL-only dedupe missed eight Medium drafts that hadn’t been published yet. A normalized-title fallback caught them all. Two layers of matching cost almost nothing and prevent real problems.

3. When a permissive parser disagrees with the source, look at what’s inside the elements. Code blocks with raw < will lie to your parser long before the parser admits it's confused.

The next thing on the list: backfilling Medium’s external_url mismatch so analytics rows actually link correctly. But that's a different evening.

External Sources

node-html-parser — the fast HTML parser that tripped on raw < in pre blocks (GitHub)
Forem API v1 — the dev.to REST API used for the cleanest backfill
Medium data export — official guide for downloading your information

If you want more of this in your inbox, The Claude Code Memory Starter is a short, free email series where I walk through setups like this one.

Our Next.js App Crashed Every 24 Hours. Here Are the Six Memory Fixes.

Digital Craft Workshop — Thu, 16 Jul 2026 15:08:29 +0000

I opened the Render dashboard on Monday morning and saw the same thing I had seen every day for a week. Memory at 100%, service restarting. Our Next.js app was eating all 512MB within ~24 hours, then OOM-killing itself.

I spent a day digging through the codebase with process.memoryUsage() logs and Render's built-in metrics. I found six separate problems. One of them cut memory usage by more than half in a single deploy.

Here is every fix, in order of impact.

The Stack

Next.js 16 (App Router) with Drizzle ORM, PostgreSQL, Clerk auth, Stripe payments, Resend for transactional email, and Inngest for background jobs. I covered the full background job setup in a previous post — five functions, one route, $0/month.

Hosting: Render.com Starter plan — 512MB RAM, $7/month.

The symptom: no sudden spikes. Just a steady upward line on the Render memory graph that ended in an OOM-kill roughly every 24 hours.

The Fix That Cut Memory in Half

The Resend email SDK was being created with new Resend(apiKey) inside 10 different files. API routes, Inngest functions, utility helpers. Every request spun up a new client with its own HTTP connections, event listeners, and internal buffers. None of them got cleaned up between requests.

This is what it looked like:

// ❌ In 10 different files
export async function POST(req: Request) {
  const resend = new Resend(process.env.RESEND_API_KEY);
  await resend.emails.send({ ... });
}

And the fix — a lazy singleton in one file:

// ✅ lib/resend.ts
let instance: Resend | null = null;

export function getResend(): Resend {
  if (!instance) {
    instance = new Resend(process.env.RESEND_API_KEY!);
  }
  return instance;
}

Every handler now calls getResend(). One instance for the entire process lifetime. I already had this pattern for Stripe and Anthropic — Resend slipped through because it was added later, in a hurry, across multiple files.

Memory dropped from ~93% to ~35% immediately after deploy. This single change was responsible for more than half of the total improvement.

V8 Knows Your Container Limit. It Still Overallocates.

Node.js 20+ reads cgroup limits and auto-sizes the V8 heap based on your container's available memory. So in theory, it should know about the 512MB limit. In practice, the auto-detected heap still leaves too little room for everything else — non-heap memory, native buffers, connection pools, and the OS itself.

On my 512MB container, V8's auto-detected heap was larger than what the process could safely use. Memory would climb slowly — not because of a leak, but because V8 was not running GC aggressively enough for the remaining headroom.

The fix is one flag:

node --max-old-space-size=384 server.js

Setting it to ~75% of the container limit gives V8 a tighter budget. It starts garbage collecting earlier, well before the container runs out.

One gotcha I hit: I initially set NODE_OPTIONS=--max-old-space-size=384 as a Render environment variable. That applies to the build step too. The TypeScript compiler also runs under Node — and it crashed at 384MB during the build.

The fix: set the flag only in the start command, not as a global env var.

// Render start command (not an env var)
node --max-old-space-size=384 .next/standalone/server.js

After the singleton fix brought memory down to ~35%, this flag is what prevented it from slowly climbing back up.

If you would rather get my solo-dev build-and-debug notes broken into a few short, copy-paste steps in your inbox, I put the essentials into The Claude Code Memory Starter — a free email series.

Four More Leaks I Found

Clerk Admin SDK — Same Bug, Different Package

Same pattern as Resend, smaller scale. createClerkClient() was called inside request handlers in 3 files instead of being a singleton. Same lazy-init fix: one **getClerkAdmin()** function, one file, one instance.

Unbounded In-Memory Rate Limiter

My /api/track analytics endpoint used a global Map for rate limiting. Cleanup only kicked in when the map exceeded 1,000 entries. On a 512MB container, 1,000 entries of IP strings plus timestamps and counters adds up.

Fix: hard cap at 500 entries with LRU-style eviction, plus a setInterval cleanup every 2 minutes.

const cleanup = setInterval(() => {
  const now = Date.now();
  for (const [key, entry] of rateLimitMap) {
    if (now - entry.timestamp > 120_000) {
      rateLimitMap.delete(key);
    }
  }
}, 120_000);
cleanup.unref();

The .unref() call matters. Without it, the interval keeps the Node process alive and it will not exit cleanly during deploys or restarts.

Cron Jobs Loading Everything Into Memory

Two Inngest cron functions had memory problems:

Analytics cleanup used Drizzle's .returning({ id }) on a bulk DELETE. This loaded every deleted row ID into an array before returning. On a table with thousands of expired rows, that array gets big. Fixed with raw SQL that returns only **rowCount**.

Orphan image cleanup listed the entire Cloudflare R2 bucket three separate times — once per context (sequences, emails, subscribers). Fixed to list the bucket once and filter in memory. Three API calls became one.

Database Pool With a Silent Zero-Timeout Default

The PostgreSQL connection pool was created with new Pool({ connectionString }) and nothing else. Most defaults are fine — max: 10, idleTimeoutMillis: 10_000. But one default is dangerous: **connectionTimeoutMillis** defaults to 0, which means "wait forever."

If a connection attempt hangs — slow DNS, unresponsive database, network hiccup — the request sits there holding memory and a pool slot indefinitely. On a 512MB container, one stuck connection is all it takes to start a cascade.

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 10,
  idleTimeoutMillis: 10_000,
  connectionTimeoutMillis: 5_000,
});

Adding connectionTimeoutMillis: 5_000 means a stuck attempt fails fast instead of waiting forever. I would not have found this without reading the node-postgres docs during the debugging session.

Results

Metric	Before	After
Baseline memory	~93% (475MB)	~35% (180MB)
Time to OOM	~24 hours	Stable (no crash)
Memory after 24h	OOM crash	~45% plateau

The Resend singleton was the biggest single win — more than half of the total improvement in one deploy. The --max-old-space-size flag prevented the slow climb back up by giving V8 a tighter GC budget.

The Checklist

If you are running Next.js on a memory-constrained container, check for these:

SDK clients (new Client()) created inside request handlers instead of module-level singletons
Missing **--max-old-space-size** — even on Node 20+ where cgroup detection works, an explicit cap gives V8 a tighter GC budget
**--max-old-space-size** set as env var instead of start command only (breaks builds)
Unbounded **Map** / **Set** / **Array** at module level without eviction or size cap
**.returning()** on bulk DELETE/UPDATE loading all results into memory
Database pool with default connectionTimeoutMillis: 0 — set an explicit timeout

Most of these take 5–10 minutes to fix once you know what to look for.

What I Took Away From This

Most Node.js memory issues on small containers are not traditional memory leaks. They are per-request allocations that should be singletons, combined with V8 not running GC aggressively enough for the available headroom.

Fix those two patterns and you will likely be fine on 512MB. I have been running stable for weeks on Render's cheapest plan — no crashes, no restarts, memory plateaus at ~45%.

If you want more of how I build and ship as a solo developer landing in your inbox, The Claude Code Memory Starter walks you through the setup over a few short emails — free.

External Sources

Node.js CLI docs — --max-old-space-size — the official V8 heap limit flag documentation
Resend Node.js SDK — the email SDK referenced in this article
Drizzle ORM — TypeScript-first SQL ORM used in the stack
Inngest — background job platform for the cron functions
node-postgres Pool API — connection pool configuration and defaults

Daniel Rusnok is a software developer and solo maker building Drippery — a dead-simple drip email tool for creators. He writes about TypeScript, Next.js, and the realities of shipping software alone.

I automated away an hour of project setup with a Claude Code skill

Digital Craft Workshop — Tue, 14 Jul 2026 15:05:36 +0000

Not a member? Use this link.

Every new SaaS project I start used to eat an hour of clicking — GitHub repo, npx create-next-app, copy-paste the DB config from my last project, walk through the Render dashboard, paste env vars, wait for the first deploy to fail because I forgot node server.js.

I did this three times in a row for three sibling projects. Then I automated the whole thing into a 90-second command.

The setup tax

I keep a folder called foundary-tools where each subdirectory is a separate SaaS or internal tool. Three projects in, every new sibling shares 90% of the same scaffolding.

Same Next.js 16 + React 19 skeleton. Same Drizzle + postgres-js setup. Same Tailwind v4 config. Same server.js that binds IPv4 explicitly because Render's port scanner doesn't see IPv6-only processes. Same .gitignore. Same tsconfig.json. Even the background job architecture is shared.

The only thing that changes between projects is the domain logic — about 5% of the initial commit.

So the other 95% was me, manually, every single time:

gh repo create danielrusnok/<name> --private
Copy a Next.js skeleton from the last project
Rename "name" in package.json, update CLAUDE.md, update the metadata in layout.tsx
Wire Drizzle against the shared Postgres, pick a unique pgSchema name
Paste the specific server.js with the 0.0.0.0 bind trick
Open dashboard.render.com, click New → Web Service, connect repo, fill in build/start commands, paste DATABASE_URL
Commit, push, wait 3 minutes, watch the first deploy fail because I typed something wrong
Fix, push again, wait another 3 minutes

An hour, easily. And at least twice I deployed a project that was silently missing an env var because I was tired and skipped a step.

How Claude Code skills work

If you use Claude Code, a "skill" is a procedural playbook Claude loads from **~/.claude/skills/**. Each skill is a directory with a SKILL.md — frontmatter describing when to trigger (natural-language phrases), plus step-by-step instructions for Claude to follow.

Skills can include helper scripts. You delegate judgment to the LLM and deterministic work to scripts. I leaned into this split even harder when I added persistent memory to Claude Code — same principle, different tool.

The division I landed on:

Claude handles: asking the user for inputs, confirming destructive actions, interpreting errors from gh / npm / the Render API, deciding whether to retry or escalate.
Python handles: walking a template directory, substituting placeholders, reading env vars from sibling projects, POSTing to Render's REST API.

Don't make the LLM do regex on **package.json**. Don't make the script decide whether to retry a failed network call. Each does what it's good at.

Nine steps, three approval gates

I named the skill foundary-new-project. It triggers on phrases like "nový foundary projekt" or "new foundary project" — same natural-language entry point as every other skill I use.

The workflow is nine steps, three of which require my explicit approval:

Validate & read secrets from sibling .env files
Scaffold the template into ~/foundary-tools/<name>/
Run npm install
Smoke-build with npm run build — fail fast before anything external happens
git init + first commit
Approval gate: create GitHub repo, push
Fetch Render owner ID (cached after the first run)
Approval gate: create Render web-service via API
Update CLAUDE.md with the Render service ID and print a recap

The approval gates exist because my intent changes between runs. Sometimes I want to scaffold locally and push later. Sometimes the name I picked collides with an existing Render service. A hard confirmation before external state changes is cheap insurance.

The scaffold script

scaffold.py is the least interesting part, which is how it should be:

def copy_template(target, name, schema, description):
    for src_root, dirs, files in os.walk(TEMPLATE_DIR):
        src_root_p = Path(src_root)
        rel = src_root_p.relative_to(TEMPLATE_DIR)
        dst_root = target / rel
        dst_root.mkdir(parents=True, exist_ok=True)
        for fname in files:
            src = src_root_p / fname
            dst = dst_root / fname
            raw = src.read_bytes()
            try:
                text = raw.decode("utf-8")
            except UnicodeDecodeError:
                dst.write_bytes(raw)
                continue
            dst.write_text(substitute(text, name, schema, description))

Three placeholders: __NAME__, __SCHEMA__, __DESCRIPTION__. The schema is the project name with hyphens swapped for underscores (SQL identifier rules).

I don't have a keychain integration. I don't maintain a separate secrets file. I read **DATABASE_URL** from **~/foundary-tools/drippery/.env.production** and RENDER_API_TOKEN from ~/foundary-tools/framelock/.env.local.

Why? Because those projects are already configured. The files exist. Permissions are already set to 0600. My adjacent project is my secret store by construction.

The new project's .env.local gets written with chmod 600 and added to a .gitignore that blocks .env*. Normal hygiene.

The Render API call

Render has a clean v1 REST API where POST /v1/services creates a web-service with the config baked in.

create_body = {
    "type": "web_service",
    "name": args.name,
    "ownerId": args.owner_id,
    "repo": args.repo,
    "autoDeploy": "yes",
    "branch": "main",
    "serviceDetails": {
        "plan": "free",
        "region": "oregon",
        "env": "node",
        "envSpecificDetails": {
            "buildCommand": "npm ci && npm run build",
            "startCommand": "node server.js",
        },
    },
    "envVars": [
        {"key": "DATABASE_URL", "value": args.database_url},
    ],
}

The owner ID is cached after the first run in ~/.claude/skills/foundary-new-project/.render-owner-id, so subsequent scaffolds skip a round-trip.

The whole script is about 80 lines of urllib.request — no SDK, no extra dependency. If the POST returns 409 or 400, Python exits with the error text and Claude reads it, tells me, and asks what to do.

That loop — script fails loud, LLM interprets, human decides — is why I reach for skills instead of **set -e** bash scripts.

If you'd rather get this kind of solo-builder setup broken into a few short, copy-paste steps in your inbox, I turned the essentials into The Claude Code Memory Starter — a free email series.

Template, not generator

The template/ directory is a real Next.js skeleton I can open and edit. When the stack evolves — new Next.js version, Tailwind upgrade, a server.js tweak — I edit the template files directly and the next scaffold picks up the change.

No code generator to maintain. No AST rewrites. Just files with three placeholders.

The template has 15 files: app/{layout,page,globals}, lib/db/{index,schema}, lib/env.ts, server.js, drizzle.config.ts, next.config.ts, postcss.config.mjs, tsconfig.json, .gitignore, .env.example, AGENTS.md, CLAUDE.md, README.md, package.json. Every one is either identical across projects or differs only by name/description.

The landing page is deliberately dumb — a hero with the project name and a "Coming soon" line. No DB calls, no auth, nothing that could break the first deploy. The first deploy's only job is to prove the pipeline works. I push every change straight to production anyway — this just makes sure the wiring is correct before real code lands.

90 seconds, zero dashboard clicks

From "I want a new project called X" to "a private GitHub repo exists, a free Render service is deploying from main, and npm run dev works locally" — about 90 seconds of wall time. Most of that is npm install and the initial next build.

Three approvals. Zero clicks in the Render dashboard. Zero copy-paste from old projects. Zero chance I forgot to rename something in package.json.

Compared to an hour of manual work where I screwed up half the steps — worth it.

Three things worth stealing

Skills beat shell scripts for anything with branching logic. A bash script with set -e exits on any failure. An LLM-driven skill reads the error, decides whether to retry, rephrase, or ask the human. The difference shows up the first time gh auth status is expired or the Render API rate-limits you — the bash script dies, the skill adapts.

Approval gates before external state changes. Local filesystem mutations and git commit are cheap to undo. GitHub repo creation, Render API calls, git push — those leak state outside my machine. A hard [y/N] confirmation before each one is the right trade-off.

Read secrets from adjacent projects. I was about to overthink secret storage — keychain, 1Password CLI, encrypted env file. My sibling projects' .env.local files are already provisioned and protected. One less system to maintain.

What's next

The skill is globally installed at ~/.claude/skills/foundary-new-project/, so it triggers in any Claude Code session regardless of working directory. The scripts hard-code paths into ~/foundary-tools/, which keeps the scope tight.

Next thing I'm automating: the shutdown flow. When a project turns out to be a dead end, I want "archive the repo, delete the Render service, drop the pgSchema, move the folder to ~/foundary-tools/.graveyard/" as one command. Same skill pattern, reversed.

If you run a portfolio of similar side projects as a solo builder, this is the best automation I've set up this year. The real win is the marginal cost: I can spin up a new experiment at 9:47 PM on a Tuesday and have it deploying by 9:49.

External Sources

Claude Code Skills — official docs on building and installing skills
Render API — Create Service — the POST /v1/services endpoint used here
Drizzle ORM — TypeScript ORM with schema-per-project support
Next.js — the React framework powering the template

If you want more patterns like this landing in your inbox, The Claude Code Memory Starter walks you through the setup over a few short emails — free.

How I Taught My AI Coding Assistant to Remember — and You Can Too

Digital Craft Workshop — Sun, 12 Jul 2026 15:07:06 +0000

Every developer who uses AI coding assistants hits the same wall: you explain something once, and next conversation, it's forgotten. You correct a mistake, and three sessions later, the same mistake appears. It's like working with a brilliant colleague who has amnesia.

Today, I want to share a workflow I've been using with Claude Code that fundamentally changes this dynamic. Instead of repeating myself, I tell Claude to write down what it learns — and it actually sticks.

The Problem: Groundhog Day Development

Here's a real scenario from my codebase. I'm building a team-based access control feature in a .NET + React application. During our first session, Claude:

Added comments to every file (I don't want comments)
Created EF Core migrations (we use raw SQL scripts)
Added unnecessary using statements
Used pricing flags instead of feature flags
Forgot to add database GRANT permissions for new tables

Every single one of these mistakes would repeat in the next conversation. I'd have to re-explain the same rules over and over.

The Solution: Two Persistence Mechanisms

Claude Code has two built-in mechanisms for persistent context that survive across conversations.

1. CLAUDE.md — Project Rules

CLAUDE.md sits in your project root and acts as a set of instructions Claude reads at the start of every conversation. Think of it as a .editorconfig for AI behavior.

Here's what mine looks like after a day of working together:

## Code Style Rules
- No comments in code. Code should be self-explanatory.
- No unnecessary usings. Every using must be actually needed.

## Database Rules
- Never create EF Core migrations. Always deliver raw PostgreSQL scripts.
- Always add GRANT SELECT, INSERT, UPDATE, DELETE for application-dev user.

The key insight: I didn't write these rules upfront. They emerged organically from corrections during our work session. When I said "stop adding comments," I followed up with "write that down so you remember next time." Claude added the rule to CLAUDE.md, and the behavior stopped — permanently.

2. Memory Files — Contextual Knowledge

The second mechanism is Claude's memory system — markdown files stored in .claude/projects/.../memory/. Unlike CLAUDE.md (which holds rules), memory files store contextual knowledge that helps Claude make better decisions.

For example, after I explained how feature flags work in our codebase (frontend hooks, backend services, sysadmin razor pages), I told Claude to save that knowledge. It created a reference file covering:

Which hook to use for feature flags vs pricing flags
Where the sysadmin flag editor lives
The naming convention for flags

Next time Claude needs to add a feature flag, it won't use a pricing flag by mistake. It won't forget to add the checkbox in the sysadmin razor page. The knowledge is there, indexed and searchable.

If you'd rather have this whole setup broken into a few short, copy-paste steps in your inbox, I turned it into The Claude Code Memory Starter — a free email series.

The Workflow: Correct Once, Remember Forever

The pattern is simple:

Claude makes a mistake (or you notice a pattern worth preserving)
You correct it — "don't do X" or "always do Y"
You tell Claude to save it — "write that down" or "remember this for next time"
Claude persists it — either as a CLAUDE.md rule or a memory file
Future conversations benefit — the rule or context is loaded automatically

This turns every correction into a permanent improvement. Your AI assistant gets smarter with every session — not through model updates, but through accumulated project-specific knowledge.

What Goes Where?

Not everything belongs in the same place:

CLAUDE.md is for actionable rules:

Code style preferences
Workflow constraints (no migrations, always run tests)
Project-specific patterns to follow or avoid

Memory files are for contextual knowledge:

How systems work (feature flags, auth, deployment)
Project goals and motivations
References to external resources
Team member roles and responsibilities

Neither should contain things derivable from code (architecture, file paths) or git history (recent changes, who did what).

Real Impact

After one working session with this approach, my Claude Code setup knows:

Never add comments to code
Always provide raw SQL with GRANT statements for new database objects
How feature flags work across three layers (frontend, backend, sysadmin)
The full requirements spec for the feature we're building
That tms_accs is a feature flag, not a pricing flag

Tomorrow, when I start a new conversation to continue this feature, none of this context will be lost. I won't waste the first 10 minutes re-explaining constraints. Claude will just... know.

Getting Started

If you're using Claude Code, you can start right now:

Create a CLAUDE.md in your project root
Next time you correct Claude, add: "and write that down so you remember"
Watch as your AI assistant accumulates project knowledge over time

The best part? These files are just markdown. You can review them, edit them, commit them to your repo (CLAUDE.md), or keep them local (memory files). Your team members can benefit from the same rules, or each developer can have their own memory layer.

It's not about having a smarter model. It's about building a smarter working relationship — one correction at a time.

If you want the starter version of this to land in your inbox, The Claude Code Memory Starter walks you through it over a few short emails — free.

From .NET Architect to Frontend Developer — What Surprised Me, What I Miss, and What I Had to…

Digital Craft Workshop — Fri, 10 Jul 2026 15:03:05 +0000

From .NET Architect to Frontend Developer — What Surprised Me, What I Miss, and What I Had to Unlearn

You may remember me from the days when I wrote about CQRS, DDD, and .NET. It’s been three years — I’ve crossed the bridge to the other side.

Bridge between backend and frontend (chatGPT generated)

I burned out at my previous job three years ago and started looking for new opportunities. Along with a new company came the chance to fill a missing role on the front-end team. I took the opportunity and gradually transitioned from full-stack to fully front-end focused. And just like that, my entire scope changed.

Why the sudden shift?

I’ve always wanted to work on something more visible. My creativity was getting thirstier by the day, and the backend started to feel dull.

In the backend world, I satisfied my creative itch through architecture — from individual projects and services to entire application structures. Now, I express that creativity through layout design, animation choices, and collaboration with UX designers.

How do I feel about React?

React clicked with me right away. Its component-based structure is exactly my kind of fun. Finding the sweet spot between generic reusability and the Single Responsibility Principle is what drives me most.

What surprised me about front end?

📈 The Progress

Before React, my last encounter with HTML, CSS, and JavaScript (mainly jQuery) was about ten years ago — and mostly just minor tweaks. Today, I work on entire websites and complex features. The front end has come a long way. With React, TypeScript, Node.js, and Styled Components, it feels like an entirely different kind of programming.

🛠 Tooling

I expected chaos but got a surprisingly mature ecosystem. Prettier and ESLint help keep the codebase nice and tidy. Visual Studio Code is a pleasant, lightweight environment, and although Microsoft has made good progress with the performance of Visual Studio, it still feels bulky to me.

📦 Bundle size matters

In the backend, I’d happily install any NuGet package — service size wasn’t usually an issue (unless you were deploying in some expensive cloud). In front end, bundle size affects load speed, so you tend to write utilities yourself rather than pulling in a bloated library just for two functions.

What do I miss from the backend?

❌ Clean compiler errors

Maybe it’s just our internal tooling, but deciphering cryptic error messages and not being able to click straight to the offending file still feels frustrating. Visual Studio spoiled me.

🧪 Unit testing

Side note: if you like reading about the craft of crossing between backend and frontend, I share short, free lessons like that in The Claude Code Memory Starter, a tiny email series you can join in one click.

Sure, there’s Jest, but unit-testing React components doesn’t spark joy for me. It makes sense in design systems and shared libraries. But if you’ve got a QA engineer automating tests via Playwright, I honestly don’t see much benefit. On the backend, I often used TDD. On the front end, I haven’t even thought of it.

📚 Third-party libraries

Every dependency needs to have a healthy community and a small footprint. You can’t just grab the first thing that pops up in a search — you need to do at least some due diligence.

What I Had to Unlearn

🧠 OOP Principles — used rarely

I barely use object-oriented principles these days. Inheritance appears only thanks to TypeScript, mainly for models and component interfaces. Encapsulation? Only when a component is used exclusively in one file.

And the only kind of polymorphism I can think of is when children are passed into a React component — allowing it to take on different shapes or content.

🧱 Monolithic thinking

I no longer need to think in terms of big code blocks — modules, domains, layers, orchestration.

Frontend forced me to think in much finer granularity — small components that snap together like Lego bricks.

⚙️ Abstraction

On the backend, I used to spend hours building the perfect abstraction. On the front end, I rarely feel the need — and often don’t even see the room for it.

In closing

I’ve missed writing, and this post is my attempt to start something new.

I’d love to write blog posts from the perspective of someone standing between the backend and front end worlds — or from a backend developer trying to build good frontend code.

Thanks for reading.

Have any of you made a similar transition? What surprised you the most?

If this resonated, you might also enjoy The Claude Code Memory Starter — a short free email series, one bite-sized lesson at a time.

How I Upgrade my Code-Style of MediatR Pipeline using .NET 6

Digital Craft Workshop — Wed, 08 Jul 2026 15:06:44 +0000

SOFTWARE ARCHITECTURE & REFACTORING

How I Upgrade my Code-Style of MediatR Pipeline using .NET 6

I want to share with you how .NET 6 features with the new MediatR.Extensions.AttributedBehaviors NuGet package helped me polish my MediatR pipelines.

What is MediatR

It is a popular library for C# created by Jimmy Boggard, which can be described as a simple Mediator Pattern implementation in .NET. MediatR NuGet package currently has almost 50 million downloads and still rising.

Wiki page on its GitHub says:

MediatR is a low-ambition library trying to solve a simple problem — decoupling the in-process sending of messages from handling messages.

The word in-process is essential. This is not a Message Broker as Kinesis or RabbitMQ. This is about sending the message from one place and handling such message in a different place, but still in one process.

I use MediatR for decoupling Command and Query Requests. So In my case, the MediatR message is Query or Command, depending on the direction of data flow. This architectural design is called Command-Query Separation, and I am explaining it in the first paragraph of blog-post 3 CQRS Architectures that Every Software Architect Should Know.

You can see how I can handle HTTP GET by defining a GetWarehousesQuery as a MediatR request (message), and GetWarehousesQueryHandler as its Handler in the code sample below.

Warehouses Query Handling

Upgrade Code with .NET 6 Features

Records

Actually records are with us since .NET 5 and C# 9, but it is related to the topic of a blog post so that I will introduce them to you too. The feature called Records. Records introduced a shorter syntax for defining an immutable class. I find helpful when I am declaring Command or Query class.

Look at line 8. The definition of GetWarehousesQuery is now one-line code. I like to have Query and Command classes with theirs Handler classes in one place, which makes my code cleaner.

There is a drawback. You will not be able to change the value of any property after Record initialization. It is an immutable object, and the setter of every property is defined with the init keyword.

Global Usings

Another sugar feature of .NET 6 is Global Usings. The new keyword global before Using directive is making it possible not to include using MediatR in every file where we are implementing interfaces from the MediatR library.

Global Usings are project-scoped, so I recommend you to create just one dedicated file for them in the root of the project folder. Define your Global Usings only there. It can be a mess once you start to write global using in a random file.

Let’s create a GlobalUsings.cs file with this line of code:

global using MediatR;

Now, we can remove using MediatR; from the code sample.

File Scoped Namespaces

File Scoped Namespace means defining one namespace per file without curly brackets. So our code sample can be even cleaner. Take a look below.

Query and Handler in one short file. That’s how I like it.

Upgrade Code with MediatR Attributed Behaviors

MediatR Pipeline

Before moving to my last upgrade, I need to explain what MediatR Pipeline is. It is a pipeline defined for one MediatR Request (message). Pipelines execution starts with Mediator.Send method invocation and passing an object of MediatR Request into it.

Side note: if you enjoy small, practical ways to keep code clean like this, I share short free lessons in The Claude Code Memory Starter — a tiny email series you can join in one click.

Simple pipeline

Pipeline Behaviors

MediatR has a feature called Pipeline Behaviors. Behaviors can be attached to the pipeline by defining a proper interface implementation.

Pipeline with behaviors

You can attach Behavior before or after Handler, depends where you will invoke the next() delegate. A typical example can be a Validation Behavior that will validate the MediatR Request form before Handler.

Now some code. This is my new CreateWarehouseCommand pipeline. The code in the Handler is not vital for proof of the concept. What it does is to persist the new Warehouse record into the database.

Now let’s define Validation Behavior.

The ValidateCreateWarehouseBehavior will be executed before Handler because we are invoking next delegate after validation. If the await next() was at line 14 before if, Handler would be invoked before validation. This is how you can manage the position of Behavior towards the Handler or another Behavior in the pipeline.

Behaviors have to be registered into the DI container manually.

services.AddScoped>, ValidateCreatedWarehouseBehavior>();

By the way, if you have multiple Behaviors for one pipeline, their order of execution is defined by order of registrations into the DI container. This is an unpleasantly hidden way of behaving by MediatR. But I have a nice fix for it in the next paragraph.

MediatR Attributed Behaviors

The last upgrade is the extension library for MediatR called MediatR Attributed Behaviors. The library helps you remove the responsibility of manual DI registrations of Behaviors from the developer. Also, you can see the Behaviors of your pipeline right over the MediatR Request definition. Take a look at the last code sample.

Another power of this extension library is defining the order and scope of behaviors and passing it as other parameters.

[MediatRBehavior(typeof(MySingletonPipelineBehavior), serviceLifetime: ServiceLifetime.Singleton, order: 1)]

public class MyQuery : IRequest

Sources

Last Words

I appreciate your attention. I have a list of non-restricted links for each of my blog-post here. I am part of the Itixo company organizing the biggest .NET conference in Central Europe, Update Conference Prague.

How to Implement Azure Functions in any Language with Custom Handlers

Digital Craft Workshop — Mon, 06 Jul 2026 15:10:41 +0000

How to Implement Azure Functions in any Language with Custom Handlers

Introduction of Custom Handlers with Demo using Go Language.

Azure Functions with Go Language

Introduction

Every Azure Function has its handler. Azure Functions supports handler implementations in many different languages but they may not provide a native implementation in your favorite language. That is where Custom Handlers comes at the scene.

The language of your choice must support HTTP communication because Custom Handler is a web server that receives events from Functions Host modified into HTTP requests with JSON payloads.

Communication Diagram

Functions Host is a bunch of JSON configuration files where you will define which trigger and bindings you want to use and of course the path to the executable file, which is our Custom Handler (Web Server).

Once the Trigger activates by event, the Functions Host sends a request payload to the Web Server. The payload can hold trigger and input binding data.

The Web Server invokes the function and possibly returns a response payload. A response payload can be used for output binding.

Demo

The source code can be found on my GitHub.

Things you Need

Create Project

Location of Create New Project Button

Click on the button highlighted in the image to create a new project.
You will be asked to choose basic settings. Select Custom language, HTTP Trigger, HttpExample as a name of the function, and Anonymous authorization level to define Function Host.

Create a Handler

Create a file in the root folder and save it as handler.go.
Copy/Paste this code into the file.

The function helloHandler is printing a simple message as an HTTP response. The form of the message depends on the value of nameparameter in the HTTP request.

If the value name is set, the response will be:

Hello, {name}. This HTTP triggered function executed successfully.

If the value name is NOT set, the response will look like this:

This HTTP triggered function executed successfully. Pass a name in the query string for a personalized response.

3. Open a command line or PowerShell and compile Custom Handler into an executable file named handler.exe by using this command (installed Go):

go build handler.go

Modify host.json

Now you need to specify the file path for customHandler:defaulteExecutablePath property in host.json. If you created the *.exe file in the root folder, you can set the value to handler.

You also need to set the value of customHandler:eneableForwardingHttpRequest to true.

On a side note — if you like getting your tooling set up properly like this, I put together a short free email series, The Claude Code Memory Starter, on giving AI coding agents a persistent memory.

Run the function

Open a command line or PowerShell again and run this command (installed Azure Function Core Tools) in the root folder:

func start

2. Navigate to the following URL to execute the function:

[http://localhost:7071/api/HttpExample?name=medium](http://localhost:7071/api/HttpExample?name=medium)

If you get a similar response as me, you were successful.

3. You can also take a look into the console and see if your function was executed.

Summary

We found out what Custom Handlers of Azure Functions are, how they work, and how we can easily implement them with Go language. As a next step, I would recommend that you should try to publish function into the Azure.

If you like the article, give it a few claps. Thank you for your time.

If a topic like this is your kind of thing, you might also enjoy my free email series The Claude Code Memory Starter — a few short lessons on giving AI coding tools a memory that sticks.

Sources

Microsoft documentation.
Pluralsight course by Mark Heath — Microsoft Azure Developer: Implement Azure Functions.

3 Things that Change my Way of Thinking in 2020

Digital Craft Workshop — Sat, 04 Jul 2026 15:19:33 +0000

3 Things that Change my Way of Thinking in 2020

This is a list of things that completely changed me in 2020, and it was not the COVID-19.

This year is hard for all of us. When everybody is scared of how global warming affects humanity's future, other catastrophes came by. Large fires in Australia, COVID-19 Pandemic, American Riots, and recent events, the Islamic state’s strikes in France and Austria.

But from my individual perspective, I love the year 2020. This year was groundbreaking for my career. My long-term relationship with the love of my life could not be better, and I doubled my incomes in nine months. Here is what happen.

Entrepreneurship

Last year was the last time I was an employee. I quit and concluded a new contract with the same company I worked for, but this time as a hired entrepreneur.

Becoming an entrepreneur was not my idea. The origin of it comes from the CEO of the mentioned company and also my good friend. “It will suit you and open doors for you. You’ll see.” He told me. And in a few months, I find out he was right.

In the spring, the company's IT specialist, where my beloved works, suddenly end his contract, and that company needs to find someone immediately to take his place.

Once you are an entrepreneur, you can have as many customers as you can handle. So I immediately took his place and migrated all of the company’s IT obligations under my wings.

After a tough week of work, the work was done, and now it cost me a few hours of work every month, and I am paid more than well. I couldn’t achieve it if I stay an employee.

Entrepreneurship brings you the freedom to do more and help others more. It unlocks a different way of thinking about work-life.

Psychology

I am Youtube addicted. Especially when it comes to stand-up comedy or TED talks. Someday in February, I came across the famous interview of Cathy Newman with Dr. Jordan B. Peterson. The interview topic should be the doctor’s new book, The 12 Rules for Life — An Antidote to Chaos.

From my perspective, it was obvious that the interviewer does not read the book nor read it with an open mind. Peterson’s comments on young men’s mindsets touched me, and I decided to search for another his interviews or lectures.

Therefore, I found out that he uploads all of his psychology lectures for free, and now I can’t be more thankful. It answers so many questions every young man has. I recommend you read his book or play one of those videos.

The main thought I learn from him is that life's meaning can be found in responsibility. How much responsibility you can take, that much is your life meaningful for you, your loved ones, your community, and even for the world.

Take responsibility for your life on your shoulders. Stop accusing the law, the rich people, or the economy for your problems. You are the one who can change everything in your life.

Don’t wait until some politicians discuss the problems of groups in society you are part of. The solution to your problem can be only one google search away.

Physical Health

I was good at sports in my whole childhood. I played hockey for ten years. Hockey is a big deal in the Czech Republic, and many young men start with hockey at a really young age.

More precisely, I was a goalie. I wasn’t in a stable form, once I catch every puck, once I got 15 goals in one match. Today I think it was unstable self-esteem. In the last two years of my career, I was bullied by the team members for my bad results on the ice.

Suddenly, I quit hockey. It was a busy childhood. Four pieces of training weekly plus match on the weekend in winter and five pieces of training in summer. It was a relief.

Since then, I never workout for more than one week. But this year, I find out through my study that mental health relies heavily on physical health, and I want to work a whole day and don’t feel tired the next morning. So I want to do something about it.

First, I cut the amount of alcohol consumption to almost zero. As a Czech man, I don’t count one beer after lunch into it. But these situations or rarer than ever before.

Second, I talked to my girlfriend about the food, and she taught me the basics of balancing my daily food income. Now I am eating mashed eggs every morning and dine a tuna salad every evening, and I feel so light every morning I couldn't believe it.

Third, I am daily consuming a dietary supplement. As a central-Europeans, we are lacking Omega 3 acids from seafood, and almost every individual lacks Magnesium. Plus, some complex vitamins, and I feel healthy like never before. But this is a recipe for me, read something about it or talk to your doctor before you take any action.

Now I feel physically capable of anything, and I even started with a light daily work-out. It has been two months now, and my back hurts are gone.

Summary

Educate yourself. Take responsibility for your life. Don’t rely on any system or anyone else.

Study your body more and find your own recipe to improve it. We are all ecosystems as our planet. We want all to take care of the planet more, but how about start with yourself. Once you have no limits, you will help the planet more than the only wave with signs in protesters' crowd.

No More Mess in my Head Around Phrases Related to Identity in Computing

Digital Craft Workshop — Thu, 02 Jul 2026 15:04:36 +0000

Azure

No More Mess in my Head Around Phrases Related to Identity in Computing

What is Identity? Azure Active Directory is just Active Directory in Azure? Microsoft Graph is a Data Visualization Framework or What?

Credits of logos for [Microsoft](https://microsoft.com).

Identity

What is Identity in Cloud

Identity is a unique identification of an object. Such an object can be a human being, machine, or a combination of it. When we talk in the cloud computing context, identity means a set of properties about this object stored in the cloud's datacentre.

Introduction to Cloud Computing

Cloud computing is the present and future of software utilization, development, and hosting. Let me introduce you to its…levelup.gitconnected.com

Identity & Access Management

Identity Management (IdM) and Identity and Access Management (IAM) is an interchangeable term in identity access management. So if you are reading about one, you are probably reading about the second term too.

IAM is a framework of policies that tell what users can do in their restricted area and what he needs from the user to operate properly. Such systems identify, authenticate, and authorize individuals or hardware applications to use restricted resources.

IAM exists in the world without the internet too. It appears in different forms. For example, the “Staff Only” label at doors in markets, id card pinned at employees suit, or doorman as a profession by itself. Even your dog protecting yard is some Access Management of your property.

Dog protecting an off-limits area.

Every IAM operates in its defined context. The context of IAM specifies the number of properties it needs from the Identity. For example, every patient has a folder with properties about his identity at the doctor's office.

Identity Platform

Identity Platform is an IAM service provided by third-parties such as Microsoft or Amazon (Amazon Cognito).

Using External vs. Internal Identity Platform

External identity platform (IP) helps you build applications without its own identity management service such as Identity Server. Authorization and authentication can be handled externally, and the only thing you need to do is integrate between your system and MIP.

Integration with an external identity platform does not make sense if you are not using third-party software, and most of your companies applications were built in-house. For example, if the whole company is using Windows and Office 365, it does make sense to integrate your system with Microsoft Identity Platform.

Microsoft Identity Platform

The Microsoft identity platform helps you build applications your users and customers can sign in to using their Microsoft identities or social accounts, and provide authorized access to your own APIs or Microsoft APIs like Microsoft Graph. — docs.microsoft.com

Components of the Microsoft Identity Platform?

OAuth 2.0 and OpenID Connect standard-compliant authentication service. — Possibility of secured work or school accounts authentications.
Microsoft Authentication Libraries or MSAL. — Microsoft MVP and my friend Daniel Krzyczkowski have great GitHub repo with guidelines for using MSAL.
Application management portal. — Registration and configuration of applications in the Azure portal. Management is also possible through PowerShell or configuration API.

Microsoft Graph

Microsoft Graph is the gateway to data and intelligence. It provides a unified programmability model that you can use to access the tremendous amount of data in Microsoft 365, Windows 10, and Enterprise Mobility + Security. — docs.microsoft.com

Downloaded from [https://docs.microsoft.com/en-us/graph/overview](https://docs.microsoft.com/en-us/graph/overview). Credits for [Microsoft](https://microsoft.com).

Mostly when you are sign-in or up with your Microsoft account and you tracked the communication, you will find out that the browser is talking a lot to https://graph.microsoft.com, which is a single endpoint of Microsoft Graph API.

Side note: I also write short, free lessons on getting more out of AI coding tools — if that's your thing, The Claude Code Memory Starter is a tiny email series you can join in one click.

Once you are integrating your application with the Microsoft Identity Platform, you will communicate through this API. You can do it directly or with MSAL, which encapsulates the HTTP communication with API.

Active Directory vs. Azure Active Directory

Active Directory

Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. — Wikipedia

Physically it is nothing else than an on-premise private server. Active Directory or Active Directory Domain Services is a database of your company’s users and computers. It provides authentication and authorizations for applications or users. It uses dinosaur protocols like Kerberos and NTLM.

Azure Active Directory

Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service. — docs.microsoft.com

Credits of the logo to [Microsoft](https://microsoft.com).

Azure Active Directory (Azure AD) takes AD approaches, expands them, and brings them to the next level, the cloud level. Azure AD provides organizations with an Identity as a Service (IDaaS) solution for applications across Azure and on-premise servers too.

Azure Active Directory vs. Microsoft Graph

Azure Active Directory is a security token server which analogous to a directory in the Cloud. When organizations want to move their on-premise directories to the cloud and make their applications securely accessible anywhere from the internet, they can take advantage of Azure AD.

Azure AD has two versions. The V1 endpoint and the V2 endpoint and Microsoft Identity Platform is made of the V2 endpoint, documentation, and application registration tools like App Registrations in the Azure portal. The Microsoft Identity Platform contains part of the Azure Active Directory.

Sources

More about Azure

Introduction to Cloud Computing

Cloud computing is the present and future of software utilization, development, and hosting. Let me introduce you to its…levelup.gitconnected.com

How to Create a Free Azure Account Step by Step

Guide for creating a free Azure account. What services can you use for free? What is Directory or subscription and what…levelup.gitconnected.com

How to Choose the Azure Region

What should you consider before choosing Azure Region? How Microsoft geographically divide datacentres position to…danielrusnok.medium.com

Understanding the Azure Resource Groups and Azure Resources

Also with Guide How to Create your First Azure Resource Group and Add your Azure Resource Into it.danielrusnok.medium.com

Daniel Rusnok’s Newsletter

Every month I will send you an email about a list of my newest articles. It will be, of course, the friendly links…www.danielrusnok.com

If this helped clear things up, you might also like The Claude Code Memory Starter — a short, free email series, one bite-sized lesson at a time.

DEV Community: Digital Craft Workshop

How I Wired Persistent Memory Into Every Claude Code Session

The realization: hooks inject, they don't execute

Hook 1: recall the moment a session opens

Hook 2: catch the project I name mid-conversation

Hook 3: capture without making me wait

What the extractor actually keeps

If you copy one idea from this

External Sources

How to Make Chrome Extension Iframes Transparent on Dark-Mode Sites (CSS color-scheme Fix)

The white rectangle nobody sees

Why Chrome does this

The two-line CSS fix

The reusable React component

Make the iframe document transparent too

Why this bug is invisible on light-themed sites

How to test for it before customers do

What we shipped

How I Put a Code Reviewer in Front of Every git push to Main with a Claude Code Subagent

The architecture

The subagent definition

tools: Read, Grep, Glob, Bash

The pre-push hook

!/usr/bin/env bash

Sharing one config across every repo

!/usr/bin/env bash

Soft warning, not hard block (and --no-verify still works)

What I deliberately do not ask the reviewer

What this gets you

My Own Content Pipeline Didn’t Have My Own Content. Here’s the Backfill That Fixed It.

My Own Content Pipeline Didn’t Have My Own Content. Here’s the Backfill That Fixed It.

Three platforms, three different integration battles — and a parser bug that silently ate three of my articles.

Dev.to — the platform that just works

Substack — the platform that wants your cookie

Medium — the platform that hands you a zip file

The silent bug

The deduplication logic that saved me twice

What the unified data actually unlocked

Three things I’ll keep doing

External Sources

Our Next.js App Crashed Every 24 Hours. Here Are the Six Memory Fixes.

The Stack

The Fix That Cut Memory in Half

V8 Knows Your Container Limit. It Still Overallocates.

Four More Leaks I Found

Clerk Admin SDK — Same Bug, Different Package

Unbounded In-Memory Rate Limiter

Cron Jobs Loading Everything Into Memory

Database Pool With a Silent Zero-Timeout Default

Results

The Checklist

What I Took Away From This

External Sources

I automated away an hour of project setup with a Claude Code skill

The setup tax

How Claude Code skills work

Nine steps, three approval gates

The scaffold script

The Render API call

Template, not generator

90 seconds, zero dashboard clicks

Three things worth stealing

What's next

External Sources

How I Taught My AI Coding Assistant to Remember — and You Can Too

The Problem: Groundhog Day Development

The Solution: Two Persistence Mechanisms

1. CLAUDE.md — Project Rules

2. Memory Files — Contextual Knowledge

The Workflow: Correct Once, Remember Forever

What Goes Where?

Real Impact

Getting Started

From .NET Architect to Frontend Developer — What Surprised Me, What I Miss, and What I Had to…

From .NET Architect to Frontend Developer — What Surprised Me, What I Miss, and What I Had to Unlearn

You may remember me from the days when I wrote about CQRS, DDD, and .NET. It’s been three years — I’ve crossed the bridge to the other side.

Why the sudden shift?

How do I feel about React?

What surprised me about front end?

📈 The Progress

Soft warning, not hard block (and `--no-verify` still works)