What surprised me here is how unsentimental the article is about Claude Code skills. The pitch is not “these skills make the model smarter,” which is the usual marketing fog. It’s closer to: if you use the right wrappers around the work, you can waste less time arguing with the model about things that should have been decided before coding started. That framing feels right to me.
I also think the example is well chosen. “Add AI-generated collections” sounds like a tiny feature until you actually try to specify it. Then the real work shows up: when does the AI act, what counts as a match, can it create new collections, what happens to user-organized data, how much autonomy is too much. The article is basically admitting that the hard part is product shape, not code generation. That’s the part a lot of AI coding demos quietly skip.
The bit I like most is the insistence on separating facts the model can discover from decisions the human has to make. That seems obvious, but in practice people blur those together constantly. If Claude can inspect the codebase and find that bookmarks already have a relationship to collections, you shouldn’t be paying attention to a human explanation of that. You should be spending your attention on behavior: should the AI suggest or auto-apply, should it create new collections, should it ever reshuffle existing ones? That’s a cleaner use of the tool.
I’m a little less convinced by the proliferation of named skills, though. Not because the ideas are bad. They’re mostly sensible. It’s just that this ecosystem often turns ordinary engineering judgment into a menu of branded sub-skills, and I’m never sure how much of the value comes from the skill itself versus the fact that it forces you to slow down and think. “Use the smallest implementation,” “write down decisions,” “keep the UI consistent” are all good habits even without a special prompt package attached. The packages may help adoption, but they also risk making discipline feel productized.
The strongest signal in the piece is the emphasis on keeping a record of why choices were made, not just what was chosen. That matters more as AI-assisted work gets less linear. If you let Claude help you today and come back in three weeks, chat history is a terrible source of truth. A glossary, an ADR, a design system doc — those are boring, but boring is exactly what you want when future-you is trying to remember why the app behaves the way it does.
I’d probably try this workflow on a real feature, but with one guardrail: I wouldn’t let the process become its own hobby. If the project is small, the ceremony might be overkill. If the feature is genuinely branching and likely to grow, then yes, this feels like a decent way to keep Claude from improvising a mess.
Reference: Claude Code Skills Worth Trying: From Vague Idea to Finished Feature