HanLHo. - Fractional Architect & Software Product Engineer - opencode

Combining agent skills

2026-02-26T00:00:00+00:00

A short post on combining skills. It's not always clear when a skill will be called or triggered. The easiest way is to put instructions and directly invoke the skill you want by name.</p>

For example, for my Today I Learned mini blog site</a>, I have two skills to keep my TILs focussed and concise. One skill evaluates that my text is concise and utilitarian, which is what I expect or aim for in a TIL. And I have a more general skill that I also apply for this blog that creates the text according to UK English 'as done by an English teacher'.</p>

To combine both, I have the review-til</code> skill that invokes both and specifies the output:</p>

Review the provided TIL file or text by running both checks in parallel:
</span>
</span>1. </span>**TIL Rules Check**</span>: Invoke the </span>`til-rules-checker`</span> skill to verify content guidelines (word count, focus, clarity, format)
</span>
</span>2. </span>**Text Grading**</span>: Invoke the </span>`text-grader`</span> skill to assess spelling, grammar, and clarity using UK English standards
</span>
</span>After both checks complete, provide a unified summary with:
</span>- TIL rules verdict (PASS/NEEDS REVISION)
</span>- Text grade (A/B/C/D/F)
</span>- Combined list of actionable improvements (if any)
</span>
</span>If a file path is provided as an argument, read that file first. If text is provided directly, use that text.
</span></code></pre>
Note both Invoke the '...'</code> instructions.</p>
This works in Codex and Opencode. When I asked to review two TILs at once (Review both non-committed TILs</code>) the result looks like this:</p>
  </span>Review</span> summary:
</span>
</span>  </span>-</span> beads-query-default-limit.md
</span>      </span>-</span> Word count: 32
</span>      </span>-</span> TIL rules: PASS (focused, clear, non-blog style, utilitarian)
</span>      </span>-</span> Text grade: A (96%)
</span>  </span>-</span> beads-query-subcommand.md
</span>      </span>-</span> Word count: 55
</span>      </span>-</span> TIL rules: PASS (focused, clear intent, non-blog style, utilitarian)
</span>      </span>-</span> Text grade: B (84%) </span>due</span> to grammar issues (hard cap applied)
</span></code></pre>
(The reason for the B</code> grade is also detailed in the full output.)</p>
In case you are interested, these are the skills I have currently published online:</p>

check-til-rules</a>: This is the skill that has my TIL rules.</li>
review-til</a>: The skill I usually invoke that combines the two skills. The content at the time of writing, aside from the frontmatter, is above.</li>
</ul>



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>


My agentic coding stack for October 2025
2025-10-05T00:00:00+00:00
After wrapping my head around the constant changes in LLM subscriptions and performance, here's my new coding stack for October 2025:</p>
Warp Pro</strong>: my go-to agentic CLI, speedy and reliable for coding and task automation. Supports most top end LLMs.</p>
Zed Pro</strong> (using the $20 trial, then €10/month)</p>
OpenCode</strong> for agentic CLI dev (local + cloud models, easy swapping, no lock-in)</p>
I dropped Claude Code and did not subscribe to Codex. If this turns out to be a bad idea, I can always resubscribe again.</p>
My main decision influences: cost control, flexibility and avoiding vendor lock-in (Claude Code's past month changes have this effect).</p>
After spending a few months in the CLI I want to look again at working more in an IDE, hence Zed is on this list.</p>
Note: I do not subscribe to Max plans, I combine multiple lower cost plans.</p>