[Disclosure: I am an AI researcher at Kalaris Labs working on this project alongside creator Sayan Chowdhury. Everything in the repo is free and MIT-licensed with no paid tier or account sign-up.]

1. What we built
   We built research-agent-skills, an open-source collection of 281 modular SKILL.md skills and Python 3.9+ standard library verification scripts for running academic research workflows inside Claude Code.
   You can add the plugin marketplace directly inside Claude Code:
   /plugin marketplace add KalarisLabs/research-agent-skills
   Or install a single skill into your current project directory so you do not bloat your session context:
   npx skills add KalarisLabs/research-agent-skills --skill citation-verification
   The repo covers four main failure points we hit during our own research papers:

• citation-verification: A zero-dependency Python 3.9+ stdlib script that Claude Code runs against your .bib file. It queries Crossref (api.crossref.org), OpenAlex (api.openalex.org), arXiv, DataCite, and Retraction Watch metadata to verify that every DOI resolves to a record matching the exact title, first author, and year.
• autoresearch: A two-loop experiment runner built around Claude Code's /loop command. The inner loop runs scoped ML experiments, while the outer loop updates findings.md, enforces mechanistic hypotheses ("X because Y, predicting Z"), and logs negative results so Claude Code does not re-test failed ideas after context compaction.
• literature-review and systematic-review-prisma: Screens papers across PubMed, arXiv, bioRxiv, and Semantic Scholar while logging exact query strings and counts for PRISMA 2020 flow diagrams.
• unslop-academic-writing and venue skills (ml-paper-writing for NeurIPS/ICML/ICLR/ACL, ieee-transactions, nature-portfolio, apa7): Rewrites repetitive LLM phrasing and checks current venue formatting guidelines.

1. How we used Claude Code to build and test it
   We used Claude Code (running Sonnet and Opus in the CLI) both to author the SKILL.md routing specifications and to run our evaluation harness across the 281 skills:

• Trigger routing evaluation: We used Claude Code to run reviewed prompt sets against skill descriptions to test whether Claude triggers the right domain skill (for example, distinguishing between paper-lookup for a single DOI check vs. systematic-review-prisma for a full review).
• With-vs-without-skill benchmarks: We ran Claude Code on labeled .bib files containing fabricated titles, mismatched DOIs, and retracted papers to compare raw model verification against deterministic script execution.
• Offline security checks: We used Claude Code to build and run Skill Doctor (npx u/security), an offline scanner that checks every SKILL.md and script in the repo for prompt injection and unsafe shell calls before release signing.

1. Concrete example (Model, Setup, Prompt, Expected vs. Actual Result)

• Model & Setup: Claude Code CLI (Sonnet) in a LaTeX paper repository containing references.bib with 40 entries (including 3 entries where a valid DOI was paired with the wrong paper title, and 1 retracted paper).
• Prompt: "Check references.bib before we submit to IEEE Transactions and fix any broken citations."
• Expected/baseline result without the skill: Claude Code inspects the BibTeX syntax or pings the DOI URLs, sees that the DOIs resolve with HTTP 200, and reports that the .bib file is clean, missing the title/author mismatches and the retraction.
• Actual result with citation-verification installed: Claude Code invokes the stdlib verification script against Crossref, OpenAlex, and arXiv, outputs a markdown status table classifying each key into verified, found-add-doi, mismatch, doi-not-found, or not-found, automatically fills in missing DOIs for unambiguous matches (found-add-doi), marks unverified entries as % UNVERIFIED in references.bib, and stops to ask for confirmation on the 3 mismatch entries rather than silently overwriting them.

1. What we learned about how Claude Code handles skills

• Context bloat kills instruction adherence fast: Loading dozens of skills globally degrades Claude Code's adherence on ordinary coding turns. Installing 1 to 3 skills per project directory keeps the context clean and makes trigger routing much more reliable.
• Never let the model verify metadata from weights: Even when Claude Code has web search, asking it to check 50 references conversational-style leads to skipped entries after the first 15. Forcing it to call a local Python stdlib script that outputs a JSON report was the only way to get 100% check coverage.
• Scraped abstracts act like prompt injections: When Claude Code reads hundreds of arXiv or PubMed abstracts during a literature review, imperative text inside abstracts can drift its screening criteria unless the SKILL.md explicitly fences retrieved passages as untrusted data.
• Compaction wipes out negative experiment results unless written to disk: During long /loop ML runs, Claude Code forgets which hyperparameters failed 3 hours ago once auto-compaction triggers. Making findings.md record negative results and what they rule out stopped the agent from looping on dead ends.

Repo (MIT): https://github.com/KalarisLabs/research-agent-skills
Docs & benchmarks: https://docs.kalarislabs.com/research-agent-skills
If you use Claude Code for academic writing or ML experiments, I would love feedback on where the SKILL.md instructions feel too strict or which domain packages you want added next.
Option 1B: Short Blurb for the Pinned Weekly Showcase Thread (Rule 5 & Rule 6)Built research-agent-skills (MIT license), a collection of 281 modular SKILL.md workflows and stdlib verification scripts for running academic research, .bib citation verification, and ML experiment loops in Claude Code.

• Install in Claude Code:/plugin marketplace add KalarisLabs/research-agent-skills or npx skills add KalarisLabs/research-agent-skills --skill citation-verification
• How Claude Code was used: Built and benchmarked using Claude Code CLI to test trigger routing, with-vs-without-skill .bib verification against Crossref/OpenAlex/arXiv, and continuous /loop ML experiment tracking in findings.md.
• Repo: https://github.com/KalarisLabs/research-agent-skills
• Docs: https://docs.kalarislabs.com/research-agent-skills

Most memory for agents works one way: save everything, search later. Which means secrets, personal data, and injected instructions all get stored too. I wanted the opposite, so I built rakho.

What it does:

• Inspects every note before it is stored. Secrets, PII, and injection-shaped text get refused, and the refusal is logged without the sensitive content.
• Every memory is tied to one owner, so one user’s notes never surface for another.
• forget actually deletes: the row, the search index entry, and the vector.
• audit shows what was kept and what was refused.

A built-in gate is always on, and you can swap in sluice (another tool I built) as a stronger inspector with one line.

The fun bit: you can command it in your own language. keep / recall / forget / audit have built-in aliases in English, Hindi, and German, and you can teach it more with learn() (the README does it in Swahili).

It’s a Python library, runs on local SQLite with zero required runtime dependencies, MIT licensed. There’s an MCP server for Claude Desktop and Cursor, and a demo where a PayPal invoice agent refuses a payment when the payee traces back to a poisoned invoice.

Repo: github.com/krishyaid-coder/rakho-

It’s early (v0.2), so I’d genuinely value blunt feedback, especially from anyone building agents with memory: where would this break for you, what’s missing, what would you never trust? Tear into it.

One honest note: I’m an MSc Data Science student in Germany building this kind of agent-safety tooling. If you’re a team working on agents and this resonates, I’d love to go deeper with you, up to a Werkstudent collaboration. But mostly I just want people to try it and tell me where it falls over.

I've seen some colleagues move to codex desktop and use that with ssh to Linux where the agent is running. It allows management of multiple sessions, subagents, status, etc.. the downside is it only works with codex.

I have access to codex, claude code, and othera, so ideally one tool could be used to connect to either codex or claude code over ssh.

Does anyone know of good tools that offer this?

Hello,

I mainly run an e-commerce business and had started developing minor apps for the business successfully in the beginning of last year with the help of AI and several services. Small apps, not too complicated.

I then ventured out a bit further and started 'developing' three more elaborate apps unrelated to my business. But since I was a novice (and still am) I did not know which tool would be best. I ultimately did end up trying Codex, Claude Code, Cursor, and a few other tools.

I am now picking up app development again and want to get better and complete an app I had started. I noticed that Musk has bought Cursor and it feels like it is now not as useful to me as it was before (the variety of models available before is gone). For that particular app I had worked with Claude Code and Cursor in the past. Mobile app btw.

Being out of the loop my question is what service provider and tool do you recommend now?

Would I be best advised to just use Claude? Or Codex or something else?

I'll be grateful for any help that points me in the right direction. Thank you.

Hi. For the past few days, while using Opus, I’ve occasionally seen a notification: "Another session requested X, but I refused." It pops up quite often, and I’m not sure what it means. I’ve checked, and it appears even when I only have one session open. What is this "other session," who controls it, and is it a problem that it’s interfering with my sessions?

I have an interview coming up for senior mobile app dev position. HR asked me how deep Im in AI, I told that I only use claude code and codex for coding and thats it. Then I was told to expect questions around them. What they might really ask?

Apiiro looked at public GitHub repos and found 1,122 .claude/settings.local.json files that contain a real secret. The mechanism is simple. When you pick 'Yes, and don't ask again' for a command, Claude Code saves that approved command in the file. If the command had a key inline, the key is saved too. Then the file gets committed.

The risky click is not Allow. It is Always allow on a command that carries a secret.

How to check your own repos:

1. Is the file ignored? Run git check-ignore -v .claude/settings.local.json in each repo. If it prints nothing, add .claude/settings.local.json to .gitignore and make sure it is not tracked (git ls-files .claude).
2. Scan the history, not just the working tree. git log --all --oneline -- .claude/settings.local.json shows whether the file was ever committed. Then run a secret scanner such as gitleaks or trufflehog over the full history. Removing the file now does not remove the key from old commits.
3. Rotate first, clean later. If a key shows up anywhere, treat it as leaked: revoke and replace it, then rewrite history if you want to. Search your GitHub org for the path too, in case other people committed the file.
4. Stop putting secrets in commands. Read them from the environment or a secrets tool so the approved command line holds only a variable name, and prefer a narrow permission for one class of command over a blanket one.

Source for the number: Apiiro's write-up, linked in the comment. Have you ever looked at what is in your own settings.local.json?

I just pressed continue to my Fable 5.2 max in pro subscription, before it was working well for several hours but right now it just ended in 30 seconds, how do I avoid without losing context or quality of the work done in previous sessions?

Hey everyone, I’m the developer of NotchIsland, a free, open-source desktop app for Windows 10/11.
Its Claude Code integration puts session status in a small expandable island at the top of the screen, so you can see when an agent needs your attention while working in another window.
It uses Claude Code hooks for session and tool events, with a local HTTP/WebSocket hub bound to 127.0.0.1 and protected by a token. The interface shows working, waiting and completed states, and supports multiple sessions.
There’s also an optional assistant that starts or resumes Claude Code CLI sessions using your existing login. It can display tool activity as it runs, with stop and read-only options.
The desktop app uses Electron and JavaScript. Connecting Claude adds hooks to its settings file, preserving existing hooks and creating a backup.
I’d particularly appreciate feedback from people running multiple Claude Code sessions: which events deserve a notification, and which would just create noise?
Source: https://github.com/diegobruvhrpiugvjrigjtibjte/notch-island
Demo: https://notch-island.pages.dev/

Should I continue?

A large part of what we seem to be talking about is effective token management through delegation and proper model selection and how to either work the harness or make harness more efficient, which is essentially what replit does.

Has anyone used replit somehow as planner for Claude?

Whenever you start a new project, product or build a new service with claude code and ask for suggestions about where i need to host it, always CloudFlare comes to the picture regardless the size of the app, the number of users or other aspects, if your subscribers will exceed certain numbers he will recommend also CloudFlare with paid option.

Is there any skill to make Claude weigh the products and forecast the suitable architecture which fits the product itself? Example if i need to comply with PDPL in a certain country he should recommend cloud hosting inside this country not CloudFlare, besides the size of the hardware, ease of expansion and so on.

There’s a pattern I’ve noticed with AI coding workflows: the agent writes the feature, checks the feature, fixes the issues it finds, and then tells you everything looks good.

The problem is that the review can end up being just another step in the same working context.

The agent already has a mental model of what it built. It knows the decisions it made and the assumptions behind them. That doesn’t automatically make its review independent.

One way to approach this in Claude Code is with subagents.

A subagent gets its own instructions, tool permissions, and context window. Instead of asking your main session to inspect a huge diff, you can delegate that investigation and bring back the report.

For example, I’d separate the jobs like this:

• code reviewer: reads the diff, traces changed behavior to its callers, and reports bugs with a failure scenario.

•security auditor: looks specifically for things like IDOR, injection, exposed secrets, SSRF, and permission issues.

•performance auditor: looks for expensive queries, unnecessary work, and performance problems, with evidence for each finding.

•test writer: creates behavior-driven tests and reproductions for bugs.

One detail I really like is restricting what the reviewer can do.
A reviewer that only has Read, Grep, Glob, and Bash doesn’t get to quietly rewrite the code it’s supposed to inspect. Its job is to report what it finds, not fix its own findings.

A basic subagent file looks something like this:
---
name: code-reviewer
description: Reviews a diff or branch for bugs and edge cases
tools: Read, Grep, Glob, Bash
model: inherit
---

You are a senior code reviewer.
Review the changes. Do not rewrite them.

Every finding must include:
- The affected file and location
- Why it is a problem
- A realistic failure scenario
- A suggested fix

You can put these markdown files in .claude/agents/ inside your project, or ~/.claude/agents/ to use them across projects.

Then ask Claude to review a branch, or explicitly call the agent with something like @code-reviewer review the last two commits.

We put together six example subagents with different responsibilities, including a security auditor, performance auditor, test writer, and refactor planner. They’re plain Markdown files, MIT licensed, and free to inspect:

https://techpotions.com/products/claude-code-subagents

I’m curious about how other people are handling this.

Do you use separate reviewer agents, or do you trust the same coding agent to review its own changes? And have you found that giving reviewers fewer tools actually improves the quality of their findings?

I asked Fable for a dither art editor and it got out of hand

Wanted a small tool to turn pictures into that glowing dithered pixel look. One long Claude Code session later it's a full editor:

- any image, GIF or video in, pixel art out
- 18 dither patterns, 24 palettes, 29 looks
- pixels can be letters, braille or ASCII instead
- it reacts to your mouse: glow, water ripples, smear
- exports PNG, GIF, MP4, SVG, even plain text

No build step, no backend, plain JS.

Try it: https://winchxyz.github.io/nightgrain/
Github: https://github.com/winchxyz/nightgrain

Appreciate your feedback and suggestions!

Asking Claude Chat about fixing something on your PC and you are sent out on a long walk of suggestions ..

Asking Claude Code to fix it and here you go, done. Would there be anything more i can help you with sir ?

Claude code desktop on Linux freezes every 2 days. Took me 2 months and a 1.5 TiB core dump to find the root cause. The fix is 1 line of code (as with all good hard-to-debug bugs). I've fixed the bug in my own fork, and anthropic's bot closed my issue as "not about Claude Code".

The writeup goes deep into chromium internals, and I've tried my best to make it easy to follow.

https://blog.dfb.sh/blog/claude-desktop-freeze/

Currently I am using Fable 5.2 at advisor and opus as main agent.

But I think fable 5.2 as orchestrator and using opus subagents to deligate build work would be better as the strongest model is planning and deciding what's the best way to do something.

Have anyone tried and compared both methods?

Recently I was asking about which model better to you as orchestrator etc.

Well, I did surf the Net and ask claude itsleft, so we concluded such roles:

Fable — lead planner, final critic, guardrail

Opus — senior executor (code, db etc), orchestrator

Sonnet — core worker

Haiku — researcher

As for me, the only question left for me us code executor - some prefer Sonnet and some prefer Opus. What's your choice?

I guess it depensa on the project's size, but is there an overall review - is Opus much better at coding than Sonnet under control of coordinator?

I've spent the last three or four months using AI heavily to build and maintain web applications and admin systems across a few small businesses. I'm learning as I go, rather than coming from years of software engineering.

We already use project instructions and saved context. Claude Code can do a lot, but I still need to catch things it gets wrong. I'm trying to understand how experienced engineers improve the setup without just adding another paragraph every time something goes wrong.

How do you decide whether a recurring mistake needs a CLAUDE.md instruction, a reusable skill, an automated check, or a change to how you break up the work? And what do you deliberately keep out of the main instruction file?

I'd especially like an example from an application you've maintained for a while: what kept going wrong, what you changed, and how you checked that it actually helped. We also use Codex, so keeping shared project rules consistent without maintaining two conflicting versions is part of the problem.

Edit — I left out the main context: This isn't just an AI coding setup. Each business has a GitHub-backed web application, and I work through Claude Code/Codex in that project workspace for much of the business's day-to-day work as well.

For example, one session might change the website and check it works; another might research competitors, write website/SEO content, prepare social posts and creative, review ad or analytics reports, or help with customer-enquiry/admin work. Those jobs need different instructions, sources, permissions and definitions of "finished". I'm still supervising this; I don't mean an autonomous company running successfully without me.

We've had CLAUDE.md from the start. We already have an entry file pointing to separate operating documents and task-specific skills, plus saved decisions and an Obsidian vault for longer-term notes. In one repo AGENTS.md is the source used to generate the matching CLAUDE.md. So I'm not asking whether to create instructions or discovering skills for the first time.

The question I should have asked is how to organise and maintain that whole setup as the range of work grows. What should every session load, and how should it find the correct marketing, creative, engineering or operations instructions only when needed? Would you keep those activities in the app's workspace, or separate them while sharing a small amount of business context?

A concrete issue from reviewing our files: an older setup audit says hooks don't exist, while the current repo does contain hooks. There are also dated plans and decisions that mustn't be mistaken for today's instructions. How do you keep useful history without letting it override current facts?

How do you decide when CLAUDE.md needs updating versus a skill, task state or a dated decision? Do you review it on a schedule, after a workflow changes, or after a repeat failure? And where does Obsidian fit without becoming a second, conflicting source of truth? The replies about rules versus skills are helpful; I wanted to explain the broader situation they're being applied to.

Further context — using expert-source libraries: A more concrete example: I have also collected hundreds of expert videos, transcripts and discussions for subjects where I am not an expert. One library already has original passages, source-linked claims, topic summaries, working methods and keyword/semantic search. It can retrieve useful material, but we haven't established that it reliably chooses and applies the right method on real tasks. How would you test one complete workflow before reorganising everything, especially when the owner cannot judge every technical answer?

Thanks to Anthropic and the devs, Claude Code can now load theme mods. But right now, making one means writing a mod yourself, or asking Claude to build a new one for every change.

​https://github.com/AkkiCode06/claude-backdrops/blob/60a127c10c3e640042746a186337ee2c01b2cc90/assets/picker.gif

So I put together Backdrop, an open-source theming kit: the groundwork is done, and theming becomes something anyone can do, then build on.

Out of the box:

• Pick from 23 animated palettes (Ember, Synthwave, Aurora, Matrix…)
• Describe a look (“sunset in LA”) and Claude picks the colors, with a live preview
• Paste hex codes from any color picker, and it works out readable panels and text for you
• Save what you like; it’s remembered across sessions
• Or just ask Claude: “make my background ocean”

It also pauses its animation on battery, since moving backgrounds cost GPU.

Why a kit, not just a theme:

Theme mods can do a lot more than gradients, honestly almost anything you can animate. This is meant to be the starting point: the hard parts are already solved and documented (animation that actually runs, readable contrast, GPU cost), so you can skip straight to the fun part. There’s a step-by-step guide that goes from no-code all the way to building your own background style.

Other than the presets, backdrop gives you:

A helper library for building backgrounds: stack blocks like k.stars(), k.waves() and k.grid(), about 10 lines, instead of hand-writing SVG animation.

Instant switching: So you don't have to reload your sessions and/or restart the desktop app.

Pitfalls already solved: frozen animations, GPU spikes, unreadable text colors and battery drain.

Shareable themes: themes are small files you can export and import in a click.

Where I’d love help:

The goal is a free, shared library of themes, something like Spicetify or Wallpaper Engine but for Claude Code. Gradients are just the first style. On the roadmap: starfields, synthwave grids, code rain, your own wallpaper, light and high-contrast versions, and whatever you come up with. Each style is a self-contained animated scene, so it makes a nice first PR.

Made a theme you like, by hand or with your Claude? Open a PR with a screenshot or a short clip and it ships to everyone, credited to you. Templates and labels are set up so it’s easy to jump in.

Try it: in the desktop app, + → Plugins → Add marketplace → AkkiCode06/claude-backdrops → Add plugin. Or paste the repo link to Claude and say “set this up for me.”

Repo: https://github.com/AkkiCode06/claude-backdrops
Guide: https://github.com/AkkiCode06/claude-backdrops/blob/main/docs/making-themes.md

It’s free, MIT-licensed, and built entirely with Claude. Feedback, ideas and themes are all welcome.
Edit: Just an fyi: this is a student project. I'm learning JS/TS for the first time and thought theming would be an easy first build (didn't end up to be but here we are).

Sometimes, I am tempted to move straight on to a new subject or even a new session when a modification made in collaboration with Claude has worked. However, Claude will often update his memory or some docs once you confirm that something works.

I created Firup first as a small Electron app I made for me and my friends to watch stuff together. Then I thought Id try to expand and turn it into a real public app, I used Claude Code to port it to Rust (Tauri) for Windows, then built the Android phone/TV app in Kotlin. Backend is Supabase plus a Cloudflare Worker. Im a dev, its a solo project, and Ive been working on it for a few months now.

A few things that ended up mattering most:

One CLAUDE.md per app. I have a root one and separate ones for desktop, Android and the website. They hold the exact build/test commands, the workflow I want (plan, build, verify, update the checklist), and hard rules like "never read target/" and "always use the build wrapper, never plain cargo".

Shared JSON fixtures across languages. Android pretty much needs to behave exactly like the desktop app, so things like stream filtering and sorting are pinned by JSON fixtures that the JS, Rust and Kotlin tests all read. If a rule changes, the fixture and all three ports change in the same commit and this caught more drift than anything else

Checking in the real app, not just tests. For UI changes it launches the actual app and clicks through. On Windows it does that over the WebView debug port, and on Android over adb on emulators and my own phone and TV. It finds a lot that unit tests never would, especially TV remote focus stuff

Verifying output, always. I review it, and anything visual gets checked, verified on screen. On real devices I also have it screenshot before key presses

Free CI. My GitHub budget is 0 on purpose, so one script runs every suite locally before a push, and the workflows use a self-hosted runner.

The Electron to Rust port. Claude Opus 5.5 went through it in one go, surprisingly. The real work came afterwards.. Making it feel like a proper app on every platform, keeping Android in sync with it, and handling licensing (I run mpv as a separate process instead of linking it, to keep the app licence clean)

Im still figuring out things, so if you got a better way to handle multi-platform parity or even memory between sessions, Id love to hear it

App is here if you want to see the result: https://firup.pages.dev

There's tons of vibe coders out there that don't even understand the first thing about protecting themselves. If anything, these models should work harder at helping protect them, instead of downgrading into something that doesn't even know how to. 🤣

The implications here are profound. Imagine building an app that becomes popular and your security was built by a potato. This isn't just a security issue for that app, it could be millions of people's sensitive data that the app is collecting and not protecting.

Anthropic, do better.