HanLHo. - Fractional Architect & Software Product Engineer - claude-code

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>



Implementing an Urgent Feature with Opencode, Claude, and Zed
2025-12-18T00:00:00+00:00
This is a short post to share a positive experience I had using an LLM agent to quickly add a feature to an existing personal CLI time-tracking application</a>. Below, I describe how I added it using Zed, Opencode and Claude.</p>
To start, I wasn't even sure the feature I needed existed in a text-based time-tracking application I use day-to-day to keep track of what I work on. My application has</em> a way of getting the information I needed out, but the feature that should make this easy was missing details on what</em> I had actually worked on.</p>
So, should I invest the time and expand the feature, or accept that it was missing for now and spend a lot more time on manual work? I could try an LLM agent and see if it could help me implement the change quickly. Each choice had downsides: spending more</em> time digging through time-tracking information to fill in timesheets is not very appealing, and implementing the feature (with or without agents) could become a time sink. I also had lots of other work planned for the day.</p>
I decided to implement it, telling myself I’d stop if it didn’t look like I had a clear path to finish it within one hour.</p>
Because I think it is relevant to the (spoiler) successful implementation, let me share a little about this project. It is a Rust codebase that I use to test development practices, and I think it is structured and implemented fairly well. The CLI, the main part of the application, has over 95% coverage using behaviour-driven, DSL-style acceptance tests. This setup gives the LLM models both structure and plenty of examples to follow when adding tests. I will not go into the details here, but I have added a brief example at the end. Also noteworthy: this is a small project, which definitely makes a difference.</p>
For this implementation, I used Zed with its Opencode integration. Lately, I have been on the command line building smaller apps prompt-driven, without worrying much about the fine details. But for this project the actual implementation mattered to me, so I wanted to track changes more closely in an IDE. Opencode taps into my Claude subscription; I can use Opus for planning and Haiku for implementation.</p>
Honestly, I was very pleased with how smoothly this feature was implemented. What contributed to this was the plan-first approach before implementing anything. For anything non-trivial, always plan first!</p>
Here is a high-level overview of my interaction with Opencode in Zed:</p>

Investigate

I started with Claude Opus and asked whether the feature I needed already existed, rather than looking it up myself because I was under time pressure. It didn't.</li>
</ul>
</li>
Plan

I asked Claude to plan the feature and use a test-driven approach. It broke the work into nine tests, and I asked it to pause after each one for me to review.</li>
Before starting any implementation, I asked it to write the plan to a Markdown file in the backlog.</li>
Then I reviewed the plan.</em> That sounds more superficial than what I did, but I cannot say much more than that it simply looked good.</li>
</ul>
</li>
Implementation

I switched to Claude Haiku for implementation.</li>
It started off well and asked for feedback after each test cycle, and I asked for a refactor to remove duplication.</li>
While it was implementing, I discovered I wanted a different kind of description for the tasks, so I told it to change that in the plan. I did not switch models for this.</li>
The plan was updated in all the correct places.</li>
After this, the workflow changed: it stopped asking me for feedback after each step, and before I realised it, seven of nine tests were running. Not the TDD flow I asked for, but it worked.</li>
Instead of asking it to redo anything, I reviewed the implementation (it was not a lot of code) and continued.</li>
I ran the program against my own data and everything worked as intended. Aside from the one refactoring to remove duplication, I did not change the code.</li>
One loose end I had to remind it of: update the documentation.</li>
</ul>
</li>
</ul>
I have shared the full session here: https://opncd.ai/share/aBYozahW.</p>
There were some pitfalls of using LLMs that I ran into, and I admittedly leaned into them. Speed beating accuracy is a real risk. The feature works and the code looks good, but if I were coding hands-on I probably would have reviewed more thoroughly. It is hard to tell if the end result would have been drastically</em> better. It requires discipline to not start running along with the agent and to not start accepting everything if the outcome is as expected. The LLM gave me what I needed and any follow-up changes should be small, but I still see little things I would have done differently if I done it manually (which other developers may disagree with too, to be fair). For example, some of the tests could do with fewer assertions. The current code organisation makes that easy to address later. If</em> any tech debt was added, it is very small and under control, so I stopped, generated my reports and filled in my timesheets.</p>
Overall, working in Zed made it easy to review the code, and combining Opencode's plan phases kept things organised. The existing, structured DSL-based test approach with plenty of examples also helped.</p>
Extra: How an LLM can work better with a well-structured DSL</h2>
To give some context, what the application needed was to combine two existing flags: breakdown</code> and details</code>. The time breakdown</code> reports were already implemented but were only reporting time spent per day, week, month or year. What I needed were details of the projects I had worked on. The application already had a details</code> flag but it was not implemented for this view.</p>
In the test DSL, the flags are set by calling methods in the given</code> setup phase: breakdown_flag(...)</code> and details_flag()</code>. The breakdown feature did not implement the details</code> flag, so it was not used in the tests for this feature. What is nice (and I credit this way of testing for it) is that the LLM was able to figure out the details_flag</code> was already present and decided to re-use it: Cmd::given().details_flag()....</code>. Here is an example of such a DSL test:</p>
#[</span>test</span>]
</span>fn </span>breakdown_day_with_details_should_show_tasks_per_day</span>() {
</span>    </span>let</span> some_content = </span>r</span>"</span>## TT 2020-01-01
</span>- #project-a 1h Task A
</span>- #project-b 2h Task B</span>";
</span>
</span>    Cmd::given()
</span>        .</span>details_flag</span>()
</span></mark>        .</span>breakdown_flag</span>("</span>day</span>")
</span></mark>        .</span>tags_filter</span>(&["</span>project-a</span>", "</span>project-b</span>"])
</span>        .</span>at_date</span>("</span>2020-01-01</span>")
</span>        .</span>a_file_with_content</span>(some_content)
</span>        .</span>when_run</span>()
</span>        .</span>should_succeed</span>()
</span>        .</span>expect_task_with_duration</span>("</span>project-a</span>", "</span>1h 00m</span>")
</span>        .</span>expect_task_with_duration</span>("</span>project-b</span>", "</span>2h 00m</span>");
</span>}
</span></code></pre>
Thank you for reading,</p>
Hans</p>


Grounded decision records from AI conversations
2025-09-02T00:00:00+00:00
If you've read some of my posts before or worked with me, you know I like using Architectural Decision Records (ADRs) for lots of reasons</a>. To me the most important one is documenting the why of a decision.</p>
If you've worked with AI models before, you've probably asked them for options when brainstorming solution ideas when you're not sure about direction. In this situation, I've found it quite easy, maybe even more logical, to document the decision in a decision record with help from the AI model you have been working with. After all, you got feedback from it anyway.</p>
This post briefly explains how I use Claude Code to write decision records (not necessarily architectural ones) when it's helped me make a decision. My goal isn't to dive into an elaborate investigation into the pros and cons of this approach, but I will touch upon a few points. The process is not specific to Claude Code but can be adapted to other AI models or tools as well.</p>
Here's the process I've been following:</p>
1. Ask for the decision record during the conversation</strong></p>
After going back and forth on options and reaching a decision, I ask something like:</p>
Given</span> your feedback, I think Option 2 is the way I want to implement.
</span>
</span>Principally</span> I do not want to complicate things with 2 tools at the moment.
</span>
</span>Before</span> implementing, summarise this into an ADR in the '</span>adr/</span>' directory as a way of confirming our mutual understanding.
</span>
</span>So,</span> write an ADR first, then ask me to confirm the ADR. Once I do, continue implementing.
</span></code></pre>
The phrasing is a bit sloppy, as this is what I actually wrote in my recent changes, but that's OK, Claude Code can work with this.</p>
2. Review and edit the generated draft</strong></p>
What it comes up with initially is actually pretty good. A lot will depend on the conversation you had with it and the input you gave it, of course. But the decision record mostly contains what was discussed and decided quite well. The text will be structured like an ADR even without me having to explain what an ADR is. It even picked up the decision record's next number too.</p>
Usually content editing is needed, but having a complete draft to start with makes a big difference instead of starting from a blank page. So after the draft is written, I edit it mostly on content only.</p>
3. Use as implementation foundation</strong></p>
When done, the decision is basically documented and it can serve as the basis of our next step. To make the continuation based on the decision record only, at this point you could clear or restart the Claude Code session to start fresh.</p>
This last step is meant to ground the decision record in reality. When you include the decision record as basis for implementation, it becomes living documentation that creates a feedback loop. During implementation you may encounter issues not anticipated during the decision making process. These can then be documented in the decision record, creating a continuous improvement cycle.</p>
I often use my home projects as playgrounds to experiment with new ideas, technologies, and methodologies I want to try out because they're new to me or because I want to confirm they're still useful. This is why most of my home projects serve two purposes: build the thing and apply what I think are best practices.</p>
In this particular project, I felt the need to create decision records. They aren't necessarily architecture related decisions but more decisions I'd like to document to remember why I went this way. I mainly make use of the markdown format of ADRs to document my decisions.</p>
Generally speaking, this is mostly an experiment at the moment. I'm trying this out in the setting of personal projects, but I think it may lower the bar for writing decision records in general. Not everyone wants to go to great lengths to record decisions, even if they see the value. Personally, I think it doesn't need to take a lot of time to document a decision, yet I often end up spending much more time on it than I anticipated or hoped for when I started writing one.</p>
Here</a> is a decision record example for those interested. It is written by an LLM mostly. I know this may be controversial, but it is also useful. I do not think this is 'AI slop', if you review it and it all makes sense, I don't see much need for a complete rewrite. Having a documented decision is worth more than not documenting because it was written by AI. I haven't tried this in a team or organisational setting, but I'm curious to see how it works out and how people would feel about it. In any case, whoever created the decision record with help of an AI is always responsible for the decision and its recording.</p>
Also, "working with an LLM replaces thinking" is an often heard argument. I agree and it's a reason for concern for me too, the impact on my own thinking. But an LLM also comes up with good ideas. It is easy and tempting to simply accept what's there. Maybe not all decisions require deep thinking though, and we just want to note down why we're doing the thing we're doing this way.</p>
I am also thinking it may be useful to add to the decision record to what extent an LLM was used to generate the content. Firstly it will get it out of the way when people are suspicious of AI being used and to what extent. I think this is comparable to time or other constraints one has when writing ADRs or decision records in general: this may be worthwhile to document too. Sometimes there is not enough time to think deeply about the decision or consider more options and you have to make a decision with quite some unknowns. In these cases I recommend documenting this in the decision record too.</p>
Finally, there are quite some interesting things that can be done next. When working with Claude Code, if you would create decision records more often it makes sense to create a command to use as 'saved prompt'. I actually created an agent for this as well (to try out agents mostly, I admit).</p>
I've written about ADRs before, if you want to read more about them:</p>


Less Mentioned Benefits of Architecture Decision Records</a></p>
</li>

Ground Your ADRs with a Verification Section</a></p>
</li>
</ul>
Thank you for reading, Hans</p>


Output Styles in Claude Code
2025-08-22T00:00:00+00:00
Claude Code's output styles control how the AI responds to your requests. This summary covers the built-in styles and when to use each one.</p>

TLDR:</strong> Output styles = stored system prompts that change Claude's behaviour. Slash commands = stored user prompts for quick actions.</p>
</blockquote>
Use the 'default' style for classic coding, 'Explanatory' for learning, 'Learning' for hands-on practice, and create custom styles as needed to match your workflow or creative needs (start from the default system prompt for inspiration).</p>

Note:</strong> Requires Claude Code version 1.0.81 or later</p>
</blockquote>
Default and Built-in Output Styles</h2>


Default Output Style</strong></p>


Purpose: Optimized for software engineering tasks.</p>
</li>

Features: Includes system prompt instructions for concise code generation, automatic code verification, and test integration.</p>
</li>

Context: This is the initial state, designed for efficient programming workflows.</p>
</li>
</ul>
</li>

Explanatory Output Style</strong></p>


Purpose: Adds educational value and explanations to its software engineering help.</p>
</li>

Example: When planning a project, it might explain why it's choosing one database over another, or the reasoning behind selecting a store over React context.</p>
</li>

Best for: If you want to enhance your learning while coding or need insight into design decisions.</p>
</li>
</ul>
</li>

Learning Output Style</strong></p>


Purpose: Mimics a pair-programming experience to help you learn by doing.</p>
</li>

Features:</p>


Provides code insights as you go.</p>
</li>

Assigns you small, strategic coding tasks (adds "to-do human" items).</p>
</li>

Checks your work and offers feedback or explanations based on your solutions.</p>
</li>
</ul>
</li>

Best for: Developers who want to upskill or learn new patterns interactively.</p>
</li>
</ul>
</li>
</ol>
Custom Output Styles</h2>


You can create your own Output Style.</p>
</li>

Behind the scenes: Claude generates a new output-style file and modifies the system prompt accordingly.</p>
</li>

Impact: Output styles are tightly coupled to the system prompt, so customisations can drastically change behaviour. Switching to a non-default output style removes software-engineering–specific logic from the system prompt.</strong></em> This potentially reduces coding efficiency but broadens capability in other domains (research, creative writing, etc.).</p>
</li>
</ul>
Put differently: output styles introduce the ability to change the _system prompt_ which can be very powerful! Here is an example where I change the behaviour with respect to Claude Code's commit behaviour.</p>
How to Use & Select Output Styles</h2>


Use the CLI to create/select/explore output styles (output-style:new</code>, then select from available styles).</p>
</li>

Output styles can be selected per session or per project as needed.</p>
</li>
</ul>
Advanced Tips</h2>


Output style selection is part of a broader "system prompt + user message" structure.</p>
</li>

You can further manipulate prompts using --append-system-prompt</code> to add final adjustments to the behaviour.</p>
</li>

For customisation, consider starting from the default system prompt (you can use Claude tracing for this but here is the default system prompt of Claude Code 1.0.85</a>).</p>
</li>
</ul>
Further Resources</h2>


Ray Amjad's Youtube video</a></p>
</li>

Anthropic Output Styles documentation</a></p>
</li>
</ul>


Examples of using Claude Code's output styles
2025-08-22T00:00:00+00:00
A very short post on Claude Code's new output styles</a> feature which I have been experimenting with in the past days.</p>
Here are some actual examples of how you can leverage output styles to change 'hard-configured' Claude Code behaviour:</p>


Remove Claude Code branding from commit messages</a></p>
</li>

Use Jujutsu with Claude Code</a></p>
</li>
</ul>
Thanks for reading,</p>
Hans</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>


Remove Claude Code branding from commit messages using output styles
2025-08-22T00:00:00+00:00
When Claude Code creates git commits for you, it automatically adds its own signature to every commit message, including a promotional link and co-author attribution. Personally I think this is pretty annoying but especially for professional work or team repositories you may prefer cleaner commit messages.</p>
By default, Claude Code adds these lines to every commit:</p>
🤖</span> Generated with </span>[</span>Claude Code</span>]</span>(https://claude.ai/code)
</span>
</span>Co-Authored-By:</span> Claude <noreply@anthropic.com>
</span></code></pre>
Fortunately, since version 1.0.81, Claude Code supports 'output styles'</a> (here is my own summary</a>). Output styles are configuration files that allow you to customise Claude Code's behaviour by modifying its system prompt (the internal instructions that control how Claude responds).</p>
This feature allows us to remove Claude Code's behaviour of adding itself to every commit message.</p>
Creating the Custom Output Style</h2>


Start claude</code>.</p>
</li>

Create a new output-style using the /output-style:new</code> command. Name it, I used no-claude-in-commit-msg</code>.</p>
</li>

Complete the creation wizard. The initial content you enter doesn't matter since we'll replace it entirely in the next step.</p>
</li>
</ol>
Configuring the System Prompt</h2>


Locate the new output style file. Look for a .md</code> file with your chosen name in the .claude/output-styles/</code> directory (either in your project folder or home directory) and open it in your text editor.</p>
</li>

Replace the entire file content with a modified system prompt that excludes commit message branding. You have two options:</p>


Manual approach</strong>: Find the system prompt yourself to remove Claude Code references</p>
</li>

Ready-to-use version</strong>: Use my version based on the system prompt of Claude Code 1.0.85</a></p>
</li>
</ul>
If you're curious about the changes, view the diff</a> showing exactly which lines were removed to eliminate Claude Code self-references in commits and pull requests.</p>
</li>

Save the file.</p>
</li>

In claude</code>: /output-style</code> should now show the updated style.</p>
</li>
</ol>
Testing the Changes</h2>
Now let's verify that our custom output style works as expected:</p>
Before: Default Output Style</h3>
First, let's see what happens with the default output style:</p>
> /output-style
</span>  </span>⎿</span>  Set output style to default
</span>
</span>> commit </span>changes
</span>╭───────────────
</span>│</span> Bash command            
</span>│                         
</span>│</span>   git commit</span> -m </span>"</span>chore(claude): Add default output 
</span>│   style configuration                              
</span>│                                                    
</span>│   🤖 Generated with [Claude Code](https://claude.ai/code)
</span>│                                                    
</span>│   Co-Authored-By: Claude <noreply@anthropic.com></span>"  
</span>╰───────────────
</span></code></pre>
Notice the Claude Code branding and co-author attribution in the commit message.</p>
After: Custom Output Style</h3>
Now let's switch to our custom output style and try the same operation:</p>
> /output-style
</span>  </span>⎿</span>  Set output style to '</span>no-claude-in-commit-msg</span>'
</span>
</span>> commit </span>changes
</span>╭───────────────
</span>│</span> Bash command            
</span>│                         
</span>│</span>   git commit</span> -m </span>"</span>chore(claude): set output style
</span>│   to no-claude-in-commit-msg</span>"                   
</span>╰───────────────
</span></code></pre>
Nice! The commit message is now clean, containing only the actual commit description without any Claude Code references.</p>
Conclusion</h2>
You've successfully customised Claude Code to remove its self-referential branding from commit messages. Your git history will now be cleaner and more professional, containing only the essential commit information without promotional content.</p>
For more details on output styles, check the official documentation</a> or my own summary</a>.</p>

HanLHo. - Fractional Architect & Software Product Engineer - claude-code

Agent Chisels: My LLM Agent Skills and Workflows

Implementing an Urgent Feature with Opencode, Claude, and Zed

Grounded decision records from AI conversations

Output Styles in Claude Code

Default and Built-in Output Styles</h2> Default Output Style</strong></p>

Examples of using Claude Code's output styles

How to Use Jujutsu (jj) with Claude Code

Important Considerations</h2>

Missing Git Features</h3> When you override Claude Code's Git behaviour, you lose may some built-in safety features:</p>

Summary</h2> To integrate Jujutsu workflows in Claude Code, but these three solutions exist:</p>

Remove Claude Code branding from commit messages using output styles