We really need some consolidation around commands, skills, subagents, and plugins. For example, if you want to, say, review code, you have five options now: - Write a .claude/commands/review.md. Simple but deprecated. - Use a /code-review skill, either one you install or one you just write yourself (it's just Markdown, after all). - Use the /pr-review subagent. Also just Markdown, but it runs "in the background" and…
Hey, Boris from the CC team here. I agree, we're working on consolidating these. Going forward it will just be the built-in /code-review skill. Here's how to use the skill on the latest version: /code-review # do a balanced code review. checks for bugs and inconsistencies, poor code quality, duplication, band aids, etc. /code-review --fix # same as above, but also fix the issues # choose an explicit effort level (def…
Yikes. That Nix code is a mess without meaningful organization & only usable via experimental flakes.
There are two kinds of organization happening here that you might not see: 1. All .nix files (besides flake.nix) are flake-parts modules: https://flake.parts/ 2. It's not only usable with experimental flakes. Works fine with unflake or trix. The experimental part of flakes is enabling flake support in the `nix` CLI. Flakes are also a design pattern in pure Nix syntax that can be evaluated fine without the experimenta…
Flake parts modules means that it’s an abstraction on top of an abstraction, flakes, on top of Nix. Then to need to throw unflake or trix at the problem is more layers & woven dependencies—same for ‘Dendridic’ patterns. If you invert that paradigm, & just import or callPackage Nix files from the flakes, then accessing say a package.nix or module.nix or overlay.nix is trivial for anyone not taking part in your specific design pattern—be it flakes, nilla, whatever. I feel this is another of these situations where engineers want to engineer their way out of messes by adding more code. Rather than a “how do I do X-PROBLEM in flakes?” if the question is “how to do X-PROBLEM is bog standard Nix?” you end up at design that tends to be a lot simpler since the the simpler bits are now decoupled from the framework (which flakes behaves more like); instead, flakes now own its complexity only in its file instead of its patterns ‘infecting’ simple parts (case in point, 2 weeks ago I helped a project get the overlays be compositionally sound by removing a coupling of inputs as a first argument & a self threaded into the package via callPackage). This is why ‘package normal form’ exists for packages in Nixpkgs so any setup can callPackage it… or how overlays already offer more powerful/flexible composition than input.follows which adds to flakes composition problems. With exceptions, Nix itself was already good enough for most cases… it just needed some design guidelines everyone could start reasonably follow (which the experiment post points out is “the good part” (good post btw… hadn’t seen)), except the state of flakes being as the are means they are stuck in limbo as too many projects now rely on it; which I guess that limbo itself means they are stable since all changes insight in-fighting—& all of these forks now have incompatible changes making it non-standard. I say best to just skip flakes since most projects don’t need anything more than pinned input starting point to produce: a package, an overlay, & a module (if relevant).
(for context, you're replying to the author of an alternative nix input pinning mechanism, which means... they're probably aware of all that and yet they chose their wording like this anyway)
Hahaha, I didn't see. Hi toastal, I appreciate your work.
Isn't it simpler to use claude's vocabulary? I don't see a good use case for this.
To understand a solution you must first understand the problem. If your whole company calls its customers "clients" but claude finds that confusing, I think it's probably easier to tell claude that then get everyone in the company to change how they talk.
Claude understands that though and so does everyone else. So not a good example
Great review. If you use this program every day, there is one thing you should know. CLAUDE.md is doing a lot of the most important work here, and it's the most fragile piece of the stack. A rule like "always re-read X before editing" is written as a piece of prose, and prose is subject to context. It's either one compaction or one subagent that appears from quietly disappearing, and there's no warning when this happens. The subagent case is the clear one: a subagent gets a new window, doesn't have the parent's CLAUDE.md discipline, and acts on the assumption that the rule was meant to stop something. The only thing that can reliably enforce the rules is settings.json permissions.deny, which the runtime checks before the model picks a tool. This means that you can't use cat or grep to bypass it. Everything left in prose is a strong default, not a guarantee. It's good to know which of your rules are which.
How many times can I read the same shallow guidance written by AI on using a coding agent? Good god when will it stop
This was so nauseating to read. It could just be stripped down so much, the problem is the content is quite good and then it's just full of this AI fluff. ...
"Read it again." - "Now the fun part." - "Short file, huge payoff. Keep it tight." - "The file isn't a knowledge base, it's a guardrail"
Also the Specific-day + specific-number + reveal format of sentences as well.
"Read it again." - This is the worst one, as if I didn't read it the first time. I do not think I have ever been told to read a code snippet again at the end of it.
"a different kind of force multiplier" - make it stop!!!