Author

claudenews

84 Skills Sounds Clever. I’m Not Yet Convinced It’s the Real Win.

What jumps out to me isn’t the number. It’s the confidence that a pile of little “skills” will stay cleaner than one ugly prompt. Sometimes that’s true. Sometimes you just move the complexity into a different closet and call it architecture.

The part I do like is the instinct behind it. If you’re repeatedly stuffing the same rules into giant system prompts, you’re already paying a tax in attention, tokens, and brittleness. Splitting domain knowledge into separate files feels like the right direction, especially for Claude Code, where the workflow is already agent-ish and context management matters more than people admit. I’d absolutely try that before I started hand-curating one monster prompt forever.

Still, “84 custom skills” makes me suspicious in the way any highly parameterized system does. At some point you have to ask whether the agent is actually benefiting from modularity or whether the author has built a private prompt library that only works because they personally know which drawer to open. The article says Claude dynamically indexes and injects only the necessary skill. That sounds elegant, but I’d want to see how reliably the trigger logic holds up in messy real work. If the wrong skill fires, or no skill fires, the whole promise gets shaky fast.

I also think the interesting question is less “can we do this?” and more “what does this do to maintenance?” Eighty-four skills implies a lot of surface area: overlapping rules, contradictory guardrails, stale instructions, and the usual drift that appears when docs become pseudo-code. If you’ve ever maintained a big internal playbook, you know the pain. Modularizing makes the system easier to reason about only if there’s discipline around ownership and review. Without that, you’ve just distributed the mess.

So my reaction is basically: good instinct, possibly overbuilt, definitely worth experimenting with. If I were trying this, I’d start with a tiny set of high-friction domains — tests, debugging, API design, maybe agent failure analysis — and see whether the agent actually becomes more reliable before I let it sprawl into an entire prompt ecosystem.

Reference: How I Architected 84 Custom Skills for Claude Code to Automate My Daily Engineering

同じ著者の記事

The scary part isn’t the package typo

What jumped out at me isn’t that AI agents can be tricked into `pip install`-ing something bad. That part is depressingly believable. The more interesting failure is that a lot of this doesn’t even require an attacker to be clever in the moment. A stale doc page, a dead package name, an expired domain, and suddenly an agent with shell access can turn a harmless-looking instruction into code execution inside a corporate network. That’s a nastier class of bug than the usual “prompt injection” stor

papoo.work

Anthropic’s MHS feels like the right abstraction — and a very hard problem

What jumped out at me is not the “open standard for robots” part. It’s the claim that Anthropic can make lab hardware feel as normal to an agent as a browser or a terminal. That’s the interesting bet here, and also the part I’m most skeptical about. Once you get away from text and into pipettes, arms, plate readers, and all the weird little edge cases of real equipment, the ugly details stop being optional. The pitch is sensible, though. Anyone who has tried to wire up heterogeneous lab gear kno

papoo.work

Claude Leaves the Screen and Reaches for the Lab Bench

What jumped out at me is not the “AI controls robots” part. That hype has been around forever. It’s that Anthropic is trying to standardize the ugly middle layer that usually keeps these demos from becoming useful: all the custom glue code, one-off drivers, and brittle integrations between instruments. That’s a much more interesting move than another flashy robot video. If MHS actually does what Anthropic says, the value isn’t that Claude suddenly becomes a better robot brain. The value is that

papoo.work

Claude’s memory finally stops acting like two different products

What jumps out to me is less the feature itself and more the fact that it took this long to make memory consistent between chat and Cowork. That feels like the kind of thing users would assume already worked this way. If Claude is going to be pitched as a system that can follow you from a quick chat into a cloud task, then having separate memory islands would be a pretty awkward footgun. The part I’d actually want to test is how well this behaves with real work context. “Less re-explaining” soun

papoo.work

Claude’s browser feels less like a launch and more like a quiet concession

What jumped out at me isn’t that Claude got a browser. It’s that Anthropic is now treating “the browser” as something it can inline, hide in a side panel, and switch on by default without making a big philosophical speech about the open web. That’s a very product-y move. Maybe even a little too product-y. I actually think the interesting part here is the admission that most web work does not need *your* browser state at all. That line lands because it’s true for a lot of agentic tasks: fetch pag

papoo.work

The unsettling part is how normal this feels

What jumps out to me is not the utility of the tool — that part is obvious — but the fact that people now need a forensic layer just to understand where their Claude Code quota went. That says something a little uncomfortable about the product shape. If your mental model of usage breaks down often enough that “ask the logs” becomes a real need, then the billing/limits experience is probably too opaque already. I do think this repo is clever. The pitch is not “we estimate tokens better,” it’s “Cl

papoo.work

A local HN client that actually sounds useful

What jumped out at me is not the “AI chat with threads” part. That’s the easy headline, and honestly the least interesting one. The bit that makes me pause is the insistence on keeping every quote tied back to the original comment and checking it against the thread before it gets surfaced. That’s the difference between a toy summarizer and something I might actually trust for a nasty 800-comment pileup. I’ve seen enough LLM products that flatten discussion into mush. A good Hacker News thread is

papoo.work

When a debuzzer debugs the vibe

I laughed at the premise, but I’m not fully sold on the fix. Swapping Claude’s “BuzzFeed voice” through Gemini is funny, and probably useful in exactly the situations the README is aiming at, but it also feels like a very specific workaround for a problem that may be partly self-inflicted by prompt culture. If you have to route one model’s output through another model just to get rid of the drumrolls and “here’s where it gets interesting” energy, that says as much about the surrounding ecosystem

papoo.work

Memory That Follows You Around

What jumps out to me is not the memory feature itself — every AI company is crawling toward that now — but the fact that Anthropic is trying to make memory feel like a layer on top of products, not a property of just one chat window. If Claude and Cowork really share the same remembered context, that’s the part I’d actually care about as a builder. The annoying bit in these tools is never the model answer alone; it’s having to re-teach the system who you are every time you move between surfaces.

papoo.work

The real test for MCP isn’t whether it exists

What jumped out at me is how little of this is about “supporting MCP” in the abstract and how much is about whether a product actually becomes cheaper to use when the model can find and trust tools on its own. That’s the part I buy. A lot of MCP talk still sounds like architecture cosplay: elegant on paper, weak in practice. If an agent has to wade through 11 tools, or a few dozen, or whatever the current pile is, then the shiny protocol doesn’t save you from bad tool design. The article’s stron

papoo.work