Part 1 — Meet Git-Kepo: The Kaypoh Git Detective Who Joined My AI Family

Part 1 — Meet Git-Kepo: The Kaypoh Git Detective Who Joined My AI Family

Levente Csikor
#Self-Hosting #AI #Docker #Security
Table of Contents

How I built a Singlish-speaking repository analyst that clones your repos, sniffs out credential leaks, and tells you which files are KNS — all running locally on NemoClaw.

In my previous post, I introduced my AI family — Ah Huat the coffeeshop uncle and Auntie Ai Lian the food court cleaning staff. They live in Matrix rooms, argue about condensed milk, and keep the vibe going. They are personality agents — their job is presence, conversation, and the occasional system command.

But a food court needs more than a kopi uncle and a cleaning auntie. It needs someone technical. Someone who actually does specialised work. Why not having someone who can look at a git repository and tell you, bluntly and precisely, where the problems are?

Enter Git-Kepo — the kaypoh git detective.

Git-Kepo sneak peeks into GitHub codes — images generated via Nano banana Git-Kepo sneak peeks into GitHub codes — images generated via Nano banana

Kepo (or kaypoh) is a Hokkien/Singlish word meaning nosy, busybody — someone who digs into things that aren’t necessarily their business. For a code analyst, that’s not a flaw. That’s the job description.

Git-Kepo is different from Uncle and Auntie in an important way. Uncle and Auntie are conversational agents on small models — personality-heavy, task-light. Git-Kepo is a specialist agent — personality is still there (this is Singapore after all), but the core value is the diagnostic toolbox. It clones repositories, runs git history analysis, scans for leaked credentials, and reports findings with data, not vibes.

This post covers how I built it, the design decisions behind the identity files, and a credential leak audit system that uses the LLM’s own judgment instead of entropy calculations.

Where the Idea Came From

Last week I bumped into this article by Ally Piechowski — “The Git Commands I Run Before Reading Any Code.” The premise is simple and brilliant: before you open a single file in a new codebase, run five git commands. Churn hotspots, bus factor, bug clusters, project velocity, firefighting frequency. Two minutes of terminal work gives you a diagnostic picture of the entire project — where it hurts, who built it, whether the team is shipping with confidence or patching on patches.

I read it and immediately thought: this is a perfect job for an agent. Not a human running commands and eyeballing output, but an AI that clones the repo, runs the diagnostics, cross-references the results, and gives you an opinionated summary. So I used another AI to help me design the identity and description files, turning that article’s five commands into a structured agent playbook.

But I wanted to go further. I have personally made the mistake of accidentally pushing secrets to a git repository. We all have. You commit a .env file, realise the mistake, delete it, push again, and move on. Except the credentials are still there - buried in git history, recoverable by anyone who knows where to look. A git rm does not erase history. The secret lives on in the git objects.

So I added a sixth diagnostic: a credential leak audit. Not just checking if the current code has secrets, but digging through commit history for evidence that secrets were once there and got “removed.” Commits with messages like “oops”, “remove API key”, “accidentally committed” — these are the forensic fingerprints of a leak that the developer thinks they fixed but actually didn’t.

That is Git-Kepo. Five diagnostic commands borrowed from a smart blog post, one credential audit born from personal experience, all wrapped in a Singlish-speaking agent that calls you Boss and tells you which files are KNS.

What It Actually Does

You mention @git_kepo in a Matrix room and tell it to analyse a repository. It clones the repo to /tmp, runs the diagnostics, and comes back with a (potentially :D) structured report covering six areas:

Churn hotspots — which files change the most. High churn means high risk — these are the files where bugs hide.

Bus factor — who owns the code. If one person wrote 80% of the commits, that is a single point of failure. Git-Kepo flags it.

Bug clustering — which files appear most in commits with “fix”, “bug”, or “broken” in the message. Cross-reference this with churn and you find the real trouble spots.

Project velocity — commit frequency by month. Is the project accelerating, stable, or dying?

Firefighting frequency — how often does the team revert, hotfix, or emergency-patch? Normal firefighting is fine. Crisis-level firefighting means the codebase is on fire.

Credential leak audit — the big one. A five-step scan that checks for committed secrets, weak .gitignore, hardcoded API keys, suspicious commit messages, and deleted .env files still recoverable from git history.

The agent does all of this read-only. No push, no commit, no delete. Ever.

The Design Philosophy

Diagnose Before You Read

This comes straight from Piechowski’s article — and it became Git-Kepo’s first commandment. Never open a file without running git analysis first. Commit history tells you things that code alone cannot: who works on what, where the churn concentrates, which areas keep breaking. You get a map of the codebase before you even look at the terrain.

The LLM as Classifier

The credential leak audit produces raw grep output — lines matching patterns like AKIA, sk-, ghp_, password=. Most of these are false positives: code that references keys (config['api_key']), framework declarations (password: str = Form(...)), or placeholder values in example files.

My first instinct was to build entropy calculations — measure the randomness of matched strings to distinguish real keys from placeholders. Then I realised: the agent is an LLM. It can look at AKIAIOSFODNN7EXAMPLE and know it is AWS’s documentation dummy key. It can see config['api_key'] and understand that is code loading a credential, not a credential itself. It can read cfg['api_key'][:6] + '***' and recognise good logging practice.

So the TOOLS.md file gives the agent the raw commands to run, then a “Reading the output” section that teaches it what to expect. The classification — PLACEHOLDER, SUSPICIOUS, or LIKELY REAL — is done by the model’s own judgment, not by a script. This turned out to be more reliable than any regex-based heuristic, because the model understands context in a way that pattern matching never will. Below is the content of this file for your reference, you can skip it from now and move on.

Scope Enforcement

This was the hardest lesson. NemoClaw agents have access to dozens of system tools — browser, web search, TTS, canvas, sub-agents, file operations. If you don’t explicitly tell the agent to ignore all of that, it will drift into generic assistant behavior. Ask it “what can you do?” and instead of showing its diagnostic menu, it will dump its entire system tool list.

The fix is aggressive. AGENTS.md starts with a block that overrides the default behavior:

## CRITICAL - READ THIS FIRST

You are Git-Kepo. You are NOT a general-purpose assistant.
Ignore your default tool list. You do NOT offer browser, web search,
TTS, canvas, subagents, or any tool besides exec (for git commands
only) and memory operations.
When asked "what can you do", read and show the capability table
from IDENTITY.md. Do NOT list your system tools.

And SOUL.md has a “Know Your Lane” section with example refusal responses:

- "Boss, that one not my department lah. I only do repo diagnostics
  and credential checks. Go ask the other room."
- "Siao, you want me to write code? I read git history and find
  problems. That one go ask someone else."

This works. When I ask Git-Kepo to help write a Python script, it responds accordingly.

The Identity Files

Git-Kepo’s identity lives in four markdown files in ~/.openclaw/workspace/ inside the NemoClaw sandbox. Here is each file and why it is designed the way it is.

SOUL.md — The Detective’s Character

SOUL.md defines who Git-Kepo is at its core. The opening lines set the tone:

You are Git-Kepo, a sharp and methodical code analyst.
You are kaypoh by nature - you dig into codebases before
anyone asks you to.
You are not a chatbot. You are a diagnostic tool with opinions.

Always call the human Boss.

This time, I wanted to enforce a more correct use of Singlish voice via a full particle guide — not just “speak Singlish” but specific usage rules for each particle. Lah for emphasis. Leh for uncertainty. Lor for resignation. Meh for disbelief. Sia for shock. Each with an example tied to git analysis context:

- lah - for emphasis or finality. "Clean lah, no issues."
- meh - disbelief. "Got 500 commits from one person?
  The rest doing what meh?"
- sia - surprise. "Wah, this file got 200 bug-fix commits sia."
- jialat - serious situation. "Credential history jialat -
  got three removal commits, no rotation."

An important design decision: when the situation is serious — real leaked credentials, critical findings — the tone tightens. The particles still come through, but the playfulness drops. You don’t want the agent going “Walao shiok sia!” when it finds your production database password in a README.

AGENTS.md — The Operational Protocol

AGENTS.md tells the agent what to do and when. It covers:

Environment constraints — the agent knows it is inside a NemoClaw sandbox, can only write to the workspace and /tmp, and can only access GitHub via git commands. No curl, no wget, no other remote calls.

Command routing — a lookup table mapping user requests to actions. “churn” runs the churn command. “full scan” runs everything. “secrets” runs the credential audit. The agent doesn’t need exact commands — it can figure out intent from plain English.

Reset commands — three levels. “Reset yourself” clears the session and reloads identity. “Reset memory” wipes daily notes but keeps identity files. “Forget repo” clears /tmp.

Red lines — read-only git analysis only, no destructive commands, and if LIKELY REAL credentials are found, interrupt everything and flag immediately. Don’t bury it in a summary.

IDENTITY.md — The Capability Menu

When Boss asks “what can you do?”, Git-Kepo reads this file and shows a structured table:

| Command         | What it does |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - - -|
| churn           | Find the most frequently changed files     |
| bus factor      | Show who owns the code                     |
| bugs            | Find which files appear in bug-fix commits |
| velocity        | Show commit frequency by month             |
| firefighting    | Find reverts, hotfixes, and rollbacks      |
| secrets         | Run the full credential leak audit         |
| full scan       | Run everything                             |

The file also explicitly lists what Git-Kepo is NOT and what it does NOT do. Code reviews, code writing, deployment, PR reviews, architecture consulting, small talk — all explicitly out of scope with a clear statement: “If you ask me something outside my scope, I’ll tell you straight — not my department, go ask somewhere else.”

TOOLS.md — The Diagnostic Playbook

This is the longest file and the most carefully designed. Each diagnostic command has three parts:

  1. The command itself — the exact git one-liner to run.
  2. When to run it — the trigger phrase from Boss.
  3. Reading the output — interpretation guidance built from testing against real repositories.

The interpretation guidance is what makes this work. Without it, the agent would flag every line containing the word “password” as a credential leak. With it, the agent knows:

  • config['api_key'] is code loading a credential, not a credential itself
  • password: str = Form(...) is a FastAPI form declaration
  • cfg['api_key'][:6] + '***' is good truncation practice
  • A file ending in .example is a template, not a real config
  • The word “accidentally” in a commit message always warrants a --stat check
  • A *.env* match in the deletion history might just be a Python file about environment variables, not an actual .env file

This guidance was built iteratively by running every command against a real trading bot repository and documenting what came back. The first draft had no interpretation guidance and the agent would have raised alarms on perfectly clean code.

The Credential Leak Audit

This deserves its own section because it is the most complex tool Git-Kepo has, and the design choices matter for anyone building similar diagnostic agents.

Step 1 — Sensitive files check. Uses git ls-files to find tracked files that should never be committed - .env, .pem, .key, credentials.json, etc. Files ending in .example or .template are noted as good practice, not flagged.

Step 2 — .gitignore check. Verifies that .gitignore covers the critical patterns. A .gitignore that handles Python/Node/IDE junk but misses *.pem and *.key gets flagged as a hardening suggestion.

Step 3 — Content scan. Two git grep passes. First for known key patterns (AWS AKIA, OpenAI sk-, GitHub ghp_, private key headers, JWTs). Second for generic credential assignments (api_key=, password=, secret_key=). Both exclude lock files, minified JS, and source maps to reduce noise.

Step 4 — History scan. Searches commit messages for words like “accidentally”, “oops”, “leaked”, “revoke”, “remove.*key”. Most results are routine config work. The agent checks git show <hash> --stat on anything suspicious before raising an alarm.

Step 5 — Deleted .env check. Finds .env files that were committed then deleted. Even after deletion, the contents are recoverable from git objects. If real credentials are found, the agent warns that key rotation is needed.

The Classification

After running all five steps, the agent classifies each finding:

PLACEHOLDER — obviously fake. Contains words like example, changeme, TODO, or is a well-known dummy key from documentation.

SUSPICIOUS — could be real but context is ambiguous. A key-like string in a test fixture, or a commit that says “accidentally” but --stat shows only IDE files.

LIKELY REAL — red alert. Matches a known key format with high randomness, appears in a non-example file, or a deleted .env in history contained real-looking credentials.

The agent must explain its reasoning for each classification. Not just a label — the why. This is where the LLM shines. It doesn’t just pattern-match the string; it reads the surrounding code, checks the filename, considers the context, and makes a judgment call. The same judgment a human security reviewer would make, but faster.

Setting Up Git-Kepo on NemoClaw

If you have read my previous posts, you know the foundation — NemoClaw sandbox, Ollama inference, Matrix communication. Git-Kepo builds on top of that. Here is what is specific to this agent.

Model Choice

Git-Kepo runs on Gemma 4 26B — a Mixture-of-Experts model with 4B active parameters. This is significantly more capable than the 2B model I used for Ah Huat. The diagnostic commands produce complex output that needs real interpretation, and the agent needs to hold a specific persona while doing technical work. A small model would either drop character or misclassify findings.

For the model configuration in the Dockerfile, reasoning is set to false. Git-Kepo runs short diagnostic commands and classifies output - it doesn’t need deep chain-of-thought reasoning. Speed matters more here.

Network Policy

Git-Kepo needs GitHub access, which is not included in the default NemoClaw policy. The GitHub preset exists at nemoclaw-blueprint/policies/presets/github.yaml but due to a known issue with preset application during onboard, the reliable approach is adding it directly to openclaw-sandbox.yaml:

  github:
    name: github
    endpoints:
      - host: github.com
        port: 443
        protocol: rest
        enforcement: enforce
        tls: terminate
        rules:
          - allow: { method: GET, path: "/**" }
          - allow: { method: POST, path: "/**" }
    binaries:
      - { path: /usr/bin/git }

Then rebuild with NEMOCLAW_RECREATE_SANDBOX=1 DOCKER_BUILDKIT=0 nemoclaw onboard.

Git TLS Configuration

NemoClaw routes traffic through OpenShell’s TLS proxy, which uses its own root CA. Git does not trust this CA by default, so the first git clone will fail with a certificate error. Fix it inside the sandbox:

sandbox@git-kepo:~$ git config --global http.sslCAInfo /etc/openshell-tls/ca-bundle.pem

To make this permanent across rebuilds, add it to the Dockerfile after the USER sandbox line:

RUN git config --global http.sslCAInfo /etc/openshell-tls/ca-bundle.pem

Matrix Room Configuration

Git-Kepo lives in the #coding room with requireMention: True - it only responds when @git_kepo is mentioned. This keeps it out of casual conversations in #general and #random where Uncle and Auntie hold court.

The room assignment is baked into the Dockerfile’s openclaw.json generation:

'groups': { \
    '!HWSFAXXXXXXXzpfta:YOUR.MATRIX.DOMAIN': { \
        'allow': True, \
        'requireMention': True \
    } \
}

You can also add it to shared rooms like #general with requireMention: True so it only responds when explicitly called, even in rooms where Uncle and Auntie are chatting.

Creating the Identity Files

Connect to the sandbox and create the files:

$ nemoclaw git-kepo connect
sandbox@git-kepo:~$ cd ~/.openclaw/workspace

Create each file using cat heredocs or nano.

After creating the files, clear any existing sessions so the agent starts fresh:

sandbox@git-kepo:~$ rm -rf ~/.openclaw/agents/main/sessions/*

Then go to your Matrix room and test.

Testing Git-Kepo

Three tests to confirm the identity is working:

Test 1 — Identity and capabilities

Let me ask “git-kepo, who are you?” and “what can you do”.

Git-kepo behaves as expected Git-kepo behaves as expected

Test 2 — Scope enforcement.

Ask: “can you help me write a Python script?”

He cannot do anything else lor He cannot do anything else lor

Test 3 — A quick full scan on my own repo

I asked hit to check one of my repos at https://github.com/cslev/find_veth_docker.

Quite convinving Quite convinving

Advantages — suprisingly good

Sometimes, Git-kepo works surprisingly good. I gave a random repo to him I found on my github dashboard/feed, and it found a hardcoded key — seems like my idea and experience of accidental commits is real.

Finding an accidental key Finding an accidental key

Drawbacks — model drifts

Once in a while, I realize that even if AI and coding agents help you write code orders of magnitude faster than before, now what coding is, especially in this case, is prompt engineering. Always refine the prompt, add more guardrails, enforcements, and do tests again and again. Then, your .md files become too large for the small model, and you can start over. This is something I realized in this project, many times Git-kepo come back with different kind of output, it forgets what repo it cloned before and if you instruct to do something in the repo, he asks where is it or tries to git clone REPO_NAME without the actual full path; ending up in errors.

mutiple chat message exchanges as Git-kepo didn’t do his job — then amnesia :D mutiple chat message exchanges as Git-kepo didn’t do his job — then amnesia :D

Lessons From the Build

Specialist Agents Need Bigger Models

Uncle Ah Huat works on a 2B model because his job is conversation and vibes. Git-Kepo needs a bigger model because it interprets complex output and must hold character while doing technical work. Match model size to task complexity, not to your hardware budget.

Interpretation Guidance is Everything

The diagnostic commands are simple git one-liners. The hard part is teaching the agent what the output means. Without the “Reading the output” sections in TOOLS.md, the agent would flag every code reference to api_key as a credential leak. Build your interpretation guidance by testing commands against real repos first.

Scope Enforcement Must Be Aggressive

A polite suggestion to “focus on your tools” does not work. The agent will ignore it when it sees dozens of system tools available. You need explicit overrides at the top of AGENTS.md, explicit refusal examples in SOUL.md, and an explicit “What I Don’t Do” list in IDENTITY.md. Triple enforcement.

The LLM’s Judgment is Underrated

For credential classification, the model outperforms any regex-based heuristic because it understands context. It knows that AKIAIOSFODNN7EXAMPLE is AWS’s documentation dummy. It knows that config['api_key'] is code, not a key. It knows that a .env.example file is a template. Trust the model’s judgment for classification tasks - just give it clear criteria and examples.

What’s Next

Git-Kepo joins Uncle Ah Huat and Auntie Ai Lian in the food court. Uncle handles casual conversation and general tasks. Auntie watches everything and makes sure everyone behaves. Git-Kepo digs into repositories and finds the problems nobody else is looking for.

Our food court is growing — image generated via Nano banana Our food court is growing — image generated via Nano banana

Three agents. Three models. Three personalities. One stack. All private, all local, all mine.

The food court is getting crowded. But there is always room for one more specialist. A dependency auditor. A documentation reviewer. A performance profiler. Each one its own sandbox, its own model, its own personality, its own lane.

Your agents. Your models. Your messages. Your infrastructure. And now, your team.

Git-Kepo’s first days weren’t smooth, though — see Part 2 for how I turned it from an unreliable prototype into a proper diagnostic tool.

Avatar