And it's been a thing wayyyyyy before 3D printers were even a twinkle in some engineers eye

I don't think the person you reply to conflates "information diet" with "tech". They are just saying that their information diet consists for a large part of tech news, and other people have other information diets that don't contain that much tech news..

The description reads like someone asked opus 5 to build this, then asked them to "write a short description of what this is".

> "Skills" as developer macros can be useful, but at most those are things shared with the team (in the repo), not something you download from the internet. If you have so many skills that you feel the need to manage them, that's a code smell.

I have three development machines. You kinda need something like git to keep everyone in sync!

And there's still value in encoding a process in a skill - it's way more token efficient to tell the model what but also HOW to do something. Otherwise, it just spends a lot of tokens figuring out something that they previously did already.

> I have three development machines. You kinda need something like git to keep everyone in sync

I got tired of the constant git push/git pulling just for inter machine transfer, now I just have a ~/Git directory with all my projects that I just Syncthing between my desktops/laptops and Syncthing ignore any repos that specific machines don't need

"Why not" is a perfectly good reason to do things, and we do things like that all the time

They even make the front page of hackernews all the time. Like spending 6 months making Doom run on a calculator

In my country (for people with a so called "dynamic pricing" contract) the price of electricity already drops significantly when we have a load of green energy (wind, solar). I guess this is just a side effect of not having a well-balanced grid. But still that's already kind of a CO2-based pricing - although not directly

This is what makes me wonder how much additional benefit an explicit carbon signal actually buys you over normal dynamic pricing

On grids where pricing declines due to more low carbon generation generating, there is no extra value. On grids where pricing declines due to more fossil generation running, that is the signal you want to avoid loads during those time windows.

At the moment, lower prices are not necessarily a guarantee of lower emissions. And so, if you want to orchestrate loads to move them to the lowest emission time windows (perhaps not prioritizing cost), carbon signal is the way to do so.

Mostly yes, but it works the other direction as well: a fossil power station may not want to completely shut down because it expects more demand later in the day, and offer a few hours of low cost electricity to stay in the merit order.

A lot of fossil power stations cant shut down for a few hours, they have to keep themselves on.

Coal mostly. This is why coal is largely being phased out for natural gas which can cycle on and off as needed.

lmao that completely unnecessary chatgpt "visualisation" at the end

My claude.md has a section about not writing those comments, it has stored this in memory, and still every session I need to remind my good friend to stop writing so many garbage wordsalad comments

Maybe system prompt has priority or something but Opus just really really likes writing bad comments

That's why I mentioned hooks in particular. That feels like the right layer for this sort of adjustment. A PostToolUse hook on Edit|Write would be much more reliable than just a CLAUDE.md instruction. The consistency I get from CC comes from instructions at multiple layers.

CLAUDE.md heirarchy: At the top level you've got general instructions you want all contexts to follow and each subdirectory can add more specific instructions in their own CLAUDE.md files. References in CLAUDE.md are not fully loaded into the context. They are loaded opportunistically. So keep important instructions in the CLAUDE.md file itself and not a referenced or linked file.

Rules files: These offer path scoped rules via frontmatter. So you could have specific rules for certain types of files Claude Code interacts with. Certain rules for handling all .cs or .js files for example.

Auto-memory: You cannot rely on this one. I use auto-memory as a cache for potential future CLAUDE.md instructions. I have an audit process that kicks off when the auto-memory gets beyond a certain number of entries.

Skills: On demand context. I don't tend to use /skills explicitly. I tend to have them used in context. I've got a task tracking system I call threads. So whenever I say "Create a thread for X" it has always reliably followed the specific instructions. I've got skills for managing my NAS for searching historical session for sharing content and other things. I use them a lot of times in place of MCP servers.

Hooks: Deterministic scripts run on lifecycle events. I've got hooks that run linters on code files post edit and hooks which tie into the request / response events to push my history into a SQLite database.

Output Styles: CC ships with a few different styles, but you can create your own. This is key for changing the default voice. CLAUDE.md instructions are appended to the system prompt and can fight against the system prompt. A custom Output Style would let you replace the instructions in the system prompt with your own instructions. This can be done at the user level or per project.

The system prompt is probably produced by a model as well, I would be very surprised if anyone at Anthropic ever opened it with an actual text editor

Yes they should just use Sol to write their prompts.

They help explain the blast radius