Claude Code skills, rules, and language bundles https://git.cjennings.net/rulesets/atom?h=main 2026-06-09T19:15:52+00:00 2026-06-09T19:15:52+00:00 Craig Jennings c@cjennings.net 2026-06-09T19:15:52+00:00 urn:sha1:5bd8247acf4757e0868883ed65d395fec3fb7a0c The skill ran one flat criteria set on every change, so a concurrent, DB-backed service got the same review as a shell script, and the checks that matter for the service (concurrency, performance, auth, API compatibility) weren't in the set at all. Phase 3.5 splits the checks into a universal core that always runs plus nine modules that activate on the project's review profile. A project declares the profile with a "Review profile:" line in its CLAUDE.md. Absent that, the skill auto-detects from framework, ORM, concurrency, and manifest signals and recommends declaring one. The security and dependency modules defer their depth to /security-check. 2026-06-02T18:50:39+00:00 Craig Jennings c@cjennings.net 2026-06-02T18:50:39+00:00 urn:sha1:9bc7e6730f5ca27bdff30089a34bca1e224da9e4 The skill's chat echo (report, criterion table, verdict, draft summaries) was rendering bold and backtick spans as reverse video, which is hard to read in the terminal. Phase 5 now requires plain text for everything echoed to chat, while the artifact posted to GitHub keeps normal markdown. It's the same constraint as interaction.md's no-reverse-video rule, repeated at the print step where the violation actually happens. 2026-05-25T20:11:08+00:00 Craig Jennings c@cjennings.net 2026-05-25T20:11:08+00:00 urn:sha1:a5b955f7c74ad5e27bb73c6d2143359cc66b2455 Voice gains pattern #40: strip the "why" from praise on an approve, since the author already knows why their change is good and the justification reads as flattery. Always keep the why on a finding or change-request, delivered gently. Behavior only changes when the reason lands. review-code now runs a praise/correction gate before posting any summary, and its inline-comment guidance is tightened so the why-it-matters survives the brevity cuts. The reviewer states the stakes (a user hits a 500, a screen reader announces nothing), not just the mechanism. 2026-05-22T23:17:45+00:00 Craig Jennings c@cjennings.net 2026-05-22T23:17:45+00:00 urn:sha1:1e216dd170a46d99ef400ca6bf98f97b23c1db9b Extended the posted-summary voice guidance: a re-review confirming requested changes is just "Approving" plus at most a bare positive. An approve summary must not carry a clause describing what the change does or why it works — that's the banned pattern, since the author already knows the rationale and restating it reads as padding. 2026-05-22T19:07:44+00:00 Craig Jennings c@cjennings.net 2026-05-22T19:07:44+00:00 urn:sha1:5ff5088b0a3978f35b49e35c71add4764697c257 Two clarifications to review-code where it appeared to contradict other rules. The "trust CI, don't run builds" rule read as a blanket license to skip verification. I scoped it to reviewing a diff, not shipping one. A pre-commit or pre-push flow still owes the local verification verification.md requires. Reading a PR doesn't duplicate CI. Producing one doesn't get to skip it. The CLAUDE.md-adherence audit could put a CLAUDE.md citation into a team-visible PR comment, which commits.md says not to do. I added two modes. A private review cites CLAUDE.md directly. A public review translates the rule into the engineering reason and doesn't name the file, since a teammate can act on the reason but not on a file they can't reach. 2026-05-22T18:48:59+00:00 Craig Jennings c@cjennings.net 2026-05-22T18:48:59+00:00 urn:sha1:a4389e8259a68d6e237485f6de4f05c7d1c6cc5d Two related changes to review-code's strengths guidance. The mandatory "three minimum" could force filler on a tiny diff or padded praise on a weak PR, so I relaxed it to up to three specific strengths, with an honest "nothing notable" allowed when the diff doesn't earn them. I also reframed the old "No Strengths section" anti-pattern as "skipping strengths out of laziness": a substantive diff still demands them, a weak one doesn't. The other change tells reviewers to name the good thing and stop, without explaining why it's good. Explaining praise reads as sycophantic since the author already knows the rationale. Elaboration is for findings, not compliments. 2026-05-20T14:47:13+00:00 Craig Jennings c@cjennings.net 2026-05-20T14:47:13+00:00 urn:sha1:b9da9b5142f1d343378e8d4f5aa6780ee8728cd4 review-code was a command with disable-model-invocation set, so the model could never reach for it on its own. Every time a review fit the moment, the agent had to hand back to me to type the slash command. Moving it to a skill makes it model-invocable while it stays slash-invocable as /review-code. git mv keeps the file history (99% rename). The frontmatter drops disable-model-invocation and gains name: review-code; the body is unchanged. It also drops the discovery-check paragraph in commits.md, which only existed to find the command on disk when it was missing from the skills list, moot now that the skill shows up there. 2026-05-06T11:17:08+00:00 Craig Jennings c@cjennings.net 2026-05-06T11:17:08+00:00 urn:sha1:aa6924591127970d3241ab6b1a50f4bab457da27 I converted 16 user-invoked skills to commands. Skills cost ~150-300 tokens each per session for descriptions the model uses to auto-route. Commands cost nothing until you type the slash. These 16 are workflows I always trigger deliberately. The auto-routing wasn't earning its keep. This reclaims ~4-5k tokens per session. Nine skills stayed where auto-routing genuinely helps: debug, root-cause-trace, five-whys, add-tests, frontend-design, humanizer, playwright-js, playwright-py, and pairwise-tests. Pairwise-tests stays a skill because its helper files don't fit a single-file command shape. For arch-decide, I preserved the upstream MIT LICENSE alongside the command at .claude/commands/arch-decide.LICENSE so attribution stays intact. 2026-04-25T00:11:41+00:00 Craig Jennings c@cjennings.net 2026-04-25T00:11:41+00:00 urn:sha1:e5b54c24afdd569765b215732884bd0a8f2758a9 Linear ticket bodies are now Problem + Fix only. PR descriptions keep the four-section format (Problem, Fix, Why this fixes it, How it was tested). Linear's GitHub integration handles the cross-link via the PR body's Linear: line. Cross-ref to the content-scope rule appended at the end of each Tier 1 skill that produces public artifacts: testing.md, arch-document, arch-decide, arch-design, review-code, respond-to-review, brainstorm, codify. Single-source the rule in commits.md, point at it from each output-producing skill. 2026-04-22T13:08:59+00:00 Craig Jennings c@cjennings.net 2026-04-22T13:08:59+00:00 urn:sha1:1fb4232671d30aa867e3e7b0c74d48a989e460c5 The fix-issue skill has been replaced by start-work, which covers the same ground (picking up a ticket with a known fix and carrying it through to handoff) with a seven-phase structure and three user-approval gates. Deleted fix-issue/SKILL.md and swept the references. Updated: - Makefile SKILLS list: remove fix-issue, add start-work so make install creates the right symlink. - brainstorm/SKILL.md: implementation-path list points at start-work. - debug/SKILL.md description: both "do NOT use for ticket-driven work" and "Companion to" references updated. - review-code/SKILL.md description: "drafting implementation" redirect updated. No change in meaning. Every old fix-issue context now names start-work.