<h2 id="table-of-contents">Table of contents</h2>
<ul>
<li><a href="#claude-code-hooks">Claude Code hooks</a></li>
<li><a href="#how-hooks-work">How hooks work</a></li>
<li><a href="#blocking-destructive-commands">Blocking destructive commands</a></li>
<li><a href="#protecting-sensitive-files">Protecting sensitive files</a></li>
<li><a href="#audit-trail">Audit trail</a></li>
<li><a href="#wiring-it-up">Wiring it up</a></li>
<li><a href="#prompt-injection-defense">Prompt injection defense</a></li>
<li><a href="#why-global-config-not-per-repo">Why global config, not per-repo</a></li>
<li><a href="#same-idea-different-tools">Same idea, different tools</a></li>
</ul>
<h1 id="claude-code-hooks">Claude Code hooks</h1>
<p>Claude Code runs shell commands, reads files, and edits code
on your machine. Hooks let you intercept those actions with
shell scripts that run before or after each tool call. The
scripts get JSON on stdin describing what Claude is about to
do, and they can block it by exiting with code 2.</p>
<p>I set up three hooks: one that blocks destructive commands,
one that blocks access to sensitive files, and one that logs
everything to a JSONL audit trail.</p>
<h1 id="how-hooks-work">How hooks work</h1>
<p>A hook is a shell script registered in
<code>~/.claude/settings.json</code>. There are two lifecycle events:</p>
<ul>
<li><strong>PreToolUse</strong>: runs before Claude executes a tool. Exit 0
to allow, exit 2 to block. The block message goes to stderr.</li>
<li><strong>PostToolUse</strong>: runs after. Good for logging. Can run async
so it doesn't slow things down.</li>
</ul>
<p>Each hook gets a JSON object on stdin with <code>tool_name</code>,
<code>tool_input</code>, <code>session_id</code>, and <code>cwd</code>. You can use <code>jq</code> to
pull out whatever you need.</p>
<p>A <code>matcher</code> field controls which tools trigger the hook. It
takes a regex, so <code>Bash</code> matches only the Bash tool while
<code>Read|Edit|Write|Bash</code> matches all four.</p>
<h1 id="blocking-destructive-commands">Blocking destructive commands</h1>
<p>This one intercepts every Bash tool call and blocks anything
that could wreck the system.</p>
<pre><code class="language-bash">#!/usr/bin/env bash
# ~/.claude/hooks/block-destructive.sh
# PreToolUse hook, matcher: Bash

set -euo pipefail

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

if [[ -z "$COMMAND" ]]; then
  exit 0
fi

BLOCKED=""

case "$COMMAND" in
  *"rm -rf /"*|*"rm -rf ~"*)
    BLOCKED="recursive delete of root or home" ;;
  *"git push --force"*|*"git push -f "*)
    BLOCKED="force push" ;;
  *"git reset --hard"*)
    BLOCKED="hard reset" ;;
  *"DROP TABLE"*|*"DROP DATABASE"*)
    BLOCKED="database drop" ;;
  *":(){ :|:&#x26; };:"*)
    BLOCKED="fork bomb" ;;
  *"curl"*"|"*"sh"*|*"curl"*"|"*"bash"*)
    BLOCKED="piped remote execution" ;;
  *"chmod 777"*)
    BLOCKED="world-writable permissions" ;;
  *"mkfs."*)
    BLOCKED="filesystem format" ;;
esac

# Check dd writing to /dev/
if [[ -z "$BLOCKED" ]] &#x26;&#x26; echo "$COMMAND" | \
   grep -qE 'dd\s+if=.*of=/dev/'; then
  BLOCKED="raw device write"
fi

if [[ -n "$BLOCKED" ]]; then
  echo "BLOCKED by block-destructive hook: $BLOCKED" >&#x26;2
  exit 2
fi

exit 0
</code></pre>
<p>Testing it:</p>
<pre><code class="language-bash">$ echo '{"tool_name":"Bash","tool_input":{"command":"rm -rf /"}}' \
  | ~/.claude/hooks/block-destructive.sh
BLOCKED by block-destructive hook: recursive delete of root or home
# exit code: 2

$ echo '{"tool_name":"Bash","tool_input":{"command":"git push --force origin main"}}' \
  | ~/.claude/hooks/block-destructive.sh
BLOCKED by block-destructive hook: force push
# exit code: 2

$ echo '{"tool_name":"Bash","tool_input":{"command":"ls -la"}}' \
  | ~/.claude/hooks/block-destructive.sh
# exit code: 0  (allowed)
</code></pre>
<p>When Claude tries a blocked command, it sees the stderr
message and knows the action was rejected. It can then
rephrase or ask for confirmation.</p>
<h1 id="protecting-sensitive-files">Protecting sensitive files</h1>
<p>The second hook blocks access to credentials, SSH keys, and
cloud configs. It handles both file-path tools (Read, Edit,
Write) and Bash commands that might <code>cat</code> or exfiltrate
those files.</p>
<pre><code class="language-bash">#!/usr/bin/env bash
# ~/.claude/hooks/protect-sensitive.sh
# PreToolUse hook, matcher: Read|Edit|Write|Bash

set -euo pipefail

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty')

check_path() {
  local filepath="$1"
  case "$filepath" in
    */.env|*/.env.*|*.env)
      echo "BLOCKED by protect-sensitive hook: .env file" >&#x26;2
      exit 2 ;;
    */.ssh/id_*)
      echo "BLOCKED by protect-sensitive hook: SSH key" >&#x26;2
      exit 2 ;;
    */.aws/credentials*)
      echo "BLOCKED by protect-sensitive hook: AWS creds" >&#x26;2
      exit 2 ;;
    */.kube/config*)
      echo "BLOCKED by protect-sensitive hook: kubeconfig" >&#x26;2
      exit 2 ;;
  esac
}

if [[ "$TOOL" == "Bash" ]]; then
  COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')
  if echo "$COMMAND" | \
     grep -qE '(cat|less|head|tail|curl -d @|base64|scp)\s+\.env'; then
    echo "BLOCKED by protect-sensitive hook: .env access via bash" >&#x26;2
    exit 2
  fi
  if echo "$COMMAND" | \
     grep -qE '(cat|less|head|tail)\s+.*(\.ssh/id_|\.aws/credentials|\.kube/config)'; then
    echo "BLOCKED by protect-sensitive hook: sensitive file access via bash" >&#x26;2
    exit 2
  fi
else
  FILEPATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')
  if [[ -n "$FILEPATH" ]]; then
    check_path "$FILEPATH"
  fi
fi

exit 0
</code></pre>
<pre><code class="language-bash">$ echo '{"tool_name":"Read","tool_input":{"file_path":"/home/user/.ssh/id_ed25519"}}' \
  | ~/.claude/hooks/protect-sensitive.sh
BLOCKED by protect-sensitive hook: SSH key
# exit code: 2

$ echo '{"tool_name":"Bash","tool_input":{"command":"cat .env"}}' \
  | ~/.claude/hooks/protect-sensitive.sh
BLOCKED by protect-sensitive hook: .env access via bash
# exit code: 2
</code></pre>
<p>This isn't foolproof. Claude could read a sensitive file
by some path I didn't think of. But it catches the obvious
cases and raises the bar.</p>
<h1 id="audit-trail">Audit trail</h1>
<p>The third hook runs after every tool call and appends a JSON
line to a log file. It runs async so it doesn't slow Claude
down.</p>
<pre><code class="language-bash">#!/usr/bin/env bash
# ~/.claude/hooks/audit-log.sh
# PostToolUse hook, async

LOG="/Users/kp/gh/multi/logs/claude-audit.jsonl"

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // "unknown"')
SESSION=$(echo "$INPUT" | jq -r '.session_id // "unknown"')
CWD=$(echo "$INPUT" | jq -r '.cwd // "unknown"')

case "$TOOL" in
  Bash)
    PARAM=$(echo "$INPUT" | jq -r '.tool_input.command // empty') ;;
  Read|Edit|Write)
    PARAM=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty') ;;
  *)
    PARAM="" ;;
esac

jq -nc \
  --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --arg sid "$SESSION" \
  --arg tool "$TOOL" \
  --arg param "$PARAM" \
  --arg cwd "$CWD" \
  '{timestamp: $ts, session_id: $sid, tool: $tool, param: $param, cwd: $cwd}' \
  >> "$LOG"

exit 0
</code></pre>
<p>After a session, the log looks like:</p>
<pre><code class="language-json">{"timestamp":"2026-03-11T13:14:18Z","session_id":"abc123","tool":"Bash","param":"echo hello","cwd":"/Users/kp/gh/multi"}
</code></pre>
<p>You could pipe this into whatever alerting or analysis you
want. I'm keeping it simple for now, just a file on disk.</p>
<p>The end goal is to use this log to build something like
<a href="https://github.com/ldayton/Dippy">Dippy</a>, a smart
auto-approve hook. Dippy parses bash commands with an AST
and auto-approves safe ones while still prompting for
anything destructive. I want to do the same thing but
trained on my own audit trail, so the approve/deny decisions
reflect how I actually work. That's a future post.</p>
<h1 id="wiring-it-up">Wiring it up</h1>
<p>All three hooks go in <code>~/.claude/settings.json</code> under a
<code>hooks</code> key:</p>
<pre><code class="language-json">{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{
          "type": "command",
          "command": "/Users/kp/.claude/hooks/block-destructive.sh"
        }]
      },
      {
        "matcher": "Read|Edit|Write|Bash",
        "hooks": [{
          "type": "command",
          "command": "/Users/kp/.claude/hooks/protect-sensitive.sh"
        }]
      }
    ],
    "PostToolUse": [
      {
        "hooks": [{
          "type": "command",
          "command": "/Users/kp/.claude/hooks/audit-log.sh",
          "async": true
        }]
      }
    ]
  }
}
</code></pre>
<p>Use absolute paths, not <code>~</code>. JSON doesn't expand tilde.</p>
<p>The <code>async: true</code> on the audit hook means Claude doesn't
wait for it to finish before moving on. Logging shouldn't
slow down the workflow.</p>
<h1 id="prompt-injection-defense">Prompt injection defense</h1>
<p>One thing I haven't built yet but plan to: a PostToolUse
hook that scans tool output for prompt injection attempts.</p>
<p>The idea is to grep the output for patterns like "ignore
previous instructions" or "you are now in admin mode" and
flag them. This matters most for tools that ingest external
data. If Claude is reading web pages, parsing documents,
or pulling content from APIs, a malicious payload in that
content could try to hijack the session.</p>
<p>Lasso Security published a
<a href="https://www.lasso.security/blog/prompt-injection-taxonomy-techniques">prompt injection taxonomy</a>
cataloging these techniques: encoding, obfuscation,
role-playing, context manipulation, and more. A PostToolUse
hook is the right place to catch
them because you see the actual content before Claude acts
on it.</p>
<p>I'll cover this in a future post once I have it running on
real workloads.</p>
<h1 id="why-global-config-not-per-repo">Why global config, not per-repo</h1>
<p>Claude Code hooks can be configured at three levels:</p>
<ul>
<li><code>~/.claude/settings.json</code> (global, user-level)</li>
<li><code>.claude/settings.json</code> (per-repo, checked into git)</li>
<li><code>.claude/settings.local.json</code> (per-repo, gitignored)</li>
</ul>
<p>Safety hooks belong in global config. If they're per-repo,
a malicious repository can ship its own <code>.claude/settings.json</code>
that disables your protections or adds hooks that exfiltrate
data. You clone it, run Claude Code, and the repo's hooks
run instead of yours.</p>
<p>This is a real attack vector. In 2025, Check Point Research
found
<a href="https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/">CVE-2025-59536</a>:
an attacker plants a <code>.claude/settings.json</code> with hooks in
a repo. You clone it, run Claude Code, approve the trust
dialog (which doesn't mention hooks), and the hook commands
execute immediately. Reverse shell, data exfiltration,
whatever the attacker wants. Anthropic patched it in August
2025, but the lesson stands: keep safety hooks in global
config where only you control them.</p>
<h1 id="same-idea-different-tools">Same idea, different tools</h1>
<p>Claude Code isn't the only AI coding tool with hook support.
Here's how the same concepts map elsewhere.</p>
<table>
<thead>
<tr>
<th>Feature</th>
<th>Claude Code</th>
<th>Cursor</th>
</tr>
</thead>
<tbody>
<tr>
<td>Hook format</td>
<td>Shell scripts</td>
<td>Shell scripts</td>
</tr>
<tr>
<td>Config</td>
<td><code>~/.claude/settings.json</code></td>
<td><code>.cursor/hooks.json</code></td>
</tr>
<tr>
<td>Events</td>
<td><code>PreToolUse</code>, <code>PostToolUse</code></td>
<td><code>preToolUse</code>, <code>postToolUse</code></td>
</tr>
<tr>
<td>Input</td>
<td>JSON on stdin</td>
<td>JSON on stdin</td>
</tr>
<tr>
<td>Block mechanism</td>
<td>Exit code 2 + stderr</td>
<td>Exit code 2 + stderr</td>
</tr>
<tr>
<td>Async support</td>
<td><code>"async": true</code></td>
<td>Not documented</td>
</tr>
</tbody>
</table>
<p>Cursor added hooks in version 1.7 (October 2025) with a
nearly identical model: shell scripts, JSON stdin, exit
codes. It also supports a "prompt" handler type where an
LLM evaluates a natural language condition to allow or deny,
which is interesting but slower. The same shell scripts
could work in both tools with minor config changes.</p>
<p>OpenCode takes a different approach. Instead of shell
scripts, it uses JavaScript or TypeScript plugins placed in
<code>.opencode/plugins/</code> or <code>~/.config/opencode/plugins/</code>. You
register functions on events like <code>tool.execute.before</code> and
<code>tool.execute.after</code>. More powerful (you get full access to
the session and project context), but less portable than a
shell script you can reuse across tools.</p>


<p>The <a href="/bot-wiki.html">bot-wiki post</a> introduced a structured wiki
designed for machine consumption. The whole point was to build
something a RAG pipeline could actually use. This is that pipeline.</p>
<h2 id="the-stack">The stack</h2>
<p>The wiki has 21 markdown pages with structured frontmatter:
title, summary, keywords, scope. The RAG pipeline is a single
Python script that:</p>
<ol>
<li>Embeds all 21 pages into vectors using OpenRouter's API</li>
<li>Stores them in a FAISS flat index (129 KB, committed to git)</li>
<li>At query time, embeds the question, finds the nearest pages,
and feeds them to an LLM for a grounded answer</li>
</ol>
<p>Dependencies: <code>faiss-cpu</code>, <code>openai</code> (for the OpenAI-compatible
API), and <code>pyyaml</code>. That's it.</p>
<h2 id="why-faiss">Why FAISS</h2>
<p><a href="https://github.com/facebookresearch/faiss">FAISS</a> is Meta's
library for similarity search over dense vectors. It runs
in-process, no server needed. You give it vectors, it gives
you nearest neighbors. The index is a flat file you can
commit to git.</p>
<p>I picked it because this is 21 vectors. There's no need for
a database, a server, or a managed service. <code>pip install faiss-cpu</code>, build an index, save it, done. The index is
129 KB. It loads in milliseconds.</p>
<p>If you're working at larger scale or want more features,
the main alternatives are:</p>
<ul>
<li><a href="https://github.com/chroma-core/chroma">Chroma</a>: embedded
vector database with a nice Python API. Good if you want
metadata filtering or persistence without managing files
yourself. Still runs locally.</li>
<li><a href="https://github.com/qdrant/qdrant">Qdrant</a>: vector search
engine written in Rust. Runs as a server, supports
filtering and payloads. Better fit when you have millions
of vectors or need a proper API.</li>
<li><a href="https://www.pinecone.io/">Pinecone</a>: fully managed cloud
vector database. Zero ops, but you're paying per query and
your data lives on someone else's servers.</li>
</ul>
<p>If you're already running PostgreSQL,
<a href="https://github.com/pgvector/pgvector">pgvector</a> is worth
a look. It adds vector columns and similarity search to
your existing database. No new service to run, and your
vectors live next to your relational data.</p>
<p>For 21 pages committed to a git repo, FAISS is the obvious
choice. No dependencies beyond the pip package, no running
services, no accounts.</p>
<h2 id="why-whole-page-chunks">Why whole-page chunks</h2>
<p>The wiki pages are short, 18 to 65 lines each. Splitting them
by section would lose context without gaining anything. The
frontmatter was designed to enrich embeddings, so each chunk
looks like this:</p>
<pre><code>Title: Claude Code
Summary: Anthropic's CLI-based AI coding assistant. Runs
  in terminal, edits files directly, supports MCP tool
  integrations and custom hooks.
Keywords: claude-code, anthropic, cli, ai-coding-assistant,
  mcp, hooks
Scope: Covers Claude Code setup, configuration, MCP
  integration, hooks, and usage patterns.

Claude Code is Anthropic's CLI tool for AI-assisted software
engineering. It operates directly in the terminal...
</code></pre>
<p>Prepending the summary, keywords, and scope to the body gives
the embedding model more signal about what the page covers.
21 chunks, 5,434 tokens total.</p>
<h3 id="chunking-in-general">Chunking in general</h3>
<p>Most RAG guides recommend chunks of 256 to 512 tokens. That's
a reasonable default for long documents where you want to
retrieve a specific paragraph, not the whole thing. Smaller
chunks give more precise retrieval. Larger chunks give the
LLM more context per result.</p>
<p>The tradeoffs:</p>
<ul>
<li><strong>Too small</strong> (under 100 tokens): chunks lose meaning on
their own. "See above" or "as mentioned" with no referent.
Retrieval finds fragments, not answers.</li>
<li><strong>Too large</strong> (over 1000 tokens): embeddings become diluted.
A chunk about five topics matches all five weakly instead
of one strongly. You also burn more of the LLM's context
window per retrieved result.</li>
<li><strong>Overlap</strong> helps when chunks split mid-thought. A common
pattern is 512-token chunks with 50-100 tokens of overlap.
This adds redundancy but reduces the chance of cutting a
relevant passage in half.</li>
</ul>
<p>The wiki pages average about 260 tokens each, which lands
right in the sweet spot. They're also self-contained by
design, each page covers one topic with clear boundaries.
No reason to split them further.</p>
<p>If I were indexing longer documents (blog posts, docs, book
chapters), I'd split by section headers first, then by token
count within sections. Semantic boundaries beat arbitrary
ones.</p>
<h2 id="building-the-index">Building the index</h2>
<pre><code class="language-bash">pip install -r bin/requirements-rag.txt
python bin/wiki-rag.py build
</code></pre>
<pre><code>Embedding 21 wiki pages...
Indexed 21 pages, 1536 dimensions, 5434 tokens
Index: 129,069 bytes, metadata: 29,663 bytes
Saved to blog/markdown/wiki/.index
</code></pre>
<p>The embedding model is <code>text-embedding-3-small</code> via OpenRouter.
1536 dimensions per vector. The FAISS index uses <code>IndexFlatIP</code>
(inner product on normalized vectors = cosine similarity). No
approximate search needed at this scale.</p>
<p>The index and a <code>metadata.json</code> file (slug, title, summary,
full chunk text for each page) get saved to
<code>blog/markdown/wiki/.index/</code>. Both files are committed to git.
Any tool that wants to query the wiki can just read the index
directly without needing the embedding API.</p>
<p>The build is a manual step, not part of <code>npm run build</code>. Wiki
content doesn't change often, and there's no reason to pay for
embeddings on every deploy.</p>
<h2 id="querying">Querying</h2>
<p>A query hits two models. First, the question gets embedded
into a vector using the same embedding model that indexed
the wiki pages. FAISS compares that vector against the 21
stored vectors and returns the closest matches. Those
matches are wiki pages that are semantically similar to the
question, not keyword matches, but meaning matches.</p>
<p>Then the retrieved pages get passed to an LLM (Claude
Sonnet) as context, along with the original question. The
LLM reads the pages and writes an answer grounded in what
they actually say. Without the retrieval step, the LLM
would just guess from its training data. With it, the LLM
answers from your specific documents.</p>
<p>That's the "retrieval-augmented" part of RAG: find relevant
documents first, then generate an answer from them.</p>
<pre class="mermaid">
graph LR
    Q[Question] --> E[Embed question]
    E --> F[FAISS search]
    F --> R[Top 3 wiki pages]
    R --> P[Build prompt]
    P --> LLM[Claude Sonnet]
    LLM --> A[Answer + sources]
</pre>
<pre><code class="language-bash">python bin/wiki-rag.py query "What MCP servers does this
  project use?"
</code></pre>
<pre><code>Question: What MCP servers does this project use?

Top 3 matches:
  1. [0.644] MCP Integrations (wiki/mcp)
  2. [0.563] Linear MCP (wiki/mcp/linear)
  3. [0.524] GA4 MCP (wiki/mcp/ga4)

Answer:
Based on the provided context, this project uses three MCP
servers:

1. Playwright, for browser automation
2. Linear, for project management
3. GA4, for accessing website traffic data and reports

All MCP servers run as subprocesses communicating via JSON-RPC
over stdio, and are configured in ~/.claude.json or a
project-level .claude.json file.
</code></pre>
<p>The retrieval nailed the right pages. Here's a different query:</p>
<pre><code class="language-bash">python bin/wiki-rag.py query "How do I run security scans?"
</code></pre>
<pre><code>Question: How do I run security scans?

Top 3 matches:
  1. [0.484] Security Toolkit (wiki/devops/security-toolkit)
  2. [0.439] DevOps &#x26; Security (wiki/devops)
  3. [0.343] OpenClaw Kubernetes Security (wiki/openclaw/kubernetes)
</code></pre>
<p>The answer included the actual docker commands from the security
toolkit wiki page, copy-paste ready. The third result
(Kubernetes security) is a reasonable stretch, the word
"security" overlaps, but the top two are exactly right.</p>
<h2 id="the-script">The script</h2>
<p>The interesting parts are small. Embedding is a single API call
since all 21 pages fit in one batch:</p>
<pre><code class="language-python">client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)
response = client.embeddings.create(
    model="openai/text-embedding-3-small",
    input=texts,
)
</code></pre>
<p>OpenRouter's embedding endpoint is OpenAI-compatible, so the
<code>openai</code> Python package works with just a base URL swap.</p>
<p>FAISS search returns similarity scores and indices:</p>
<pre><code class="language-python">scores, indices = index.search(query_vec, k)
for score, idx in zip(scores[0], indices[0]):
    page = metadata[idx]
    # score is cosine similarity (0 to 1)
</code></pre>
<p>The retrieved pages get stuffed into a prompt with instructions
to only use the provided context and cite sources. The LLM
(Claude Sonnet via OpenRouter) generates the answer.</p>
<h2 id="cost">Cost</h2>
<p>Indexing 21 pages used 5,434 tokens at
<code>text-embedding-3-small</code> rates ($0.02/1M tokens). That's
$0.0001. Each query embeds a short question (maybe 20 tokens)
plus one chat completion. A query costs roughly $0.002 to
$0.01 depending on the response length.</p>
<p>Building the index and running test queries cost $0.03
total on OpenRouter. That covers the embedding API calls
and the chat completions for query-mode answers. The
development itself (writing the script, iterating on the
blog post) ran through Claude Code on an Anthropic Max
subscription, so that cost isn't on the OpenRouter bill.</p>


<p>I added a new top-level section to this site: the
<a href="/wiki.html">Bot-Wiki</a>.</p>
<p>It looks like a wiki. It reads like a wiki. But it's not really for
humans. It's a structured knowledge base designed for AI agents and
RAG pipelines to consume.</p>
<h2 id="why-a-wiki-when-i-already-have-a-blog">Why a wiki when I already have a blog?</h2>
<p>Blog posts are stories. They have a narrative arc, opinions, tangents.
They're written for people who want to understand how I got from point
A to point B. That's great for learning from my experience but
terrible for a robot trying to answer "what MCP servers does this
project use?"</p>
<p>The wiki is the opposite. Each page is a factual reference card.
Structured metadata, explicit scope declarations, keyword lists for
embedding search, and cross-references for graph traversal. The tone
is robots writing notes for other robots.</p>
<h2 id="whats-in-it">What's in it</h2>
<p>The wiki covers the same ground as my recent blog posts but organized
by topic rather than chronology:</p>
<ul>
<li><strong>AI Tools</strong>: Claude Code, OpenCode, OpenRouter, local LLMs, image gen</li>
<li><strong>MCP Integrations</strong>: Playwright, Linear, GA4</li>
<li><strong>OpenClaw</strong>: the agent, its skills, Kubernetes security</li>
<li><strong>DevOps</strong>: security toolkit, lint toolkit, Ruler</li>
<li><strong>Blog Architecture</strong>: how this site is built, the markdown pipeline,
testing setup</li>
</ul>
<p>Each page has frontmatter designed for machine consumption:</p>
<pre><code class="language-yaml">title: "Claude Code"
summary: "CLI AI coding assistant by Anthropic with MCP support"
keywords:
  - claude-code
  - anthropic
  - mcp
related:
  - wiki/ai-tools/opencode
  - playwright-mcp
scope: "Setup, config, MCP integration, and usage patterns"
last_verified: 2026-03-10
</code></pre>
<p>The <code>summary</code> and <code>scope</code> fields help a RAG system decide whether to
retrieve the full page. The <code>keywords</code> list feeds embedding search.
The <code>related</code> links let an agent traverse the knowledge graph.
<code>last_verified</code> tells the agent how stale the content might be.</p>
<h2 id="how-this-connects-to-rag">How this connects to RAG</h2>
<p>This is step one of a larger plan. Next I'm building a RAG pipeline
that indexes the wiki content, generates embeddings, and lets agents
query it during conversations. The wiki's structured metadata makes
chunking and retrieval much cleaner than trying to RAG over blog
posts directly.</p>
<p>The directory structure maps to the URL structure which maps to the
knowledge hierarchy. An agent asking about MCP servers gets pointed
to <code>wiki/mcp/</code> and its children, not to a 2000-word blog post that
mentions MCP in passing.</p>
<h2 id="how-its-built">How it's built</h2>
<p>The wiki reuses the blog's existing infrastructure. A new <code>WikiService</code>
reads markdown from <code>markdown/wiki/</code> instead of <code>markdown/posts/</code>,
builds a tree from the directory structure, and generates navigation
automatically. Each <code>index.md</code> file gets a tree of its children
rendered above its own content.</p>
<p>The routing plugs into the same Next.js catch-all that handles blog
posts. Wiki pages get the same layout, sidebar, and responsive
behavior. They just have different content and metadata.</p>
<p>No images in the wiki. It's all text, all the time. Robots don't
need hero images.</p>
<p>You can find it at <a href="/wiki.html">/wiki.html</a>, or use the new Wiki
link in the header.</p>


<h2 id="table-of-contents">Table of contents</h2>
<ul>
<li><a href="#why-one-router">Why one router</a>
<ul>
<li><a href="#claudes-token-efficiencies">Claude's token efficiencies</a></li>
</ul>
</li>
<li><a href="#getting-an-openrouter-key">Getting an OpenRouter key</a></li>
<li><a href="#claude-code">Claude Code</a></li>
<li><a href="#opencode">OpenCode</a>
<ul>
<li><a href="#what-didnt-work">What didn't work</a></li>
<li><a href="#what-worked">What worked</a></li>
</ul>
</li>
<li><a href="#openclaw">OpenClaw</a></li>
<li><a href="#custom-openrouter-usage-mcp">Custom OpenRouter Usage MCP</a>
<ul>
<li><a href="#registering-it">Registering it</a></li>
<li><a href="#usage-output">Usage output</a></li>
<li><a href="#model-pricing-snapshot">Model pricing snapshot</a></li>
</ul>
</li>
</ul>
<h1 id="why-one-router">Why one router</h1>
<p>I run three AI tools regularly: Claude Code, OpenCode,
and OpenClaw. Each has its own API key, its own billing
dashboard, and its own model config. Anthropic bills
Claude Code. Google bills OpenClaw's Gemini usage.
OpenCode can talk to either.</p>
<p>That's three places to check spend, three sets of rate
limits, and no single view of what I'm burning through.
OpenRouter fixes this. It's a proxy that sits between
your tools and the model providers. You get one API key,
one billing dashboard, and the ability to swap models
without changing provider credentials.</p>
<p>The tradeoff is a small markup on token costs and an
extra network hop. For a personal setup where I want
visibility and flexibility, that's fine.</p>
<h2 id="claudes-token-efficiencies">Claude's token efficiencies</h2>
<p>Anthropic's Pro and Max plans include Claude Code
usage at a steep discount compared to raw API pricing.
Pro is $20/month with generous token allowances. Max
plans scale up from there. If you only use Claude Code,
the Pro plan is the cheapest way to run it.</p>
<p>The problem is that those plan tokens only work with
Claude Code through Anthropic's direct API. OpenCode
and OpenClaw are third-party tools. They can call
Claude models, but not through your Pro subscription.
They hit the standard API and bill at full rate.</p>
<p>So the choice is: keep Claude Code on the Pro plan
(cheapest for that one tool) and manage the other two
separately, or route everything through OpenRouter and
get unified billing at API rates. I went with
OpenRouter because the visibility across all three
tools matters more to me than the per-token savings
on Claude Code alone.</p>
<h1 id="getting-an-openrouter-key">Getting an OpenRouter key</h1>
<ol>
<li>Sign up at <a href="https://openrouter.ai">openrouter.ai</a></li>
<li>Go to Settings > Keys and create a new API key</li>
<li>Add credits (pay-as-you-go, no minimum)</li>
</ol>
<p>OpenRouter gave me $100 in free credits as a signup
promo. That's a lot of tokens to experiment with before
committing any money.</p>
<p>Set the key in your shell:</p>
<pre><code class="language-bash">export OPENROUTER_API_KEY="sk-or-v1-..."
</code></pre>
<p>Add it to your <code>~/.zshrc</code> or <code>~/.bashrc</code> so it persists.
The same key works for every tool below.</p>
<p>OpenRouter's <a href="https://openrouter.ai/models">models page</a>
shows per-token pricing for every model. Useful for
comparing costs before swapping models around.</p>
<h1 id="claude-code">Claude Code</h1>
<p>Claude Code normally talks directly to Anthropic's API.
To route it through OpenRouter, you override the base
URL and auth token via environment variables:</p>
<pre><code class="language-bash">ANTHROPIC_BASE_URL="https://openrouter.ai/api" \
ANTHROPIC_AUTH_TOKEN="$OPENROUTER_API_KEY" \
ANTHROPIC_API_KEY="" \
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 \
claude
</code></pre>
<p>Four variables. <code>ANTHROPIC_BASE_URL</code> points Claude Code
at OpenRouter instead of Anthropic. <code>ANTHROPIC_AUTH_TOKEN</code>
passes your OpenRouter key. <code>ANTHROPIC_API_KEY</code> must be
set to an empty string, otherwise Claude Code tries to
use it and the auth conflicts.
<code>CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC</code> stops
telemetry calls that would fail against OpenRouter.</p>
<p>That's verbose to type every time. I wrapped it in a
shell function:</p>
<pre><code class="language-bash"># ~/.zshrc
orclaude() {
  ANTHROPIC_BASE_URL="https://openrouter.ai/api" \
  ANTHROPIC_AUTH_TOKEN="$OPENROUTER_API_KEY" \
  ANTHROPIC_API_KEY="" \
  CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 \
  claude "$@"
}
</code></pre>
<p>Now <code>orclaude</code> launches Claude Code through OpenRouter.
Regular <code>claude</code> still uses the Anthropic API directly.</p>
<p>You can also swap models. Claude Code has three model
slots (Opus, Sonnet, Haiku) that you can override:</p>
<pre><code class="language-bash">export ANTHROPIC_DEFAULT_SONNET_MODEL=\
  "google/gemini-2.5-pro"
export ANTHROPIC_DEFAULT_HAIKU_MODEL=\
  "google/gemini-2.5-flash"
</code></pre>
<p>Any model on OpenRouter that supports tool use works.
Models without tool use will break Claude Code since
it relies on tools for file reading, editing, and
command execution.</p>
<h1 id="opencode">OpenCode</h1>
<p>OpenCode has native OpenRouter support.</p>
<h2 id="what-didnt-work">What didn't work</h2>
<p>I tried putting the API key in <code>opencode.json</code>. It passed config validation but
OpenCode still tried to bill through its own payment system. "No payment method" error
pointing at OpenCode's billing page, not OpenRouter's.</p>
<h2 id="what-worked">What worked</h2>
<p>OpenCode picks up <code>OPENROUTER_API_KEY</code> from the environment automatically. The config
file only needs the model names. <code>opencode.json</code> goes in the project root where you
launch it, or the global <code>~/.config/opencode/opencode.json</code>.</p>
<pre><code class="language-json">{
  "model": "openrouter/anthropic/claude-sonnet-4-6",
  "small_model": "openrouter/anthropic/claude-haiku-4-5"
}
</code></pre>
<p>The key has to be registered through OpenCode's auth system. Inside the TUI:</p>
<ol>
<li>Run <code>/connect</code></li>
<li>Search for "OpenRouter"</li>
<li>Paste your API key</li>
</ol>
<p>After that, OpenCode routes through OpenRouter. The
<code>openrouter/</code> prefix on model names tells it which
provider to use.</p>
<p>Note: OpenCode shows a warning when you select
OpenRouter saying requests "will often be routed to
subpar providers." That feels like they're trying to just sell their own model hosting.</p>
<h1 id="openclaw">OpenClaw</h1>
<p>OpenClaw has native OpenRouter support. The model
reference format is <code>openrouter/&#x3C;provider>/&#x3C;model></code>,
same as OpenCode.</p>
<p>In OpenClaw's home directory, <code>openclaw.json</code>, for the K8s setup
<code>/home/node/.openclaw/openclaw.json</code> (the PVC mount). For a local install it'd be
<code>~/.openclaw/openclaw.json.</code>:</p>
<pre><code class="language-json5">{
  env: { OPENROUTER_API_KEY: "sk-or-..." },
  agents: {
    defaults: {
      model: {
        primary: "openrouter/anthropic/claude-sonnet-4-6"
      },
    },
  },
}
</code></pre>
<p>Or use the CLI:</p>
<pre><code class="language-bash">openclaw onboard \
  --auth-choice apiKey \
  --token-provider openrouter \
  --token "$OPENROUTER_API_KEY"
</code></pre>
<p>Since my OpenClaw runs in K8s with secrets injected via
Vault, I added <code>OPENROUTER_API_KEY</code> to the Vault secret
and updated the Vault Agent template to export it. Same
pattern as the
<a href="/openclaw-linear-skill.html">Linear API key</a> from the
previous post.</p>
<p>After redeploying, I cleared my OpenClaw agent's sessions (OpenClaw
caches the model config per session) and asked what
model it was running:</p>
<pre><code class="language-text">Claude: What model are you running on?
Pai: I'm running on Claude Sonnet 4.6 via OpenRouter
  (openrouter/anthropic/claude-sonnet-4-6).
</code></pre>
<p>Previously Pai ran Gemini 2.5 Flash through Google's
API directly. Now it's Claude Sonnet 4.6 through
OpenRouter. Same Vault-injected credentials pattern,
different model, one billing dashboard.</p>
<p>The Linear skill still works through the new model.
Pai listed my teams and issues the same as before.
The skill's curl commands don't care which model is
driving the agent.</p>
<h1 id="custom-openrouter-usage-mcp">Custom OpenRouter Usage MCP</h1>
<p>With everything routed through OpenRouter, I wanted
to check my spend without leaving the terminal. OpenRouter
has a billing API, so I built a small
<a href="https://github.com/kylep/multi/tree/main/apps/mcp-servers/openrouter">MCP server</a>
that queries it.</p>
<p>The server has two tools. <code>get_usage</code> calls the
<code>/api/v1/key</code> endpoint and returns daily, weekly, monthly,
and total spend plus remaining credits. <code>get_model_pricing</code>
calls <code>/api/v1/models</code> and shows per-million-token costs,
with an optional filter to search by model name.</p>
<p>The whole thing is one TypeScript file using the MCP SDK
with stdio transport. It reads <code>OPENROUTER_API_KEY</code> from
the environment, same key the other tools already use.</p>
<h2 id="registering-it">Registering it</h2>
<p>In <code>~/.claude.json</code>, under the project's <code>mcpServers</code>:</p>
<pre><code class="language-json">"openrouter": {
  "type": "stdio",
  "command": "node",
  "args": [
    "/path/to/openrouter-mcp/build/index.js"
  ]
}
</code></pre>
<p>No <code>env</code> block needed. Claude Code spawns it as a child
process, which inherits the shell environment.</p>
<h2 id="usage-output">Usage output</h2>
<p>After restarting Claude Code, I asked it to check my
OpenRouter usage:</p>
<pre><code class="language-text">Key: sk-or-v1-3fd...374
Free tier: no

Usage:
  Today:  $0.5467
  Week:   $0.5467
  Month:  $0.5467
  Total:  $0.5467

Credit limit:
  Limit:     $200.0000
  Remaining: $199.4533
</code></pre>
<p>That $0.55 is from a few hours of Claude Code and
OpenCode use. The $200 limit is what I set on the key
in OpenRouter's dashboard.</p>
<p>The pricing tool is useful for comparing models before
switching. Searching "claude-sonnet-4" shows all the
Sonnet variants and their per-million-token rates side
by side.</p>
<h2 id="model-pricing-snapshot">Model pricing snapshot</h2>
<p>Pulled from <code>get_model_pricing</code> on 2026-03-10:</p>
<table>
<thead>
<tr>
<th>Model</th>
<th>Prompt</th>
<th>Completion</th>
<th>Context</th>
</tr>
</thead>
<tbody>
<tr>
<td>openai/gpt-5.4-pro</td>
<td>$30.00/M</td>
<td>$180.00/M</td>
<td>1050k</td>
</tr>
<tr>
<td>openai/gpt-5.4</td>
<td>$2.50/M</td>
<td>$15.00/M</td>
<td>1050k</td>
</tr>
<tr>
<td>openai/gpt-5.3-codex</td>
<td>$1.75/M</td>
<td>$14.00/M</td>
<td>400k</td>
</tr>
<tr>
<td>openai/gpt-5.2-pro</td>
<td>$21.00/M</td>
<td>$168.00/M</td>
<td>400k</td>
</tr>
<tr>
<td>openai/gpt-5.1</td>
<td>$1.25/M</td>
<td>$10.00/M</td>
<td>400k</td>
</tr>
<tr>
<td>anthropic/claude-opus-4.6</td>
<td>$5.00/M</td>
<td>$25.00/M</td>
<td>1000k</td>
</tr>
<tr>
<td>anthropic/claude-sonnet-4.6</td>
<td>$3.00/M</td>
<td>$15.00/M</td>
<td>1000k</td>
</tr>
<tr>
<td>anthropic/claude-haiku-4.5</td>
<td>$1.00/M</td>
<td>$5.00/M</td>
<td>200k</td>
</tr>
<tr>
<td>anthropic/claude-opus-4</td>
<td>$15.00/M</td>
<td>$75.00/M</td>
<td>200k</td>
</tr>
<tr>
<td>anthropic/claude-sonnet-4</td>
<td>$3.00/M</td>
<td>$15.00/M</td>
<td>200k</td>
</tr>
<tr>
<td>google/gemini-3.1-pro-preview</td>
<td>$2.00/M</td>
<td>$12.00/M</td>
<td>1049k</td>
</tr>
<tr>
<td>google/gemini-2.5-pro</td>
<td>$1.25/M</td>
<td>$10.00/M</td>
<td>1049k</td>
</tr>
<tr>
<td>google/gemini-2.5-flash</td>
<td>$0.30/M</td>
<td>$2.50/M</td>
<td>1049k</td>
</tr>
<tr>
<td>google/gemini-2.5-flash-lite</td>
<td>$0.10/M</td>
<td>$0.40/M</td>
<td>1049k</td>
</tr>
<tr>
<td>deepseek/deepseek-v3.2</td>
<td>$0.25/M</td>
<td>$0.40/M</td>
<td>164k</td>
</tr>
<tr>
<td>deepseek/deepseek-r1-0528</td>
<td>$0.45/M</td>
<td>$2.15/M</td>
<td>164k</td>
</tr>
<tr>
<td>meta-llama/llama-4-maverick</td>
<td>$0.15/M</td>
<td>$0.60/M</td>
<td>1049k</td>
</tr>
<tr>
<td>mistralai/mistral-large-2512</td>
<td>$0.50/M</td>
<td>$1.50/M</td>
<td>262k</td>
</tr>
<tr>
<td>qwen/qwen3.5-397b-a17b</td>
<td>$0.39/M</td>
<td>$2.34/M</td>
<td>262k</td>
</tr>
<tr>
<td>qwen/qwen3-coder-plus</td>
<td>$0.65/M</td>
<td>$3.25/M</td>
<td>1000k</td>
</tr>
</tbody>
</table>
<p>Prices are per million tokens. These change often.
Check OpenRouter's models page for current rates.</p>


<h2 id="table-of-contents">Table of contents</h2>
<ul>
<li><a href="#why-i-dont-trust-the-skill-marketplace">Why I don't trust the skill marketplace</a></li>
<li><a href="#how-openclaw-skills-work">How OpenClaw skills work</a></li>
<li><a href="#the-skill">The skill</a></li>
<li><a href="#one-ai-writing-tools-for-another">One AI writing tools for another</a></li>
<li><a href="#loading-it-into-k8s">Loading it into K8s</a>
<ul>
<li><a href="#injecting-the-api-key">Injecting the API key</a></li>
<li><a href="#mounting-the-skill">Mounting the skill</a></li>
<li><a href="#the-jq-problem">The jq problem</a></li>
<li><a href="#stale-sessions">Stale sessions</a></li>
</ul>
</li>
<li><a href="#talking-to-pai-pericak-ai">Talking to Pai (Pericak AI)</a></li>
</ul>
<h1 id="why-i-dont-trust-the-skill-marketplace">Why I don't trust the skill marketplace</h1>
<p>In the <a href="/openclaw-k8s.html">K8s post</a> I mentioned wanting
to connect OpenClaw to Linear for issue tracking. The
obvious path is ClawHub, OpenClaw's public skill
marketplace. Install a community skill, set your API key,
done. I didn't do that.</p>
<p>In February 2026, a campaign called
<a href="https://cybersecuritynews.com/clawhavoc-poisoned-openclaws-clawhub/">ClawHavoc</a>
compromised ClawHub. Researchers at Trend Micro and Antiy
documented over 1,184 malicious skills that had been
published to the registry. The skills looked legitimate,
had normal names and descriptions, and passed ClawHub's
automated checks. They distributed
<a href="https://www.trendmicro.com/en_us/research/26/b/openclaw-skills-used-to-distribute-atomic-macos-stealer.html">Atomic macOS Stealer</a>,
a credential harvester targeting Keychain, browser
passwords, and crypto wallets.</p>
<p>The publishing bar was low. A one-week-old GitHub account
was enough to push a skill to ClawHub. No code review, no
signing, no sandbox. Once installed, a skill runs inside
the agent process with access to every environment variable
the agent has. That includes API keys, tokens, and anything
else injected via Vault or config.</p>
<p>This is the same pattern that hit npm, PyPI, and VS Code
extensions. A package registry with low friction publishing
and high-privilege execution is a target. ClawHub is no
different.</p>
<p>My approach: write the skill myself, keep it in my repo,
and audit every line. The Linear skill I need is about 150
lines of markdown. That's a small surface to own compared
to trusting a stranger's code with my credentials.</p>
<h1 id="how-openclaw-skills-work">How OpenClaw skills work</h1>
<p>An OpenClaw skill is a directory with a <code>SKILL.md</code> file.
The file has YAML frontmatter (name, description, required
tools and environment variables) and a markdown body with
instructions the agent follows.</p>
<p>There's no compiled code. No dependencies to install. No
background process. The agent reads the markdown, learns
what commands are available, and executes them via bash
when you ask it to. If you want to audit a skill, you read
one file.</p>
<p>Compare this to MCP servers, which are running processes
that the agent connects to over a transport protocol. MCP
servers can do more (stateful connections, streaming), but
they're also harder to audit and have a larger attack
surface. For something like "list my Linear issues," a
static document with curl commands is plenty.</p>
<p>The frontmatter declares what the skill needs:</p>
<pre><code class="language-yaml">---
name: linear
description: Manage Linear issues, projects,
  and comments via the Linear GraphQL API.
metadata: {"openclaw": {"emoji": "📐",
  "requires": {"bins": ["curl"],
  "env": ["LINEAR_API_KEY"]}}}
---
</code></pre>
<p>OpenClaw checks these requirements at load time. If <code>curl</code>
isn't on PATH, or <code>LINEAR_API_KEY</code> isn't set, the skill
doesn't load. No runtime errors, no mysterious failures.</p>
<h1 id="the-skill">The skill</h1>
<p>I had Claude write a Linear skill covering the operations
I actually use: listing issues, creating and updating them,
managing labels, and adding comments. The full skill lives
at <code>apps/openclaw-skills/linear/SKILL.md</code> in my monorepo.</p>
<p>Linear's API is GraphQL-only. No REST endpoints. Every
request is a POST to <code>https://api.linear.app/graphql</code> with
a JSON body containing the query. The skill uses <code>curl</code>
for HTTP. One API key, no OAuth dance.</p>
<p>The auth header is <code>Authorization: $LINEAR_API_KEY</code>.
Linear personal API keys don't use a <code>Bearer</code> prefix.</p>
<p>Here's what listing issues looks like:</p>
<pre><code class="language-bash">curl -s -X POST https://api.linear.app/graphql \
  -H "Content-Type: application/json" \
  -H "Authorization: $LINEAR_API_KEY" \
  -d '{"query": "{ issues(filter: { team: \
    { key: { eq: \"PER\" } } }, first: 25) \
    { nodes { id identifier title \
    state { name } } } }"}'
</code></pre>
<p>And creating an issue:</p>
<pre><code class="language-bash">curl -s -X POST https://api.linear.app/graphql \
  -H "Content-Type: application/json" \
  -H "Authorization: $LINEAR_API_KEY" \
  -d '{"query": "mutation { issueCreate(input: \
    { teamId: \"TEAM_UUID\", \
    title: \"Issue title\", \
    description: \"Issue description\" }) \
    { success issue { id identifier url } } }"}'
</code></pre>
<p>The skill also covers workflow statuses. Changing an
issue's status in Linear means looking up the target
state's UUID first, then passing it to <code>issueUpdate</code>. The
agent chains these naturally: list statuses, find the one
named "Todo", grab its ID, update the issue.</p>
<p>This matches the workflow I described in the
<a href="/linear-mcp.html">Linear MCP post</a>. Nightly agents create
Suggestion issues in Backlog, I promote the good ones to
Todo, working agents pick them up. The skill gives OpenClaw
the same Linear access that Claude Code gets through its
MCP server.</p>
<p>The full skill is about 150 lines of markdown. Ten
operations with copy-paste curl commands and a few compound
examples at the end. I read every line.</p>
<h1 id="one-ai-writing-tools-for-another">One AI writing tools for another</h1>
<p>Claude Code (Opus 4.6) wrote this skill. It read the
Trello skill as a pattern, checked the Linear GraphQL API
docs, and produced a skill that follows the same structure.
One AI building capabilities for another AI.</p>
<p>I described what I wanted at a high level, and Claude
handled the GraphQL query syntax, the jq filters, and the
escape sequences. I reviewed the output. The whole thing
took one conversation.</p>
<p>The skill lives in my monorepo under version control. If
Linear changes their API or I need a new operation, I
update one file.</p>
<h1 id="loading-it-into-k8s">Loading it into K8s</h1>
<p>Getting the skill into the running OpenClaw pod took more
work than writing it. The skill file needs to end up in
the right directory inside the container, the API key
needs to be injected, and OpenClaw needs to discover it.</p>
<h2 id="injecting-the-api-key">Injecting the API key</h2>
<p>I added the Linear API key to Vault alongside the existing
Gemini and Telegram secrets, then updated the Vault Agent
template to export it:</p>
<pre><code class="language-text">{{- with secret "secret/openclaw" -}}
export GEMINI_API_KEY="{{ .Data.data.gemini_api_key }}"
export TELEGRAM_BOT_TOKEN="..."
{{ if .Data.data.linear_api_key }}
export LINEAR_API_KEY="{{ .Data.data.linear_api_key }}"
{{ end }}
{{- end }}
</code></pre>
<h2 id="mounting-the-skill">Mounting the skill</h2>
<p>I stored the SKILL.md in a ConfigMap and mounted it into
the init container. ConfigMap mounts use symlinks
internally, and OpenClaw's skill loader rejects symlinked
paths as a security measure. So the init container copies
the file onto the PVC as a regular file:</p>
<pre><code class="language-yaml">initContainers:
  - name: config-seed
    command: ["sh", "-c"]
    args:
      - |
        # ... existing config seed logic ...
        # Copy skills onto PVC workspace
        mkdir -p /data/workspace/skills/linear
        cp /skill-src/linear/SKILL.md \
          /data/workspace/skills/linear/SKILL.md
    volumeMounts:
      - name: linear-skill
        mountPath: /skill-src/linear
        readOnly: true
</code></pre>
<p>The key detail: skills must live under the workspace
directory (<code>&#x3C;workspace>/skills/</code>), not just anywhere on
the filesystem. OpenClaw's skill discovery only scans
three locations: bundled, managed (<code>~/.openclaw/skills</code>),
and workspace. I initially tried <code>extraDirs</code> and the
managed path. Neither worked until I put it in the
workspace.</p>
<h2 id="the-jq-problem">The jq problem</h2>
<p>The original skill required both <code>curl</code> and <code>jq</code> in its
<code>requires.bins</code> frontmatter. The OpenClaw container has
<code>curl</code> but not <code>jq</code>. The skill gating check runs at
startup: missing binary means the skill silently doesn't
load. Claude dropped <code>jq</code> from the requirements. The agent
is smart enough to parse JSON responses on its own using
the <code>node</code> binary that's already in the container.</p>
<h2 id="stale-sessions">Stale sessions</h2>
<p>After all that, I asked Pai what skills it had. Still
three. OpenClaw snapshots eligible skills when a session
starts and reuses that list for the session's lifetime.
The <code>openclaw agent --message</code> CLI command was reusing an
existing session from before the skill was loaded.
Clearing the sessions directory forced a fresh snapshot:</p>
<pre><code class="language-bash">rm -rf /home/node/.openclaw/agents/main/sessions/*
</code></pre>
<p>After that, the skill appeared.</p>
<h1 id="talking-to-pai-pericak-ai">Talking to Pai (Pericak AI)</h1>
<p>With the skill loaded, Claude Code talked to Pai (the
OpenClaw agent running Gemini 2.5 Flash) through
<code>kubectl exec</code>, using the same pattern from the
<a href="/openclaw-k8s.html">K8s post</a>.</p>
<pre><code class="language-text">Claude: List my Linear teams using the linear skill.
Pai: Your Linear teams are:
  - Pericak (Key: PER)

Claude: List my Linear issues for team PER.
Pai: Here are the Linear issues for team PER:
  - PER-10: ... (State: Backlog)
  - PER-9: ... (State: Todo)
  - PER-8: ... (State: Todo)
  - PER-7: ... (State: Todo)
  - PER-6: ... (State: Todo)
  - PER-5: ... (State: Todo)
  ...
</code></pre>
<p>That's real output (titles redacted). Pai read the
skill's curl commands, called the Linear GraphQL API
with the Vault-injected API key, and returned my actual
issues. The full chain: Claude Code runs <code>kubectl exec</code>,
which calls the <code>openclaw agent</code> CLI, which sends the
message to Gemini 2.5 Flash, which reads the skill, runs
curl against Linear's API, and returns the result.</p>
<p>Two AIs, two different models, coordinating through a
Kubernetes pod with Vault-injected secrets and a
hand-written skill file. The whole thing is auditable
from end to end.</p>


<h1 id="what-openclaw-is">What OpenClaw is</h1>
<p><a href="https://openclaw.ai/">OpenClaw</a> is wildly popular and kind of confusing. From what I
can tell before starting, other than being a first-class security concern, it's meant
to be a tool that lets you connect to your ai agents over chat tools like WhatsApp.</p>
<p>It runs locally, you bring your own API key (Anthropic, OpenAI,
DeepSeek), and your data stays on your machine (until you screw up). The gateway
connects to messaging platforms like Telegram, Signal, WhatsApp,
Discord, and apparently about 20 others.</p>
<h1 id="install-on-macos">Install on macOS</h1>
<p>Prerequisites: Node.js 22+ and an API key for your chosen
model provider (more on that next).</p>
<p>The recommended install uses their script:</p>
<pre><code class="language-bash">curl -fsSL https://openclaw.ai/install.sh | bash
</code></pre>
<p>That handles Node detection and installs the <code>openclaw</code> CLI.
If you want to skip the wizard and install the binary only:</p>
<pre><code class="language-bash">curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard
</code></pre>
<p>Then run the onboarding wizard separately:</p>
<pre><code class="language-bash">openclaw onboard
</code></pre>
<p>The wizard walks through gateway setup, workspace directory,
and API key config. Everything lives in <code>~/.openclaw/</code>.</p>
<h1 id="picking-a-model">Picking a model</h1>
<p>The onboard wizard asks which model to use. OpenClaw supports
a long list of providers, but here are the ones that matter
for a personal assistant:</p>
<table>
<thead>
<tr>
<th>Model</th>
<th>Input / Output (per 1M tokens)</th>
<th>Good for</th>
</tr>
</thead>
<tbody>
<tr>
<td>Claude Haiku 4.5</td>
<td>$1 / $5</td>
<td>Cheap daily driver</td>
</tr>
<tr>
<td>Claude Sonnet 4.6</td>
<td>$3 / $15</td>
<td>Solid middle ground</td>
</tr>
<tr>
<td>Claude Opus 4.6</td>
<td>$5 / $25</td>
<td>Best reasoning</td>
</tr>
<tr>
<td>GPT-5</td>
<td>$1.25 / $10</td>
<td>Strong alternative</td>
</tr>
<tr>
<td>GPT-4o Mini</td>
<td>$0.15 / $0.60</td>
<td>Budget OpenAI</td>
</tr>
<tr>
<td>Gemini 2.5 Flash</td>
<td>Free (250 req/day) / ~$0.30 paid</td>
<td>Free option</td>
</tr>
<tr>
<td>Gemini 3 Pro</td>
<td>$2 / $12</td>
<td>Strong reasoning</td>
</tr>
<tr>
<td>DeepSeek (via Ollama)</td>
<td>Free (local)</td>
<td>Fully offline</td>
</tr>
</tbody>
</table>
<h2 id="can-you-use-your-20month-subscription">Can you use your $20/month subscription?</h2>
<p><strong>ChatGPT Plus/Pro:</strong> No. The subscription doesn't include API
access. You need a separate OpenAI API key with pay-as-you-go
billing.</p>
<p><strong>Claude Pro ($20/mo):</strong> Not anymore. Early on, people found a
workaround using OAuth tokens from the Claude Code CLI.
Anthropic shut that down in January 2026. You need a separate
Anthropic API key.</p>
<p><strong>Claude Max ($200/mo) and Claude Code subscription:</strong> Same
story. The setup-token auth path existed briefly but Anthropic
scoped the tokens so they only work with the official Claude
Code client.</p>
<h2 id="trying-geminis-model">Trying Gemini's model</h2>
<p>Apparently Google's Gemini API has a free tier, I tried it out. Gemini 2.5 Flash gets
250 requests/day free. For texting a bot a few times a day to manage issues, that's ok.</p>
<p>Annoyingly there are a bunch of 2.5 options. No idea if they all have free tiers.</p>
<p>I initially picked <code>google/gemini-2.5-flash-preview-09-2025</code> during the wizard and
gave it my api key using the <code>Paste API key now</code> option. Sadly that had an error</p>
<pre><code class="language-test">models/gemini-2.5-flash-preview-09-2025 is not found for API version v1beta,
</code></pre>
<p>Fixing it was a pain in the ass, their <code>/model</code> and <code>/models</code> tools TUI setup was jank
af and just didnt work.</p>
<pre><code class="language-bash">/exit
openclaw configure
</code></pre>
<p>I tried to switch the model up to <code>google/gemini-2.5-flash</code>.</p>
<p>Note that this thing stays running in the background</p>
<pre><code class="language-bash">➜  ~ ps aux | grep openclaw
kp               39009   0.1  1.0 444980720 173456   ??  R    11:03AM   0:07.97 openclaw-gateway
</code></pre>
<p>Re-open the TUI with <code>openclaw tui</code> if you end up out of it.</p>
<h2 id="connect-telegram">Connect Telegram</h2>
<p>I paused here to install Telegram on my MacBook. It's pretty easy if you already have
it on your phone, you just scan a QR code.</p>
<p>During the quick start it recommends you use Telegram. I chose to use
<code>Telegram (Bot API)</code>. Then I followed the instructions:</p>
<pre><code class="language-text">◇  Telegram bot token ───────────────────────────────────────────────────────────────────╮
│                                                                                        │
│  1) Open Telegram and chat with @BotFather                                             │
│  2) Run /newbot (or /mybots)                                                           │
│  3) Copy the token (looks like 123456:ABC...)                                          │
│  Tip: you can also set TELEGRAM_BOT_TOKEN in your env.                                 │
│  Docs: https://docs.openclaw.ai/telegram  │
│  Website: https://openclaw.ai                                                          │
│                                                                                        │
├────────────────────────────────────────────────────────────────────────────────────────╯
</code></pre>
<p>The /newbot prompt had me name it. Then I got the key to give OpenClaw.</p>
<h2 id="set-up-search">Set up Search</h2>
<p>I chose to use Gemini since I'm giving it that API key anyways. Plus, Google's gotta be
the best at search, right? It's like, their thing. Suprisingly it asked again for
<code>Gemini (Google Search) API key</code>. I just gave it the same key as before.</p>
<h2 id="sketchy-skills-time">Sketchy Skills Time</h2>
<p>Then I got to here and just proceeed. There was some news about malware in the skills.</p>
<pre><code class="language-text">◇  Skills status ─────────────╮
│                             │
│  Eligible: 8                │
│  Missing requirements: 43   │
│  Unsupported on this OS: 0  │
│  Blocked by allowlist: 0    │
│                             │
├─────────────────────────────╯
</code></pre>
<h2 id="places-api">Places API</h2>
<p>What, why?</p>
<pre><code class="language-text">◆  Set GOOGLE_PLACES_API_KEY for goplaces?
│  ○ Yes / ● No
</code></pre>
<h2 id="gemini-for-nano-banana">Gemini for nano banana</h2>
<p>I mean yeah but I already gave it this key twice, kinda annoying.</p>
<pre><code class="language-text">◆  Set GEMINI_API_KEY for nano-banana-pro?
│  ● Yes / ○ No
</code></pre>
<h2 id="the-other-keys-it-wants">The other keys it wants</h2>
<p>... It wants a lot of keys, just start saying no.</p>
<h2 id="hooks">Hooks</h2>
<p>I don't trust boot-md yet.</p>
<pre><code class="language-text">◆  Enable hooks?
│  ◻ Skip for now
│  ◻ 🚀 boot-md
│  ◼ 📎 bootstrap-extra-files (Inject additional workspace bootstrap files via glob/path patterns)
│  ◼ 📝 command-logger (Log all command events to a centralized audit file)
│  ◼ 💾 session-memory (Save session context to memory when /new or /reset command is issued)
</code></pre>
<h2 id="node-wants-to-find-devices-on-local-networks">Node wants to find devices on local networks</h2>
<p>MacOS popup. Yeah, nah. This is already probably the least secure thing I've ever done
on purpose.</p>
<h2 id="hatch-the-bot">Hatch the bot</h2>
<p>I love a good TUI.</p>
<pre><code class="language-text">◆  How do you want to hatch your bot?
│  ● Hatch in TUI (recommended)
│  ○ Open the Web UI
│  ○ Do this later
</code></pre>
<h1 id="talk-to-the-bot-on-telegram">Talk to the bot on Telegram</h1>
<p>The BotFather sends you a link to your bot account. I clicked it, hit start, and that
sent /start to it. It immediately told me OpenClaw: access not configured. Love it.
I copied its whole message and just dumped it into the TUI for OC to sort it out.</p>
<p>Aand, it's that error again:</p>
<pre><code class="language-text">LLM error: {
"error": {
"code": 404,
"message": "models/gemini-2.5-flash-preview-09-2025 is not found for API version v1beta, or is not supported for generateContent. Call ListModels to see the list of available models and their supported methods.",
"status": "NOT_FOUND"
}
}
</code></pre>
<p>Turns out changing the model doesn't stick unless you restart the gateway.
Entertainingly I asked it to restart the gateway in the TUI. It killed the gateway and
then immediately went unresponsive, not having a gateway to work with.</p>
<p>Restarting it... <code>openclaw gateway</code>: Conveniently that opens it in the foreground, it
looks great in tmux.</p>
<h2 id="set-up-the-tone-and-such">Set up the tone and such</h2>
<p>When the messaging finally works on Telegram it'll ask you for an identity and tone.
It's kind of fun.</p>
<h1 id="shutdown-procedure">Shutdown Procedure</h1>
<p>Don't wanna leave this thing running until it's secured.</p>
<pre><code class="language-bash"># Stop the gateway
openclaw gateway stop

# Verify nothing is still running
ps aux | grep openclaw
pkill -f openclaw-gateway
</code></pre>
<h1 id="whats-next">What's next</h1>
<p>I wanted to set this up with Linear, but honestly I don't love it runing flat on my
Macbook. I'm gonna put it in K8s and producitonize this now that I've got the MVP
figured out.</p>


<p>After building a <a href="/ai-security-toolkit.html">security scanning toolkit</a>, I wanted the
same pattern for linting. Tedious rules that slow developers down are trivial for a
coding agent to stick to, and it'll help provide some baseline quality.</p>
<p>I also don't want the agent to ever make a mess, and knowing they love to git commit
constantly, I'm leaning again on pre-commit hooks to keep things deterministic.</p>
<h1 id="megalinter-is-slow">MegaLinter is SLOW</h1>
<p>I tried <a href="https://megalinter.io/">MegaLinter</a> first. It's a
popular containerized linter that bundles 100+ tools. The full
image is 17GB. The "cupcake" flavor with common languages is
10GB. Even the language-specific flavors are 5GB on disk.</p>
<p>The scan took over five minutes on a monorepo with a few
thousand files. That's not something I want AI agents running
on demand. So I built my own.</p>
<h1 id="introducing-kpericakai-lint-toolkit">Introducing kpericak/ai-lint-toolkit</h1>
<p>Cool thing about agentic coding is you can roll your own anything with basically no
effort. I asked it to make me my own faster one, and to run it then fix up my own
project.</p>
<p>Ended up with an image containing four linters, each the fastest in its category:</p>
<table>
<thead>
<tr>
<th>Language</th>
<th>Tool</th>
<th>Written in</th>
</tr>
</thead>
<tbody>
<tr>
<td>Python</td>
<td><a href="https://docs.astral.sh/ruff/">ruff</a></td>
<td>Rust</td>
</tr>
<tr>
<td>JS / TS</td>
<td><a href="https://biomejs.dev/">biome</a></td>
<td>Rust</td>
</tr>
<tr>
<td>Dockerfile</td>
<td><a href="https://github.com/hadolint/hadolint">hadolint</a></td>
<td>Haskell</td>
</tr>
<tr>
<td>Terraform</td>
<td><a href="https://github.com/terraform-linters/tflint">tflint</a></td>
<td>Go</td>
</tr>
</tbody>
</table>
<p>All four are single compiled binaries. No Python runtime, no
Node.js, no JVM. The final image is <strong>282MB</strong>.</p>
<p>Ruff replaces flake8, pylint, isort, and black in one tool.
Biome replaces eslint and prettier. Both are written in Rust
and finish in under a second on this monorepo.</p>
<h1 id="the-dockerfile">The Dockerfile</h1>
<p>Multi-stage build. Copy hadolint and tflint from their
official images, download ruff and biome as release binaries.</p>
<pre><code class="language-dockerfile">FROM hadolint/hadolint:v2.14.0-alpine AS hadolint
FROM ghcr.io/terraform-linters/tflint:v0.61.0 AS tflint

FROM alpine:3.21

ARG RUFF_VERSION=0.15.5
ARG BIOME_VERSION=2.4.6
ARG TARGETARCH

RUN apk upgrade --no-cache

COPY --from=hadolint /bin/hadolint /usr/local/bin/hadolint
COPY --from=tflint /usr/local/bin/tflint /usr/local/bin/tflint

# ruff: Python linter (Rust binary)
RUN if [ "$TARGETARCH" = "arm64" ]; then \
      RUFF_ARCH="aarch64"; else RUFF_ARCH="x86_64"; fi \
    &#x26;&#x26; wget -qO- \
    "https://github.com/astral-sh/ruff/releases/download/\
${RUFF_VERSION}/ruff-${RUFF_ARCH}-unknown-linux-musl.tar.gz" \
    | tar xz --strip-components=1 -C /usr/local/bin

# biome: JS/TS linter (Rust binary)
RUN if [ "$TARGETARCH" = "arm64" ]; then \
      BIOME_ARCH="linux-arm64-musl"; \
      else BIOME_ARCH="linux-x64-musl"; fi \
    &#x26;&#x26; wget -qO /usr/local/bin/biome \
    "https://github.com/biomejs/biome/releases/download/\
%40biomejs%2Fbiome%40${BIOME_VERSION}/biome-${BIOME_ARCH}" \
    &#x26;&#x26; chmod +x /usr/local/bin/biome

RUN addgroup -S linter &#x26;&#x26; adduser -S linter -G linter
RUN mkdir -p /workspace &#x26;&#x26; chown linter:linter /workspace

WORKDIR /workspace
USER linter
ENTRYPOINT ["/bin/sh"]
</code></pre>
<p>The <code>TARGETARCH</code> arg is set automatically by Docker BuildKit,
so the same Dockerfile works on both amd64 and arm64. A
non-root <code>linter</code> user runs the tools. The image builds in
under 10 seconds because every tool is a precompiled binary.</p>
<p>Source:
<a href="https://github.com/kylep/multi/tree/main/infra/ai-lint-toolkit">GitHub</a></p>
<h1 id="asking-ai-agents-to-lint">Asking AI agents to lint</h1>
<p>Same approach as the
<a href="/ai-security-toolkit.html">security toolkit</a>. A <a href="/ruler-cross-tool-ai-rules.html">Ruler</a>
file provides the commands, then <code>ruler apply</code> injects them into CLAUDE.md and any
other tool config.</p>
<p>Note that this is nondetermistic and such not dependable.</p>
<pre><code class="language-markdown"># Linting

The Docker image `kpericak/ai-lint-toolkit:0.1` bundles
ruff, biome, hadolint, and tflint in one Alpine container.

Run from the repo root. Mount the project directory
as /workspace.

## Python (ruff)
docker run --rm -v "$(pwd):/workspace:ro" \
  kpericak/ai-lint-toolkit:0.1 \
  -c "ruff check /workspace --no-cache"

## JavaScript / TypeScript (biome)
docker run --rm -v "$(pwd):/workspace:ro" \
  kpericak/ai-lint-toolkit:0.1 \
  -c "biome lint /workspace/path/to/src"

## Dockerfiles (hadolint)
docker run --rm -v "$(pwd):/workspace:ro" \
  kpericak/ai-lint-toolkit:0.1 \
  -c "find /workspace -name 'Dockerfile*' \
  -not -path '*/node_modules/*' | xargs hadolint"

## Terraform (tflint)
docker run --rm -v "$(pwd):/workspace:ro" \
  kpericak/ai-lint-toolkit:0.1 \
  -c "cd /workspace/path/to/tf &#x26;&#x26; tflint"
</code></pre>
<p>The volume is mounted read-only. Linters don't need to write
to your source tree. Ruff needs <code>--no-cache</code> to skip writing
a cache directory since the mount is read-only.</p>
<p>For biome, point it at specific source directories rather
than the repo root. Otherwise it crawls <code>node_modules</code> and
takes forever.</p>
<h1 id="running-the-linters">Running the linters</h1>
<p>Here's what each tool found on the first scan of this
monorepo.</p>
<h2 id="ruff">ruff</h2>
<pre><code>46  F401  [*] unused-import
13  F841  [-] unused-variable
11  F541  [*] f-string-missing-placeholders
 1  F821  [ ] undefined-name
Found 71 errors.
[*] 59 fixable with the `--fix` option.
</code></pre>
<p>71 findings across all the Python in the monorepo. Most are
in older projects (kytrade, mods) that haven't been touched
in a while. The <code>[*]</code> markers mean ruff can auto-fix them.
Unused imports and f-string placeholders are the bulk of it.</p>
<p>Ruff scanned the entire repo in 0.5 seconds.</p>
<h2 id="biome">biome</h2>
<pre><code>7 lint/suspicious/noDoubleEquals
6 lint/style/noNonNullAssertion
4 lint/style/useConst
1 lint/correctness/useParseIntRadix
1 lint/correctness/noUnusedImports
</code></pre>
<p>19 findings. The double-equals warnings are in the blog's
route handler (<code>==</code> instead of <code>===</code>). The non-null
assertions are in test files for a game project. All fixable.</p>
<p>Biome scanned the JS/TS source in 0.7 seconds.</p>
<h2 id="hadolint">hadolint</h2>
<p>Hadolint found 14 findings across 5 Dockerfiles. The
interesting ones:</p>
<ul>
<li><strong>DL3020</strong>: Use COPY instead of ADD (2 errors in kytrade)</li>
<li><strong>DL3018</strong>: Pin versions in <code>apk add</code></li>
<li><strong>DL3013</strong>: Pin versions in <code>pip install</code></li>
<li><strong>DL4006</strong>: Set <code>SHELL</code> with <code>-o pipefail</code> before piped RUN</li>
</ul>
<p>The security toolkit's own Dockerfile got flagged for the
pipefail issue in its <code>wget | tar</code> pipe. Fair catch.</p>
<h2 id="tflint">tflint</h2>
<pre><code>Warning: terraform "required_version" attribute is required
Warning: Missing version constraint for provider "google"
Warning: [Fixable] data "aws_caller_identity" "current"
  is declared but not used
</code></pre>
<p>4 warnings across 2 Terraform directories. Missing version
constraints and an unused data source. Standard Terraform
hygiene stuff.</p>
<h1 id="size-comparison">Size comparison</h1>
<table>
<thead>
<tr>
<th>Image</th>
<th>Size on disk</th>
<th>Run time</th>
</tr>
</thead>
<tbody>
<tr>
<td>MegaLinter (full)</td>
<td>17 GB</td>
<td>5+ min</td>
</tr>
<tr>
<td>MegaLinter (cupcake)</td>
<td>10 GB</td>
<td>untested</td>
</tr>
<tr>
<td>MegaLinter (javascript)</td>
<td>5 GB</td>
<td>untested</td>
</tr>
<tr>
<td>ai-lint-toolkit</td>
<td>282 MB</td>
<td>&#x3C; 5 sec</td>
</tr>
</tbody>
</table>
<p>The custom image is 60x smaller than MegaLinter's full image
and runs in seconds. The tradeoff is that it only covers four
languages. But those are the four I need, and adding more is
one <code>wget</code> or <code>COPY</code> away.</p>
<h1 id="pre-commit-hooks-as-lazy-ci">Pre-commit hooks as lazy CI</h1>
<p>I already had semgrep and gitleaks running as pre-commit
hooks from the
<a href="/ai-security-toolkit.html">security toolkit</a>. Adding
ruff and biome follows the same pattern.</p>
<pre><code class="language-yaml">repos:
- repo: local
  hooks:
    - id: ruff
      name: Ruff
      entry: >-
        bash -c 'docker run
        -v "$(pwd):/workspace:ro" --rm
        kpericak/ai-lint-toolkit:0.1
        -c "ruff check /workspace --no-cache"'
      language: system
      stages: ["pre-commit"]
    - id: biome
      name: Biome
      entry: >-
        bash -c 'docker run
        -v "$(pwd):/workspace:ro" --rm
        kpericak/ai-lint-toolkit:0.1
        -c "biome lint /workspace/apps/blog/blog/pages
        /workspace/apps/blog/blog/components
        /workspace/apps/blog/blog/utils"'
      language: system
      stages: ["pre-commit"]
    - id: semgrep
      name: Semgrep
      entry: >-
        bash -c 'docker run
        -v "$(pwd):/workspace:ro" --rm
        kpericak/ai-security-toolkit-1:0.2
        -c "semgrep scan --config auto
        --error /workspace"'
      language: system
      stages: ["pre-commit", "pre-push"]
    - id: gitleaks
      name: Gitleaks
      entry: >-
        bash -c 'docker run
        -v "$(pwd):/workspace:ro" --rm
        kpericak/ai-security-toolkit-1:0.2
        -c "cd /workspace &#x26;&#x26; gitleaks detect
        --source ."'
      language: system
      stages: ["pre-commit", "pre-push"]
</code></pre>
<p>Every commit now gets linted for Python and JS/TS issues,
scanned for security bugs by semgrep, and checked for
leaked secrets by gitleaks. Four tools, two Docker images,
no CI server required.</p>
<p>Hadolint and tflint aren't in the hooks. Dockerfiles and
Terraform configs change rarely enough that running them
on demand through the AI agent is fine.</p>


<p>AI coding agents can write code, review PRs, and run tests. They
can't run security scans unless you give them the tools. I built a
Docker image that bundles three scanners into one container, then
wired it into my repo so any AI tool can use them.</p>
<h1 id="whats-in-the-image">What's in the image</h1>
<p>The image <code>kpericak/ai-security-toolkit-1</code> has 3 tools:</p>
<table>
<thead>
<tr>
<th>Category</th>
<th>Tool</th>
</tr>
</thead>
<tbody>
<tr>
<td>SAST (static analysis)</td>
<td><a href="https://semgrep.dev/">semgrep</a></td>
</tr>
<tr>
<td>SCA (dependency vulns)</td>
<td><a href="https://trivy.dev/">trivy</a></td>
</tr>
<tr>
<td>Secrets (files on disk)</td>
<td><a href="https://trivy.dev/">trivy</a></td>
</tr>
<tr>
<td>Secrets (git history)</td>
<td><a href="https://gitleaks.io/">gitleaks</a></td>
</tr>
<tr>
<td>Misconfig (Dockerfile, Terraform)</td>
<td><a href="https://trivy.dev/">trivy</a></td>
</tr>
<tr>
<td>Container image scanning</td>
<td><a href="https://trivy.dev/">trivy</a></td>
</tr>
</tbody>
</table>
<h1 id="the-dockerfile">The Dockerfile</h1>
<p>Multi-stage build. Copy the Go binaries from the official images,
install semgrep via pip on Alpine.</p>
<pre><code class="language-dockerfile">FROM aquasec/trivy:0.69.3 AS trivy
FROM zricethezav/gitleaks:v8.30.0 AS gitleaks

FROM python:3.12.13-alpine

RUN apk upgrade --no-cache &#x26;&#x26; apk add --no-cache nodejs git gcc musl-dev

COPY --from=trivy /usr/local/bin/trivy /usr/local/bin/trivy
COPY --from=gitleaks /usr/bin/gitleaks /usr/local/bin/gitleaks

RUN pip install --no-cache-dir semgrep

COPY .trivyignore /workspace/.trivyignore

RUN addgroup -S scanner &#x26;&#x26; adduser -S scanner -G scanner
RUN mkdir -p /workspace &#x26;&#x26; chown scanner:scanner /workspace

WORKDIR /workspace
USER scanner
ENTRYPOINT ["/bin/sh"]
</code></pre>
<p>Trivy and gitleaks are single Go binaries, so the COPY stages are all they need.
Semgrep needs Python and a C compiler for its native
extensions, which is why <code>gcc</code> and <code>musl-dev</code> are there. The base
images are pinned to specific versions for reproducible builds. A
non-root <code>scanner</code> user runs the tools so the container doesn't
operate as root. The image ends up around 800MB. Not small, but
it's a tooling image, not a production service.</p>
<p>Source:
<a href="https://github.com/kylep/multi/tree/main/infra/ai-security-toolkit-1">GitHub</a></p>
<h1 id="teaching-ai-agents-to-scan">Teaching AI agents to scan</h1>
<p>The scans are just shell commands. The objective is getting robot to run them.
I use <a href="/ruler-cross-tool-ai-rules.html">Ruler</a> to maintain a single
<code>.ruler/security.md</code> file that gets injected into CLAUDE.md,
AGENTS.md, and any other tool-specific config.</p>
<p>Here's the ruler file:</p>
<pre><code class="language-markdown"># Security Scanning

The Docker image `kpericak/ai-security-toolkit-1:0.2` bundles
semgrep, trivy, and gitleaks in one Alpine container.

Run from the repo root. Mount the project directory as /workspace.

## Static analysis (semgrep)
docker run --rm -v "$(pwd):/workspace:ro" \
  kpericak/ai-security-toolkit-1:0.2 \
  -c "semgrep scan --config auto /workspace"

## Vulnerability scanning (trivy)
docker run --rm -v "$(pwd):/workspace:ro" \
  kpericak/ai-security-toolkit-1:0.2 \
  -c "trivy fs --scanners vuln,secret,misconfig /workspace"

## Container image scanning (trivy)
docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  kpericak/ai-security-toolkit-1:0.2 \
  -c "trivy image &#x3C;image:tag>"

## Secret scanning (gitleaks)
docker run --rm -v "$(pwd):/workspace:ro" \
  kpericak/ai-security-toolkit-1:0.2 \
  -c "cd /workspace &#x26;&#x26; gitleaks detect --source ."
</code></pre>
<p>After running <code>ruler apply</code>, every AI tool in the repo knows how to
run security scans. I can tell Claude Code "scan this repo for
vulnerabilities" and it has the commands ready.</p>
<h1 id="pre-commit-hooks">Pre-commit hooks</h1>
<p>Both semgrep and gitleaks run as
<a href="https://pre-commit.com/">pre-commit</a> hooks. Every commit gets
a static analysis scan and a secret scan before it lands.</p>
<h2 id="installing-pre-commit">Installing pre-commit</h2>
<p>You need <a href="https://pre-commit.com/">pre-commit</a> installed, plus
Docker for the scanner container.</p>
<pre><code class="language-bash"># macOS
brew install pre-commit

# Linux (pip)
pip install pre-commit

# Then activate hooks in the repo
cd your-repo
pre-commit install
</code></pre>
<p>That wires <code>.pre-commit-config.yaml</code> into <code>.git/hooks/pre-commit</code>
so the hooks run automatically on every commit.</p>
<h2 id="the-hook-config">The hook config</h2>
<pre><code class="language-yaml">- id: semgrep
  name: Semgrep
  description: Static analysis scan using the security toolkit image.
  entry: bash -c 'docker run -v "$(pwd):/workspace:ro" --rm
    kpericak/ai-security-toolkit-1:0.2
    -c "semgrep scan --config auto --error /workspace"'
  language: system
  stages: ["pre-commit", "pre-push"]
- id: gitleaks
  name: Gitleaks
  description: Scan for leaked secrets using the security toolkit image.
  entry: bash -c 'docker run -v "$(pwd):/workspace:ro" --rm
    kpericak/ai-security-toolkit-1:0.2
    -c "cd /workspace &#x26;&#x26; gitleaks detect --source ."'
  language: system
  stages: ["pre-commit", "pre-push"]
</code></pre>
<p>The <code>--error</code> flag on semgrep makes it exit non-zero on findings,
which blocks the commit. Gitleaks catches patterns like API keys,
tokens, and credentials.</p>
<h1 id="running-the-scans">Running the scans</h1>
<p>Here's what each scanner produces when pointed at this monorepo.</p>
<h2 id="semgrep">semgrep</h2>
<p>The first scan found 43 findings. Most were false positives:
<code>dangerouslySetInnerHTML</code> in the blog's SSG rendering (the HTML
comes from my own markdown), <code>path.join</code> with internal filenames,
K8s manifests in old sample projects, and vendored Prism.js.</p>
<p>Two changes got it to zero:</p>
<ol>
<li>A <code>.semgrepignore</code> file to skip directories that aren't active
code: <code>samples/</code>, old infra, vendored JS, and a legacy project.</li>
<li>Inline <code>// nosemgrep</code> comments on the few remaining lines where
the finding is a known false positive, like the SSG innerHTML.</li>
</ol>
<pre><code>┌──────────────┐
│ Scan Summary │
└──────────────┘
Ran 717 rules on 485 files: 0 findings.
</code></pre>
<p>Zero findings means semgrep can run as a pre-commit hook with
<code>--error</code> and block on any new issue. No triage fatigue.</p>
<h2 id="trivy">trivy</h2>
<p>Trivy's default scanners are <code>vuln</code> and <code>secret</code>. It also has
<code>misconfig</code> and <code>license</code> scanners. Adding <code>--scanners vuln,secret,misconfig</code> enables Dockerfile and Terraform
misconfiguration checks on top of the dependency and secret
scanning.</p>
<p>The first scan found 7 npm vulnerabilities. 3 HIGH in Next.js
14 (DoS in server components), plus medium/low hits in
dompurify, lodash-es, and diff. I bumped Next.js from 14 to 15
and ran <code>npm audit fix</code> for the transitive deps. The upgrade
required no code changes. Pages Router, <code>output: 'export'</code>, and
React 18 all still work on Next.js 15.</p>
<p>With misconfig enabled, trivy also flagged Dockerfile issues:
no non-root USER, <code>cd</code> instead of <code>WORKDIR</code>, missing
HEALTHCHECK. The kind of things you'd catch in a code review
but might miss if nobody's looking.</p>
<pre><code>Report Summary
┌────────────────────────────────────────┬────────────┬───────┬─────────┬───────────────────┐
│                 Target                 │    Type    │ Vulns │ Secrets │ Misconfigurations │
├────────────────────────────────────────┼────────────┼───────┼─────────┼───────────────────┤
│ apps/blog/blog/package-lock.json       │    npm     │   0   │    -    │         -         │
├────────────────────────────────────────┼────────────┼───────┼─────────┼───────────────────┤
│ apps/blog/Dockerfile                   │ dockerfile │   -   │    -    │         3         │
├────────────────────────────────────────┼────────────┼───────┼─────────┼───────────────────┤
│ apps/blog/tf                           │ terraform  │   -   │    -    │         0         │
├────────────────────────────────────────┼────────────┼───────┼─────────┼───────────────────┤
│ infra/ai-security-toolkit-1/Dockerfile │ dockerfile │   -   │    -    │         1         │
└────────────────────────────────────────┴────────────┴───────┴─────────┴───────────────────┘
</code></pre>
<p>Zero dependency vulns. The Dockerfile misconfigs are real
findings to fix next. The policy going forward: keep SCA vulns
at 0 in active projects. Major package upgrades are acceptable
to get there. Playwright tests catch regressions from the
upgrades.</p>
<h2 id="trivy-image">trivy image</h2>
<p><code>trivy fs</code> scans source code and lock files. <code>trivy image</code>
scans a built Docker image, catching OS-level CVEs in the base
image and vulnerabilities in installed packages that don't show
up in any lock file.</p>
<p>Running it against the first version of the toolkit image found
25 vulnerabilities that <code>trivy fs</code> never saw: Alpine OS
packages, Python dependencies, and Go stdlib CVEs baked into
the trivy and gitleaks binaries.</p>
<p>Fixes for v0.2:</p>
<ol>
<li>Pinned <code>python:3.12.13-alpine</code> and added <code>apk upgrade</code> to
get the latest Alpine packages. Fixed the CRITICAL zlib CVE.</li>
<li>The Go stdlib CVEs live inside the gitleaks binary, compiled
with Go 1.25.4. No newer gitleaks release exists. Added a
<code>.trivyignore</code> with comments explaining each suppression.</li>
</ol>
<p>The policy: no HIGH or CRITICAL findings. MEDIUM and below from
upstream binaries we don't compile are accepted and documented.</p>
<h2 id="gitleaks">gitleaks</h2>
<pre><code>144 commits scanned.
no leaks found.
</code></pre>
<p>Clean. Gitleaks scans git history by default, so it catches
secrets that were committed and later deleted. Trivy also has
a secret scanner, but it only checks files on disk. If someone
committed an API key and removed it in the next commit, trivy
wouldn't see it. Gitleaks would, because the key is still in
the git log.</p>
<p>That's why both are in the image. Trivy covers dependency vulns
and current-file secrets. Gitleaks covers the git history angle.
I originally had <code>npm audit</code> in the image too, but dropped it
since trivy already scans <code>package-lock.json</code> for the same CVEs.</p>
<h1 id="the-workflow">The workflow</h1>
<p>With all this wired up, security scanning happens at three levels:</p>
<ol>
<li><strong>Every commit</strong>: semgrep and gitleaks run as pre-commit hooks.
Any new static analysis finding or leaked secret blocks the
commit.</li>
<li><strong>Scheduled</strong>: a security agent runs <code>trivy image</code> against
built container images on a schedule, triages the results,
and files issues in
<a href="/linear-mcp.html">Linear</a> for anything that needs attention.
Image scanning is too slow for pre-commit hooks but catches
OS-level CVEs that filesystem scans miss.</li>
<li><strong>On demand</strong>: I tell the AI agent "run security scans" or
include it in task instructions. The agent runs the docker
commands from its CLAUDE.md context and triages the output.</li>
</ol>
<p>The AI agent is good at triaging scan results. It can reason about
which dependency vulnerabilities actually matter for a static
export vs a running server. That's the real value of combining
scanners with AI agents: the agent reads the output instead of
just dumping a report.</p>


<p>Linear's official MCP server launched in May 2025. It lets the robots lean in on the
project management work. I want to get some ideation-bots going.</p>
<h2 id="supported-commands">Supported Commands</h2>
<table>
<thead>
<tr>
<th>Category</th>
<th>Commands</th>
</tr>
</thead>
<tbody>
<tr>
<td>Issues</td>
<td>list, get, create/update, status, statuses</td>
</tr>
<tr>
<td>Projects</td>
<td>list, get, create/update, labels</td>
</tr>
<tr>
<td>Documents</td>
<td>list, get, create, update, search</td>
</tr>
<tr>
<td>Comments</td>
<td>list, create/update, delete</td>
</tr>
<tr>
<td>Attachments</td>
<td>get, create, delete, extract images</td>
</tr>
<tr>
<td>Milestones</td>
<td>list, get, create/update</td>
</tr>
<tr>
<td>Cycles</td>
<td>list</td>
</tr>
<tr>
<td>Teams</td>
<td>list, get</td>
</tr>
<tr>
<td>Users</td>
<td>list, get</td>
</tr>
<tr>
<td>Labels</td>
<td>list issue labels, create issue label</td>
</tr>
</tbody>
</table>
<h2 id="setup">Setup</h2>
<p>Linear hosts the MCP server at <code>https://mcp.linear.app/mcp</code>. Use that endpoint, not the
old SSE one which is deprecated.</p>
<h3 id="claude-code">Claude Code</h3>
<pre><code class="language-bash">claude mcp add --transport http linear-server https://mcp.linear.app/mcp
</code></pre>
<p>Restart and authenticate via OAuth.</p>
<hr>
<h1 id="idea-nightly-ideation-engine">Idea: Nightly Ideation Engine</h1>
<p>Instead of using Linear as a human-operated task tracker, an AI agent can read youri
codebase, compare it against goals, and file suggestions directly.</p>
<p>What I'm hoping to build is a system where a scheduled agent runs nightly. It reads
blog posts, checks page speed, reviews SEO metadata, and compares everything against a
set of high-level goals:</p>
<ul>
<li>100% accurate content</li>
<li>Fast loading</li>
<li>Low cost</li>
<li>Looks good</li>
<li>Good SEO</li>
<li>Interesting tutorials about emerging tooling</li>
</ul>
<p>It should create Linear issues for anything worth improving, labeled "Suggestion" and
drop them into the Backlog.</p>
<h3 id="the-pipeline">The pipeline</h3>
<p>Linear's built-in statuses act as gates between human and agent
work.</p>
<pre class="mermaid">
stateDiagram-v2
    [*] --> Backlog: AI files suggestion
    Backlog --> Todo: Human promotes
    Backlog --> Canceled: Human rejects
    Todo --> InProgress: Agent picks up
    InProgress --> InReview: Agent finishes
    InReview --> Done: Human approves
    InReview --> InProgress: Human pushes back
</pre>
<p>Each step has a clear owner:</p>
<table>
<thead>
<tr>
<th>Status</th>
<th>Owner</th>
<th>What happens</th>
</tr>
</thead>
<tbody>
<tr>
<td>Backlog</td>
<td>AI</td>
<td>Nightly agent creates suggestion issues</td>
</tr>
<tr>
<td>Todo</td>
<td>Human</td>
<td>You move the good ones forward</td>
</tr>
<tr>
<td>In Progress</td>
<td>Agent</td>
<td>A working agent picks it up</td>
</tr>
<tr>
<td>In Review</td>
<td>Agent</td>
<td>Agent finishes, leaves a comment</td>
</tr>
<tr>
<td>Done</td>
<td>Human</td>
<td>You verify and close</td>
</tr>
<tr>
<td>Canceled</td>
<td>Human</td>
<td>Bad idea, toss it</td>
</tr>
</tbody>
</table>
<h3 id="agent-notes-via-comments">Agent notes via comments</h3>
<p>When agents work on an issue, they leave comments. This beats
internal context files because comments are visible, searchable,
and survive across sessions. If one agent starts a task and another
finishes it, the full history is right there on the issue.</p>
<p>I might also run multiple planning agents that each comment on a
ticket before I review it. A fact-checker, a SEO reviewer, and a
style auditor could all weigh in on the same Backlog issue. By the
time I look at it, there's already a thread of perspectives.</p>
<pre><code class="language-bash"># An agent checking for work:
# list_issues with label="Suggestion", state="Todo"

# An agent leaving notes:
# save_comment with issueId and markdown body
</code></pre>
<h3 id="filtering">Filtering</h3>
<p>The nightly agent queries existing Backlog suggestions before
creating new ones, avoiding duplicates. Working agents filter
by label and status to find their next task:</p>
<pre><code>list_issues → label: "Suggestion", state: "Todo"
</code></pre>
<h2 id="defining-state-as-prompts">Defining State as Prompts</h2>
<p>Linear's community Terraform provider exists but only covers teams,
labels, workflow states, and templates. No custom views. The GraphQL
API has a <code>customViewCreate</code> mutation, but nobody's wrapped it in
IaC tooling yet.</p>
<p>So instead of declaring views in HCL, I described mine as a prompt
and had Claude set it up via Playwright MCP:</p>
<blockquote>
<p>Create a custom view called "Suggestion Backlog" on the Pericak
team. Filter to issues where label includes "Suggestion" and
status is "Backlog". Description: "AI-generated improvement
suggestions awaiting human review".</p>
</blockquote>
<p>Claude navigated to Linear in Chromium, clicked "Add new view",
filled in the name, added both filters, and hit Save. The view
now lives as a tab on the team page.</p>
<p>This is nondeterministic state management. There's no lock file,
no plan/apply, no drift detection. But it works, and the prompt
is the documentation. If the view ever gets deleted, re-run the
prompt.</p>
<h3 id="a-linear-admin-agent">A Linear-Admin agent</h3>
<p>A "Linear-Admin" agent could own all workspace
configuration: views, labels, workflow states, notification
settings. You'd feed it a doc describing your desired workspace
setup, and it would use Playwright to converge Linear's UI to
match. Like Terraform, but with a browser instead of an API.</p>
<p>The tradeoffs are real. Playwright clicks are slow, brittle if
Linear redesigns their UI, and hard to make idempotent. But for
a personal workspace where the alternative is "click around in
the UI manually," the prompt-as-IaC approach is surprisingly
practical.</p>
<p>Still faster than a person.</p>


<p>Two things in this post. First, wiring up GA4 on this blog, which turns out to
be pretty straightforward on Next.js. Second, connecting the official GA4 MCP
server so Claude Code can query the analytics data directly in natural language.</p>
<p>Once the MCP is connected, you can ask
Claude things like "which posts got the most traffic last month" or "what are
my top referral sources" and it queries GA4 and tells you. No dashboard required.</p>
<h1 id="setting-up-ga4">Setting Up GA4</h1>
<h2 id="create-the-property">Create the Property</h2>
<p>Go to <a href="https://analytics.google.com">analytics.google.com</a>. Hit Create →
Property, fill in a name and your timezone, click through the business details
screens (mostly irrelevant for a personal blog), then choose Web as the
platform and enter your domain. GA4 creates the property and a web data stream
in one flow.</p>
<p>Once the stream is created, click it to open the stream details. The
measurement ID is right there. It looks like <code>G-XXXXXXXXXX</code>.</p>
<h2 id="add-tracking-to-nextjs">Add Tracking to Next.js</h2>
<p>This blog is statically exported Next.js. The right place to add the tracking
script is <code>_app.js</code>, using <code>next/script</code> with <code>afterInteractive</code> so it doesn't
block rendering:</p>
<pre><code class="language-jsx">// pages/_app.js
import Script from 'next/script';

export default function MyApp({ Component, pageProps }) {
  return (
    &#x3C;>
      &#x3C;Script
        src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"
        strategy="afterInteractive"
      />
      &#x3C;Script id="google-analytics" strategy="afterInteractive">
        {`
          window.dataLayer = window.dataLayer || [];
          function gtag(){dataLayer.push(arguments);}
          gtag('js', new Date());
          gtag('config', 'G-XXXXXXXXXX');
        `}
      &#x3C;/Script>
      {/* rest of your app */}
    &#x3C;/>
  );
}
</code></pre>
<p>Replace <code>G-XXXXXXXXXX</code> with your actual measurement ID. Deploy, open the GA4
realtime report, and visit your site to confirm hits are coming in. Takes a
couple minutes to show up.</p>
<p>Note: if you're serving via a CDN with aggressive caching (this blog uses GCS),
make sure the HTML is being revalidated, not served stale. The script tag needs
to actually make it into the page.</p>
<h1 id="the-ga4-mcp-server">The GA4 MCP Server</h1>
<p>Google ships an <a href="https://github.com/googleanalytics/google-analytics-mcp">official MCP server</a>
for GA4. It's read-only, which is fine for querying data. It wraps the GA4
Admin API and Data API and exposes a handful of tools Claude can call.</p>
<h2 id="auth-setup">Auth Setup</h2>
<p>The server uses Google Application Default Credentials. Before you can log in,
you need to enable two APIs in your GCP project. Check which project your
gcloud CLI is using:</p>
<pre><code class="language-bash">gcloud config get-value project
</code></pre>
<p>Then enable the APIs:</p>
<pre><code class="language-bash"># Required for get_account_summaries, get_property_details
gcloud services enable analyticsadmin.googleapis.com

# Required for run_report, run_realtime_report
gcloud services enable analyticsdata.googleapis.com
</code></pre>
<p>Then log in:</p>
<pre><code class="language-bash">gcloud auth application-default login \
  --scopes=https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform
</code></pre>
<p>The <code>cloud-platform</code> scope is required alongside <code>analytics.readonly</code>. Without
it you get a deprecation error and the auth fails.</p>
<p>That stores credentials at
<code>~/.config/gcloud/application_default_credentials.json</code>. No service account
file needed.</p>
<p>If you'd rather use a service account (better for shared environments), create
one in Google Cloud Console, grant it Viewer access on your GA4 property, and
download the JSON key. Set <code>GOOGLE_APPLICATION_CREDENTIALS</code> to point at it.</p>
<h2 id="add-to-claude-code">Add to Claude Code</h2>
<p>Add it to <code>.mcp.json</code> at the project root to share it with the team:</p>
<pre><code class="language-json">{
  "mcpServers": {
    "analytics-mcp": {
      "command": "pipx",
      "args": ["run", "analytics-mcp"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/Users/you/.config/gcloud/application_default_credentials.json"
      }
    }
  }
}
</code></pre>
<p>Or add it for yourself only:</p>
<pre><code class="language-bash">claude mcp add analytics-mcp --env GOOGLE_APPLICATION_CREDENTIALS=~/.config/gcloud/application_default_credentials.json -- pipx run analytics-mcp
</code></pre>
<p>Restart Claude Code and run <code>/mcp</code> to confirm <code>analytics-mcp</code> is listed.</p>
<h2 id="what-it-exposes">What It Exposes</h2>
<p>Five tools:</p>
<ul>
<li><code>get_account_summaries</code>: lists your GA4 accounts and properties. Good first
call to confirm auth is working and grab your property ID.</li>
<li><code>get_property_details</code>: details for a specific property.</li>
<li><code>run_report</code>: the main one. Queries the GA4 Data API with dimensions and
metrics of your choice.</li>
<li><code>run_realtime_report</code>: same thing but against the realtime endpoint.</li>
<li><code>get_custom_dimensions_and_metrics</code>: lists any custom dimensions you've
defined on the property.</li>
</ul>
<p>The server is read-only. It can't modify your GA4 configuration.</p>
<h1 id="querying-data">Querying Data</h1>
<p>Once connected, you can ask in plain English. Claude figures out which dimensions and
metrics to use and calls <code>run_report</code> for you.</p>
<p>Some things I've asked it:</p>
<p><strong>Traffic overview:</strong></p>
<blockquote>
<p>What were my total users and sessions last week, broken down by day?</p>
</blockquote>
<p><strong>Top content:</strong></p>
<blockquote>
<p>Which pages got the most views in the last 30 days?</p>
</blockquote>
<p><strong>Referrals:</strong></p>
<blockquote>
<p>What are my top traffic sources this month?</p>
</blockquote>
<p><strong>Realtime:</strong></p>
<blockquote>
<p>How many people are on the site right now and what pages are they on?</p>
</blockquote>
<p>For anything beyond basic questions, it helps to know a few GA4 concepts.
"Sessions" and "users" mean what you'd expect. "Engaged sessions" are ones
where the user spent more than 10 seconds, viewed more than one page, or
triggered a conversion. The distinction matters when you're trying to tell real
readers from bots.</p>
<p>Claude will sometimes ask for your property ID before running a report. Either
give it the <code>G-XXXXXXXXXX</code> measurement ID or the numeric property ID from the
GA4 UI. If you add the property ID to your <code>CLAUDE.md</code> or project context,
it'll stop asking.</p>
<h1 id="what-its-actually-good-for">What It's Actually Good For</h1>
<p>The dashboard is fine for browsing. The MCP is better for specific questions,
comparing time periods, and anything you'd normally have to build a custom
report for.</p>
<p>The bigger thing I have in mind though is eventually having like OpenClaw or similar
using it in an ideation loop. Some sort of PM agent that adds potential tickets to a
Jira or Linear board and uses this data as an input.</p>
<p>I'm also just starting to love being back in tmux and not having to operate websites
as much.</p>
<p>Lastly I figure I can hook this up to voice commands somehow for a really custom voice
assistant.</p>


<p>Playwright MCP gives Claude Code a real browser to drive. Coding agents are kind of
awful at doing the right thing unless they can verify their work. If you want to do any
front-end work and not be the human in the loop every step along the way, it's gotta be
able to operate Chromium and review the photos. Opus 4.6 is multi modal and any later
models will just be better, so it can consume the photos itself.</p>
<h1 id="setup">Setup</h1>
<pre><code class="language-bash">claude mcp add playwright -- npx @playwright/mcp@latest --browser chromium
</code></pre>
<p>Or add it to <code>.mcp.json</code> at the project root to share it with the team:</p>
<pre><code class="language-json">{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--browser", "chromium"]
    }
  }
}
</code></pre>
<p>Restart Claude Code. Run <code>/mcp</code> to confirm it's listed. If you've got a session
already, tell it to store its memory first and to load it back after, works well.</p>
<h1 id="what-playwright-does">What Playwright Does</h1>
<p>At work we migrated from Selenium/WebDriver to this to address flakiness long before
the MCP was out, but at this point my interest in playwright is more about the AI
integration.</p>
<p>Playwright MCP exposes the browser as individual tools Claude can call. This post demos
the main ones, with examples against my dev blog server at <code>http://localhost:3000</code>.</p>
<p>I'm pretty sure I'll be able to post agents at this post even to tell it how I want
them to work, and ask them to write a claude.md about it.</p>
<h2 id="browser_navigate">browser_navigate</h2>
<pre><code>browser_navigate: { url: "http://localhost:3000" }
</code></pre>
<p>Loads a URL. Returns the final URL (catches redirects) and a console
error/warning count alongside the snapshot.</p>
<h2 id="browser_snapshot">browser_snapshot</h2>
<pre><code>browser_snapshot: {}
</code></pre>
<p>Returns an accessibility tree of the current page. This is the main tool for
reading page state: what's visible, what's interactive, what the structure is.
Faster and more structured than HTML, and the <code>ref</code> values it returns are what
<code>browser_click</code> and <code>browser_type</code> use to target elements.</p>
<h2 id="browser_take_screenshot">browser_take_screenshot</h2>
<pre><code>browser_take_screenshot: {}
</code></pre>
<p>Returns a PNG of the current viewport. This is the tool Claude uses to judge
look and feel. It's multimodal, so it actually reads the image and can catch
layout problems, broken images, or rendering bugs that don't show up in the
accessibility tree. It can't extract <code>ref</code> values from a screenshot though, so
use <code>browser_snapshot</code> when you need to drive further actions.</p>
<h2 id="browser_click">browser_click</h2>
<pre><code>browser_click: { element: "Posts", ref: "..." }
</code></pre>
<p>Clicks by visible label or element reference. Drives navigation and interactive
components.</p>
<h2 id="browser_type">browser_type</h2>
<pre><code>browser_type: { element: "search input", ref: "...", text: "Playwright" }
</code></pre>
<p>Types into an input. The <code>ref</code> comes from <code>browser_snapshot</code>.</p>
<h2 id="browser_evaluate">browser_evaluate</h2>
<pre><code>browser_evaluate: { function: "() => document.title" }
</code></pre>
<p>Runs JavaScript in the page context. For reading state that isn't in the DOM.</p>
<h2 id="browser_wait_for">browser_wait_for</h2>
<pre><code>browser_wait_for: { text: "Playwright MCP" }
browser_wait_for: { textGone: "Loading..." }
browser_wait_for: { time: 2 }
</code></pre>
<p>Three modes: wait for text to appear, wait for text to disappear, or sleep for
N seconds. No explicit timeout parameter. It uses Playwright's default (30s).
Needed for anything that renders async.</p>
<h2 id="browser_console_messages">browser_console_messages</h2>
<pre><code>browser_console_messages: {}
browser_console_messages: { level: "error" }
</code></pre>
<p>Returns the full console output: message text, level, and source location.
The <code>level</code> filter works like log levels: <code>error</code> gives you errors only, <code>info</code>
gives you everything. The navigate and snapshot tools show a count
(<code>1 errors, 0 warnings</code>), but this is where you get the actual content.</p>
<p>Claude can read and interpret it. Errors include full stack traces and, for
things like React hydration mismatches, the actual HTML diff showing which
component diverged between server and client. Ask Claude to look at the console
and it'll summarize the errors and suggest fixes rather than dumping the raw
text at you.</p>
<p>First thing to check when something looks wrong but the DOM appears fine.</p>
<p>Also worth having in every test suite: a test that loads each key page and
asserts no console errors. It catches a lot of regressions for free.</p>
<pre><code class="language-typescript">test('no console errors on homepage', async ({ page }) => {
  const errors: string[] = [];
  page.on('console', msg => {
    if (msg.type() === 'error') errors.push(msg.text());
  });
  await page.goto('/');
  expect(errors).toHaveLength(0);
});
</code></pre>
<h2 id="browser_network_requests">browser_network_requests</h2>
<pre><code>browser_network_requests: {}
browser_network_requests: { includeStatic: true }
</code></pre>
<p>The network log since the last navigation. Returns method, URL, and status code
for each request. Good for catching 404s on assets or confirming a request
fired. Excludes static resources by default. Pass <code>includeStatic: true</code> to see
everything.</p>
<p>No timing data. If you need to assert on response duration, use Playwright's
<code>page.on('response', ...)</code> in a test instead:</p>
<pre><code class="language-typescript">test('API calls complete within 500ms', async ({ page }) => {
  const timings: number[] = [];
  page.on('response', async response => {
    if (response.url().includes('/api/')) {
      const timing = response.timing();
      timings.push(timing.responseEnd - timing.requestStart);
    }
  });
  await page.goto('/');
  expect(Math.max(...timings)).toBeLessThan(500);
});
</code></pre>
<p><code>page.on('response', ...)</code> fires for every network response. Filter by URL
pattern to target whatever you care about: API calls, a specific domain,
a file type. Same pattern works for asserting no 404s:</p>
<pre><code class="language-typescript">test('no broken asset requests', async ({ page }) => {
  const failures: string[] = [];
  page.on('response', response => {
    if (response.status() >= 400) failures.push(`${response.status()} ${response.url()}`);
  });
  await page.goto('/');
  expect(failures).toHaveLength(0);
});
</code></pre>
<h2 id="browser_resize">browser_resize</h2>
<pre><code>browser_resize: { width: 375, height: 812 }
</code></pre>
<p>Resizes the viewport. Triggers CSS media queries based on width, so layout
reflows and responsive breakpoints work as expected. Good for a quick visual
check. Pair it with <code>browser_take_screenshot</code> to see what changed.</p>
<p>It doesn't change the user agent, device pixel ratio, or pointer type. That
means UA-sniffing code still thinks it's a desktop browser, <code>srcset</code> serves
desktop-resolution images, and <code>hover: none</code> / <code>pointer: coarse</code> media queries
don't fire. For proper mobile regression coverage, use Playwright's device
emulation in the test config instead:</p>
<pre><code class="language-typescript">import { devices } from '@playwright/test';

// playwright.config.ts
export default defineConfig({
  projects: [
    { name: 'desktop', use: { viewport: { width: 1280, height: 720 } } },
    { name: 'mobile',  use: { ...devices['iPhone 13'] } },
  ],
});
</code></pre>
<p><code>devices['iPhone 13']</code> sets viewport, user agent, device scale factor, and
touch support together. Your tests run against both profiles automatically.</p>
<hr>
<h1 id="gherkin-specs-as-source-of-truth">Gherkin Specs as Source of Truth</h1>
<p>AI-generated test code has a maintenance problem. The agent writes tests, they
drift from what the UI actually does, someone edits them directly, and now you
have no reliable source of truth.</p>
<p>What I'm experimenting with here is to keep specs in Gherkin, generate tests from
them, and treat the generated code as a build artifact. Claude rewrites the tests from
spec whenever they go stale. Nobody edits the generated files.</p>
<pre><code>tests/
  spec/
    index.feature
    post.feature
    navigation.feature
  playwright/
    index.spec.ts      # generated, do not edit
    post.spec.ts       # generated, do not edit
    navigation.spec.ts # generated, do not edit
  playwright.config.ts
</code></pre>
<p>The actual specs for this blog live in
<a href="https://github.com/kylep/multi/tree/main/apps/blog/blog/tests/spec/"><code>tests/spec/</code></a>.
Here's the index one:</p>
<pre><code class="language-gherkin"># tests/spec/index.feature

Feature: Blog index page

  Scenario: Page loads with post list
    Given I navigate to the blog homepage
    Then I see a list of posts
    And each post has a title, date, and summary

  Scenario: Posts link to their detail page
    Given I navigate to the blog homepage
    When I click the first post title
    Then I am on a post detail page
    And the post has a title and content

  Scenario: Pagination controls are present
    Given I navigate to the blog homepage
    Then I see pagination controls
</code></pre>
<p>The instruction to Claude is: read the <code>.feature</code> file, generate a matching
<code>spec.ts</code>. If something breaks, fix the spec first, then regenerate. The feature
file is what documents how the UI is supposed to behave.</p>
<p>A <code>CLAUDE.md</code> in <code>tests/</code> gives Claude guidance when generating tests, things
like keeping the suite under a minute, no sleeps, one assertion per scenario.
If you're using <a href="/ruler-cross-tool-ai-rules.html">Ruler</a> to share rules across tools,
put that content in <code>tests/.ruler/</code> instead and let Ruler generate the
<code>CLAUDE.md</code> alongside your <code>AGENTS.md</code>.</p>
<h1 id="claude-verifying-its-own-changes">Claude Verifying Its Own Changes</h1>
<p>This is the part I wanted to try. Claude makes a change, then uses the MCP
browser to check whether it worked, before handing back.</p>
<pre class="mermaid">
graph TD
    A[Claude makes a change] --> B[Build blog]
    B --> C[Start dev server]
    C --> D[Navigate to affected page]
    D --> E[Screenshot + read DOM]
    E --> F{Looks right?}
    F -->|No| H[Investigate and fix]
    H --> B
    F -->|Yes| I{Add a test?}
    I -->|No| G[Done]
    I -->|Yes| J[Write Gherkin scenario]
    J --> K[Generate Playwright spec]
    K --> L[Run test to verify]
    L --> G
</pre>
<p>It's nondeterministic. That's the strength and the problem. Claude
isn't following a checklist. It navigates to what it changed, reads what's
there, and decides whether it matches intent. That catches a class of dumb
mistakes a checklist wouldn't, but it also means "looks right" depends on the
agent's judgment, which isn't always reliable.</p>
<p>The multimodal part matters here. When Claude calls <code>browser_take_screenshot</code>,
it doesn't get back an opaque file path. It sees the rendered page. It can tell
if an image failed to load, if a layout broke, if text is overlapping. That's
more than a DOM inspection gives you. It's also not a substitute for explicit
assertions, because "looks right" is still a judgment call.</p>
<pre class="mermaid">
graph TD
    A[Claude ready to commit] --> B[Start dev server]
    B --> C[Run Playwright tests]
    C --> D{Tests pass?}
    D -->|Yes| E[Commit]
    D -->|No| F[Investigate and fix]
    F --> C
</pre>
<p>This part is deterministic as reasonably quick in headless mode.
Screenshots are for the stuff that's hard to assert: visual regressions, style
issues, anything where you'd want a human to glance at it.</p>
<h2 id="playwright-config-for-the-blog">Playwright Config for the Blog</h2>
<pre><code class="language-bash">cd apps/blog
npm init playwright@latest
</code></pre>
<pre><code class="language-typescript">// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests/playwright',
  use: {
    baseURL: 'http://localhost:3000',
  },
  webServer: {
    command: 'npm run dev',
    url: 'http://localhost:3000',
    reuseExistingServer: true,
  },
});
</code></pre>
<p>The generated specs live in
<a href="https://github.com/kylep/multi/tree/main/apps/blog/blog/tests/playwright/"><code>tests/playwright/</code></a>.
Run them with:</p>
<pre><code class="language-bash">cd apps/blog/blog
npx playwright test
</code></pre>
<p>Claude gets pass/fail output with assertion details. Unambiguous, scriptable,
no judgment required.</p>
<p>Note: <code>npx playwright test</code> runs headless by default. No browser window appears.
Pass <code>--headed</code> to watch it run, or set <code>headless: false</code> in the config.</p>
<h1 id="where-this-is-going-agent-teams">Where This Is Going: Agent Teams</h1>
<p>Claude Code has a multi-agent feature in preview. The setup that makes sense
here is a builder agent making changes and a separate verifier agent running
tests and reporting back. They work in parallel. Failures come back as tasks.</p>
<p>Not wired up yet. But the spec files, generated tests, and MCP config are what
make it possible to hand verification to a different agent without losing the
context of what the tests mean.</p>


<p>I use Cursor and Claude Code, sometimes Codex, and I'm about to try OpenCode.
Each tool has its own rules format, and I've been maintaining them separately.
<a href="https://github.com/intellectronica/ruler">Ruler</a> generates each tool's native
config from a single source. Worth setting up.</p>
<h1 id="tool-agnosticism-with-common-rules">Tool agnosticism with common rules</h1>
<p>I'm trying to keep up. There are too many tools. I don't want to migrate things around.
We're using this at work too, since different devs use different tools. Here's how I
set up Ruler to consolidate my Cursor and Claude rules together.</p>
<p>I had this rule in Cursor:</p>
<pre><code class="language-markdown"># Monorepo rules

This git repo is a monorepo. It contains multiple sub-projects.
Do not look for context or cross-reference calls between sub-projects.
Each directory within apps/ and games/ is a sub-project. They shouldn't
share code.
</code></pre>
<p>Claude Code has CLAUDE.md files scattered through the tree:</p>
<table>
<thead>
<tr>
<th>File</th>
<th>Contents</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>CLAUDE.md</code> (root)</td>
<td>Branching: never commit to main, always PR</td>
</tr>
<tr>
<td><code>apps/games/sillyapp/CLAUDE.md</code></td>
<td>iOS build and test commands, simulator lifecycle</td>
</tr>
<tr>
<td><code>apps/blog/.../posts/CLAUDE.md</code></td>
<td>Blog writing voice, formatting rules, structure</td>
</tr>
<tr>
<td><code>apps/games/kid-bot-battle-sim/features/CLAUDE.md</code></td>
<td>Interface details for that feature set</td>
</tr>
</tbody>
</table>
<h1 id="ruler-setup">Ruler Setup</h1>
<pre><code class="language-bash">npm install -g @intellectronica/ruler
</code></pre>
<p>Initialize at the repo root:</p>
<pre><code class="language-bash">ruler init
</code></pre>
<p>This creates a <code>.ruler/</code> directory and a <code>ruler.toml</code> config. Drop your
instructions as Markdown files inside <code>.ruler/</code>, then:</p>
<pre><code class="language-bash">ruler apply
</code></pre>
<h2 id="what-happens-when-you-run-it">What happens when you run it</h2>
<p>Claude Code gets <code>CLAUDE.md</code>. Everything else (Cursor, OpenCode, Codex,
Copilot, 30+ others) gets <code>AGENTS.md</code>. Generated files go into <code>.gitignore</code>
automatically, so only the <code>.ruler/</code> source is committed.</p>
<p>Ruler supports nested directories. A <code>.ruler/</code> at the repo root applies
globally. A <code>.ruler/</code> inside a sub-project applies when an agent is working
there. That matches how Claude Code already loads CLAUDE.md files walking up
the directory tree.</p>
<pre class="mermaid">
graph TD
    A[".ruler/ at repo root\nbranching, monorepo"] --> B[Claude Code]
    A --> C[Everyone Else\nCursor, OpenCode, Codex...]
    E[".ruler/ in sillyapp/\nbuild, test"] --> B
    E --> C
    F[".ruler/ in posts/\nblog style"] --> B
    F --> C
    B --> G[CLAUDE.md]
    C --> H[AGENTS.md]
</pre>
<p>You can symlink ~/.ruler to your dir too if you want global Claude rules.</p>
<h1 id="note-consider-just-using-agentsmd">Note: Consider just using AGENTS.md</h1>
<p>Most tools read <code>AGENTS.md</code>: Cursor, OpenCode, Codex, <del>others</del>. If all you have is
rules, it's not a bad idea to skip all of this and just use that format. I think it
might win. That doesn't help with Skills, though.</p>
<h2 id="skills">Skills</h2>
<p>Rules are basically just fancy prompt context that are always loaded.
Skills are just fancy prompt context loaded on-demand, maybe with some extra files
sometimes. Different tools implement them in different ways:</p>
<ul>
<li>Claude Code: <code>.claude/skills/</code></li>
<li>Cursor: <code>.cursor/skills/</code></li>
<li>Other tools follow the same pattern under their own config directories</li>
</ul>
<p>Ruler figures it out and distributes them for you. Could this all just be a bash
script? Yes. Does it do a bunch of stuff I don't understand too? Also, probably, yes.</p>
<p>Enabled by default. Pass <code>--no-skills</code> to skip it:</p>
<pre><code class="language-bash">ruler apply           # distributes rules + skills
ruler apply --no-skills  # rules only
</code></pre>
<hr>
<h1 id="consolidating-rules-migration-steps">Consolidating rules: Migration steps</h1>
<p>The <code>ruler.toml</code> at the root lists the agents to target:</p>
<pre><code class="language-toml">default_agents = ["claude", "cursor"]
</code></pre>
<p>Content moves from existing config files into <code>.ruler/</code> source files:</p>
<pre><code>.ruler/
  branching.md        # from root CLAUDE.md
  monorepo.md         # from .cursor/rules/monorepo.md (Claude never saw this)
apps/games/sillyapp/
  .ruler/
    build.md          # from sillyapp/CLAUDE.md
apps/blog/blog/markdown/posts/
  .ruler/
    style.md          # from posts/CLAUDE.md
apps/games/kid-bot-battle-sim/features/
  .ruler/
    interfaces.md     # from features/CLAUDE.md
</code></pre>
<p>Root <code>.ruler/branching.md</code> (was only in Claude Code):</p>
<pre><code class="language-markdown"># Branching

Never commit directly to `main`. Always create a branch and open a PR
against main for review.
</code></pre>
<p>Root <code>.ruler/monorepo.md</code> (was only in Cursor):</p>
<pre><code class="language-markdown"># Monorepo

This repo contains multiple independent sub-projects under `apps/` and
`games/`. Do not cross-reference or import code between sub-projects.
Each directory in those folders is its own isolated project.
</code></pre>
<p>The project-specific files (sillyapp build commands, blog style guide)
move into <code>.ruler/</code> inside their directories unchanged. Content stays the
same, location shifts.</p>
<p>Note: the existing hand-written CLAUDE.md files get replaced by generated
versions after <code>ruler apply</code>. Edit the <code>.ruler/</code> source, not the output.</p>


<p>I'm building a tabletop RPG game that generates images on the fly: character portraits,
enemy illustrations, scene art. Cloud APIs work but get expensive when every combat
encounter wants several images. More importantly, I need character consistency. If I
generate a portrait of "Aria the rogue" in session one, future images of her should
look like the same character, not a random new person.</p>
<p>ComfyUI solves both. It runs locally on Apple Silicon, exposes a REST API, and
supports IP-Adapter for using an existing portrait as a visual reference for new
generations.</p>
<h1 id="hardware-reality">Hardware Reality</h1>
<p>MacBook Air M2, 16GB unified memory. The Air throttles under sustained load since
it has no active cooling. Fine for a game that generates at natural breaks (between
scenes, at combat start) rather than continuously.</p>
<p>16GB comfortably fits:</p>
<ul>
<li><strong>SDXL</strong> (fp16, ~6.5GB): mature IP-Adapter ecosystem, good portrait quality</li>
<li><strong>FLUX.2-klein-4B</strong> (fp8, ~8-9GB): Apache 2.0, released November 2025, 4-step
distilled generation, supersedes FLUX.1-schnell. IP-Adapter support less
mature than SDXL.</li>
<li><strong>FLUX.1-dev</strong> (fp8, ~8GB): previous generation but still the best quality
option that fits 16GB. FLUX.2-dev exists but won't fit.</li>
</ul>
<p>For this post I'm using SDXL. Its IP-Adapter tools are battle-tested for exactly
this use case, and 6.5GB leaves plenty of headroom for additional models.</p>
<h1 id="install-comfyui">Install ComfyUI</h1>
<p>ComfyUI has a <a href="https://github.com/Comfy-Org/desktop">Desktop app</a> that handles
everything automatically. Use that if you just want the UI. For API access and
full control, manual install is cleaner.</p>
<pre><code class="language-bash">git clone https://github.com/comfyanonymous/ComfyUI
cd ComfyUI
python3.13 -m venv venv
source venv/bin/activate
python --version  # must say 3.13 — if it says 3.9 you have an old venv, rm -rf venv and redo
pip install -r requirements.txt
</code></pre>
<p>On Apple Silicon, the requirements file pulls a PyTorch build with MPS support
automatically. No CUDA, no special flags.</p>
<p>Start it:</p>
<pre><code class="language-bash">source venv/bin/activate
python main.py --listen 0.0.0.0 --port 8188
</code></pre>
<p><code>--listen 0.0.0.0</code> binds to all interfaces instead of localhost only. Needed for
the API to be reachable from other processes or devices on your network.</p>
<p>I keep a <code>start-comfyui.sh</code> in <code>~/models/</code> next to the model README so there's
one place for everything model-related:</p>
<pre><code class="language-bash">#!/bin/bash
source /path/to/ComfyUI/venv/bin/activate
cd /path/to/ComfyUI
python main.py --listen 0.0.0.0 --port 8188
</code></pre>
<p>Open <code>http://localhost:8188</code>. You should see the node graph UI with a default
workflow loaded. No models needed for the server to start — the UI comes up
regardless.</p>
<h1 id="model-storage">Model Storage</h1>
<p>Models don't need to live inside the repo. ComfyUI will look in additional
directories if you tell it to via <code>extra_model_paths.yaml</code>:</p>
<pre><code class="language-bash">cp extra_model_paths.yaml.example extra_model_paths.yaml
</code></pre>
<p>Then add an entry pointing at wherever you keep models. For example, if you
store them under <code>~/models/</code>:</p>
<pre><code class="language-yaml">my_models:
  base_path: ~/models/
  checkpoints: sdxl/
  ipadapter: ipadapter/
  clip_vision: clip_vision/
</code></pre>
<p>Adjust the subdirectory names to match your layout. ComfyUI merges these with
its own paths and shows everything in the UI dropdowns.</p>
<h1 id="models">Models</h1>
<p>Download SDXL (~6.5GB):</p>
<pre><code class="language-bash">hf download stabilityai/stable-diffusion-xl-base-1.0 \
  sd_xl_base_1.0.safetensors \
  --local-dir ~/models/sdxl/
</code></pre>
<p>For IP-Adapter, clone the custom node into ComfyUI's <code>custom_nodes/</code> directory:</p>
<pre><code class="language-bash">cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/cubiq/ComfyUI_IPAdapter_plus
</code></pre>
<p>No pip install needed — it has no extra dependencies beyond what ComfyUI
already installs. ComfyUI picks it up automatically on next startup.</p>
<p>Then download the IP-Adapter weights:</p>
<pre><code class="language-bash"># IP-Adapter for SDXL
hf download h94/IP-Adapter \
  sdxl_models/ip-adapter_sdxl.bin \
  --local-dir ~/models/ipadapter/

# CLIP vision encoder (required by IP-Adapter — must be ViT-bigG, not ViT-L)
hf download laion/CLIP-ViT-bigG-14-laion2B-39B-b160k \
  --local-dir ~/models/clip_vision/CLIP-ViT-bigG-14-laion2B-39B-b160k/
</code></pre>
<p>Restart ComfyUI after installing custom nodes. It rescans the nodes directory on
startup.</p>
<h1 id="quick-test">Quick Test</h1>
<p>Before touching the API, confirm generation works at all.</p>
<p>The built-in Templates target newer models and won't work with SDXL. ComfyUI
ships a test workflow in the repo — open it with <strong>File > Open</strong>:</p>
<pre><code>/path/to/ComfyUI/tests/inference/graphs/default_graph_sdxl1_0.json
</code></pre>
<p><img src="/images/comfyui-web-interface.png" alt="ComfyUI web interface"></p>
<p>It's a base+refiner workflow with two Load Checkpoint nodes. The top one
should already show <code>sd_xl_base_1.0.safetensors</code>. The bottom one defaults to
<code>sd_xl_refiner_1.0.safetensors</code> — change it to <code>sd_xl_base_1.0.safetensors</code>
too. We're not doing base+refiner, just running base twice.</p>
<p>Drop a prompt into one of the CLIP Text Encode nodes and hit <strong>Run</strong>:</p>
<pre><code>a knight in plate armor holding a mace and shield, fantasy RPG portrait,
detailed face, dramatic lighting, painterly style, 4k, highly detailed
</code></pre>
<p>First run is slow while the model loads. On M2 Air, SDXL at 20 steps takes
90-120 seconds. Subsequent runs with the model cached are faster but still
in that range — the Air throttles under sustained load with no active cooling.</p>
<p><img src="/images/oss-img-gen-knight.png" alt="Knight portrait generated with SDXL"></p>
<h1 id="img2img-post-battle">Img2Img: Post-Battle</h1>
<p>Txt2img generates from noise. Img2img starts from an existing image and
nudges it toward a new prompt. Good way to stay close to a character while
changing context or condition.</p>
<p>Add two nodes to the current workflow. Right-click empty canvas space (not
on a node) to get the picker:</p>
<ul>
<li><strong>image → Load Image</strong> — then select your knight from <code>ComfyUI/output/</code>
using the dropdown in the node, or upload it from there</li>
<li><strong>latent → VAE Encode</strong> — converts a pixel image into the latent space
the sampler works in, replacing the EmptyLatentImage</li>
</ul>
<p>Then make three connections. To draw a wire: click and drag from an output
dot (right side of a node) to an input dot (left side of another node).
The dots are color-coded by type and will only connect to compatible ports.</p>
<ol>
<li>Drag from the <strong>IMAGE</strong> dot (blue, right side of Load Image) to the
<strong>pixels</strong> dot on VAE Encode</li>
<li>Drag from either <strong>Load Checkpoint VAE</strong> dot → <strong>VAE Encode vae</strong> dot</li>
<li>Drag from <strong>VAE Encode LATENT</strong> dot → <strong>KSampler latent_image</strong> dot
(disconnects EmptyLatentImage automatically)</li>
</ol>
<p>The test workflow uses <strong>KSampler Advanced</strong>, which has no <code>denoise</code> slider.
Instead set <strong>start_at_step</strong> to <code>6</code>. With 20 total steps that runs the last
14, equivalent to about 70% denoise. Lower start_at_step = more faithful to
original, higher = more change.</p>
<p>Update the positive prompt — that's the CLIP Text Encode node wired to the
KSampler's <strong>positive</strong> input, as opposed to the negative one (which holds
your "ugly, blurry..." text):</p>
<pre><code>a knight in plate armor, damaged armor, battle-worn, dented helmet,
scratches and dents, mud-stained, exhausted, fantasy RPG portrait,
detailed face, dramatic lighting, painterly style, 4k, highly detailed
</code></pre>
<p>Hit <strong>Run</strong>. If it's changing too much, drop start_at_step to 4. If the
damage isn't reading, push to 8.</p>
<p><img src="/images/img2image-knight.png" alt="Knight after img2img battle damage pass"></p>
<p>Img2img works, but it's coarse. Fine details like face structure get lost
as you increase denoise, and at low denoise the prompt has limited
influence. Good for "same scene, different state." Not what you want for
generating the same character across completely different scenes.</p>
<p>That's what IP-Adapter is for. Instead of perturbing the reference image,
it encodes it through CLIP vision into an embedding that gets injected
alongside the text conditioning during generation. The sampler still starts
from pure noise, but the attention layers are nudged toward the character's
appearance at every step. Face and body survive across very different
scenes because the conditioning runs throughout, not just at the start.</p>
<h1 id="the-api">The API</h1>
<p>ComfyUI's API accepts a workflow as JSON and queues the generation. The workflow
you build in the UI can be exported in API format: go to Settings, enable Dev
Mode Options, then use the "Save (API Format)" button on the workflow.</p>
<p>The API format represents each node as a dict entry keyed by node ID. Here's a
minimal SDXL workflow:</p>
<pre><code class="language-json">{
  "4": {
    "class_type": "CheckpointLoaderSimple",
    "inputs": { "ckpt_name": "sd_xl_base_1.0.safetensors" }
  },
  "5": {
    "class_type": "EmptyLatentImage",
    "inputs": { "batch_size": 1, "height": 1024, "width": 768 }
  },
  "6": {
    "class_type": "CLIPTextEncode",
    "inputs": {
      "clip": ["4", 1],
      "text": "a fantasy rogue in a dark alley, RPG portrait, detailed"
    }
  },
  "7": {
    "class_type": "CLIPTextEncode",
    "inputs": {
      "clip": ["4", 1],
      "text": "ugly, blurry, watermark, text, bad anatomy"
    }
  },
  "3": {
    "class_type": "KSampler",
    "inputs": {
      "model": ["4", 0],
      "positive": ["6", 0],
      "negative": ["7", 0],
      "latent_image": ["5", 0],
      "seed": 42,
      "steps": 20,
      "cfg": 7,
      "sampler_name": "dpmpp_2m",
      "scheduler": "karras",
      "denoise": 1
    }
  },
  "8": {
    "class_type": "VAEDecode",
    "inputs": { "samples": ["3", 0], "vae": ["4", 2] }
  },
  "9": {
    "class_type": "SaveImage",
    "inputs": { "filename_prefix": "rpg", "images": ["8", 0] }
  }
}
</code></pre>
<p>Submit it:</p>
<pre><code class="language-bash">curl -X POST http://localhost:8188/prompt \
  -H "Content-Type: application/json" \
  -d '{"prompt": &#x3C;workflow_json>}'
# Returns: {"prompt_id": "abc123...", "number": 1, "node_errors": {}}
</code></pre>
<p>Poll for completion:</p>
<pre><code class="language-bash">curl http://localhost:8188/history/abc123
# When done: history[prompt_id]["status"]["completed"] == true
</code></pre>
<p>Fetch the image:</p>
<pre><code class="language-bash">curl "http://localhost:8188/view?filename=rpg_00001_.png" \
  --output character.png
</code></pre>
<p>Images also land in <code>ComfyUI/output/</code> on disk if you'd rather read them
directly.</p>
<h1 id="image-consistency-with-ip-adapter">Image Consistency with IP-Adapter</h1>
<p>IP-Adapter encodes a reference image using CLIP vision and injects that embedding
alongside the text prompt during generation. The result is a new image that
respects the prompt but is visually pulled toward the reference: same hair, same
armor, similar face structure.</p>
<p>It's not a perfect clone. Think of it as a strong nudge. Consistent text prompts
help too. If every prompt for Aria includes "tall elf rogue, purple hair, leather
armor," you're conditioning from both directions.</p>
<p>Add these nodes to the workflow above:</p>
<pre><code class="language-json">"10": {
  "class_type": "IPAdapterModelLoader",
  "inputs": { "ipadapter_file": "ip-adapter_sdxl.bin" }
},
"11": {
  "class_type": "CLIPVisionLoader",
  "inputs": { "clip_name": "CLIP-ViT-bigG-14-laion2B-39B-b160k/open_clip_model.safetensors" }
},
"12": {
  "class_type": "LoadImage",
  "inputs": { "image": "aria_portrait.png" }
},
"13": {
  "class_type": "IPAdapterAdvanced",
  "inputs": {
    "model": ["4", 0],
    "ipadapter": ["10", 0],
    "image": ["12", 0],
    "clip_vision": ["11", 0],
    "weight": 0.6,
    "weight_type": "linear",
    "combine_embeds": "concat",
    "start_at": 0.0,
    "end_at": 1.0,
    "embeds_scaling": "V only"
  }
}
</code></pre>
<p>Then change node <code>"3"</code>'s <code>model</code> input from <code>["4", 0]</code> to <code>["13", 0]</code>.</p>
<p>The prompt here asks for the same knight in a tavern — completely different
scene, same character used as reference.</p>
<p><img src="/images/oss-img-gen-ipadapter.png" alt="Knight in a tavern, generated with IP-Adapter using the portrait as reference"></p>
<p><code>weight</code> is the main knob. At 0.5 you get style and general appearance influence.
At 0.8 it starts fighting the text prompt. For character identity, 0.6-0.7 is
the range to start with.</p>
<p>The <code>image</code> input in node <code>"12"</code> is a filename relative to <code>ComfyUI/input/</code>.
Copy your reference images there, or upload them via the API:</p>
<pre><code class="language-bash">curl -X POST http://localhost:8188/upload/image \
  -F "image=@aria_portrait.png"
# Returns: {"name": "aria_portrait.png", "subfolder": "", "type": "input"}
</code></pre>
<h2 id="face-consistency">Face Consistency</h2>
<p>Standard IP-Adapter works well for overall style and body type. Faces drift more
than you'd like, especially across very different scenes. IP-Adapter FaceID handles
this by extracting face embeddings specifically rather than encoding the whole image.</p>
<p>Download:</p>
<pre><code class="language-bash">hf download h94/IP-Adapter-FaceID \
  ip-adapter-faceid-plusv2_sdxl.bin \
  --local-dir ~/models/ipadapter/
</code></pre>
<p>FaceID also requires InsightFace, which isn't on HuggingFace. Download the
<code>antelopev2</code> model package from the
<a href="https://github.com/deepinsight/insightface/tree/master/model_zoo">InsightFace model zoo</a>
and place it under <code>~/models/insightface/models/antelopev2/</code> (or wherever your
<code>extra_model_paths.yaml</code> maps <code>insightface</code>).</p>
<p>Install the Python package into the ComfyUI venv:</p>
<pre><code class="language-bash">source /path/to/ComfyUI/venv/bin/activate
pip install insightface onnxruntime
</code></pre>
<p>With FaceID installed, use <code>IPAdapterFaceIDAdvanced</code> instead of <code>IPAdapterAdvanced</code>.
It takes the same inputs but runs the face embedding extraction automatically.
Faces stay recognizable across very different scenes much more reliably than with
the standard adapter.</p>
<p>You can combine both: use <code>IPAdapterAdvanced</code> for overall character appearance
and <code>IPAdapterFaceIDAdvanced</code> for face locking, chaining them in sequence.</p>
<h1 id="game-integration">Game Integration</h1>
<p>The pattern for a TTRPG character system:</p>
<pre class="mermaid">
graph TD
    A[Player describes character] --> B[Generate initial portrait\nno reference image]
    B --> C[Store portrait in character record]
    C --> D[Game event triggers image]
    D --> E[Build scene + character prompt]
    E --> F[Upload portrait, generate\nwith IP-Adapter]
    F --> G[Display in game]
    G --> D
</pre>


Kyle Pericak

"It works in my environment"

Categories

Tags