Keep it simple
A workshop of personal Claude Code skills — design, build, and writing craft
npx -y skills add muzalee/claude-atelier --skill keep-it-simpleAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 13 days oldThe repository was created 13 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Apply to all written output — commit messages, PR descriptions, code comments, documentation, and explanations. Keep it short, no over-explaining, no filler. Never add "Co-Authored-By Claude" trailer on commits. Trigger on any writing task, especially git commit, PR create, adding comments/docstrings, or writing README/docs.
SKILL.md
2.6 KB, 540 tokens by cl100k_base, as published. Nobody here has run it
Default to the shortest form that still conveys the point.
Rules
-
Commit messages: 1–2 sentences focused on why, not a bullet list of what changed. Skip the boilerplate. Do NOT add
Co-Authored-By: Claude <...>trailer. -
PR descriptions: short summary (1–3 bullets), short test plan. No essay. No "🤖 Generated with Claude Code" trailer unless the user asks for it.
-
Code comments: only write one when the why is non-obvious (a hidden constraint, a workaround for a specific bug, a subtle invariant). Never restate what the code does. Never write multi-line comment blocks.
-
Docstrings: one short line max. Skip entirely if the function name and signature already tell the story.
-
Explanations to the user: answer first, elaborate only if asked. Skip preamble ("Sure! I'll now...", "Great question!"). No trailing recap of what you just did — the diff shows it.
-
README / docs: cover what the reader needs to do, not everything you know. Bullet lists beat paragraphs.
Why
Over-explanation wastes tokens, obscures the point, and rots (comments that describe the what diverge from the code the moment either changes). Short output respects the reader.
Examples
Bad commit:
feat: Add user authentication middleware
This commit introduces a new middleware for handling user authentication.
It validates JWT tokens on incoming requests, extracts the user ID, and
attaches it to the request object for downstream handlers to use...
Co-Authored-By: Claude <[email protected]>
Good commit:
Add JWT auth middleware — routes under /api now require a valid token.
Bad comment:
// This function takes a user object and returns their full name by
// concatenating first and last name with a space in between.
function fullName(user) { return `${user.first} ${user.last}`; }
Good comment: (none — the code is self-explanatory)
function fullName(user) { return `${user.first} ${user.last}`; }
Bad explanation: "Sure! I've now finished implementing the changes you requested. Here's a summary of what I did: 1) I edited file X, 2) I added function Y, 3) ..."
Good explanation: "Done. Added parseConfig in config.ts:42."
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.