HanLHo. - Fractional Architect & Software Product Engineer - jujutsu

Agent Chisels: My LLM Agent Skills and Workflows

2026-01-13T00:00:00+00:00

I have been meaning to share more about my LLM workflows and tooling for a while, partly to have a reference for conversations, but mostly to learn in public.</p>

Agent Chisels</a> is where I will be sharing the custom artefacts (primarily skills</code>, with commands</code> and agents</code> to follow) that I find most useful and actively use in my daily workflow.</p>

Skills</h2>

I have shared two skills</a> I use almost daily. In addition, I've also included a third skill, more of a meta-skill for evaluating other skills, which I used when reviewing these for release. I actively use this skill to iterate and improve my skills so it fits the goal of this project.</p>

documenting-architectural-decisions</code>: Document and manage architectural decisions using ADRs. Supports Y-statement and traditional ADR formats. Used for creating, reviewing, or searching decision records. This repository contains several examples of decision logs created with this skill, for example, here</a> is the one for the jj</code> plugin.</li>
</ul>
I use jj</code> or Jujutsu</code></a>, an alternative version control system, in all my projects. Getting LLMs to work reliably with it is quite a challenge, so I have a skill to detect and remind an LLM to use jj</code> and one to add the capability of using jj</code>. The Claude Code plugin</a> also adds a use-jj</code> command and a hook to remind an LLM of using jj</code>.</p>

detecting-jujutsu</code> — Verify if the current repository uses Jujutsu (jj) instead of git. Used when confirming VCS state before operations.</li>
using-jujutsu</code> — Detailed guidance on Jujutsu (jj) VCS operations including committing, pushing, searching history, and working with revisions/revsets.</li>
</ul>
And finally, there is the meta-skill to evaluate skills. Here is an example</a> of a report generated by this skill.</p>

evaluating-skills</code> — A skill to evaluate skills against best practices for size, structure, examples, and prompt engineering. Use when reviewing skills for deployment, optimisation, or standards compliance.</li>
</ul>
To use these, you can use the Claude Code plugin system or install them manually; take a look at the installation section</a> for more details.</p>
A little on the setup of the repository</h2>
I use symbolic links liberally to avoid duplication. For example, symbolic links allow me to share the independent skills with the Claude Code plugin while also using them in this project itself.</p>
All skills I share in this repo are dynamically linked to my ~/.claude/skills</code> directory. Note that this is also the easiest way to make these skills available to other LLM CLI agents</a> like Opencode, Codex, and Mistral Vibe. In this repo, I have mostly worked with Opencode</a> and the skills in the .claude</code> location just work with it.</p>
❯</span> ls</span> -l</span> .claude/skills
</span>l...</span> detecting-jujutsu -> ../../skills/detecting-jujutsu
</span>l...</span> documenting-architectural-decisions -> ../../skills/documenting-architectural-decisions
</span>l...</span> evaluating-skills -> ../../skills/evaluating-skills
</span>l...</span> using-jujutsu -> ../../skills/using-jujutsu
</span>d...</span> verify-release-readiness
</span></code></pre>
The l</code> at the beginning of each line stands for symbolic link. You'll notice one real directory in there, that is a skill only relevant to this repository.</p>
Future plans</h2>
I'll be adding LLM artefacts as I move my own setup more and more to this repository. Since I'm trying to reuse as much as possible (within reason) between different LLM agents, I need a central location anyway, preferably vendor neutral yet pragmatic (e.g. using the .claude/skills</code> location to share skills). Also, my hope is to make this repository a more live and automatically up-to-date version of the artefacts I use day to day.</p>
Related to this, I am thinking of creating a setup similar to dotfiles</a> (where developers share configuration files) but for LLM agent configurations: 'agentfiles'. I intend to share my LLM agent configurations and how I integrate them. Let me know if you would be interested in this or are already sharing.</p>



How to Use Jujutsu (jj) with Claude Code
2025-08-22T00:00:00+00:00
I prefer Jujutsu</a> (jj</code>) over Git for version control, but getting Claude Code to work with jj</code> proved tricky since Claude Code defaults to git</code>. This post explains how to configure Claude Code to use jj</code> instead of Git for version control operations and file change detection.</p>
I'll show you three possible approaches to get Claude Code working properly with Jujutsu repositories, from simple configuration changes to advanced system prompt modifications.</p>
Quick Solution: CLAUDE.md</a> Configuration</h2>
For most users, this addition to your project's CLAUDE.md</a> file should configure Claude Code to start using Jujutsu:</p>
## Version Control
</span>
</span>**CRITICAL: This repository uses Jujutsu (jj), not git.**</span> Always use </span>`jj`</span> commands for version control operations.
</span>
</span>- Use </span>`jj st --no-pager`</span> to check status (like </span>`git status`</span>)
</span>- Use </span>`jj log --no-pager`</span> to view history (like </span>`git log`</span>)
</span>- Use </span>`jj commit -m "message"`</span> to create commits (like </span>`git commit`</span>)
</span>- Use </span>`jj split -m "message" file1 file2`</span> to commit specific files only
</span>- Use </span>`jj bookmark set main -r @- && jj git push`</span> to push to remote repository
</span>
</span>- ALWAYS check for any sensitive information that shouldn't be committed
</span></code></pre>
The CLAUDE.md</a> file contains instructions that Claude Code reads for each project.</p>
Before I came up with this configuration I tried quite a number of different instructions. I suspect this one works because of the combination of:</p>


The 'CRITICAL' keyword</strong>: Signals high priority to Claude Code's instruction processing</p>
</li>

Explicit repository type declaration</strong>: Removes ambiguity about which version control system to use</p>
</li>

Specific</strong> jj</code> command mapping</strong>: Provides concrete alternatives to built-in Git commands</p>
</li>
</ul>
You can expand the command list to match your workflow, but these core commands worked for me and should get you started.</p>
Why Claude Code uses Git</h2>
Claude Code has Git instructions hardcoded into its system promp, the internal directions that override user preferences. Here is part of the Git configuration in the system prompt</a> from Claude Code 1.0.85:</p>
# Committing changes with git
</span>
</span>When the user asks you to create a new git commit, follow these steps carefully:
</span>
</span>1. You have the capability to call multiple tools in a single response. When multiple independent pieces of information are requested, batch your tool calls together for optimal performance. ALWAYS run the following bash commands in parallel, each using the Bash tool:
</span>   - Run a git status command to see all untracked files.
</span>   - Run a git diff command to see both staged and unstaged changes that will be committed.
</span>   - Run a git log command to see recent commit messages, so that you can follow this repository's commit message style.
</span>2. Analyze all staged changes (both previously staged and newly added) and draft a commit message:
</span>   - Summarize the nature of the changes (eg. new feature, enhancement to an existing feature, bug fix, refactoring, test, docs, etc.). Ensure the message accurately reflects the changes and their purpose (i.e. "add" means a wholly new feature, "update" means an enhancement to an existing feature, "fix" means a bug fix, etc.).
</span>   - Check for any sensitive information that shouldn't be committed
</span>   - Draft a concise (1-2 sentences) commit message that focuses on the "why" rather than the "what"
</span></code></pre>
As you can see, Claude Code's system prompt contains hardcoded Git configuration to commit changes. Since system instructions override user prompts when you mention committing or version control, it defaults to Git commands even in Jujutsu repositories. Or at least this i how I interpret Claude Code's behaviour.</p>
If the CLAUDE.md</a> approach above doesn't work consistently, here are more advanced alternatives:</p>
Advanced Solution: Custom Output Style</h2>
Output styles</a> let you override Claude Code's system prompt entirely, giving you complete control over its behaviour. Here is my own summary</a> of Claude Code output styles if you want to know more about this feature.</p>
Setup step</strong></a>s:</strong></p>


Start claude</code> and run /output-style:new</code></p>
</li>

Name your style (e.g., jj-support</code>) and complete the wizard</p>
</li>
</ol>

The initial content you enter doesn't matter since we'll replace it entirely in the next step</li>
</ul>


Find the created .md</code> file in .claude/output-styles/</code> (project or home) directory</p>
</li>

Replace its contents with a modified system prompt that includes Jujutsu support</p>
</li>
</ol>
You can use my pre-built version</a> based on Claude Code 1.0.85's system prompt. These are the directives I added to add 'jj' support</a>.</p>
The critical addition is automatic repository type detection:</p>
### MANDATORY FIRST STEP FOR ALL COMMITS
</span>
</span>Before ANY commit-related commands, you MUST:
</span>1. Run </span>`bash: if jj root >/dev/null 2>&1; then echo "jj"; elif git rev-parse --git-dir >/dev/null 2>&1; then echo "git"; else echo "none"; fi`
</span>2. If output is "jj" → use jj commands
</span>3. If output is "git" → use git commands
</span>4. If output is "none" → not a repository, inform user
</span>
</span>NEVER use git commands if .jj directory exists, regardless of environment info.
</span>
</span>NOTE: Environment "git repo" status may be misleading when both .jj and .git exist. Always use directory detection as the authoritative source.
</span></code></pre>
(Turns out you can add logic inside a system prompt.)</p>
Trade-offs</strong>:</p>


✅ Most reliable solution</p>
</li>

✅ Works even when CLAUDE.md</a> is ignored or 'forgotten'</p>
</li>

❌ Requires maintenance when Claude Code updates, that is if you want to keep in sync with the latest default system prompt</p>
</li>

❌ Claude Code will request permission to run the detection command</p>
</li>
</ul>
Select your custom output style with /output-style</code> and test by asking Claude to "commit the changes".</p>
Experimental Solution: Command-Line Flag</h3>
The --append-system-prompt</code> flag adds system instructions directly after Claude Code's system prompt at startup.</p>
claude-code --append-system-prompt </span>"</span>In jj repositories, use jj commands instead of git commands.</span>"
</span></code></pre>
Note</strong>: Simple instructions like the example above don't work. You'd need to pass the same comprehensive instructions used in the output style approach. I did not try this myself yet as for now I am done shaving this yak</a> for now. I am sure you can pass the inputs from a file to the prompt making it more manageable as well.</p>
Trade-offs</strong>:</p>


✅ No file modifications needed</p>
</li>

✅ Easy to test different configurations</p>
</li>

✅ Works at system level like hardcoded instructions</p>
</li>

❌ Must be added each time you start Claude Code (needs helper command)</p>
</li>
</ul>
Choosing the Right Approach</h2>
Start with</strong> CLAUDE.md</strong></a> configuration</strong>. It's simple, requires no system modifications, and should work for most users.</p>
Upgrade to custom output style</strong> if:</p>


Claude Code frequently ignores your CLAUDE.md</a> instructions</p>
</li>

You work with multiple Jujutsu repositories</p>
</li>

You want the most reliable solution</p>
</li>

You are willing to update the output style to the latest system prompts when it changes (significantly), or accept running with an outdated configuration version.</p>
</li>
</ul>
Consider the command-line flag</strong> for:</p>


When you want to stay up to date with the latest system context versions without having to update the output style each time.</p>
</li>

Testing different configurations quickly</p>
</li>
</ul>
Important Considerations</h2>
Missing Git Features</h3>
When you override Claude Code's Git behaviour, you lose may some built-in safety features:</p>


Automatic sensitive information checking</p>
</li>

Commit message formatting guidelines</p>
</li>

Built-in branching workflow guidance</p>
</li>
</ul>
Consider adding these to your CLAUDE.md</a> configuration if they're important to your workflow.</p>
Bonus: No More Claude Branding in commit messages</h3>
A pleasant side effect is that Claude Code stops adding its promotional footer to commit messages:</p>
🤖 Generated with </span>[Claude Code](https://claude.ai/code)
</span>
</span>Co-Authored-By: Claude </span><noreply@anthropic.com>
</span></code></pre>
Summary</h2>
To integrate Jujutsu workflows in Claude Code, but these three solutions exist:</p>


CLAUDE.md</strong></a> configuration</strong>: Simple and effective for most users</p>
</li>

Custom output styles</strong>: Most reliable but requires maintenance</p>
</li>

Command-line flags</strong>: Less maintenance and best for testing</p>
</li>
</ol>
Start with the CLAUDE.md</a> approach. If Claude Code continues defaulting to Git commands despite your configuration, escalate to a custom output style for complete system-level control.</p>
Thank you for reading, Hans</p>