wohlford/dotclaude

Global Claude Code configuration: style standards, development workflows, custom skills, agents, and hooks.
Installation
This repo is symlinked into ~/.claude rather than cloned over it, so the checkout stays the source of truth. Clone it anywhere, then run the installer:
install.sh symlinks this repo's tracked root entries into ~/.claude. The membership is **derived, not hand-listed** — everything tracked at the root except a declared exclusion list (the dotfiles, ruff.toml, and git-hooks/, which are consumed by tooling running inside this repo rather than by Claude Code). So a document added here appears in ~/.claude on the next run, with no list to update. Anything already present is backed up first, and backups are stripped of their exec bit.
settings.json **is** linked. Claude Code rewrites it at runtime, and the live clone marks it skip-worktree so those rewrites never surface as repository changes.
The installer records which clone owns the farm in ~/.claude/.installed-from. That marker lives only in the target — it is never tracked here and is never a farm member — and it is what lets a later run tell "this farm belongs to another clone" from "this is a first install", whether the managed paths are symlinks or ordinary files.
Two flags: --check reports drift and changes nothing (non-zero exit when the farm has drifted); --rewire authorizes repointing a farm that another clone owns, and updates the marker. The script refuses to run from inside ~/.claude itself — running a stray copy from there would relink every managed path to itself.
Restart Claude Code after installing (or after pulling updates) to reload the configuration.
Wondering how the pieces fit — what takes effect where, and what owns what? See ARCHITECTURE.md.
What's Included
Documentation
| File | Purpose |
|------|---------|
| CLAUDE.md | Global instructions loaded into every Claude Code session |
| CONTRIBUTING.md | Commit-message and semantic-versioning conventions for contributors |
| STYLE.md | Code style and formatting standards (Bash, Python, JS, YAML, JSON, Markdown) |
| templates.md | Starter templates for Bash scripts, Python modules, and JavaScript |
| workflows.md | Development workflows — the /feature pipeline, with Explore/Plan/Code/Commit and TDD as primitives |
| ARCHITECTURE.md | How this repo fits together — enforcement mesh, staging→propagate lifecycle, source-of-truth map |
| TESTING.md | Test layout and conventions (pytest suites, fixture-repo factories, harness style) |
| DELEGATING.md | Constraints a delegated subagent must observe — the block to paste into each dispatch |
Skills (Slash Commands)
| Command | Purpose |
| :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| /audit | Run the mechanical compliance sweep — linters, format, link, exec-bit, and config-validity checks over a repo's tracked files; repos exclude generated paths via .auditignore. Mechanical only — the test suite is a SEPARATE requirement and runs only under --tests, so a plain PASS is never evidence the suite passed |
| /commit | Create a git commit with automatic semver tagging following STYLE.md conventions; signing and identity follow git config |
| /debrief | Run the end-of-session pre-compaction routine (deferral follow-up, CLAUDE.md refresh, memory save, automation review, and deferred design) |
| /feature | Run the methodical, risk-tiered pipeline for a change (triage → spec → spike → plan → reviews), then continue through subagent-driven execution to an integrated change; --plan-only stops at the reviewed plan |