Christoffer Niska cniska

My tools for coding agents

Christoffer Niska (@cniska)

I do all my engineering with AI coding agents. Over time I kept hitting the same five problems, so I built a tool for each:

agent-skills: agents didn't build things the way I would.
agent-record: agents forgot what we had decided.
agent-gates: agents slipped shortcuts past review.
agent-worktree: agents working side by side got in each other's way.

Global Conventions

Conventions that hold across every repo. A project's own AGENTS.md or CLAUDE.md wins where it differs.

Comments

The best documentation is the code itself. Good code carries the what and the how, so a comment carries only the why — and since it breaks the flow of reading and shrinks the logic visible at once, it has to earn that cost back. Three shapes do:

A block comment for why something must be done this particular way: the constraint that forced it, the browser quirk it avoids, the approach that was tried and does not work, the external contract being satisfied.
A one-line docblock saying what a function does and why. No argument or return annotations.

My Workflow

TL;DR: AI coding agents now handle most of my implementation work. Powerful models make difficult decisions, balanced models handle normal implementation, and fast models take care of bounded changes. Skills carry workflow pathing, repository context, handoffs, and evidence thresholds between sessions. Delegated review speeds up personal projects, while work still gets the manual review it requires. Acolyte is my attempt to own that workflow instead of adapting it to one vendor's tool.

The workflow

A repeatable loop

I use Claude Code in the terminal almost every day at work, with Codex and OpenCode as additional coding agents. I also use them while building Acolyte, my own terminal-first coding agent, and other products where AI is a core part of the development loop. AI does most of the implementation. I direct, inspect, and v

name	handoff
description	Write forward-looking startup instructions for the next session, then reset context to save costs. Use when the context is getting long or before switching focus.

Handoff

Write the opening instructions your next session needs to pick up the work. The next session is a cold agent: same tools and checkout, zero memory of this one — its only input is this document. Every handoff is a briefing for a stranger, so it's a work order, not a report: it says what to do next, not what happened. There is no "we," nothing "we decided," no "where we left off" — if a line only makes sense to someone who was here, cut it. Size it to the next move, not to the session — a one-file fix earns a ten-line handoff, however long the session was.

One variable: does the reader already share this project? If yes, pointers can be bare paths and ticket IDs. If not (a teammate, a different context), strip originating-project assumptions and spell out where things live.

Coding Agent Landscape

Updated July 2026

Open Source

Agent	Category	Lang	License	Notes

	#!/usr/bin/env bash
	# Mechanical integrity scan for the file-based memory store. Prints PASS / WARN /
	# FAIL per check: malformed name: slugs, missing descriptions,
	# dead cross-links, orphaned files (present but not in the MEMORY.md index, so they
	# never load), index entries pointing at a missing file, and past dates worth
	# re-checking. Exits non-zero only when an index reference is genuinely broken;
	# WARNs do not fail the run. The judgment calls (stale state, contradictions) still
	# need an agent pass — this only covers what a script can prove.
	# No color: the consumer is an agent reading the output, not a terminal.
	set -uo pipefail

	#!/usr/bin/env bash
	# wt — one task, one worktree.
	#
	# Convention: task worktrees live at <repo>/.claude/worktrees/<branch>, the same
	# path Claude Code's EnterWorktree and a manual `git worktree add` use. wt makes
	# the checkout and prints where it is; opening a terminal there and starting an
	# agent is the caller's job.
	#
	# On fresh creation, wt runs an optional repo hook — scripts/worktree-setup.sh —
	# so a new worktree arrives with dependencies installed. The hook is opt-in per

	#!/usr/bin/env bash
	# Claude Code statusline: dir[/subdir] · worktree · branch[*↑↓] · model[↓] effort · pct%/size · $cur[ $tot] · ↑tok-in ↓tok-out
	# dir is the repo name (cwd basename if not a repo); subdir/worktree/branch are optional.
	# In a repo, if cwd is below the working-tree root, the cwd basename rides dim on dir (proj/subdir).
	# The three fold left to right: a name already shown drops.
	# Input: JSON on stdin (see https://docs.claude.com/en/docs/claude-code/statusline)
	#
	# One function per segment, each reading the parsed globals and echoing its rendered
	# string (empty when there's nothing to show). main parses stdin, then joins the
	# non-empty segments. Sourcing the script (the test suite) defines the helpers and

	import { type EffectCallback, useEffect, useRef } from "react";

	/**
	* Run an effect exactly once on mount. This is the only sanctioned way to
	* call `useEffect` in chat-layer code — prefer derived state, event handlers,
	* or render-time adjustments for everything else.
	*/
	export function useMountEffect(effect: EffectCallback): void {
	const effectRef = useRef(effect);
	effectRef.current = effect;

	#!/usr/bin/env bash
	set -euo pipefail

	# Validate a commit message against project conventions.
	# Usage: check-commit-message.sh <subject> [body]
	#
	# Rules:
	# - Conventional Commit format: type(scope): description
	# - Allowed types: feat, fix, refactor, docs, test, chore
	# - Single-line subject, no body