ZacheryGlass .claude: one developer's Claude Code setup in the open

A configuration directory, published as a repository

This repository contains personal configuration settings for Claude Code, which the README describes as an interactive command-line interface that provides AI assistance for software development tasks.

The framing matters. It is not a plugin, a framework or a distribution of anything. It is one person's working directory for the tool, published so that other people can read it, borrow from it, or run it as-is.

The contents are grouped by the mechanism they use in Claude Code. `settings.json` is the core configuration file, holding permission settings for various tools and commands plus custom hooks. `CLAUDE.md` holds minimal agent instructions. `hooks/` holds pre and post-tool-use scripts, and three of them are named in the README: `emoji_remover.py`, described as a post-edit hook to ensure no emojis are used, `github_issue_guard.py`, a guard for GitHub issue interactions, and `protect_claude_md.py`, protection for critical configuration files.

Then `skills/`, `commands/` and `agents/`, which are the three extension points the tool exposes, and the README links the official documentation for each of them: Agent Skills, Slash Commands and Sub-agents.

The top level also holds a `sync-docs.py` documentation synchronisation utility, a `plugins/` directory, and a `tests/` directory, along with the Go module file for the status line:

module statusline

go 1.23.4

The repository is not archived, the default branch is master, and the last push was on 2026-07-05. There are no GitHub releases and no licence is recorded for the repository, which is the one legal loose end in an otherwise openly licensed ecosystem.

Skills, commands and agents are three different extension points

The README lists the three extension mechanisms separately, and the distinction between them is the thing to take away.

Skills are reusable agent skills. Five are named. `arewedone-g` runs a structural completeness review through the Gemini CLI to offload token-heavy review work. `gemini-agent` delegates arbitrary tasks to the Gemini CLI for a second opinion or for token savings. `parallel-phases` is the most involved: an end-to-end orchestrator for multi-task parallel work, where a setup phase gathers code intelligence, analyses merge-conflict risks and groups tasks into maximally-parallel phases, then writes enriched self-contained agent prompts, and after an explicit approval gate the execution phase dispatches Opus agents in worktrees with a per-task three-reviewer gauntlet, auto-fix commits, phase merge and test gates, and a documentation update agent at completion. `root-cause-tracing` traces a bug backward through the call stack, adding instrumentation as needed, to find the original trigger. `skill-creator` scaffolds and refines new skills following the official skill authoring guidelines.

Slash commands are user-invoked. Seven are named: `/arch-review` for reviewing architecture of specified paths or staged and unstaged git changes, `/arewedone` for a structural completeness review on recent changes, `/bugs` to invoke the bug-finder agent, `/commit` to draft a conventional commit from the current staged or unstaged diff, `/docs` to run the documentation review and implementation workflow, `/perf-check` to invoke the performance-profiler agent, and `/ui-review` to invoke the ui-ux-consultant agent.

Sub-agents are invoked via the Task tool, and ten are listed with clear roles: architecture-reviewer for structural integrity, scalability and long-term maintainability, bug-finder for logical errors, race conditions and unhandled edge cases, doc-implementer and doc-reviewer as a pair, git-cherry-pick-orchestrator for cherry-picks across repositories with submodules via a plan-then-execute workflow, github-issue-creator, performance-profiler for desktop apps, structural-completeness-reviewer, test-runner, and ui-ux-consultant.

The pattern is a review-and-fix pipeline expressed in configuration. A command starts a review, a sub-agent performs it, another sub-agent implements the findings, and a documentation agent closes the loop.

The status line and why it is written in Go

The status line is the part of this repository that other people are most likely to take wholesale, and it is the part with the most engineering in it.

`statusline.exe` and `statusline.go` are a small Go binary that runs every second and renders a status bar. All data is cached to disk so git and file reads only happen when something actually changes. That single design decision is what makes a once-per-second refresh affordable: the expensive operations are amortised behind a cache, so the steady-state cost is a JSON parse and a redraw.

The README measures this over 20 runs each on Windows 11, with the benchmark script at `tests/bench.ps1`. A fully warm run with all caches hit has a median of 16ms, described as a typical tick. A git cache miss that has to exec git has a median of 62ms, and it happens once per 10 minutes per working directory. With no git repository at all the median is 13ms. Pure binary startup is 11ms, described as the floor of process plus JSON parse.

Those numbers are specific enough to be useful and narrow enough to be honest. They are Windows 11 numbers, and the 62ms git miss is the case that would matter on a slow filesystem.

The status bar itself is composed of segments, and the README documents each one. The project segment is the leaf name of `workspace.project_dir`, falling back to `current_dir`. The model segment shows the display name of the active model plus the effort level in parentheses, hidden for Haiku, with the effort read from `settings.json` and cached by file mtime. The prompt cache segment shows cumulative cache read and write tokens for the session, hidden when both are zero. The cache timer counts down 60 minutes from the last API call, shows `Expired` once the window passes and `No Cache` before the first call, resets per model when you switch models, and is reset by `/clear` or `/compact`.

The git segment shows the branch name with a `*` for uncommitted changes, `↑N` and `↓N` for ahead and behind the remote, and `HEAD@<sha>` when detached, only when `current_dir/.git` exists, cached for 10 minutes per directory. The last segment is the percentage of the context window still available, colour-coded green above 50 percent, yellow between 20 and 50, and red below 20.

That last segment is the one to notice. A developer using a coding agent runs out of context window routinely, and seeing it at 20 percent in the status bar is a different experience from discovering it when the tool starts refusing to work.

Prebuilt binaries and two build scripts

The repository commits the compiled status line executables alongside the source. The tree holds `statusline.exe` for Windows, `statusline-darwin-amd64` and `statusline-darwin-arm64` for macOS on both architectures, and `statusline.cmd`, plus the Go source `statusline.go` and the module file naming the module `statusline` and requiring Go 1.23.4.

There are build scripts for both platforms, `build_statusline.ps1` and `build_statusline.sh`, so the executable for a platform that is not prebuilt can be produced from source.

Committing binaries is a choice with clear trade-offs. It means a user on any of those platforms can clone and use the status line without installing Go, which for a configuration repository is a large part of the value. It also means the repository grows with binaries that will not match the source until rebuilt, and that a reviewer has to trust the commit rather than the build.

For the intended use, which is a personal configuration that a person copies into their own `~/.claude/` directory, that trade is probably the right way round. The audience is one person, not a distribution pipeline.

One structural detail from the `parallel-phases` skill deserves a note, because it is the kind of thing that breaks a workflow when it is not understood. Its state lives at `~/.claude/parallel-phases/<project-hash>/`, outside the repository, and the README says the skill is resilient to `/clear`.

Installing a personal configuration into your own machine

The README gives a four step procedure, and it is worth reading before copying anything, because the permissions in `settings.json` are the part with consequences.

The steps are: clone this repository to your local machine, copy the configuration files to your Claude Code settings directory (`~/.claude/`), adjust permissions and settings as needed for your development environment, and restart Claude Code to apply the new configuration.

There is no install command in the README, because there is no package to install. This is a copy operation, and the copy is the whole install.

The step that deserves attention is the third one. `settings.json` contains permission settings for various tools and commands, and those permissions are what allow an agent to run commands, read files and make changes on your machine. Taking someone else's permission set wholesale means granting a set of capabilities that was designed for their environment and their risk tolerance, not yours. The README's own instruction is to adjust them, and it is the correct instruction.

The hooks deserve the same scrutiny for a different reason. `protect_claude_md.py` protects critical configuration files, which is a sensible default. `github_issue_guard.py` guards GitHub issue interactions, and that one has a side effect outside your repository: it changes what the agent can do to issues on a remote server. `emoji_remover.py` strips emojis from edits, which is a house style rather than a correctness rule, and it is the one most likely to surprise someone who did not expect it.

Restarting at the end is necessary because the configuration is read at startup, so the new settings, hooks, skills and commands only exist in the session after the restart.

What this repository is not, and the alternatives

Three limitations are worth stating plainly.

First, it is one person's configuration, and it says so. The README calls it personal configuration settings. The permission set, the agent roster and the slash commands reflect what this developer uses. There is no compatibility promise, no versioned releases and no changelog discipline, and the last push was on 2026-07-05, which means the configuration may already have drifted from what works with the current Claude Code release.

Second, there is no licence recorded for the repository. A configuration directory that other people are invited to copy is legally ambiguous without one, and that is a real limit on how far it can be taken into a work setting.

Third, several of the skills depend on a second tool. `arewedone-g` and `gemini-agent` route work through the Gemini CLI, which is a separate dependency and a separate account, and `parallel-phases` assumes Opus agents and worktrees. Adopting those skills means adopting those assumptions.

The alternative is to write your own configuration from the official documentation, which the README links in full: the overview, settings, Agent Skills, Slash Commands, Sub-agents and the Hooks Guide. The difference in approach is that the official docs tell you what each mechanism does, while this repository shows a coherent set of them working together in one directory. The first gives you the building blocks; the second gives you a floor plan.

A third path is a middle one. Copy the status line, which is self-contained, has its own benchmarks, and depends on nothing else in the repository, and read the rest of the configuration as a reference for what a well-organised `settings.json`, hook set and agent roster look like. That gets the part with the engineering effort in it and leaves the permission decisions, which are the part that should never have been someone else's to make.

Editorial conclusion

Adopt the pieces of ZacheryGlass/.claude that solve a problem you have, in particular the Go status line binary if you want an always-on indicator of model, token cache and git state, and the hook set if you want emoji stripping or file protection on post-edit. Do not adopt it as a product, because the repository is explicitly a personal configuration with no licence recorded, no releases and a last push on 2026-07-05, so there is no stated redistribution terms and no versioned support commitment. Before you copy anything, read settings.json to see which permissions it grants, and check that the status line binary for your platform is present in the tree, since the prebuilt executables are committed alongside the source.

Frequently asked questions

Official sources

1. Issues
2. README
3. ZacheryGlass/.claude on GitHub