cc-praxis — Day Zero: The First Nine Skills
Date: 2026-03-29 Type: day-zero
Every Claude Code session starts cold. I’d explain my Java conventions, re-establish context, re-teach things Claude had learned three conversations ago. The knowledge was ephemeral — useful in the moment, gone immediately after.
Claude Code has a skills mechanism for exactly this. Skills are Markdown files with YAML frontmatter that trigger on specific conditions. When the condition fires, the skill loads automatically and Claude has the full workflow.
What I was trying to achieve: Teaching Claude to remember
I wanted Claude to just know my conventions at session start. Not re-learn. Not be told. Know.
The specific domains: how I like commits structured, code review in Quarkus, Maven BOM dependency management, observability configuration. All of it encoded once, available forever.
What I believed going in: Mostly a writing problem
I knew what I wanted Claude to do in each context. I just needed to write those workflows down in a format it could load and follow.
I expected the main challenge to be getting the descriptions right — the YAML frontmatter that determines when a skill triggers. Too vague and the skill loads constantly, wasting context. Too narrow and it never loads when you need it.
What I didn’t appreciate was how much discipline the structure itself would require — cross-referencing, consistency, preventing skills from drifting apart. That became a bigger concern than I expected.
The first nine
Nine skills, all Java and Quarkus, committed in a single shot: java-dev, java-git-commit, adr, quarkus-flow-dev, update-design, code-review, dependency-update, logging-observability, and a .gitignore. 1,625 lines of Markdown.
quarkus-flow-dev was the longest — around 350 lines encoding hard-won knowledge about the FuncDSL API, workflow patterns, and testing approaches. That skill alone made the whole project worthwhile. It captured things that had taken months to figure out.
What changed immediately: Everything about structure
Within days, almost everything about the structure changed, even though the underlying content didn’t.
CSO (Claude Search Optimization) — the description field must say when to trigger, not what the skill does. If it summarises the workflow, Claude might follow the description instead of reading the full skill.
Cross-references — skills that invoke each other need to say so in both directions. I’d written them in isolation.
Naming — the originals were generic (code-review, dependency-update). They became language-prefixed where appropriate, with generic principle skills for the rest.
Diagrams — I’d used GraphViz dot notation. Claude Code renders Mermaid natively. Everything had to be converted.
These weren’t mistakes exactly. They were things I hadn’t known to think about. The skills worked. They just weren’t as good as they could be.
The discipline is the work
The content — Java conventions, commit format, code review checklist — was mostly already in my head. Getting it into a format that Claude loads reliably, with everything pointing to everything else correctly, that’s the real work.
Nine skills felt comprehensive at the time. Within a week it would be over forty.