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.

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

Skills

I have shared two skills 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.

  • documenting-architectural-decisions: 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 is the one for the jj plugin.

I use jj or Jujutsu, 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 and one to add the capability of using jj. The Claude Code plugin also adds a use-jj command and a hook to remind an LLM of using jj.

  • detecting-jujutsu — Verify if the current repository uses Jujutsu (jj) instead of git. Used when confirming VCS state before operations.
  • using-jujutsu — Detailed guidance on Jujutsu (jj) VCS operations including committing, pushing, searching history, and working with revisions/revsets.

And finally, there is the meta-skill to evaluate skills. Here is an example of a report generated by this skill.

  • evaluating-skills — 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.

To use these, you can use the Claude Code plugin system or install them manually; take a look at the installation section for more details.

A little on the setup of the repository

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.

All skills I share in this repo are dynamically linked to my ~/.claude/skills directory. Note that this is also the easiest way to make these skills available to other LLM CLI agents like Opencode, Codex, and Mistral Vibe. In this repo, I have mostly worked with Opencode and the skills in the .claude location just work with it.

❯ ls -l .claude/skills
l... detecting-jujutsu -> ../../skills/detecting-jujutsu
l... documenting-architectural-decisions -> ../../skills/documenting-architectural-decisions
l... evaluating-skills -> ../../skills/evaluating-skills
l... using-jujutsu -> ../../skills/using-jujutsu
d... verify-release-readiness

The l 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.

Future plans

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 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.

Related to this, I am thinking of creating a setup similar to dotfiles (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.