A few weeks ago I shared a free Claude Code skill for building clean, honest dashboards. Thanks for all the feedback, it got way more attention than I expected.

Then I used it on a real project: the home dashboard of a school management system. The result was honest. Every number agreed with every other number, the QA pass checked 18 cross-totals. And I hated it.

It was a page of sentences. A line under every KPI explaining the number. A row of "insights" written as sentences. A note under every chart. It read like a report, and a school director doesn't read, they scan. The worst part: those were my skill's own rules ("one muted sub-line that explains the number", "an insights line of plain sentences").

So I went back to the sources:

• Stephen Few: Information Dashboard Design's 13 mistakes, his papers on colour rules and the bullet graph spec
• Tufte: data-ink, sparklines
• Cleveland & McGill via Nielsen Norman Group: which encodings people actually read accurately
• Datawrapper on sequential vs diverging vs classed colour scales
• Six of Apple's WWDC sessions on charts, chart accessibility and interface writing
• A dashboard designer whose work I admire, for how a page can say everything with numbers and shapes

What changed in v2

• Wordless: names, numbers, units and a one-word baseline ("▼ 15% vs Sep") on screen. Every explanation goes in a tooltip. The QA pass now counts sentences. Target: zero.
• Monitor: overview → what needs attention → closer look → act. Problems are flagged on the data itself, and the action sits on the flag (a "not marked yet" heatmap cell is the remind button).
• Inverted salience: a plain light-to-dark heatmap makes the worst cell the palest when low is bad. v2 uses classed tiers where intensity grows toward the problem, plus a non-colour cue for colour-blind readers.
• New components: heatmap, bullet graph (Few's spec, replaces gauges), segmented share bar, one tooltip system.
• New QA: a salience test ("where does the eye land first?"), real messy data, colour-blindness emulation, plus the old "known totals" check.
• A case study of the school dashboard in three versions, including the one I rejected.

How I tested it

I gave a fresh agent only the new skill and asked it to build a dashboard for ad buyers running Meta/Google campaigns for several clients (screenshots above, fake data, UI in Uzbek). It came back with a clean page: CPL heatmap per client per day, budget runway as bullet graphs, problems in amber, 0 sentences, all totals checked.

It also found real flaws in the skill: a contrast bug in my own heatmap snippet (accent text on accent tint, 3.1:1), two layout rules that contradicted each other, no rule for "neutral" metrics like spend. All fixed before release.

Install

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

Already installed? Run /plugin marketplace update dashboard-design-skill

Repo (MIT, free): https://github.com/abdiraimov-otabek/dashboard-design-skill

Works with SwiftUI too. Happy to hear where it breaks for you.

If I had to create agents or sub-agents how do I do it. And when would I know if I have to create and agent or sub-agent.

If I had to create a whole team of agents, lets say a software team a product management team. A team to help in content and marketing just for an example how would that go?

I have tried it and told claude to do it from time to time, but never end up using it cause the output or the specification dont match. I feel like something is wrong in the way I am doing things. Any advice or insight would be appreciated. Thanks

Tired of seeing huge cache read/write numbers in ccusage? 👀

Meet Cctoken-saverr , a lightweight skill to help manage /clear, /compact, context usage, and cache costs.

🚀 Give it a try, share your results, and let's discuss what actually works! Contributions, suggestions, and open discussions are welcome.

GitHub: https://github.com/V-inaya-K/cctoken-saverr

Every new session picked up the rules from CLAUDE.md, but not what the last session found broken, left half done, or needed to ask me. I'd re-brief or drag various gitignore'd files around to carry state.

So I built symbion: a notebook and ticket registry that lives in a git repo beside the project. The video shows the loop:

1. At session start, a hook hands the agent what is open: bugs, tasks, its unanswered questions, anything due.
2. It works them, and resolves a bug against the commit that fixed it.
3. When it needs a call from me, it files a question with options. I answer with one click in the browser, or from the terminal, and the next session acts on the answer.
4. /symbion wrap ends the session with a commit whose message is the next session's handoff.

A test result also knows its age. A check records what ran, what it said and the commit it ran at, so a week later it reads behind 12, not "tests pass".

Live demo of the browser view (read-only, a real project's notebook): https://symbion.nullphase.net/

Repo, free and MIT: https://github.com/phreakocious/symbion

How Claude helped: Claude Code wrote most of the code, with me directing and reviewing. symbion has tracked its own development since September: Claude files its bugs, tasks and test runs in it, and asks me its questions there. Before each release, fresh Claude agents read the whole diff for anything that should not go public.

It also works with Codex and Hermes Agent. No MCP server and no account: a CLI, a skill file and two hooks.

How do you carry a session's unanswered questions over to the next one?

I have a background as a CTO and I'm a founder of a small SaaS. Claude Code has been my buddy for a while and over time, I've found that there's a specific workflow that yields the best results for us. So I had Claude Code turn our company's development workflow into a Claude Code plugin that does spec-driven development that doesn't stop at the code. We've used it enough internally, with really good results, that I've decided to open source it under the MIT license: https://github.com/Beakpoint-Insights/roost. It is free to use.

Give it a try

/plugin marketplace add Beakpoint-Insights/roost
/plugin install roost@roost
/roost:setup

What it does

You give it an idea, described in a way that you might say it is the title of an "epic." For instance, "Let customers invite teammates to their workspace."

It then shapes that idea into an epic, asking you clarifying questions along the way. It stores the epic in your issue tracker (for us, Jira). Part of this "epic shaping" is that it creates vertical slices as stories, creates Cucumber tests (and stores them in Jira), and links the stories to their tests.

It pauses from time to time to let you double check that everything is the way you want it: do you like the way it sliced up the work? Do you like the test cases it wrote? That sort of thing.

When you're ready, it builds the epic slice by slice. Each slice is its own PR. If the slices touch multiple repositories (like an API repo and a UI repo), it knows how to handle that. It automates the Cucumber tests as it goes. It prefers TDD. We like GitHub's stacked PRs, so each slice is added to the stack. As it gets ready to close out each slice, it does code reviews and unstructured exploratory tests. It reports back any bugs it finds, and recommends whether those bugs get fixed in the current slice, in a future slice, or deferred until after the epic is released.

When the whole epic is done and ready to be released, it does a final walk through of all the end-to-end tests you've defined and another round of unstructured exploratory testing.

When you're ready to roll it out, it presents a rollout plan and does a "paired rollout" with you. It gives you commands to run or tasks to do (e.g. "Create products X, Y, and Z in Stripe"). You share the results. It documents your progress. And voila, it's released.

How Claude Code helped

• I told it to watch all my Claude Code sessions over about a 2-3 week period. It discovered patterns to how we developed and collected those patterns into the different phases of the SDLC.
• We started at the most inside level of the matryoshka dolls in each phase of the SDLC ... things like writing a test case or building a well-defined feature or running an exploratory test. We built each of these standalone skills, having an orchestrator (aka "team lead") session send the instructions to the agent working on the API or the UI or the architecture, etc. We continued to tune these skills until they were working well.
• We then built new skills that managed the orchestration ... like how we would move from building a vertical slice to doing the exploratory testing to filing the bugs that came from the exploratory testing to triaging them, etc.

Today's limitations

It isn't yet perfect, and we have some known limitations. All of these limitations are on the roadmap to be addressed:

• It wants you to use Jira for issue tracking and Xray for testing.
• It wants you to use `gh stack` throughout the epic.
• It has only received limited testing outside of our own tech.

Next steps

1. Give it a try.
2. Post feedback to GitHub discussions

The old friction hasn’t gone anywhere.

I learn much better by listening than by reading. Podcasts work really well, but when I want to learn something specific, finding material and figuring out what to trust takes forever.

I was trying to learn more about consulting, so I built something for myself.

It's called Claudemy.

You give it a topic you want to learn, and it goes:

- Researches the topic using 20–40 sources

- Builds a structured 12-lesson course

- Writes short, podcast-style lessons

- Generates audio you can listen to

- Keeps citations so you can check where the information came from

I built it as a Claude Code skill because that's what I use every day.

I open-sourced it on GitHub

GitHub: https://github.com/assafkip/claudemy

work with structured products. When I asked Claude to “price this autocallable”, it would write a new Monte Carlo script every time. Then came the run → error → fix loop, and two runs of the same trade could give different code and different numbers. That’s not usable for anything a risk or model validation team has to sign off on.

So I built Structured Derivative Pricer, a skill that never generates pricing code. The components are already built and tested on top of QuantLib: curves, models, calibration, schedules, market conventions, Monte Carlo, Longstaff-Schwartz and so on. Claude’s only job is to read the term sheet and assemble those components into one YAML file. The engine validates the whole spec, reports every error at once, shows the plan (closed form or MC, and why) and then prices.

Install

/plugin marketplace add kuanHungWang/financial_engineering_skill
/plugin install financial-engineering@financial-engineering-skill

It also works as a plain skill folder (~/.claude/skills/) or through npx skills add kuanHungWang/financial_engineering_skill for other agents. On first use it sets up its own Python venv with QuantLib.

What it covers

• Asset classes: equity (single or correlated baskets) and rates (term rates, CMS, SOFR-style overnight)
• Models: Black-Scholes (constant, term or Dupire local vol), Heston (given or calibrated to the vol surface), Hull-White 1F (calibrated to ATM swaptions)
• Payoffs: fixed and floating legs (in arrears, compounded with lockout, caps/floors), range accruals, worst-of / best-of, and path-dependent legs with carried state (snowball, memory/phoenix coupon, ratchet, cliquet, lookback)
• Early termination: autocall knock-out, TARN, Bermudan issuer call / holder put via Longstaff-Schwartz
• 15+ worked examples: phoenix memory autocall, callable snowball, CMS spread range accrual, inverse floater TARN, cancellable swap and more

What you get back besides a price

The output is meant to be something a reviewer can check:

• MC standard error and confidence interval, PV per leg, and knock-in / autocall / exercise probabilities
• a cross-check against a closed form where one applies, a martingale check of the simulated forward, and the Bermudan in-sample vs out-of-sample gap
• price.py inspect re-prices with the same seed and dumps every intermediate (paths, fixings, cashflows, discount factors, regression coefficients) to CSV/JSON
• report.py evidence runs convergence, seed stability, sensitivity, stress and benchmark tests. Claude then writes a model validation report (SR 11-7 outline by default, or your own template), with every number copied from the evidence and none computed by the model
• the engine can be exported into your project so the model re-prices without AI, with pinned versions and baseline-verify checks

How I built it

I built it with Claude Code over about 4 weeks (53 commits, all through PRs). What I learned:

• The key design decision was “Claude picks and wires components, never writes math.” Pricing quality now depends on the tested engine, not on what the model writes that day. The skill has a test suite of around 190 tests.
• The SKILL.md tells Claude to ask instead of guess on ambiguous terms (barrier observation frequency, who holds the call right, fixing conventions). It also tells Claude to refuse unsupported products (FX/quanto, equity + stochastic-rate hybrids, American exercise) rather than approximate them quietly.
• It never makes up market data. Mock data exists for demos and is always labelled as mock.

Price: free and open source (Apache).

Repo: https://github.com/kuanHungWang/financial_engineering_skill

It’s a model, not investment advice. Validate against your own controls. I’d especially like feedback from people in quant, risk or model validation on which products or checks you’d want next.

Well, I made one post here thats now at 80 upvotes and the Github has now received ~30 stars from that! The crazy part is that I know its you guys and I know that many not only clicked the GitHub link, but opened the skill file, clicked other things in the gallery, and some of you even looked at other projects of mine and starred some of them! For example, I know at 60+ people visited the gallery. 80 upvotes -> 60 visitors is crazy!

Maybe I am making a mountain out of a molehill, but just want to say that I appreciate you guys. Hopefully, you will find the skill I made useful in your projects!

I maintain config-drift-checker, a free tool that runs eval suites for Claude Code setups (CLAUDE.md, skills, hooks) on every PR and every Claude Code release. A green suite only means something if it would go red when the setup breaks, so I built mutation testing and pointed it at my own suite.

How it works: it makes 15 sabotaged copies of the setup (delete a rule, invert a rule, blur the skill's trigger description, drop the skill, disable the hook), runs the cases that should notice each one, and counts how many go red.

Result: 6 of 15 caught. The misses were the interesting part. Deleting "use constructor injection" or "validate request bodies" changed nothing, because Sonnet does both by default. So a missed sabotage means one of two things: the graders are too loose, or the rule isn't pulling its weight. Deleting the response-wrapper or pagination rules was caught immediately.

Report: https://jameskomo.github.io/config-drift-checker/mutation/report.html

Four other things I measured:

1. Trigger map. 25 prompts in and out of scope, one-turn sessions on Haiku, $0.04. My Spring skill fires on 71% of the prompts it should take and on 30% it shouldn't, with 95% ranges. One passing trigger test had been telling me "it works". https://jameskomo.github.io/config-drift-checker/triggers/report.html
2. Model and version matrix. Sonnet and Haiku on Claude Code 2.1.296 and 2.1.310, $0.73. Sonnet held everywhere. Haiku missed one case on 2.1.310 (one run per cell, so a lead, not proof). https://jameskomo.github.io/config-drift-checker/matrix/report.html
3. Same suite, three agents. 54 runs: Claude Code 1.00, Gemini CLI 0.77, Codex 0.63. CLAUDE.md rules travel through AGENTS.md and GEMINI.md reasonably well. Hooks don't run at all in the other CLIs, so if your safety depends on a hook, it only protects you on Claude Code. https://jameskomo.github.io/config-drift-checker/agents/
4. PSA if you run evals in GitHub Actions: on Claude Code 2.1.310, claude plugin eval refused every Bash-granting run on GitHub's ubuntu-24.04 runners ("cannot confine it, no sandbox backend"), even with bubblewrap installed. Ubuntu 24.04 blocks unprivileged user namespaces through AppArmor. Fix on a throwaway runner: sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 (Claude Code's own error message suggests it). My release canary caught it, but my fallback runner kept the check green, which hid it for a day. Reports now say when that happens.

Repo (free to use, source-available, zero dependencies): https://github.com/jameskomo/config-drift-checker

Built with Claude Code, which also ran most of this work as parallel sub-agents. Happy to answer questions, especially if you want to try mutation testing on your own suite.

Open source!!!!

Hi I just got claude pro for one month but I don't know how to build something meaningful as i am tech student in 2nd year I don't know much about tech yet .

I just wanted to know: What Claude skills or agents are you using for designing and building ? What are tips to get good output from Claude? Give me some unique ideas for website

Give me complete Guide please !!!

New to Claude and ai. But I’m sick and tired every year having to remember my home and car insurance, broadband renewal, phone contract, gas and electric. How would I go about out getting Claude to helps me with this? Is it something I can do in chat or would code be better suited?

any commands that would help?

appreciate it.

Hey,

I created a comprehensive skill that you can use to audit your software before shipping to production

Repo: https://github.com/luigimorel/software-audit-skill

Made a few updates to UNPARALLELED!

I've refined the skill instructions to help Claude make better design decisions and added UNPARALLELED Studio.

The goal is still the same: get Claude to create more thoughtful, distinctive interfaces instead of falling back on the usual AI-generated designs.

Here's a quick demo of the results. Would love some feedback!

Website: https://unparalleled.pages.dev

GitHub: https://github.com/Phantom-Con-Artist/unparalleled-skillset

Been building these for nearly three years, lots of versions. My last one was a stack of subagents, one per step. Moved to one main session running skills, a cheap model building, separate reviewers. Did it before Anthropic's fold-your-subagents guide came out, ended up pretty much where it lands. Used it successfully on real projects since.

It's mine, so bias warning. 36 judges, blind to who built what, order swapped, "neither" allowed:

- 15 Haiku 5.5 agents reading both repos

- 3 each of Qwen 3.8 Max, Gemini 4 Argon, DeepSeek v4.1 Flash, GPT-6.1 Sol, Kimi K3.1 Pro, Grok 4.7, GLM 5.3, given the README and core workflow files of both

Question: 48 hours unattended on a real codebase, list of tickets, which one?

36-0 Topping Out. Every family, every order. More files made them more sure (16 of 21 high confidence).

Why: fresh session per job from files, built for a ticket queue with stop rules and a spend cap. Superpowers runs one approved plan at a time, its readme says it can go "a couple hours" on its own.

The catches they found:

- gates are instructions, not hard blocks

- one stopped job ends the whole night shift

- 3 stars, Windows only, no proven 48 hour run

Win on design, not proof. Superpowers is far more proven.

Not asking anyone to switch. Point your agent at the repo and have it compare against your setup, might be a nugget or two worth nicking.

Anyone pushed Superpowers past a few hours?

https://github.com/kaithoughtarchitect/toppingout

Nobody drew this. One prompt, and Claude Code wrote the whole reel as code: paper props, a mascot in a hat, captions that pop on every word.

The voice goes first. A free local voice reads each line, whisper.cpp times every word, so every prop lands on the word that names it. (free voice model runs locally: kokoro)

One markdown file, one command. Runs in Codex, Gemini and Antigravity too. No API keys, nothing to pay.

Free and open source: https://github.com/haiderfarooq3/paper-reel

I built an open-source skill for Claude that helps write and review product language in real interfaces:

https://github.com/RicardoGurrola15/adaptive-product-language

The problem is that an agent can build a functional screen while producing copy that is generic, robotic or disconnected from the actual product.

The skill helps with:

- landing pages

- onboarding

- login and registration

- forms

- pricing and paywalls

- CTAs

- errors and recovery

- loading, empty and success states

- bilingual interfaces

- product copy audits

It uses project context such as:

- what the product does

- who it is for

- the domain and market

- supported features

- pricing and limits

- approved terminology

- locale and tone

It has separate modules for:

- compose

- improve

- audit

- remediate

- localize

- context

The main principle is simple:

> Text without context is erratic.

It should help Claude adapt the language to the product instead of making every interface sound like the same template. It also checks for unsupported claims, ambiguous CTAs, literal translations and wording that does not match the actual product behavior.

The skill is primarily intended for Claude, but the repository uses portable Markdown-based instructions and can also be adapted to other agent hosts such as Codex or Gemini.

Early tests are preliminary:

- Gemini 3.8 Flash: 2,912 baseline UTF-8 output bytes vs 2,663 with the skill

- Claude Sonnet 4.6 Thinking: 3,289 baseline bytes vs 3,034 with the skill

- Codex contextual pilot: baseline and skill both scored 3.89/4

These are small samples. The byte measurements are not token savings, and the Codex result did not show an improvement. I am not claiming that the skill always produces better copy.

I am especially interested in feedback from people using Claude skills in real projects:

- Does the context layer feel useful or too heavy?

- Which product surfaces should be tested first?

- How should unsupported claims be evaluated?

- How can the skill stay adaptive without making every product sound alike?

- What failure cases should be added?

The attached image shows the preliminary output-byte observations. The repository includes the full skill, context template, references, examples and benchmark documentation.

Genuine question: what makes something a “skill”?

A Markdown file? A repeatable workflow? Something that reliably survives inputs the author didn’t think of?

I’m building skillEd, an open-source toolkit to help evaluate skills and compare their behavior after changes: https://github.com/DeadHead04/skillEd

But the definition itself feels worth discussing.

What would you need to see before calling a skill dependable? Examples, failure cases, a test suite?

Specific counterexamples would make excellent issues. I’d love to test where this framing falls apart.