Releases: DazzleML/dazzle-claude-code-config
Release list
v0.4.7 - The Key: Footer Convention (codes, acronyms, and jargon)
dazzle-claude-code-config v0.4.7
A public collection of Claude Code skills, commands, agents, and settings templates — a ready-made payload repo to point ccs at, or to fork as your own.
Two documentation releases in one: v0.4.6 was tagged internally but never published, so its change ships here alongside v0.4.7.
What's new
The Key: footer convention (v0.4.7)
dotclaude/CLAUDE.md gains a "Shorthand codes: where they belong, and the Key: footer" section under Git & GitHub Conventions.
Every project accumulates private vocabulary that reads as precise to its maintainers and as noise to everyone else. The section names three families of it, and gives one test that covers all three:
- Shorthand codes — acceptance-check IDs, slice labels, decision IDs.
- Project acronyms and tool nicknames — more dangerous than numbered codes, because an acronym looks like an ordinary word and a reader may never notice they've missed something.
- Repurposed jargon — ordinary words carrying project-specific meaning. The easiest to miss, since nothing about them looks like shorthand.
The test: would a competent engineer, new to the project and holding none of its private docs, know what this means? If it's coined-here or repurposed-here, it needs a key. Industry-standard terms (CI, PR, API, JSON) are exempt — keying those is noise, and a rule that keys everything gets ignored.
Then the part with teeth — the audience split:
| Audience | Codes? |
|---|---|
| Commit messages, design docs, issues | Yes — they carry exact traceability |
| Checklists shipped to external testers | Yes, but with a legend table defining every code used |
| CHANGELOG, README, release notes, CLI output | No — spell the guarantee out plainly |
Plus the Key: block format, and why the defining-doc citation is mandatory even when a code is glossed inline: the gloss is itself compressed, and codes recur across a project's life, so the citation is the only reliable path back to what one meant.
This was written from a mistake rather than from theory. A sibling project shipped a user-facing CHANGELOG describing fixes in terms of internal acceptance-check IDs — precise for its maintainers, undecodable for everyone who actually reads changelogs.
Statusline callout (v0.4.6, previously unreleased)
The context-percentage statusline gets a visible callout in the README inventory, instead of being buried in the settings section.
Using this collection
pip install dazzle-claude-config
git clone https://github.com/DazzleML/dazzle-claude-code-config ~/claude/dazzle-config
ccs diff --checkout-dir ~/claude/dazzle-config # look first
ccs apply --only dotclaude/skills --checkout-dir ~/claude/dazzle-config # take a slice
ccs apply --checkout-dir ~/claude/dazzle-config # or the lotapply merges into your live config rather than replacing it, backs up anything it overwrites, and treats CLAUDE.md as seed-if-absent — your own memory file is never clobbered. Fork it if you want to build on it; it's designed to be forked.
What's inside
14 skills, 29 commands, 12 agents, a hook, scripts, a settings template set, and a curated global CLAUDE.md — covering structured design analysis, postmortems, human test checklists, multi-agent consultation, and GitHub workflow conventions.
Version History (0.4.x)
| Version | Key Change |
|---|---|
| v0.4.7 | Current — the Key: footer convention for codes, acronyms, and jargon |
| v0.4.6 | Statusline callout in the README inventory (tag only — published with v0.4.7) |
| v0.4.5 | Memory-import orchestrator, setup guide, contributor surface |
| v0.4.0 | The maximal public collection |
Requirements
Nothing to install for the collection itself — it's configuration. To sync it into your live config, ccs needs Python 3.10+ and git.
v0.4.5 - Memory-import orchestrator, setup guide, contributor surface
dazzle-claude-code-config v0.4.5
A curated, working set of Claude Code skills, commands, and agents -- a live ccs payload repo you can fork as your own config home -- and, as of this release, adoptable end-to-end: an orchestrating CLAUDE.md you never have to edit, a five-step install, and the full setup walk.
The 0.4.x series is the "make it adoptable" wave on top of v0.4.0 (the maximal collection: 14 skills / 28 commands / 11 agents). Content is stable; docs and adoption mechanics moved fast this series.
What's New in 0.4.x
The orchestrator imports your personal sections (v0.4.1)
Born from a real drift problem: the global CLAUDE.md originally asked adopters to edit [FILL IN] sections in place -- which forks the shared file and turns every upstream pull into a merge conflict. Now the personal sections are Claude Code memory imports:
@~/claude/claude-config/environment.md
@~/claude/claude-config/projects.md
@~/claude/claude-config/task-rules.md
ccs apply seeds all three with starter templates (never overwriting existing files -- seed-if-absent), your details live in user territory where no sync or upgrade touches them, and the shared CLAUDE.md stays byte-identical to upstream forever. Verified on a pristine fixture: one ccs apply lands the orchestrator plus all three seeds, and a second apply reports nothing to do.
Also in v0.4.1: python scripts/install-hooks.py -- the guard-hook installer now runs identically from cmd, PowerShell, or any POSIX shell.
Install quickstart + the exhaustive setup guide (v0.4.3)
The README now opens with the whole install in five steps:
pip install dazzle-claude-config
git clone <your-fork-or-this-repo> ~/claude/dazzle-claude-code-config-public
ccs apply --checkout-dir ~/claude/dazzle-claude-code-config-public
# then: edit the seeded ~/claude/claude-config/*.md and set CLAUDE_CODE_ROOTSand docs/setup.md is the exhaustive walk: Claude Code install, fork-vs-consume, what ccs apply actually does, personalization, the companion DazzleML plugins (session-logger, claude-session-backup with csb setup), hooks, verification, multi-machine rollout, and troubleshooting seeded with real failure modes. docs/customization.md is the companion checklist of every directory, env var, and placeholder that expects your values.
Contributor surface + docs truth-ups (v0.4.2 / v0.4.4 / v0.4.5)
CONTRIBUTING.md (ground rules for a config collection: no personal content, cross-platform conventions, the guard hooks, VERSION/CHANGELOG lockstep), docs/platforms.md + Platform badge, the standard footer, docs-index corrections, and the PAL MCP (aka Zen MCP) rename.
Installation
See the quickstart above, or fork first (recommended) so the repo becomes your payload: the manifest, guards, and hook installer travel with the fork. Pairs with ccs v0.2.0, which also accepts any bare ~/.claude mirror as a payload -- not just this layout.
Version History (0.4.x)
| Version | Key Change |
|---|---|
| v0.4.5 | Current -- README wording pass, PAL MCP rename |
| v0.4.4 | CONTRIBUTING, platforms doc + badge, house footer |
| v0.4.3 | Install quickstart + exhaustive docs/setup.md |
| v0.4.2 | docs index truth-up |
| v0.4.1 | Memory-import orchestrator, cross-platform hook installer |
| v0.4.0 | The maximal collection -- first release |
Earlier: v0.1.0-v0.3.0 (seed through settings/docs waves) -- see the CHANGELOG.
Platform Support
| Platform | Status |
|---|---|
| Windows 10/11 | Tested (primary dev; Git Bash for shell scripts, Python installer for hooks) |
| Linux / macOS / BSD | Expected to work (markdown-first content; POSIX-native scripts) |
Details: docs/platforms.md
Requirements
- Claude Code
- git; Python 3.10+ (for ccs and the hook installer)
- Optional: node (Bash-guard hook + statusline),
ghCLI (GitHub workflow commands), dazzlecmd
Validation: every published file passed personal-marker sweeps plus independent adversarial content review; the install path is verified by pristine-fixture ccs apply runs (idempotency included); pushes go through a credential-scanning guard that travels with forks.
v0.4.0 - The maximal public collection
The first release of the public Claude Code config collection — deliberately maximal: everything the disclosure audit permits, in one working payload.
The big idea: configuration sets should be as easy to share, load in, and swap out as tools are in dazzlecmd. Fork this repo, point ccs at it, layer your private overlay on top.
What's in v0.4.0
- The orchestrator:
dotclaude/CLAUDE.md— a curated global memory file with [FILL IN] invitation sections for your machines/layout/integrations (applied seed-if-absent; never overwrites yours) - 14 skills / 28 commands / 11 agents / 1 enforcement hook — the full workflow: orient → design → verify → gate → commit → ship → reflect (see docs/workflow.md)
- Settings templates (battle-tested permission lists, templated hooks/statusline) and async research scripts
- Docs: workflow guide with mermaid lifecycle, project-structure conventions (the private/ vault, the dazzlecmd-first graduation path), and the make-it-yours customization checklist
- Guards that travel with forks: pre-push credential scanning + VERSION/CHANGELOG lockstep (
sh scripts/install-hooks.sh); personal marker lists stay in an untracked local file by design - Vendored git-repokit-common at
scripts/repokit-common/
Every published file passed marker scans plus independent adversarial content review. Full inventory and history in the CHANGELOG.