.bashrc, the worst case is your shell behaves slightly weird until you remove the offending line. When you install someone else's skill, the worst case is much more interesting, because the skill might delegate to a subagent that runs code, opens PRs, or talks to your APIs. Skills come with more power, and therefore more responsibility for whoever is curating the list.
Third, sharing skills across machines and teams is not yet a solved problem the way dotfiles are. There is no stow for skills. No chezmoi equivalent. No widely-adopted "here is my skill repo, symlink-mount it into ~/.claude/skills/ and you are done" pattern. The ecosystem is still young. People are figuring it out as we go.
So the right framing is closer to this. Dotfiles is the entry-point analogy. Once you internalise the analogy, you can start to see that skills are a strict superset. They borrow the dotfiles vibe and then add agency on top.
The mental model I landed on
Two cartoon vertical stacks side by side: a terminal-styled stack on the left with a config scroll on top and small toolbox icons below, mirrored by a robot-styled stack on the right with the same shape but glowing module folders, connected by a thin dotted arrow showing the parallel architecture, flat illustration in soft pastel colors.
Here is how I now think about the whole stack.
.bashrc and CLAUDE.md are the same kind of object. Both are "load this every time I start a session." Both should be lean, opinionated, and universal. Both should grow rarely and shrink often.
Skills and /usr/local/bin/<tool> are the same kind of object. Both are "invoke this when the task calls for it." Both can do heavy work that does not belong in the rc file. Both can be shared, versioned, swapped out.
The new piece, the part that makes skills not just dotfiles, is that skills can spawn subagents. Your tool in /usr/local/bin/ does not call another shell to delegate work back to itself. A skill can. That is the upgrade. That is why "dotfiles with agency" is a more accurate metaphor than "dotfiles for Claude."
If you are still piling rules into CLAUDE.md and have not yet started moving the per-task ones out into skills, give the exercise a try. Even just the act of asking "is this rule universal, or is this for a specific moment?" sharpens your sense of what each layer is for. You may end up with a leaner CLAUDE.md, a few well-tuned skills, and a setup that finally has the kind of layered shape your terminal config has had for years.
That is all I had on this one. If you made it till here, thank you, genuinely. See you in the next one, where I will probably be complaining about something else that broke.