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.