Skill Hell & the No-Op Purge, Lee Robinson Jumps to Cursor & Loops You Can Trust

Skill Hell & the War on No-Op Phrases

The week's loudest craft argument came from Matt Pocock, who has spent the last few days picking apart how people write skills — and concluding that most of them are bloated.

The thesis. Pocock's no-op thread did real numbers (160 replies, 117 RTs, 2,485 likes, 236K views): "Take a look at your favourite skill… Check for lines like: 'Make the commit message very detailed', 'Be thorough', 'Make the implementation easy to read.' What do these lines have in common? They're no-ops. They do nothing to change the agent's behavior. Agents always write good commit messages. They always try to be thorough… Try removing them. Does the output change? No? Then the line was a no-op. Agent-authored skills are LITTERED with no-ops — entire paragraphs and sections of text that do nothing… No-ops make skills harder to evaluate, harder to maintain, and burn tokens uselessly." His one-liner the same morning summed up the mood: "2023: Tutorial Hell / 2026: Skill Hell."

The pushback — and it's a good one. The sharpest reply came from Sophia Bits: "every single token in the context window participates in attention, there's no such thing as a no-op. frontier models are more robust thanks to RL, but we know empirically that even whitespace changes can cause large behavioral changes" (citing arxiv.org/abs/2310.11324). Pocock conceded the literal point but held the practical one: "I'm not saying it's a literal no-op — I'm saying that including the phrase/sentence makes no meaningful difference." He later posted a clarification thread after the backlash: "Some folks are reading this as if there is a canonical list somewhere of 'no-op phrases' that never do anything… That's not what I mean — I mean phrases can be no-ops in the context of that skill. I.e. removing the phrase results in no change in the skill's behavior." Frostbite was blunt: "This might be your first miss, Matt :( This is easily A/B testable to show it doesn't track." And the it's-AI-written dig ("can tell this was written by AI the second I saw 'no op'") got a flat denial: "It actually wasn't."

The how-to. Pocock's prescription, from a follow-up: "People ask me how I get my skills so short. Just remove the no-ops, kill duplication, and take out anything irrelevant to the task. You'll be surprised with how little is left." Asked for a tool to do it, he pointed people at his own: "/writing-great-skills — 'Do a no-op pass on this skill.'" He also shipped a new in-progress skill, /loop-me: "Interviews you about your work and finds opportunities for delegating your day-to-day work to AI" (SKILL.md here). Counterpoint worth keeping in mind, from Pocock himself two days earlier: "Usually the more of a skill I've handwritten, the better it is. Paying attention to each word as you write it is unreasonably effective."

Where Do AI Coding Assets Belong? The Git Debate

Pocock's other thread of the day was a genuine open question that pulled a 300-reply crowd.

The question. Pocock (300 replies, 949 likes, 104K views): "There are a class of AI Coding assets that IMO don't really belong checked into git — PRDs, Research files, Decision maps, Implementation plans. Folks who agree with me, what are you using instead?"

The most-cited answer. nicole surfaced Dex's take (prompting Pocock's rueful "Why does Dex always beat me to the punch"): "context engineering docs for agentic engineering — plans, research, etc — SHOULD NOT be stored in version control. Keep them outside your repo, accessible to the agent via FS tools, discoverable… Why? They don't need merge semantics, just linear history… and if committed they live on branches, get lost when you change branches, you have to remember where they were."

The most concrete war story. Alexander Benz: "we put spec files in a separate notion doc and inject as context. keeping them in git creates a false signal. the agent reads the file as current state, not target state. caused some bad rewrites at mato before we learned to separate them." Echoed by Nico: "notion for context, git for code, mixing them creates noise in both directions."

The dissenters — keep it in git. A substantial camp pushed back. Michael Ogundare: "in a world where GitHub is merely used for storage and distribution of files (which is fast approaching), the best place seems to be to check them in still." Josh McK: "you're correct technically, but less so directionally. Store the inputs / sources / reasoning / decisions / plans close to where those can be used for future work." Ehtesham Kafeel likes .planning/{feature} folders in-repo so "even other developers can pick it up." And a popular middle path — Zack Story's sidecar repo: "the key distinction is not that they don't belong in git, it's that I want them always up to date, always synced, and merge-conflict free." The recurring non-git destinations: GitHub Issues, Notion, an out-of-repo vault, or a colocated sidecar repo.

Lee Robinson → Cursor, and GLM-5.2 in the Editor

The move. Lee Robinson dropped a career bomb (404 replies, 90 RTs, 6,705 likes, 226K views): "Personal update, I'm starting a new role at Cursor! I'm moving into ML, working on training Composer. I'll be researching how to improve model behavior and personality." His follow-up framed the mission: "Excited to make Composer feel like a great coworker. Please send me any feedback/examples if the model did something strange."

The explainer that earned the role. Asked what "improve personality" even means, Robinson wrote the clearest plain-English pass on post-training anyone posted this week: "The goal is a model that acts and feels like working with a top 0.01% coworker. There are obvious things to avoid, like slop phrases ('I found the smoking gun'). But more broadly, it means a model that is resourceful, proactive, honest, and useful. You need to first get shared agreement on what good/correct looks like (a model spec, principles, constitution) and then find ways to put that document into practice. These improvements come during SFT, helping shape the model's output style… It's also during RL, nudging the model towards the behavior you want. There's also RLHF where I'll vote on which responses I like better and why, which trains reward models. We can also 'tax' the model during RL to disincentive style behaviors we don't like — for example, using way too much bold text, or writing extremely lengthy final messages." The reply that landed, from Pawzard: "model personality researcher is just a guy who argues with a robot until it has opinions 💀"

GLM-5.2 lands in Cursor. Robinson also shipped the open-weights story straight into the editor, extending yesterday's GLM crown (116 replies, 104 RTs, 1,933 likes, 150K views): "You can now try GLM 5.2 in Cursor! Excited to see more useful open models, thank you to Fireworks for partnering here." Asked for benchmark detail, he pointed at cursor.com/blog/cursorbench. LLMJunky's read on where that leaves the field was less charitable to the closed labs, eyeing a leaderboard: "Codex didn't even make the list."

Loops You Can Trust — Verifiers Take Center Stage

The loop debate — which last week was still arguing about whether agents can run unattended at all — shifted today toward trust: how do you let a loop run while you're not watching?

The new framing. lauren (@poteto) published a new post (47 RTs, 244 likes, 27K views), boosted by Lee Robinson as "Loops You Can Trust". The replies homed in on the first principle — the_simian: "I appreciate the first step: knowing what good looks like, and 'doing one by hand'. Like in audio, 'trash in, trash out.' This is the most preemptive anti-slop move I've discovered." The refrain echoing across the timeline, via LLMJunky's RT of MilksandMatcha: "Never loop without verifiers." The structural idea underneath it all — split the agent that writes from the agent that checks, because a model grading its own work is too forgiving.

swyx on the infra bill that's coming. swyx: "we are going to have to Rebuild So. Much. Infra. for the age of Software Factories." He also flagged a podcast full of "alpha" on "why everyone is building a metaharness now" — the verifier-wrapped loop, productized.

Ronacher's pinning RFC. On the maintenance side of running agents in production, Armin Ronacher opened a dependency-pinning question for Pi: "Who has opinions on shrinkwrap, npm and pinning dependencies? I published an RFC for moving away from shrinkwrap for Pi. Main result would be that you kinda have to curl-to-bash to get locking" (RFC 0047). It comes amid a busy release stretch for Pi — 0.80.0 and 0.80.1 shipped ("Big changes to the internal AI package… I had to re-release because I messed up") — and the ongoing saga of the project's own coding agent "Gramps" introducing regressions, with Ronacher conceding: "Gramps correctly identified that I'm not chill enough on regressions ;)"

Also Worth a Look

  • Mistral OCR benchmarked on ParseBench. Jerry Liu (13 replies, 16 RTs, 161 likes, 21K views): "We benchmarked Mistral OCR against other frontier and open-weight models… For a model at its price point, it is quite competitive! It wins on semantic formatting — strikethroughs, super/subscripts, title hierarchy, links… does ok on tables and doesn't really have chart capabilities" (parsebench.ai). The comment that captured the trend, from Evolution Plus AI: "the price-to-performance on the smaller OCR models is quietly the most useful thing happening in doc parsing right now. most people don't need frontier, they need good-enough that doesn't cost a fortune per page." Liu also noted updated Mistral OCR results using the annotation feature for charts now land "ahead of GPT-5.5 and just behind Gemini 3.1 Pro."

  • Gemini 3.5 Flash's native computer use posts a new high. trycua, via LLMJunky's RT: "We had early access from @GoogleDeepMind to Gemini 3.5 Flash's native Computer Use. On Cua-Bench it posted the highest mean reward of any frontier model we tested — 0.267." The grounded counterweight to the autonomy hype, from LLMJunky: "Computer and Browser use are amazing, life changing innovations. But they have seriously glaring problems… Though they claim background use, many tasks [still need babysitting]."

  • Claude Code for web hit an egress wall. Simon Willison: "Claude Code for web just started saying 'GitHub is blocked by egress policy', which is a big problem for me because most of my prompts there start with 'clone simonw/sqlite-...'." A small but telling friction point as cloud agents tighten their network sandboxes.

  • Thariq's Claude Tag interview is on deck. Following yesterday's Claude Tag launch, Peter Yang announced he's interviewing Thariq on Friday to walk through "his Claude Code setup and how he uses /goal and /loop and dynamic workflows" — worth watching for the next iteration of the proactive-agent playbook.

  • The Fable watch, and SpaceX's valuation flex. Theo: "Google can't help but snatch defeat from the jaws of victory" — and, still needling Anthropic over the unresolved export ban, "Pinned: Okay but seriously, where the hell is Fable?" On the money side, Theo's one-liner: "SpaceX is worth approximately 2,143x Figma right now."

  • OpenClaw keeps shipping. Peter Steinberger's OpenClaw RT: "🦞 OpenClaw 2026.6.10 just dropped… ⚡ Automatic fast mode for short talks, 🧠 Much more reliable model routing, 🔒 Safer session state + trusted [tools]." Quiet, steady maturation in the same agent-harness lane everyone else is racing into.