5 Skills That Make Your Coding Agent Work Better

When you give a coding agent a bug, it usually starts editing right away.

It guesses how the code fits together. It makes choices for you, and you only see them once the code is written.

Then the session ends, and the next one remembers none of it.

In this article, we'll go through five skills for Claude Code by fixing a real bug in git-lrc. Each skill helps at a different point, from planning the fix to passing the leftover work to a new session.

git-lrc is an open-source Go CLI that runs an AI code review every time you commit. It does this through Git hooks.

The bug is issue #144. git-lrc can install its hooks for all your repos, or for just one repo with --local.

After lrc hooks install --local, every git commit hangs. There's no error and no timeout, so you have to kill it by hand.

In my terminal, the same line kept printing until I pressed Ctrl+C.

The issue mentions two smaller problems too. lrc hooks disable doesn't stop the hang, and lrc hooks uninstall misses hooks installed with --local.

What the Agent Does on Its Own

I started with a plain prompt, with no skills installed:

Fix issue #144 in git-lrc: after `lrc hooks install --local`, git commit hangs forever because the hook chains to itself. Fix only the hang.

It listed the repo and opened the issue first. 44 seconds later, it had changed four lines in one file and called it done.

It didn't ask me anything along the way. It picked how to compare the paths, skipped writing a test, and only checked the script's syntax.

Every one of those choices was its own, and I saw them only after the code existed.

Grill Me: Agreeing on the Fix Before Any Code

Grill Me changes that order. It's from Matt Pocock's skills collection.

claude plugin install mattpocock-skills@claude-plugins-official

/grill-me fix issue #144: lrc hooks install --local makes git commit hang

Grill Me asks questions in rounds. Each question is numbered and comes with its own suggested answer, so a quick "yes" is enough when you agree.

The first round had four questions. The first one asked how the hook could avoid calling itself, and offered three ways.

It suggested the same path check the plain run had picked. It turned down an environment variable guard, since that could break user hooks that run git themselves.

It also raised a Windows detail. The bug came from Git Bash, so it picked a plain pwd -P path compare over the -ef file test.

The other questions covered things I hadn't planned for. What happens to people already stuck in the loop? And which tests would prove the fix?

The questions named real files, like tests/worktree-hooks.sh, so it had read the code before asking. It only asked me about decisions.

I said yes to three suggestions. For uninstall, I picked "out of scope" in place of its idea of printing a hint, to keep this change about the hang.

After one round, it said the plan was settled and listed the decisions, still without writing any code.

The plan came down to four points:

• A path check in hooks/dispatcher.sh, using pwd -P and no -ef
• Disable and uninstall left for a later session
• No migration, with release notes telling affected users to rerun lrc hooks install --local
• A Go test for the hook template, plus a shell test that makes a real commit

The plain run and Grill Me landed on a similar fix. The difference is that I agreed to every choice before any code existed, and the plan came with tests.

The same collection also has /grill-with-docs, which asks the same kind of questions and writes the decisions into the repo as docs.

graphify: Finding How the Hook Gets Installed

To understand the bug, the agent has to follow the install from the Go code to the shell script that becomes the hook.

Without help, it does this by searching and opening files one at a time. On a repo with about 230 Go files, that takes a while and costs tokens.

graphify builds a map of the codebase first, so the agent can ask questions about it.

uv tool install graphifyy
graphify install

/graphify . --code-only

It parses the code on your machine with tree-sitter, and it reads shell scripts as well as Go. For code, no LLM is used.

The --code-only flag skips the docs. git-lrc has READMEs in many languages, and reading those would need the model.

My run parsed 337 files, and its cost file showed 0 tokens used.

The result goes into a graphify-out/ folder. It has an interactive graph.html, a short GRAPH_REPORT.md, and a graph.json for later questions.

The graph had 3,479 nodes and 11,204 edges. A fair share of that is bundled D3 JavaScript, which shows up as its own groups in the sidebar.

Then I asked it about the install:

/graphify query "how does lrc hooks install --local write the pre-commit hook?"

It traced the install step by step, from the lrc hooks install command down to the code that writes the hook into .git/hooks/pre-commit. I checked each step against the code, and they all matched.

The answer also marked which links came straight from the code and which ones graphify guessed. That makes it easy to see what to double-check.

It missed one link. The Go code pulls in the hook script in a way graphify can't follow, so the agent filled in that step by reading the files itself.

It ended with the cause of the bug. The hook runs git-lrc's review, then runs any other pre-commit hook it finds in the repo.

With --local, the hook it finds is itself. So it calls itself again, and again, and the commit never ends.

Archify: Drawing the Loop

The loop is easy to miss in code, and very easy to see in a diagram.

Archify turns a plain request into a diagram, saved as a single HTML file that opens in any browser.

npx skills add tt-a1i/archify -g

Use Archify to draw a sequence diagram of what happens on git commit after lrc hooks install --local.

The diagram has two parts. The top shows the lrc check passing, and the bottom shows the loop.

In the loop, the hook calls the next hook, which turns out to be itself. A note says each call waits on the next one, so nothing ever finishes.

It also showed why lrc hooks disable doesn't help. Disabling skips git-lrc's review, but the hook still calls itself.

Once the fix was ready, I asked for the same diagram again, side by side with the old one:

Use Archify to show the same flow after the fix, compared with the current one.

Archify drew both flows in one diagram, the old one on top and the fixed one below.

It also added the user's own hook to the picture, which I hadn't asked for. Before the fix, that hook never gets a turn. After it, the hook runs once and the commit goes through.

Archify draws the flow and stops there. It doesn't try to judge whether the change is safe.

Karpathy Guidelines: Keeping the Fix Small

The fix itself is a few lines in one shell script. All the hook has to do is skip itself when it looks for other hooks.

Agents often go further than that. They clean up nearby code, or fix every problem in the issue at once.

Karpathy Guidelines is a short set of rules for this, based on Andrej Karpathy's notes on how coding agents go wrong. There are four:

• Think before coding. The agent states what it's assuming, and asks when it's unsure.
• Simplicity first. The least code that solves the problem.
• Surgical changes. Only the lines the task calls for get touched.
• Goal-driven execution. The agent decides how it will check the fix, and keeps going until the check passes.

It installs from inside Claude Code:

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

To see if it makes a difference, I gave the agent the same prompt twice, on the same code. The first run is the plain one from earlier.

The second run had these rules turned on, and nothing else changed. Here's how the two compared:

Without the rules, the change to hooks/dispatcher.sh was this:

-if [ -x "$LOCAL_HOOK" ]; then
+# With --local the dispatcher is itself the repo hook; skip chaining to avoid calling itself forever.
+SELF_DIR_REAL="$(cd "$SCRIPT_DIR" 2>/dev/null && pwd -P)"
+LOCAL_HOOK_DIR_REAL="$(cd "$GIT_COMMON_DIR/hooks" 2>/dev/null && pwd -P)"
+if [ -x "$LOCAL_HOOK" ] && [ "$SELF_DIR_REAL" != "$LOCAL_HOOK_DIR_REAL" ]; then

With the rules, it was this, plus one new line in the existing template test:

-if [ -x "$LOCAL_HOOK" ]; then
+# With --local installs the dispatcher lives at $LOCAL_HOOK, so skip chaining to itself.
+if [ -x "$LOCAL_HOOK" ] && ! [ "$LOCAL_HOOK" -ef "$0" ]; then

Both fixes were small, and neither touched disable or uninstall. On this bug, the agent stayed inside the task even without the rules.

The difference showed up in the checking. With the rules, the agent added a test and tried its check in a scratch repo under sh and dash before calling the job done.

That's the fourth rule at work. The plain run stopped at a syntax check.

The rules run also picked -ef, the one option the Grill Me plan had ruled out for Windows. It never saw the plan, so it had no way to know.

This was one try each, and an agent can answer differently every time. So it's an example, and a small one.

For the real fix, I went back to the Grill Me session and asked it to build the agreed plan. It came to 39 added lines across three files.

Four of those lines are the fix, and the rest are the two tests. The Go tests passed, and the shell test passed all 25 of its checks.

One of the new checks makes a real commit after a local install, with a 20 second timeout. Another makes sure the user's own hook runs exactly once.

With the fix in place, the commit goes through:

$ timeout 10 git commit -m test5; echo "exit: $?"
LiveReview pre-commit: interactive environment detected; no-op
LiveReview pre-commit: interactive environment detected; no-op
LiveReview: attestation already present for 151d039c...; proceeding with commit
LiveReview: attestation already present for 151d039c...; proceeding with commit
lrc: cleared attestation for committed tree 151d039c...
[master 5f26387] test5
 1 file changed, 1 insertion(+)
exit: 0

Each line shows up twice because my machine also has a global install, and the global hook calls the local one. That's a separate, smaller problem, and it doesn't hang.

Handoff: Leaving Notes for the Next Session

The hang is fixed, but two problems from the issue are still open. disable still doesn't stop the chain, and uninstall still misses local installs.

The current session knows how the code fits together, what we decided, and what's done. A new session would know none of that.

Handoff writes all of it into one short document for the next agent:

/handoff fix the disable and uninstall problems from issue #144

The document points to the issue and the exact places in the code, instead of copying code in. It also lists the two Archify diagrams and my rules for the agent.

At the end, it suggests which skills the next session could use, like Grill Me for the open questions and a code review before finishing. The skill also asks it to leave out keys, passwords, and personal details.

It's saved in your system's temp folder, so it never ends up in the repo.

One part of the document surprised me. It asked whether the disable problem is still a bug at all.

With the loop fixed, the user's own hook running while git-lrc is disabled might be the right behavior. So the document asks the next session to check with me before changing anything.

A handoff only knows what its own session saw. My first version said the tests had never run, because I'd run them in a different terminal.

I told the session, and it updated the document. When I also said the fix was committed, it checked the repo before writing that down.

The commit hadn't gone through yet. So the document says the fix isn't committed, and tells the next session to check that first.

The next session starts by reading the file:

Read /tmp/handoff-issue-144-disable-uninstall.md and continue.

Wrapping Up

Grill Me turned a quick guess into a plan I agreed with, tests included. graphify traced how the hook gets installed, and Archify made the loop visible.

Karpathy Guidelines got the agent to test its own fix, and Handoff passed the rest of the issue to a new session.

You won't need all five on every task. Grill Me is too much for a typo, graphify helps most on a large codebase, and Archify is worth it when a flow has several moving parts.

Karpathy Guidelines costs almost nothing, so it can stay on all the time. And Handoff is useful whenever the work continues in another session.

Together, they cover the points where a coding agent most often goes wrong: before it starts, while it reads, while it writes, and when the session ends.