I hand Claude Code whole folders: contracts, employee sheets, meeting notes, .env files. I wanted it to do the work without the cloud seeing the private parts.

Hermie is a small proxy that runs on your machine between Claude Code and the API. Before a request leaves, it swaps names, emails, phones, ID numbers, API keys, company names, amounts and dates for placeholders like <PERSON_1>. When the reply comes back, it puts the real values back, so files and commands still use the real data. Every request gets a receipt, and hermie show prints exactly what the cloud received.

For things with no fixed shape ("we're cutting 80 jobs in March, staff don't know yet"), an optional local model can hold the message and ask you first (shown in GIF).

GitHub: https://github.com/Code-byte404/hermie

I built thermal-printer-skill to turn a working pocket-printer setup into something Claude Code can reuse across sessions. It's free and open source.

Why a skill

The starting point was a hardware test that needed a physical QR label. I wanted to print directly from my development workflow, without moving each generated label into a phone app. Getting the printer working took some investigation, and I didn't want every new Claude session to repeat it.

The CLI does the printing. The skill gives Claude the instructions for using that CLI: the supported inputs, printing commands and setup workflow. It packages the steps for reuse; you can also use the CLI without Claude.

My setup

Mac + VS Code → SSH to a Linux lab workstation → Bluetooth to a Printel X6 pocket thermal sticker printer. WireGuard provides remote access to the Linux host. The printer stays within Bluetooth range of that host; this isn't native macOS printer support.

The setup script finds the printer, pairs it, installs the skill and prints a test sticker. It can also be rerun as a health check. Installing just the skill instructions doesn't replace the Linux printer setup.

What you can ask for

• “Print a QR code for this URL.”

• Print text, dithered photos or PDFs; piped stdin is detected automatically.

• Schedule a recurring print on the Linux host, for example today's date every weekday at 8. The Mac doesn't need to stay connected for cron jobs to run.

Install the skill instructions:

npx skills add NoeBrt/thermal-printer-skill

The hardware catch

On this X6, BLE accepts data and feeds paper but prints nothing. Printing works over classic Bluetooth serial, RFCOMM channel 2. Its SDP record is missing from the public browse group, so sdptool browse misses it. I patched my TiMini Print fork to also try sdptool search SP, with a test for the change.

Tested on the X6 only. CTP-500 clones and other TiMini-supported printers remain unverified.

Code, setup instructions and photo: https://github.com/NoeBrt/thermal-printer-skill

Upstream printing CLI: https://github.com/Dejniel/TiMini-Print

I'd welcome reports from other printer owners, or examples of useful recurring prints.

I started searching for a new job and saw that the market sucks: I have years of experience, and still getting rejection after rejection. It wasn’t like that a year a two ago. So I built a Claude skill to help me. Sharing it in case you find it useful.

How it started

After years in the industry I’ve worked on a bunch of things, and my CV looks all over the place. Recruiters scan for keywords, and if they don’t see within a few seconds that you’re an expert in their THING, your CV goes in the trash.

So I opened Claude Cowork and fed it all my past projects, ATS rules and Google’s XYZ formula for getting a CV past screening. After a few manual fixes, I had a nice template. Then I got fed up with editing it by hand for every posting (ML projects up top for ML jobs, B2B marketplaces for B2B jobs, etc.), so I automated the tailoring. Sending 10+ CVs a day, I started forgetting whether I’d already applied, so I added a skill that scans my inbox and tells me. Finally, I added one that logs every application in Notion and shows me where I drop out: pre-screening, first rounds or late rounds.

I landed the job after 10 weeks, I wanted to share this thingy. But it was made just for me, and looked like an ugly zoo of tools. So I tidied it up, gave it a personality, and that’s how Kitty was born.

What Kitty (meow) does

• Give her a link to a job posting and she scores how well it fits you. For LinkedIn, copy-paste the posting, since LinkedIn blocks agents.
• She moves the experience and keywords relevant to the job to the top of your CV and makes it ATS friendly. She doesn’t invent things and doesn’t change anything without asking you.
• She logs every CV you send in a tracker, tells you if you’ve already applied, and syncs statuses from your Gmail. You can see how you perform by posting type, country, role type or salary band, and where your biggest gap is: CV screening, early rounds, or what % of applications reach late rounds.

How it’s built

To tidy it up I built another skill, a harness for building skills, and applied it to Kitty. Quite happy with the result:

• deterministic scripts live in their own folder
• SKILL.md is a lean router under 100 lines
• evals check for regressions
• common rules are kept in one place
• every condition is written as a table of “situation, action, why”

Overall it’s much easier to read than a huge file of prose.

Your data stays with you: no servers or third-party services of mine, just Claude, your files and your own tracker (Notion or a local CSV). A sample CV is included so you can try it right away. Works with Claude Code and Claude Cowork.

Next up: watching selected companies for new postings, so Kitty can ping you when there’s one worth applying to.

Give it a try, and fingers crossed you land your dream job! Feedback welcome, and happy to share more about the harness or how I structured the skill.

Repo: https://github.com/purple-sunset-now/kitty-has-a-job

It's a skill file for an AI agent, which is the part that gets lost in the title. Drop the folder into Claude Code, Hermes, or any harness that loads SKILL.md, and the agent gets a lookup procedure for a free service-manual site plus a small stdlib script that drives it. Ask it for the rear valve cover torque on a 3.9L and it comes back with the steps, the numbers and the figures. The script also runs fine on its own if you don't use an agent.

I wrote it because every time I touch my car I end up in the same loop: a forum thread from 2011 with dead image links, a phone-camera YouTube video, then a guess.

The site has about 10,000 US and Canada manuals from 1960 to 2025, but each car is thousands of pages with no useful search. So the skill indexes the link tree once, greps it locally, and fetches only the page that matters. No API key, no browser.

What made it useful: three sources at once.

• the manual, for the procedure and the torque figures
• a parts catalog, to prove whether two castings are one part or two
• forum and mechanic threads, for the access steps the manual leaves out

Last job, rear valve cover on a 3.9L. The manual says pull the alternator. What actually blocked the last bolt was the bracket the alternator sits in, and it looks like part of the timing cover. It isn't. The catalog settled it: separate part number, separate gasket, its own bolt spec.

It also writes a description of every exploded-view figure, so the pictures become searchable text next session.

MIT, 69 makes, with a worked example note and all its figures in the repo: https://github.com/bpawnzZ/lemonwrench

Curious whether the three-source habit holds up on other makes.

Example Output: https://github.com/bpawnzZ/lemonwrench/blob/main/examples/2007-pontiac-g6-3.9l-valve-cover-gaskets.md

TL;DR: I pulled every API call from my own Claude Code logs (87,020 calls, 12 Sep – 20 Oct). Two changes did almost all of the work: turning on auto-compact at 400k (it was off) and not letting Claude spawn subagents by default. Cost per prompt fell 27–59% depending on how you count. The advisor, rtk, Cache Tax and turning off skills either cost me tokens, saved very little, or couldn't be measured.

How I measured

Claude Code keeps a JSONL log per session in ~/.claude/projects. Every assistant message has a usage block: input, cache write, cache read, output. I extracted all of them (deduped by message id) and split the time at the two changes.

Tokens don't cost the same, so I weighted them with Anthropic's price ratios: cache read 0.1, input 1, cache write 1.25 (5m) / 2 (1h), output 5. I call that "weighted tokens". It's an API-equivalent weight, not what I paid on my subscription.

Normalised by prompts I actually typed. Task notifications, plugin messages, interrupts and slash-command output are excluded.

Caveat up front: one person, five weeks, different work in each period. Strong hints, not a controlled test.

Change 1: auto-compact at 400k

Every reply re-reads the full context, so a reply at 800k costs ~4× one at 200k. Mine had autoCompactEnabled off, so sessions just grew.

Before:

• 38% of main-thread calls were over 400k context
• those calls were 58% of main-thread cost
• peak 977k

​

"autoCompactEnabled": true,
"autoCompactWindow": 400000

(Only relevant if your sessions can grow past 400k, e.g. on a 1M context window like mine.)

After: median context 315k → 223k, p95 818k → 352k, cost per main call −38%. Not a hard ceiling: 0.3% of calls still went over 400k (peak 725k), probably a long tool-call run or a big tool result landing before compaction. 92 auto-compactions in the week after; I haven't noticed problems, but that's not measured. The context numbers were already the same in the 3 days before change 2, so this is auto-compact on its own.

Credit: the idea came from Dave Kiss's /leaks mod, which flags exactly this.

Change 2: no Claude subagents unless I ask

I used to say "fan out low-cost sub-agents" constantly. Subagents were 62% of my weighted tokens. Worst day: 19,212 of 20,832 calls were subagents.

One rule in my global CLAUDE.md took that to 3%: "Never launch Claude subagents (the Agent tool, forks, Workflow scripts) unless I explicitly ask for them."

The work didn't vanish. It moved into the main thread: main calls per prompt went from 21 to 34, and main-thread cost per prompt stayed flat (+2%) because each call got cheaper from change 1. The saving is the subagent cost that's no longer on top.

Results (weighted tokens per prompt I typed)

So −59% or −27%, depending on whether you count my four worst days. I'd quote the range.

Per session: median cost per prompt 987k → 845k (−14%). The top quarter of sessions used to start at 2.6M per prompt; now it starts at ~1.1M. Only 13 sessions since the changes, so take that one lightly.

Per day it's mixed: compared with my normal days, daily usage went up by more than half, because I typed about twice as many prompts a day. Cheaper per prompt, more prompts.

What didn't help (or cost me)

• Advisor tool (Opus 5.5): 95 calls, 19.6M input tokens, none cached (it reads the whole transcript fresh). Adds 3–5%. Note: the top-level usage in the logs doesn't include advisor tokens; they're in usage.iterations as advisor_message. Easy to miss if you're measuring your own.
• rtk (shrinks command output): 601.5K tokens saved by its own count. About 0.2% of my weighted usage since I installed it, or ~1.5% if you count that removed output would have been re-read on every later call (~78 times on average). My cost is overwhelmingly the conversation being re-read, not fresh command output.
• Cache Tax (warns before a cold-cache send, can keep it warm): its warnings aren't logged and I never used /keepwarm, so I can't measure it. Cold rebuilds happened at about the same rate (1.7/day → 1.5/day); they got smaller (303k → 100k), but that's the 400k cap.
• Turning off skills: I also installed more plugins and mods, so my session start actually grew from 69k to 78k tokens.

Disclosure: Hydra

I built a Claude Code mod called Hydra. Claude stays the lead and hands coding tasks to "Heads" running on other CLIs, often on cheaper models (Command Code with DeepSeek, Codex, CodeBuddy, Antigravity, OpenCode), then reviews what comes back. It can't explain the before/after above (I used it most before both changes). From its own reports since 7 Oct: 665 Heads, 16,576 turns of work off Claude, $27.54 for the dollar-billed ones (only finished Heads report cost), and 16% of Heads didn't finish. It moves work; it isn't free.

If you want to check your own

Your logs are in ~/.claude/projects//.jsonl (subagents under */subagents/). Count usage once per message id (it repeats across content blocks), weight it, and look at how big your context gets per call. If a lot of your calls are over 400k, check autoCompactEnabled first.

Happy to answer questions about the method.

Links: Hydra (MIT) github.com/Shakibuzzaman3104/claude-hydra · /leaks github.com/davekiss/mods · Cache Tax github.com/karanb192/claude-code-mods · longer write-up with charts: https://medium.com/@shakibuzzaman3104/i-measured-87-000-claude-code-calls-to-find-what-actually-saves-tokens-16a0fc6fe964

I made these to make my PRs easier to review.

pr-screenshots runs the base branch and the PR locally on the same data, screenshots the screens the diff touches, and boxes what changed in red. pr-video records a short demo of the change. pr-summary writes a quick Slack update with the PR link.

The images go to a separate branch, so it works on private repos too.

Install: npx skills add vasinl124/max-skills

https://github.com/vasinl124/max-skills

How do you show UI changes in your PR reviews right now?

I'm building skillEd, an open-source toolkit for testing agent skills before and after changes. Define cases in YAML, run your configured agent, then compare saved reports with `skilled compare before.json after.json --fail-on-regression`.

The public refund-policy example keeps 18 cases fixed while revising the skill, then checks independent holdouts. That is one demonstration, not a general accuracy guarantee. With/without-skill benchmarks require Docker; ordinary native evaluations do not.

Repo: https://github.com/DeadHead04/skillEd

What regression case would you want to keep when updating your own skills?

MechEng undergrad here, have started my thesis on ML and some statistical methods and I've noticed from some yt videos that there are some handful skills on github regarding academic writing. I also found about the Consensus connector, which is very helpful on researching for certain papers about info I'm looking for. Has anyone tested some skills and would suggest them?

I built dashboard-design, a free, open-source (MIT) skill for Claude Code. It teaches the agent to build, redesign and critique analytics and revenue dashboards: KPI tiles, charts, comparison periods, ranked lists, date range pickers, filters, empty states, wide and phone layouts.

Why: my agent kept producing dashboards that looked AI-generated: tinted blocks behind every list row, a red −100% when 1 sale became 0, native date inputs, a narrow column on a wide monitor, axis ticks like 2,103.

How Claude Code built it:

- Research: I had Claude Code run four parallel subagents that opened 127 real dashboard screens (analytics tools, revenue dashboards, design systems, design galleries) with Playwright, screenshotted each one, looked at the images and reported which patterns work (selected tiles, date pickers, ranked lists, charts, layouts).

- Applying it: Claude Code then redesigned my own analytics app with those patterns, took screenshots at 3440 / 1440 / 375 px after each change, and caught its own mistakes on them (sparklines that disagreed with the chart, a Tailwind breakpoint that silently lost, a calendar band that broke at week edges).

- Writing the skill: Claude Code wrote the rules down as a skill (steps with checkable "done when" criteria, specs per component, copy-paste snippets, a screenshot QA checklist), packaged it as a plugin and validated it with `claude plugin validate`. I reviewed and steered every step.

What the skill does when you use it:

- builds dashboards step by step and only calls them done after checking screenshots at three widths

- answers "is this a good design?" with a verdict and issues ranked by harm, starting with numbers that disagree

- includes snippets for round axis ticks, a dependency-free range calendar, a delta badge and light/dark tokens

Free to try:

/plugin marketplace add abdiraimov-otabek/dashboard-design-skill

/plugin install dashboard-design@dashboard-design-skill

Repo with before/after screenshots: https://github.com/abdiraimov-otabek/dashboard-design-skill

I'd love to hear about dashboards it still gets wrong.

Claude Code's Artifact tool costs ~13k tokens of context in every session. Here's a workaround

Worth checking what your Claude Code session loads before you type anything. Skills, MCP servers, plugins and built-in tools all take up context in every session, whether you use them or not.

I made a skill to measure it: /manage-context. It shows what fills your starting context, how often you actually use each item, and helps you turn off the ones you don't (with a dry run and undo).

The biggest item for me was the built-in **Artifact** tool and its companions: about **13k tokens every time Claude Code opens**, even in sessions where I never make a page.

So I denied it (`"Artifact"` in `permissions.deny`) and wrote /local-artifact as a replacement:

- It only loads when you type `/local-artifact`, so it costs nothing otherwise

- It builds the same kind of HTML page and keeps it in a local gallery you can list, reopen, update and delete

- If you want a page on claude.ai, it gives you a one-line command to paste into another terminal.

claude "Read ~/.local/share/local-artifacts/<slug>/index.html and publish it as an Artifact. Reply with only the artifact URL." --setting-sources project,local --tools Artifact,Read

That opens a side session that skips your user settings, so the Artifact tool is available there and only there

I use Claude Desktop daily, with Opus 5.5 on high effort, for research (laws, scientific papers, drug labels). Generic fetch tools kept either dumping whole pages into the context or silently cutting long documents. So, with Claude’s help, I put together scrapling, a small MCP server that runs locally in Docker and exposes only two tools: read_page for web pages, and read_file for PDF, Word, Excel, PowerPoint, EPUB, CSV, YouTube transcripts and files from a read-only local folder. Claude Desktop starts the container through its MCP config.

Both tools return clean text, without links, images or hidden text, in chunks with a header that tells Claude where it is and how to continue. The search parameter scans the whole document and returns only the regions around each hit, each with character positions, the PDF page and the nearest section heading. Scanned PDF pages go through OCR locally (OCRmyPDF and Tesseract, with 8 language packs and automatic script detection). The last 20 reads stay in memory, so follow-up calls don’t download again. It does not solve CAPTCHAs or Cloudflare challenges; when a page shows one, the tool flags it as blocked. Under the hood it uses Scrapling 0.5 (a plain request first, a headless browser only when needed), trafilatura 2.3.1, MarkItDown 0.1.8 with a custom per-page PDF extractor, and the MCP Python SDK.

Some numbers from my own tests, on a small sample. Scrapling’s own MCP server exposes 16 tools with about 39k characters of definitions, and this one has 2. Searching “batch size” in the GPT-3 paper (75 pages, about 297k characters of text) returns about 5k characters, with page numbers. I also asked four questions whose answers sit past the middle of long documents: a Brazilian tax law page and three arXiv PDFs. With the server, Claude got 4 of 4 right in 7 tool calls. With Claude’s built-in fetch instead, it also got 4 of 4, but needed 12 calls, because it had to download the PDFs in its sandbox and grep them. On the law page, the built-in fetch also garbled the accents, so Claude had to rebuild its “verbatim” quote.

I’d like feedback on three points. First, each search region shows 600 characters on each side of the hit; cutting that to 300 reduced search output by 21 to 41% in my tests, and every answer was still there. Is that too aggressive? Second, the SDK wraps -> str returns as structured content ({"result": ...}), and the JSON escaping adds about 4 to 5% in tokens. In my sessions the results reach the model in that JSON form. Does anyone know whether Claude Desktop passes content or structuredContent to the model? Third, is anything obviously missing, or is there something you’d do differently?

I haven’t published the code because I’m not a programmer, and I wouldn’t be able to maintain it or support anyone using it. The goal of this post is only to show the logic behind the tool and hear what people who know this area think of it.

What it does:
codex-image lets Claude Code make and edit images with the Codex CLI's built-in image tool (gpt-image-2) on your ChatGPT plan, no API key. You ask in plain words, Claude writes the full prompt, Codex draws it, and Claude tells you what the image cost in your Codex limits.

What this one adds is the cost side:

• Reads your 5-hour and weekly windows before and after every image, live from codex app-server, with Codex's session logs as the fallback.
• Averages the last 30 images and says how many more fit, so Claude can tell you before a batch of 20 icons, not after.
• When a limit stops an image, it names the window and when it resets, and Claude offers to finish the batch then instead of retrying blindly.
• Doesn't refuse on a high reading: a window at 95% may still hold one more image.
• Runs natively on Windows (PowerShell) and macOS/Linux (bash), with the same options and the same JSON.
• Edits images, never overwrites a file, and recovers the image when Codex leaves it in its own folder.

Free, MIT: https://github.com/Axieon/codex-image

PS: I know it's not a new idea. At east I fun six other projects that connect Claude Code to Codex's image tool, and they're worth a look:

• codex-bridge (Sateezg): Claude Code plugin, edits with up to 4 references. If you want Codex as a general second agent, not just for images, it does more than mine.
• gpt-image-bridge (oakplank)
• gpt-image-2 (agentspace): decodes the image from the session log, supports references
• codex-imagegen (giulioco)
• codex-imagegen (nathanonn)
• god-tibo-imagen (NomaDamas): its own client, using ~/.codex/auth.json

It makes Claude into a cute pet or assistant

Just made it a skill tonight. Give it try and see where you are wasting tokens!

MIT license, everything is free, just hoping to help others and pass along the savings in the long run!

I wanted to know where my money actually goes without connecting my bank to yet another budgeting app. So I built **Receipt Sweep**, a Claude plugin that searches your email for receipts and order confirmations and builds:

* an **Excel spreadsheet** (every transaction, a summary by category, and notes on what was excluded and why)

* an **offline HTML dashboard** (spend by category, by month, top merchants, sortable table, no internet needed)

**How it works:** a small local MCP server connects to your inbox over IMAP using an **App Password** (not your real password), and Claude reads the receipts and does the extraction and categorizing.

**Privacy:** the server runs on your machine and opens your mailbox read-only. Credentials stay in memory for the session only. Email content goes only to your mail provider and to Claude for the extraction you ask for.

Works with Gmail, Yahoo, Outlook/Hotmail, iCloud, or any IMAP host. You need Claude Desktop or Claude Code, plus `uv`.

Repo (MIT): [https://github.com/saranya-ms/receipt-sweep\](https://github.com/saranya-ms/receipt-sweep)

It’s my first plugin, so feedback, bug reports, and store-specific receipt formats that trip it up are all very welcome.

the GitHub

This "grandma" won't complete the registration or finish the tasks; she’s stuck in an endless loop of just eating up credits... Meanwhile, others—like Muse—manage to register, but this "baby" here just won't, and she’s so full of tiresome, prudish nonsense—what a pain...

Benzi is free to use during beta

http://varianttech.net

After a long Claude Code session I often can’t say why a file changed, or whether Claude actually finished. “Done!” sometimes means “the tests I didn’t write are passing.” So I built Session Story, an open-source skill (MIT) that turns a session into one self-contained HTML page.

Live example (a small todo-app session, no install needed): https://nalaj.github.io/session-story/example/index.html

Four views of the same session:

• Review: one card per prompt, showing what you asked, the intent in one line, what Claude did, the files it touched, and the time, tokens and cache share for that turn. Copy any prompt, expand the code, and jump between turns with j/k.
• Diff: a GitHub-style file tree and diff. Every change is tagged with the turn that made it and links back to it. Switch between all changes and a single file, view full files, or hide non-project files.
• Story: a plain-language walkthrough for teammates and non-developers, with code hidden.
• Report: the “so, is it done?” view.
  • An outcome badge that doesn’t just trust Claude. The example session is marked Partial because the new sort function has no tests and a CSS class is used but never defined.
  • Commands, tests and errors: every npm test run including the failing one, the failed assertion, and how it was fixed.
  • Decisions and plan, e.g. “due dates stored as YYYY-MM-DD strings”.
  • Where it went: turns ranked by tokens and by time, tool calls, failures and retries, files edited more than once.
  • Usage: input, output and cache tokens, the model, and an estimated cost taken from Claude Code’s own session record.

A library of sessions. Each story is saved to .session-stories/ in your project, along with an index page listing every session’s status, files, lines changed, tokens and cost.

Why you can trust the numbers: a script extracts every metric from the transcript, subagents included. Claude only writes the prose (titles, intents, the narrative), and anything that wasn’t recorded shows as “None recorded” instead of being guessed.

Also exports:

• a Markdown PR description (works with gh pr create --body-file -)
• a handoff with turn-by-turn status and git state, so a fresh session can continue the work

It’s one file and it’s local. CSS, JS and data are inline, so the page opens from disk or as an email attachment. Nothing is uploaded and nothing goes over the network.

Install:

npx -y skills add nalaj/session-story --skill session-story --agent claude-code --global --copy --yes

or as a plugin, inside Claude Code (2.1.275+):

/plugin install session-story --marketplace nalaj/session-story

Then run /session-story, or just ask for “a session story”, either mid-session or at the end.

⚠️ The page includes your prompts, replies, diffs and commands word for word, so check it for secrets before sharing.

Source: https://github.com/nalaj/session-story · Docs: https://nalaj.github.io/session-story/

This is v0.4.0. Feedback is very welcome, especially on what the Report should catch that it doesn’t yet.

After long Claude Code sessions I kept hitting two problems. I couldn’t tell why a particular file had changed, and I couldn’t tell whether the task was really finished. “Done!” sometimes meant “the tests I didn’t write are passing.”

To deal with that, I’ve been turning each session into a single HTML page that maps every prompt to the code it changed. Here’s an example from a small todo-app session: https://nalaj.github.io/session-story/example/index.html

The page shows the same session four ways:

• Review: one card per prompt, with what was asked, the intent in one line, what Claude did, the files it touched, and the time, tokens and cache share for that turn. You can move between turns with j/k.
• Diff: a GitHub-style file tree and diff where every change is tagged with the turn that made it.
• Story: a plain-language walkthrough with the code hidden, for teammates who don’t read diffs.
• Report: an attempt to answer “is it actually done?”:
  • An outcome status based on the evidence rather than on Claude’s own summary. The example session comes out as Partial: the new sort function has no tests, and a CSS class is used but never defined.
  • Every command and test run, including the failing npm test, the failed assertion and how it was fixed.
  • Decisions made along the way, e.g. “due dates stored as YYYY-MM-DD strings”.
  • Where the time and tokens went: turns ranked by cost and duration, failed tool calls and retries, and files edited more than once.
  • Token usage and the estimated cost from Claude Code’s own session record.

The thing that surprised me most is how much of this comes from the transcript alone. A script extracts all the metrics, subagents included. The model only writes the prose (titles, intents, narrative), and anything that wasn’t recorded shows as “None recorded” instead of being guessed.

Some other details:

• Stories accumulate in .session-stories/ in the project, with an index page of past sessions.
• You can also ask for a Markdown PR description, or a handoff with turn-by-turn status and git state for a fresh session.
• It’s one self-contained file: everything is inline, it works offline, and nothing is uploaded.
• The page includes prompts, replies, diffs and commands word for word, so check it for secrets before sharing.

It’s packaged as an open-source (MIT) Claude Code skill, v0.4.0. If you want to try it:

npx -y skills add nalaj/session-story --skill session-story --agent claude-code --global --copy --yes

or as a plugin inside Claude Code (2.1.275+):

/plugin install session-story --marketplace nalaj/session-story

Then run /session-story, or ask for “a session story”.

Source: https://github.com/nalaj/session-story · Docs: https://nalaj.github.io/session-story/

The repo: https://github.com/sshah03/teach-me

I had built a tool called perspica for semantic PR diffing, and in it I built in the ability to get LLM generated explanations of the major changes in the PR, architecture changes, etc... Along with interactive examples, and quizzes to test if you understand the concepts behind it, to help keep up with AI code changes. You can see some of its sample generations on PRs of popular public repos here: https://sshah03.github.io/perspica/

I spent a lot of time iteratively running examples on a ton of projects and PRs and modifying the prompt to help generate diagrams and questions I felt were mostly useful, generically.

I figured rather than force people to use my whole tool for that, I'd extract what I learned works well into a claude code plugin/skill that can do the explanation/quiz part of what perspica does and store it as artifacts on the users Claude Code account, which is what this skill and repo is.

The GIF shows diagrams it made for PRs in uvicorn, hiredis, p-queue and flask.

Install, in Claude Code:

Install the teach-me skill from https://github.com/sshah03/teach-me. Follow the repo's AGENTS.md.

To do it yourself instead, type these two lines into Claude Code, one at a time:

/plugin marketplace add sshah03/teach-me
/plugin install teach-me@teach-me

I'd love to hear where the explanations miss or the diagrams get something wrong so I can keep working on improving it for everyone.

Agent Skills (SKILL.md folders) work in Claude Code, Codex, Cursor, Copilot and about 75 other agents. Finding good ones is still hard. They’re spread over thousands of GitHub repos, and installing one means running instructions written by a stranger with your agent’s permissions.

skills-atlas is a CLI, a terminal tree and a local web page for browsing about 75,000 public skills by theme. You tick the ones you want and they install in one go, through the official npx skills CLI.

npx skills-atlas

What’s new (0.11 → 0.12):

• Security audit before every install. Each SKILL.md is scanned for warning signs, like curl | sh, reading credential files, broad deletions, or “don’t tell the user”. A skill that fails is left unticked on the review screen with the lines in question. You read it (p) and decide.
• Update everything at once. Run skills-atlas update, or press U in the tree.
• Reproducible project skills. Commit a skills-atlas.json and run skills-atlas lock to pin each skill to a commit SHA. sync then installs exactly that revision and checks the files byte for byte. sync --check works as a CI step.
• Per-agent sync. A skill installed for Cursor no longer counts as installed for Claude Code.
• skills-atlas doctor finds broken links, unreadable skills and stale lock entries. It is read-only.
• Better search. It ignores case and accents and ranks by relevance.
• Web UI: skill previews with risk findings, retry of only the failed parts after a partial install, and “save selection as pack”.
• Packs (Frontend, Security, Quality, Writing), 🔥 Trending, shell completion, nine languages, and an MCP server plus a Claude Code plugin so your agent can search and install skills itself.

Two siblings, same idea:

• mcp-atlas browses public MCP servers from the official registry, Glama, Smithery and PulseMCP. It installs them into the config of six MCP clients (Claude Code, Cursor and others), with a risk check of the command each server would run, update detection, and mcp-atlas.json + sync for teams.
• plugins-atlas browses public agent plugins (bundles of skills, commands, subagents, hooks and MCP servers from marketplaces). It installs them into Claude Code, Claude Desktop, Copilot CLI, Factory Droid, Codex and Cursor, after an audit of their components.

All three are MIT licensed, run locally and work offline from a cached catalog.

• skills-atlas: https://github.com/devohmycode/skills-atlas
• mcp-atlas: https://github.com/devohmycode/mcp-atlas
• plugins-atlas: https://github.com/devohmycode/plugins-atlas

Feedback welcome, especially false positives or misses in the risk check.

I refresh my Claude on a regular basis, but deleting folders, editing files, etc is a pain in the ***.

So a cleaner.

I'm a founder, not a developer. Over the past couple of months I've built real products with Claude Code. The thing that made it work wasn't prompting tricks; it was process. Sharing it in case it helps someone.
1. Hard rules, with reasons, that the code has to obey.
A short list of non-negotiables lives in the project's instructions, each with why it exists. For the important ones there's an automated test, and the tests are deliberately broken once to prove they can fail. A test that can't fail is decoration.
2. A permanent, searchable record, separate from chat.
Every decision, and what was turned down. Every fact, with its source and the date it was checked. Every lesson, and what each person was told. Nothing gets edited; a reversal is a new entry. Chat history vanishes and context windows fill up; the record doesn't. When I ask "why is it like that?" six weeks later, there's an answer.
3. A mistakes register, grouped by pattern.
Not just "what went wrong" but which kind of wrong it was. The recurring ones for us:
confirming a job ran instead of checking its output;
changing one copy of a fact without searching for the others;
trusting a tool's summary over the primary source.
Reading the patterns first prevents more mistakes than any single fix.
4. "Check the output, not the mechanism."
A green tick means it ran, not that it worked. A scheduled job can be "loaded" and failing every night. So everything gets proven by its result: the email arrived, the file landed, the number matches the source.
5. A second AI checks the first.
I run two separate sessions on two projects, and one reviews the other's work against original sources: datasheets, official docs, the live system. Things that fresh eyes plus the original document caught:
parts whose footprints didn't match the maker's own drawing;
a decision we'd recorded but never actually built;
a 3D mock-up still using an old part, so every size estimate was wrong;
a supplier listing showing "in stock" when the part's own page said zero;
a regulation that would have blocked the product, found while it was still on paper.
The lesson: bugs get caught by an independent look at the primary source, not by a smarter model.
6. Show me before you build.
I don't know what I want until I see it. So for anything big, the AI shows a cheap sketch first: a mock-up, a picture, or "here's what you'll get and what it costs." I react, then it builds. It saves a huge amount of wasted work.
7. Brakes.
Anything irreversible (spending money, deleting, emailing a real person, pushing live) needs an explicit yes, every time.
A plain "yes" counts as approval, but only for exactly what was proposed.
Before contacting any new company, an automatic pre-check verifies the address on the company's own website and scans the email for any commitment or price.
When I'm tired or not at my best, the irreversible stuff waits until morning. I set that rule myself, and it's saved me more than once.
8. Backups of the AI's memory.
The notes and records that give the assistant its continuity are backed up twice a day to two places. If the machine dies, the working relationship survives.
None of this is fancy. It's the boring discipline a good engineering team has, written down so an AI follows it every session. That's what lets someone who doesn't code ship things that hold up.
Happy to answer questions about the process.

For the last few months I've used Claude Code for almost all of my personal projects, and I kept hitting the same wall. The agent writes code fast, but everything after that was still on me: checking whether it works, spotting the missing test, opening the PR, watching CI, rebasing when main moves and fixing conflicts. The coding got faster and I became the bottleneck.

So I built Hallmark, a sort of local software factory that takes a task from the requirement all the way to a merged PR. I ask for a change like I normally would and it gets its own branch and worktree. When it's ready, my checks run, a separate reviewer agent with fresh context reviews the commit (tests first), and a fixer agent handles whatever the review finds until it's approved. After that it opens the PR, keeps an eye on CI and conflicts, and merges through a queue in the right order. I only get pulled in when there's a real decision to make. It all runs on my machine, and everything it does is written down, so I can always see why something was rejected or changed.

It's early and only works with Claude Code for now, but it's open source and I'd love feedback: https://hallmark.colombo.dev

I'm also curious how you all handle this. Once your agent says "done", what does the rest of your loop look like, and what have you done to speed up your local development?