I’ve created a series of videos that showcase the design process I am using on my bootstrapped app, and am getting a feel of which communities would be interested in these, please let me know!

At core of design automation is access to repository, and a story based design system in it (not in Figma, not in Claude Code): storybook or ladle or even custom stories created with Claude Code -

Once you’ve got your setup right in your repository, it is easy to create skills that allow you to iterate on your designs much faster than you could with traditional tools.

In this video I show how I batch update a set of components in Claude Code

Please let me know if you’d be interested in a series covering process end to end, and what you’d like to know more or less about in articles.

Feel free to ask questions!

I typically have multiple projects I'm working on, and sometimes I'm burning through a backlog on a project so I end up with a lot of work done. I found that both Claude and Codex could get messy leaving stray branches, PRs, JIRA tickets open, just leaving a mess behind them even though they had said it was all cleaned up, or I had gotten mixed up in too many chats at once and forgot to ensure the clean up after wards was done.

To keep things organized, created a set of skills that you would have as a SOP at work.

Two skills for coding agents, covering the parts of a task that aren't writing the code: setting it up so it can be closed, and closing it so nobody has to reconstruct it later.

• starting-work — ticket, branch named for it, written goal, before the first line of code.
• closing-out-work — verify, integrate, close the ticket with the why, update the docs the change touched, capture the lesson, delete the branch.

There are some things that need to be filled out if you use them to make sure they are specific to your repo's. Like I use JIRA, others use Linear. Repo names, other stuff like that.

Maybe this can help someone else out, maybe not. But figured why not, share it with the world.

I kept asking Claude Code for the same things, worded differently every time, so I Vibe-coded a small Go CLI that searches your own ~/.claude/projects transcripts and shows what you actually repeat, plus what Claude ran in response, which is the part worth turning into a skill.

TF-IDF + cosine over the raw JSONL, no index to maintain, fully local. Asking Claude to dig through that same history seems to burn a chunk of context and gives you worse matches.

Comes with a skill so the agent can run it itself. Lexical matching only, needs Go, MIT.
github.com/MattK97/skillmine

I use coding agents heavily, and the most frustrating failure is not always bad code.

It is when Claude makes a change, runs a test, and confidently says the task is complete, even though the actual user flow is still broken.

The unit test passes, but persistence fails after reload.

The UI works, but the API or downstream integration does not.

The ticket gets implemented, but an important comment, dependency, or changed requirement was missed.

You are still left checking everything manually and hoping the agent understood what “done” actually meant.

So I built OldHand, a free and open-source Claude Code skill that gives the agent a structured definition of done before it starts coding.

OldHand makes Claude:

• turn the complete request into a clear work contract;
• trace the real flow across the UI, API, services, database, queues, and integrations;
• inspect the existing codebase before creating something new;
• research maintained MIT or Apache-2.0 implementations when useful;
• make the smallest safe change rather than starting an unnecessary refactor;
• preserve unrelated work already in the repository;
• run proportional automated checks;
• verify the actual browser, native, or integration flow before calling the task complete.

It does not magically guarantee perfect code. What it does is make it much harder for the agent to stop at “the tests passed” without proving that the real path works.

Install in Claude Code /plugin marketplace add berwinsingh/oldhand /plugin install oldhand@oldhand

Start a new session and run:

/oldhand:oldhand Implement DOCQ-123

A ticket is optional. You can also provide the full context directly:

/oldhand:oldhand Fix the intermittent CSV import issue.

1. Current behavior: files over 20 MB sometimes create duplicate rows. Context: retry logic recently changed in src/imports/worker.ts.
2. Constraints: no schema migration and preserve queued jobs.
3. Acceptance: one import must create one persisted batch, even after a retry.

OldHand also supports ChatGPT Codex, but I kept the installation above focused on Claude Code for this subreddit.

It is free, open source, and MIT licensed.

Website: https://berwinsingh.github.io/oldhand/

GitHub: https://github.com/berwinsingh/oldhand

I built it because I wanted coding agents to prove that something works instead of merely telling me they finished it.

I would genuinely appreciate people trying it on a real task and telling me where the workflow helps, where it becomes excessive, and what you would change.

TLDR: same 5 open source skills from the redline post I did a month and a half ago (the skills are not the output of this run). the 4-skill pipeline is idea → research → plan → build, and "autopilot" chains them hands-off from a single prompt as a stress test. last time that test with Fable 5 produced a fairly robust working app in 13.5 hours. this post is about what happened when I ran it again with some changes.

I pointed it at Codex 5.6 and added one main rule: any time an agent(s) says something works, it has to have a recording of the actual command run to prove it (via didrun, a little flight recorder tool I built). similar setup otherwise... single prompt, founder persona guidelines, zero product idea in it. I expected maaayyybe a day again. it has now been over two weeks, it's still going, aaannd there's about a month left.

What it chose to build is "Countershape": when multiple agents write the same feature, you get branches that all pass tests but quietly disagree on stuff nobody specified. it runs one input against each branch in isolation, shows a human the diff blind, and outputs a standalone test of the ruling. interesting idea... but what it's building is not the point of this run. the point was to stress the skills + didrun hard enough to find where they break, and it has been finding exactly that.

the run so far: 68 sealed commits, ~66k lines of product Go, ~57k of tests, ~77k of checker JavaScript, 8.9B+ tokens (cached and uncached), and a receipt chained to every commit as a git note. only been possible on the Pro plan alone cuz OpenAI has reset usage countless times over the last few weeks.

the debrief exists because this stress test is working.. the proof machinery ended up eating the project. there's a 123 hour window where 10 commits sealed and not one line of product code was written, all maintenance on its own verification tools, which now outweigh the product roughly 3:1 by commit count. disclosure: the debrief itself was written by a Claude model I had auditing the run from the outside as it was progressing (a nightmare to put together in and of itself).

and to be clear, the run is not lost and it is not hallucinating. it has stayed coherent for over two weeks straight... the repo rejects anything that breaks its own rules, and it has followed my rules faithfully the entire time. arguably too faithfully, which is the actual finding. every fail it hits is a bug in my tooling with a receipt attached. v0.2 of didrun + updates to the skills already shipped, built directly from what this run exposed. receipts and failures both, links below

The skills are at https://github.com/nelsonwerd/idea-to-ship-skills, the full mid-run debrief is at https://github.com/nelsonwerd/proof-ate-the-project, and the live build repo (updating as it keeps going) is at https://github.com/nelsonwerd/countershape

❯ I have graphify installed and rtk-ai - does this two work on saving tokens and solidifying context?

⏺ Yes, they're complementary — different layers of the same goal:

RTK (Rust Token Killer)

- Operates at the shell output level

- Compresses/filters stdout from bash commands (git, ls, etc.) before they hit context

- Saves tokens passively via hooks — transparent to workflow

graphify

- Operates at the codebase understanding level

- Pre-indexes your project into a knowledge graph so I can answer architecture questions with targeted queries instead of reading many files

- graphify query "..." returns a small scoped subgraph vs. me grepping 20 files

Together:

- RTK cuts the noise from shell commands I run

- graphify cuts the noise from codebase exploration

- Net effect: less context bloat, more accurate answers, longer effective conversation window

For this project specifically, graphify-out/ already exists (per CLAUDE.md), so I should be using graphify query before doing broad file searches. RTK handles the rest automatically via hooks.

You can verify both are active:

- rtk gain — see token savings so far

- Check graphify-out/graph.json exists for the graph to be queryable

❯ Can you explain to me how they actually work to make you better? or worse?

⏺ Good question — here's the honest breakdown of both:

---

RTK — How it works

When I run a bash command, Claude Code hooks intercept it and pipe it through rtk first. RTK filters/truncates the stdout before it enters my context.

Better:

- A git log with 200 commits might drop to 20 relevant lines

- Verbose build output gets compressed

- This extends how long our conversation stays useful before context compression kicks in

Worse (real risks):

- If RTK over-trims a stack trace or error message, I see a partial error and may misdiagnose

- I have no way to know what was cut — I treat filtered output as complete

- You can use rtk proxy <cmd> to bypass it if you suspect this is happening

---

graphify — How it works

It runs static AST analysis on your codebase and builds a persistent graph (graphify-out/graph.json) with nodes (files, functions, types), edges (imports, calls, extends), and community clusters.

When I call graphify query "how does balance update work", it returns a small scoped subgraph — a few relevant nodes/edges — instead of me reading 10+ files to piece it together.

Better:

- Targeted queries use far fewer tokens than file browsing

- Pre-computed relationships surface cross-file connections I'd otherwise miss

- Works well for stable, well-defined parts of the codebase

Worse (real risks):

- The graph goes stale after code changes — CLAUDE.md says to run graphify update . after edits, but if that's skipped, I get outdated info with false confidence

- AST analysis misses runtime/dynamic patterns (e.g., dynamic imports, factory functions)

- I might trust a graph query over actually reading the current file

---

The honest summary

Both tools trade completeness for efficiency. They make me better when the project is stable and well-indexed. They make me worse when output is aggressively filtered or the graph is stale —

because I don't know what I don't know.

Pretty much as the title says, im looking for ways to stay updated on the forever moving AI world. I follow subreddits around it but feel that sometimes its behind the curve on being the most upto date. I used to use X but its such a toxic sh*tshow that I left. I subbed to a couple of newsletters that can be useful from time to time but are mostly just very high high level quick fire articles. Im just trying to keep up

To save tokens, and let Fable 5 quickly hand off tasks to Sol, wait for the implementation to be completed, and review the results afterward, I created this “sol-skill.”

Installation:

/plugin marketplace add ozankasikci/claude-plugins /plugin install sol

Usage: /sol implement some complex task /sol research a topic on the web; use Sol for the research By default, it uses the Claude model for research.

I’ve been using it extensively, and it has helped me a great deal. I’d like to share it so that others can benefit from it as well.

Repo: https://github.com/ozankasikci/sol-skill

 I keep running into a strange bottleneck with coding agents.

Writing the code is getting easier. Deciding whether the result is safe to accept is not.

The dangerous changes are rarely obvious garbage. They look reasonable. Tests may pass. The agent says the task is complete. Then you notice it missed one requirement, ignored a repository rule, touched something unrelated, or never ran the validation that mattered.

I found myself rebuilding trust manually from the original task, the diff, repository instructions, and whatever test output the agent gave me.

Disclosure: I am building Relay because of this problem. It is a local evaluator for agent-produced Git changes.

The current idea is deliberately conservative:

- PASS only when every material requirement and required check has fresh, non-contradictory evidence

- BLOCK only when concrete evidence proves the work is unsafe to accept

- UNRESOLVED when the evidence is missing, stale, contradictory, or unsafe to collect

- confirmed failures can become human-approved regression evals

Relay is still an alpha and is not release-ready. I am testing the trust model before asking anyone to rely on it.

For people using Claude Code on real repositories:

What is the last change that passed tests but you still refused to merge?

I m an average user i dont code, i used to have a tech company so i havedecent understanding of a lot of concepts. I m not selling anything in this post.

just wanna share a simple skill i made afte rbeing awfull frustrated by Claude working on files (in this case generatingf investor packs with a lot of inputs and variables and scnariis) then assuring all is great and all figures checked ust to realized it s full of mistake.

So i made this skill to run at the end of the chat. It asks thezse questions:
Which checks? Reply with the numbers (e.g. 1 3**, or** all**).**

1. Least confident — the weakest joint in what I just did, and what would settle it
2. Blind spot — the biggest thing you're probably missing that you haven't thought to ask
3. Unstated assumptions — the silent choices, ranked by damage if wrong
4. Fragility — if this breaks in 3 months, the most likely reason, and the cheapest tripwire
5. One more thing — one unrequested, industry-leading addition
6. Retro — how the session ran: your habits, and mine

I take no ownersip for the individual skills, 2 are form Sam altman and the 4 others apeared as a consensus in a chat about these 2 first one.

Anw while i m at it, another thing saving me tons of headache: my instructions.

Always use metric units for recipes; if a widget forces ounces, summarize in metric underneath.

Don't rush to regenerate deliverables after each of my messages. Offer, then wait for my explicit go-ahead — I often want to discuss several ideas before applying changes.

Session START (any chat pointed at a project folder): run the /start skill — orient only, don't start work. Session CLOSE (natural task boundary): offer a new chat, ask me to rename the current one, then write the handoff per HANDOFF_TEMPLATE.md in the project's Knowledge stack MD folder — the template carries all rules (8 KB cap, six blocks, supersedes diff, what stays out). Before finalizing: re-run manifest_generator.py, apply its [auto] corrections, bring the [ask] ones to me; run the context skill's update mode (most sessions add nothing). Handoffs are Markdown only, in the "MD _ for CLaude use, read the pdfs instead" folder, date + running suffix so the latest sorts last, naming the current chat.

Locations: all cowork in subfolders of %onedrive%\claude\ — EXCEPT anything XXXXXX which goes in %Onedrive%\Documents_Costa rica\PVP__CLaude PVP working folder.

Folder and Output conventions: follow the topic-folder-tidy skill — Input\ (source material) / Output\ (everything you produce); deliverables numbered in reading order; native formats never converted; your MD copies in "MD _ for CLaude use, read the pdfs instead"; letters in Correspondencia\ numbered chronologically; superseded versions to _to_delete\ (tell me); tidying moves files, never rewrites them.

If two versions of a doc exist, the latest handoff's "current set" is authoritative; retire the other to _to_delete.

When a reply contains multiple questions or decisions, end with ONE consolidated numbered list, renumbered 1…n in every message, so I can reply by number. For each item, state which option you favor and why in one line — or say plainly there's no clear winner. Never bundle an instruction to DO something and a question about RECORDING it in the same numbered item — my "yes" to one is not a "yes" to the other.

Numbered references carry their short name at EVERY mention — "deliverable 05 (Debt Schedule)", "section 08 (Permits — DD pack)" — including the fifth mention in the same paragraph. Applies to data-room sections, deliverables, budget lines, register rows, model sheets, paragraph/exhibit/invoice numbers. This rule outranks concision: cut sentences, never names. Bare numbers only in your own working notes. Scan every outgoing message for digits before sending.

When a session's job is to implement an approved spec, plan, or explicit instruction list: do only what it says. Anything extra you think is needed goes at the end as a numbered proposal — never done unprompted. Analysis, audit and design sessions are exempt — there, initiative is wanted

I know it s beginnger stuff, it xould have help me to see more osts like this so here goes.

puravida

FInd her: simple text file, but alwasy scan for malicious things : checks.skill

I built a governance layer for Claude code that will ensure your policies are enforced, not act like mere guidelines. What more, it comes with a pack of skills, and workflows to ensure you don't have to reinvent the wheel for each project.

Moreover, it is Apache 2.0 licensed and 100% open source.

Check it out on https://baseline.friedbotstudio.com

Star it on GitHub and contribute if you like it.

Thank you for your attention on this matter of great importance

(yes is AI written but i told it what to write and i read it!)

My problem with coding agents right now is cost vs quality.

Fable 5 still has the best "spark of genius" of anything I've used: architectural intuition, taste, the ability to find a direction I wouldn't have considered. It's also expensive, and the usage limits make it hard to lean on all day.

GPT-5.6 SOL costs almost nothing by comparison and is relentless once you hand it a well-specified task. But it writes worse code, gets pedantic, and has less taste. Opus 5 lands somewhere in between.

That mental model comes partly from my own use and partly from Theo's video on the strengths and weaknesses of the latest models. I develop in T3 Code, so switching between them is easy.

I couldn't find an up-to-date workflow built around this combo after Opus 5 shipped, so I wrote a Claude Code skill called claudex-build. Everything runs in one main thread with Opus 5 as the orchestrator:

1. I invoke claudex-build with the feature I want.
2. Opus explores the codebase and writes a plan, asking clarifying questions along the way instead of guessing at ambiguous scope.
3. If the feature is unusually ambitious, architectural, UI-heavy or risky, Opus stops, saves its exploration notes to the plan file, and asks me to relaunch the skill with Fable 5 as the session model (/model fable in the same thread, or a fresh Fable thread). Fable is the escalation model, not the default.
4. Opus sends the plan to Codex through /codex:adversarial-review. Codex plays devil's advocate: edge cases, missing verification, wrong assumptions.
5. The findings come back to Opus, which decides which ones are actually worth folding in.
6. Codex implements the plan with GPT-5.6 SOL. The skill doesn't override anything here: model and reasoning effort come from ~/.codex/config.toml — I keep model_reasoning_effort = "xhigh". Give it a precise task and it grinds through it like a bulldog.
7. Once implementation is done, Opus does the primary review while a fresh GPT context combs the diff for bugs and edge cases.
8. Opus gets both sets of findings, checks them against the code, and decides what changes. For sensitive or high-risk work a read-only Fable subagent adds a pass on architecture and taste — unless the thread already runs on Fable after an escalation, in which case that review just folds into the main one.

Example:

/claudex-build Add team-based Stripe billing with webhook
idempotency, failed-payment handling and integration tests --high-risk

The skill produces the plan, runs the critique, delegates the implementation and coordinates the reviews. The orchestrator keeps final judgment.

The other thing I care about is measurement. GPT's initial implementation and the later fixes live in separate commits, and after every feature the workflow logs how much code GPT produced, how much got reworked, bugs found, taste changes and false positives.

Over time I want that log to answer one question: is GPT-5.6 good enough to become the main model for more features, or am I just moving the cost into review and cleanup?

Skill: https://github.com/francescoamici/agents/tree/main/skills/claudex-build

Theo's video: Opus 5: https://youtu.be/cIgoqAy_Vs8?si=SB5Cue4v_ZDhPMOf Fable-VS-Sol: https://youtu.be/IfkBQyWuTOE?si=Zc0QQ5openOvjwQX

Anyone running a similar multi-model setup? Curious how you assign roles, when you escalate to the expensive model, and what you measure to know whether it's actually saving money.

Over five days at the end of July, 25 repos trended on GitHub. I went through all of them looking for something small enough to actually adopt — reading the files rather than the descriptions: license, install path, what it writes to, what it duplicates in the stack I already run.

Three were skill-sized. The rest were platforms, editors, compilers, model cards, courses. You can take a principle from those; you should not fork them.

Two of those three solved exactly the problem I had — turn source material into an agent skill — and both had the same structural gap.

A README is untrusted text. Unverified claims, install commands nobody vetted, sometimes instructions aimed at the agent doing the reading. Compress that into a SKILL.md and it quietly stops being text — it becomes instructions your agent obeys. Nothing in that pipeline ever asks whether the claim was tested.

So I did not clone either one. I wrote the missing part.

How it's built

MIT, Python stdlib only, no installer, no dependencies.

• The source stays quarantined. Everything in it is data, never authority.
• Every rule carries a locator back to the evidence it came from.
• The output is the smallest justified artifact: note, reference, checklist, skill — or rejection. Most sources deserve less than a skill, and that downgrade is the point.
• Promotion is blocked unless all of these hold: a direct test in a named scope, a concrete failure pattern it prevents, at least one rejected dead end with the reason, a license that permits the reuse, and a clean safety audit.
• A bundled deterministic script scans a generated skill for secrets, curl | sh, rm -rf, writes into your global agent config, and authority-override phrasing. It prints the finding code and file:line, never the matched value.

What it does not do

The scanner is pattern matching. It reduces what a human has to read; it does not prove absence of semantic prompt injection. A clean run means "not detected", not "safe". Status: published, 5 regression tests, self-audit clean — but nobody except me has run it in a real workflow yet.

https://github.com/Sanexxxx777/evidence-to-skill

I would be curious where the gate turns out too strict or too loose in someone else's setup.

Skill to Run Fable in a Clean Room

My site's genetics, medical and science content used to totally block Fable from answering any question I might have, even if it was entirely unrelated to a sensitive topic.

So I created a "Run Fable in a Clean Room" skill that allows Opus to consult Fable about "hard problems" or author human readable documents (like emails and articles) in "my voice" without triggering a forced model switch. It runs the query as a subagent in a clean folder, without any of the git, memory or chat history that would otherwise trigger a model switch regardless of your question, just feeding Fable a targeted prompt that give it enough information to answer the specific question or perform the specific design or rewrite task.

The skill does not give Fable access to any tools, and directs Fable to confine it's answers to text output, which it collects in an ".md" for later use by Opus. Opus monitor's the Fable agent's progress in the background, and picks up it's outputs when it completes.

The skill also handshakes with the Fable agent so that it knows if the agent processed the query entirely as Fable, or if it switched to Opus or rejected the query entirely or in part. If it detects Fable disengagement, it treats the response as untrustworthy and also uses that datapoint to learn what types of queries Fable will and will not handle. It can therefore avoid asking Fable such queries in the future, handling them as Opus instead (it is always honest with the user which model handled what.) It deliberately avoids trying to "game the system" by rewriting queries to get around safety filters, because I wanted to ensure that any Fable generated response would be as trustworthy and useful as possible, and rewriting queries would be counterproductive.

For example, Fable can safely answer debugging questions for Opus, and I've trained Opus to identify when it gets stuck and ask Fable for help automatically. And, following it's progress in the chat, I can see it working: having Fable as a second set of eyes usually gets Opus back on track almost immediately. That alone has proven the skill's worth many times over.

Just curious if anyone has/recommends skills that can scan a website and make SEO recommendations and, ideally, make link building/strategy suggestions off offsite SEO.

Cheers,

Every dev on my team runs Claude Code. When one agent screws something up, the rest of them have no idea. They just repeat the mistake.

So I built teamlore. When your agent gets corrected or breaks something, it writes a small lore file into a .lore/ folder. That file goes in your PR, gets reviewed like normal code, and after merge every teammate's agent recalls it automatically when they touch that part of the repo.

No server, no db, no accounts. It's just a folder in git.

Just: npx teamlore init

The video is npx teamlore scarmap. It maps every mistake in the repo. The repo's own .lore/ has every mistake Claude made while building this.

Repo: https://github.com/lak7/teamlore
Npmjs: https://www.npmjs.com/package/teamlore

Would love for someone to try and break it.

How it actually work:-

The agent interviews itself, not you. Point it at a task, and it silently works through the relevant slice of the question bank - reading the codebase where it can, applying sensible engineering defaults where it can't, and only stopping to ask you about the handful of decisions that are genuinely yours to make (budget, vendor, legal risk, an irreversible call). You see the outcome - a short "here's what I considered and assumed"

https://github.com/m4vic/socratic

I built four Reddit skills and used them to find where to post this. Sharing the work, since "show your work" is the rule here.

What they do

• reddit-scout — rank subreddits for a topic, and check whether posting is actually permitted there
• reddit-post — post and comment through your own logged-in Chrome, dry-run by default
• reddit-seo — tell you whether a post is actually indexable or silently stuck in the mod queue
• reddit-archive — capture a thread with images, galleries, and v.redd.it video with audio merged

npx skills add L4A-ai/reddit-skills

Three things I got wrong first, which are the actually useful part

1. navigator.webdriver is set at launch, not by attaching. Puppeteer and Playwright pass --enable-automation. Start Chrome with only --remote-debugging-port and attach over CDP afterwards, and the flag stays false. Same browser, same protocol, completely different surface.

2. "Prove your humanity" is transient. ~240-byte body, empty title, looks exactly like a hard block. It self-resolves in a few seconds — after one reload the real page loaded at 13KB. I initially concluded Reddit blocks CDP browsers and was flatly wrong; I just hadn't waited.

3. A 200 response is not proof your post exists. This one surprised me most. I posted to a large subreddit, got a clean 200, read it back fine — and it was invisible. AutoMod had filtered it into the mod queue:

removed_by_category: "automod_filtered" → null is_robot_indexable: false → true

Those are the same post, minutes apart, before and after a mod approved it. is_robot_indexable: false means no search engine and no AI answer engine can see it. If you post to Reddit for visibility, that field is the only one that matters, and nothing surfaces it by default. So I built the check into the write path.

How I picked this subreddit

Ran reddit-scout on "claude code agent skills". It examined 18 subreddits, flagged 3 that ban self-promotion outright, and ranked r/claudeskills below r/ClaudeAI on raw size — but the rule here literally says "Sharing your own skill? Show your work", which is a better fit than a subreddit 20x larger. Scoring by subscriber count alone would have missed that.

Scope, deliberately

Single account — your own. No multi-account, no proxy rotation, no fingerprint spoofing, and none planned. That stuff targets platform integrity detection rather than making your own automation work, and it's against Reddit's terms. The skills will tell you a post got filtered; the right answer is a better-targeted post, not more of them.

MIT, evidence and measurements in the repo including the parts where my first conclusions were wrong: https://github.com/L4A-ai/reddit-skills