woah

If you run Claude Code and Codex side by side, you've been installing skills into whichever one was open, and neither will ever tell you the other is missing them. The setup is a shared folder both read plus a check that shouts when they drift. Twenty minutes, and the second assistant stops being the dumber one.

The failure this prevents is a quiet one. A skill wired into one assistant and forgotten in the other doesn't error, it just isn't there, so the same request comes back worse in one tool than the other and nothing tells you why. Checking ours after months of casual installing turned up three skills only one assistant could see, and a research toolkit connected to one and not the other.

Which is why the folder is only half of it. Write yourself a check that compares the two skill folders and the two MCP configs, then hang it off something you already run daily. Ours goes off with every dashboard build and flags four things: a skill in one and not the other, a broken link, a skill sitting as a real folder where a link should be, and a server declared in one runtime only.

Fork a skill only when its own text names the assistant it's talking to. One of ours tells the model to resist drifting back to default Claude patterns, so the Codex copy has to say Codex, and that one keeps a separate copy per tool. Everything else is shared by default. The rule is worth stating because the temptation is to fork whenever something feels slightly off, and then you're back to maintaining two of everything.

Worth knowing before you start: the same discipline scales down to a repo you hand someone else, but inverted. Symlinks into your home folder are exactly what you don't want there, so a project that leaves your machine should physically own its copies, with no personal absolute paths anywhere in them.

Audit my AI assistant setup for drift and fix it. I run Claude Code (~/.claude/skills, MCP servers in ~/.claude.json) and Codex (~/.codex/skills, MCP servers in ~/.codex/config.toml). 1. List the skills each one can see and show me what's in one and not the other. 2. Do the same for MCP servers, ignoring each tool's own internal ones. 3. Move any skill that lives inside a single tool's folder out to ~/.agents/skills/ and symlink it into both, so there is one canonical copy. Tell me first if the two copies of anything differ, and don't merge them without asking, some skills name the assistant they're talking to and are meant to stay forked. 4. Write me a small script that reports all of this: skills in one and not the other, broken symlinks, real folders where a link belongs, MCP servers in one runtime only. Then tell me where to hook it so it runs on its own.

An agent skill that teaches your coding agent the small details that make an interface feel polished: concentric corner radii, optically centred icons, staggered enter animations, numbers that don't jump as they update. Install it once and "make it feel better" becomes an instruction your agent can actually act on.

The premise: great interfaces are a pile of small details that compound, not one big move. The skill codifies about sixteen of them with exact values, so the agent stops guessing.

The greatest hits, in plain terms: outer radius = inner radius + padding, align icons by eye not by maths, layered shadows instead of hard borders, split and stagger enter animations by about 100ms, keep exits softer than enters, tabular numbers so counters don't shift the layout, a gentle scale(0.96) on press, and a 40x40px minimum tap target.

When it reviews your frontend it hands back a before/after table per principle, so every change is legible and you can see exactly what moved and why, rather than a vague "trust me, it's better".

When your agent works with an online service it makes slow, repeated API calls and burns tokens doing it. Printing Press turns any API, app or site into a fast local command-line tool your agent can drive, generated from a single prompt, so it queries a cached copy instead of hammering the live service. Or skip the build: 175+ are already made, one command to install.

The trick is local mirroring. Instead of your agent firing repeated calls at a remote API, the generated CLI keeps a local SQLite copy of the data, batches operations, and exposes commands built for an agent to read. Fewer round-trips, faster answers, and it can answer questions the raw API can't, like joining across sources.

You generate one from a single prompt, an API spec, or just a website URL, and it outputs a complete Go CLI plus companion agent skills and an MCP server. So even a service with no public API or SDK becomes something your agent can drive cleanly.

Or skip building: the community library has 175+ ready-made CLIs across 19 categories, one command to search and install. Some bundle several sources behind one interface (flights across Kayak and Google Flights, say), so your agent queries one tool instead of stitching three APIs together.

Most software is built for millions of strangers, then bent to fit each one with settings and profiles. Situated software does the opposite, built for one small group in one situation, so it's personal by design, not personalised after the fact. The idea is 20 years old, but AI just made it the cheap default: the tool for your team, or only yourself, is now an afternoon's work.

In 2004 Shirky was pushing against the 'Web School' instinct: build for scale, generality and completeness, for the maximum number of anonymous users. Situated software is the opposite, made for a specific small group in a specific context. His students built apps for their own class that worked precisely because they never had to serve anyone else.

The only reason mass-market generic software was the default is cost: you had to spread an expensive build across millions of users to justify it. AI collapses that. When a working tool is an afternoon, not a quarter, building the one that fits your studio, your team, or just you stops being a luxury.

The lesson for anyone building with AI: stop reaching for settings and 'make it work for everyone' the moment a tool feels narrow. Narrow is the point. Something that fits one situation exactly beats something that fits every situation adequately, and now you can actually afford to make it.

A sharp test for whether copy still has fluff in it: a summary works by taking words out, so if you can remove words and not lose an idea, those words were fluff. Paul Graham's standard, turned into a prompt you can hand your agent to tighten any draft.

Edit this copy so it can't be summarised. The test: a summary works by removing words, so if any words can come out without losing an idea, they were fluff. Cut them. Go line by line and delete anything whose removal costs nothing. Stop only when taking out one more word would lose something interesting. Don't smooth it back into filler afterwards, leave it dense.

Your coding agent guesses at UI because it has never seen what actually ships. Mobbin's MCP plugs Claude (or Cursor, Codex, v0) straight into its library of 600,000+ real product screens, so your agent designs from proven patterns in finance, health and e-commerce instead of inventing them.

The pitch is blunt: agents can write code, but they don't know what works, so they guess, and it shows. The MCP swaps guesswork for precedent, the agent can search and cite real screens before it builds.

It reads from Mobbin's catalogue of 621,500+ screens from shipped apps across finance, health, e-commerce and more, the same library designers already open for reference.

Reach for it when you want generated UI grounded in what successful products actually do, not the generic defaults a model falls back on.

A public pack of agent skills that hand a model real design discipline: NYT-grade data viz, a genuine Müller-Brockmann grid, the Vignelli canon, brand books, subway-campaign mockups. The design-system ones make output look like a studio touched it. Worth knowing they style the work, they don't think of it for you.

They're JSON skill exports from Airtable's Hyperagent. Each is a SKILL.md plus a few helper scripts, so you can read one as a design brief or adapt it into your own agent. I dropped the data-viz one into Claude Code in about a minute.

The value is the encoded taste. The data-viz skill carries five house rules (one hero colour, no legends, lined-up figures, a headline that makes a claim) and a set of hard-won fixes for interactive charts. That's judgement you'd otherwise keep in your head.

The catch is the lesson for anyone designing with AI: it makes a chart look Times-grade, but a beautifully set chart of nothing is still nothing. I built a surf forecast that looked sharp and said nothing, and it only landed once the chart had a point to argue. The skill gives polish on tap. You still bring the idea.

Most AI writing reads generic, the same flat "AI voice" everyone can now spot. Spiral learns your writing fingerprint, sentence length, word choice, punctuation, openings, and drafts in your voice instead. It also runs as an MCP server, so your agent can write as you without re-pasting samples.

The pitch is "a writing partner for you and your agent." It's both a web app and an MCP server, so the same voice profile works whether you write in Spiral or ask Claude to draft for you.

Connecting an agent is frictionless: point your client at api.writewithspiral.com/mcp, sign in with OAuth, no API key to paste. Your agent gets tools to draft, edit and humanise text in your style, and to manage your styles, workspaces and drafts.

Made by Every. Personal is $15/month, Team $25/user, or it's included in the $30/month Every bundle.

An open-source pack of 23 specialist skills for Claude Code, product, design, engineering, QA, security, ship. Run the slash commands in sequence and one person operates as a whole org, from planning to deployment.

So your coding agent stops guessing your colours, type and spacing and treats them as law. A file pairing YAML design tokens with the rationale in markdown, plus a CLI that validates it, checks contrast ratios, and exports to frameworks like Tailwind.

A Claude Code plugin that generates several UI variations at once, lets you compare them and give feedback in an overlay, then synthesises a refined version and writes a DESIGN_PLAN.md. For exploring a screen before you commit to a direction.

Flips the session: instead of moving on, Claude becomes a teacher that won't stop until you've actually understood what it built, the problem, the solution, and why it matters. Paste it at the end of a working session; the /goal line keeps it going until it really lands.

you are a wise and incredibly effective teacher. your goal is to make sure the human deeply understands the session.

do this incrementally with each step instead of all at once at the end. before moving on to the next stage, you should confirm that they have mastered everything in the current one. this should be high level (e.g. motivation) and low level (e.g. business logic, edge cases).

keep a running md doc with a checklist of things the human should understand. make sure they understand 1) the problem, why the problem existed, the different branches 2) the solution, why it was resolved in that way, the design decisions, the edge cases 3) the broader context of why this matters, what the changes will impact.

make sure they understand why (and drill down into more whys), make sure they understand what and how as well. understanding the problem well is imperative.

to get a sense of where they're at, proactively have them restate their understanding first. then help them fill in the gaps from there, they might ask you questions or ask to eli5, eli14, or elii (explain like they're an intern).

quiz them with open-ended or multiple choice questions with AskUserQuestion (be sure to change up the order of the correct answer, and to not reveal the answer until after the questions are submitted). show them code or have them use the debugger if necessary!

/goal the session should not end until you've verified that the human has demonstrated that they understood everything on your list.

Claude Code can now write its own harness on the fly, a JavaScript file that spawns and coordinates subagents, custom-built for the task. Good for long, parallel or adversarial work where a single context window starts to drift, get lazy, or grade its own homework.

It fixes three failure modes of one long context: agentic laziness (stopping at 20 of 50 items), self-preferential bias (preferring its own results when verifying), and goal drift (losing constraints after compaction). Separate Claudes with isolated goals sidestep all three.

Common patterns it composes: fan-out-and-synthesise, adversarial verification (a separate agent tries to refute each finding), generate-and-filter, tournament (agents compete, judges pick a winner), and loop-until-done.

Pair with /goal for a hard stop condition and /loop to run on an interval, good for continuous triage or research. Save a workflow by pressing s in the workflow menu, share it via a skill.

Thariq (Claude Code team) has mostly stopped using markdown for specs, plans and reports in favour of HTML. It carries far richer information, and you're far more likely to actually read it and share it.

You don't need a skill for it. Just ask Claude to make an HTML file or an HTML artifact. The trick is knowing what you want it to do and how you'll use it.

Strong use cases: side-by-side design explorations in a grid, PR explainers with rendered diffs and annotations, research reports with SVG diagrams, and throwaway custom editors (drag tickets, tune a config, tweak an animation) that end in a copy-as-JSON or copy-as-prompt button.

Examples gallery: thariqs.github.io/html-effectiveness.

An open-source agent skill that researches any topic across Reddit, X, YouTube, TikTok, Hacker News, Polymarket, GitHub and the web in parallel, then ranks what it finds by real engagement, upvotes and views, not editorial picks. Run /last30days <topic> before you pick a library, build a feature, or write.

The pitch is research, plan, build. Run it before picking a library, shipping a feature, meeting a partner, or writing, so your plan is grounded in what people say right now, not stale training data.

It ranks by engagement, not editorial. You get the actual high-upvote threads and most-watched videos with the receipts attached, instead of a tidy summary that buries the signal.

Output comes in compact, json, markdown or html, so you can pipe the raw findings straight into a plan or a doc.

Matt Van Horn's complete agentic-engineering stack, built around one loop: plan first, build mechanically, and spend your own time being the signal, not the hands. The spine is a plan.md for every idea and four to six parallel agent sessions running at once.

Run a lot of sessions. He keeps four to six terminal tabs open, each a separate agent, one planning, one building, one researching, one fixing a bug. Your job across them is to be the signal: supply taste and direction, let the agents supply volume. The rare valuable thing is your judgement, not your typing.

Get voice-pilled. Voice-to-LLM works where other dictation fails because the model fills the gaps from context, so you can mumble and restart. Monologue or Wispr Flow on Mac, Apple dictation on the phone.

Research before you plan. He runs last30days on a topic first, a library, a feature, even a person he's about to meet, so the plan is grounded in what the community knows now, not stale training data.

Point your agent at your notes. Every plan gets better because it can read every prior plan. Pick a notes tool with a CLI or API (Bear, Obsidian, gbrain) and let your own knowledge compound.

Write your own skills. Anything you do more than twice becomes a reusable command. The trick is to point the agent at a skill that already works and have it copy the shape.

The honest closer: building with agents is the most addictive video game ever made. Take breaks, talk to your loved ones, and build something people actually want, even if people is just you.

Matt Van Horn ran /last30days five times across 865 posts about Fable 5's launch and pulled out what actually held up on day one. Short version: aim higher, prescribe less, and run it as an orchestrator, not a worker.

The biggest shift is from steps to destinations: state the outcome, let it interview you, and get out of the way. Over-prescriptive numbered instructions now degrade output rather than help it.

Effort is the dial that matters. Several testers found Fable on medium beats Opus 4.8 on high or max while using fewer tokens, so the cheap setting of the smart model can beat the max setting of the cheaper one. The flip side is cost: Fable counts as double usage on paid plans, and people burned through weekly limits in minutes.

Vision is the sleeper. People fed it screenshots and got working rebuilds, an Apple Fitness clone in 7 minutes, Notion in two prompts. The practice is screenshot first, describe second, pixels beat your UI vocabulary.

The highest-leverage prompt in the thread is one move: describe your business in detail, then ask what it would do with it. Don't ask for generic advice, ask for the highest-leverage jobs to take off your plate, ordered by impact, and tell it to start on the top one now.

If you keep hitting Claude Code limits (the 5-hour and weekly windows), you can show them right in the terminal status bar instead of running /usage every time.

Claude Code lets you replace the status bar with your own script: on every update it receives JSON that includes, besides the model and current directory, a rate_limits field with usage percentages for both windows.

This script puts them in the right corner of the line: yellow past 80%, red past 95%. It also shows the current model, reasoning effort level, and context size in tokens.

The repo has the script and install instructions, including the pitfalls the author already hit.

37,000 words on AI, addressed to "all people of good will". When the Catholic Church makes AI its defining human question, that's a signal worth clocking, whatever you build.

This is an unusually direct signal that AI is being treated as one of the central human questions of the moment, not just as a technology story.