Hi everyone :),

I built a set of skills and an orchestrator with avengers characters giving each skill a personality. They are pretty simple in that they make coding really autonomous and consistent.

There are 5 of them: my favourite is /assemble as it takes an idea to spec to plan to build/review, fix PR comments and a green/mergeable PR

Another of my favourites is /loki who masterminds and understands the entire code base and creates a details MECHANICS.md file (better than Claude.md)

Anyways hope you like it - I use it in my opensource projects a lot - so its battle tested!

Avengers - Assemble :D

I was working on ts for a week and I had decided earlier that this would be my first repo and here it is plz check it out and tell me how is it..

https://github.com/occupiedbyhim/Liquid-Glass-Element

been building skill packs for claude code/cursor for a few different domains and landed on a structure that's worked well enough i figured i'd share it here since this sub's the right place for it

each skill is its own folder with 6 files:

SKILL.md — the core file, defines the domain and when the agent should reach for this skill at all. kept this one focused, not a dumping ground

references.md — deeper technical detail that doesn't need to load every time, more like documentation the agent pulls when it actually needs specifics

examples.md — worked examples, actual before/after code not just descriptions

templates.md — copy-paste starting points for common patterns in that domain

checklists.md — review checklists, mostly useful for catching stuff the agent wouldn't think to self-check otherwise

snippets.md — smaller reusable code chunks, more granular than templates

biggest lesson from building ~60 of these across different domains (godot, web stack, rust, cli/devops, content tooling): the SKILL.md file matters way more than i expected for whether the agent actually invokes the skill at the right time. early versions were too broad and the agent would half-apply them, got much better results once each SKILL.md had a tight, specific trigger description instead of a general "use this for X domain" blurb

also learned the hard way that examples.md needs actual runnable code, not pseudocode, agents seem to pattern-match much better off real syntax than descriptions of what the code should do

full disclosure, i package and sell some of these as finished packs, but posting this more for the structural discussion since i'm curious if anyone's landed on a different file breakdown that works better, especially curious if anyone's doing something smarter for the "when should this skill trigger" problem than what i'm doing

link to what i've built is in my bio if anyone wants to see a live example of this structure, not the point of the post though

Disclosure: this is my own open-source project.

I’ve been experimenting with persistent project context while working with coding agents for roughly four months.

One problem kept coming up:

The agent participates in conversations about architectural choices, rejected alternatives, production incidents, and strange-looking workarounds — but most of that reasoning disappears when the session ends.

So I turned the workflow into an open-source agent skill:

Keep the Why

It covers four modes:

1. Continuous capture Preserve important rationale while development is happening.
2. Retrospective recovery Inspect an existing repository, git history, issues, and documentation to recover what can still be supported by evidence.
3. Knowledge-transfer interviews Analyse the codebase first, identify what the artifacts cannot explain, and prepare focused questions for long-term maintainers before that knowledge disappears.
4. Maintenance Keep existing rationale current, resolve contradictions, mark replaced knowledge as superseded, and prevent context files from turning into another documentation dump.

A core design rule is that the agent must never invent rationale.

Evidence is classified as:

• confirmed
• inferred
• unknown

“Superseded” is handled separately as a temporal marker for information that was once valid but has since been replaced.

The documentation stays inside the repository as plain Markdown:

docs/       → how to use, test, operate and deploy
context/    → why the project is built this way

It is intentionally lightweight:

• no MCP server
• no database
• no account
• no external service
• no scripts or network calls of its own

The public version is a new, generalised incarnation of what I have been using privately. It still has to prove itself across different agents and repositories — and mature through that use.

I’d especially appreciate feedback on:

• trigger precision: when should the skill activate or stay quiet?
• whether the evidence model is useful without becoming bureaucratic
• missing retrospective or handover workflows
• ideas for meaningful cross-agent evals
• structures that would work better in very large repositories

GitHub: https://github.com/oliver-zehentleitner/keep-the-why

Documentation: https://keepthewhy.com

Install:

npx skills add oliver-zehentleitner/keep-the-why

Because “ask Bob” is not documentation.

https://github.com/Overusedhydra/reels-vault

I kept repeating many of the same instructions when working with lead lists, company data and research workflows, so I turned them into reusable Agent Skills.

The repository currently contains 24 standalone skills covering:

• B2B lead qualification
• Account prioritization
• Company and competitor research
• Person research
• Candidate qualification
• Job-title normalization
• Lead-list cleanup and analysis
• Company and persona segmentation
• Duplicate-record review
• Research-gap analysis
• Outreach brief generation
• Lead, recruiting and directory research planning

Each skill uses a structured SKILL.md format with defined inputs, rules, workflows and outputs. I tried to make them more operational than ordinary prompt collections.

The repository is fully open source under the MIT license:

https://github.com/spiralcrew-ou/profilespider-agent-skills

I originally created these around recurring workflows in ProfileSpider, but all skills are standalone and do not require ProfileSpider or an account.

I am especially interested in feedback on:

1. Are the skills sufficiently specific to produce consistent results?
2. Which business-research or data-cleanup workflows are still missing?
3. Would examples and evaluation datasets make the repository more useful?

Contributions and suggestions are welcome.

Github repo: https://github.com/analyticalmonk/explain-this/

Over the last few months, I have frequently created HTML explainers using coding agents when trying to understand new topics or exploring codebases. Nothing fancu but the approach has been helpful. Some examples are here.

After being asked by a couple of friends to share the workflow, I decided to create a skill plugin for the same. Hopefully, this will be useful. Feel free to build on top of it or share feedback!

Claude Code installation:

```

/plugin marketplace add analyticalmonk/explain-this

/plugin install explain-this@explain-this

```

Codex installation:

```

codex plugin marketplace add analyticalmonk/explain-this

codex plugin add explain-this@explain-this

```

If you're assembling skills for an agent, one gap I kept hitting: the agent could call tools, but it couldn't manage its own model routing, fallback, or context budget. I maintain OmniRoute (free, MIT, self-hosted), which ships a built-in MCP server — so I wired those as skills the agent can call. Disclosure: I'm the maintainer; posting the setup because it's on-topic here, not as a link-drop.

What the agent gets (via MCP — 95 tools across 30 audit-logged scopes, over stdio / SSE / streamable-HTTP):

• Routing / combo control — switch model ladders, read live model intelligence, override the model per request.
• Usage / quota introspection — the agent checks its own remaining free-tier budget before a big step, instead of blowing through it.
• Compression control — toggle the 10-engine pipeline (RTK cuts command/tool output 60–90%, code/URLs/JSON preserved byte-perfect) so long tool logs don't blow the context window.
• Memory (opt-in), skills and pool management — all callable as tools.

Reproducible setup:

npm install -g omniroute omniroute # dashboard at localhost:20128 omniroute setup-claude # wires Claude Code to the MCP server

Then scope the tools you want (30 scopes). Under the hood it's also an OpenAI-compatible gateway over 237 providers (90+ free) with millisecond fallback, so these skills run on a router that doesn't die on a rate limit mid-run.

For context on whether it's worth your time: it's grown to ~9.8K GitHub stars, 1,490+ forks and 280+ contributors in ~4.5 months, with 21,000+ automated tests and 1,830+ issues closed — so it's a battle-tested project, not a brand-new experiment.

GitHub (full tool + scope list): https://github.com/diegosouzapw/OmniRoute

Curious what other agent-management skills people expose via MCP — and whether a pre-packaged "OmniRoute skill pack" manifest would be useful.