A skill catalog for generative models

Link to the catalog page

Every generative model has its own character. One understands long descriptions better, another expects short tags, a third edits an image from a reference image really well but breaks down with too many negative prompts. Even models close in purpose can require different settings, a different prompt structure, and a different approach to iteration.

So I started collecting a separate catalog of model skills — short, practical profiles for specific models and their variants.

The idea isn't to make yet another model list. A list on its own doesn't help much in practice. What matters is quickly understanding how exactly to work with a given model, where it's strong, what its typical mistakes are, and what prompt shape it responds to best.

What a model skill is

A model skill is a compressed working instruction for a model.

It doesn't contain generic advice like "write more detail" — it contains concrete rules: which generation mode fits, how to structure the prompt, where to place important details, whether a negative prompt is needed, which settings are worth keeping next to the model, and which phrasing to avoid.

A skill like this can be used as a quick reference before generation, or as context for an agent that helps write prompts. Instead of re-remembering a model's quirks every time, I open the profile and immediately see the working form.

Why the catalog exists

When there are only a few models, you can keep everything in your head. But in a real pipeline, different families show up fast: image, video, editing, reference-based generation, local OSS models, hosted APIs, experimental checkpoints. Each has its own limits and its own strengths.

The catalog keeps this knowledge from turning into one big pile.

For each model you can see:

• which tasks it's suited for;
• which modes it supports: T2I, I2I, editing, video, and others;
• how ready the profile is for practical use;
• which settings and constraints matter;
• which skill text can be quickly copied into a working context.

The main goal isn't to describe a model nicely — it's to shorten the path from picking a tool to writing a correct prompt.

How the skills are built

A skill isn't written "by feel" in a single pass. It's usually assembled from several layers.

First I look at primary sources: the model's official pages, model cards, documentation, GitHub repositories, technical reports. They help separate the model's real properties from rumors and one-off user findings.

Then practical material is added: workflow examples, ComfyUI notes, discussions, comparisons, local tests. This data is useful, but it can't be turned into rules mechanically — it's often tied to a specific wrapper, sampler, LoRA, node version, or runtime setting.

After that, the information is sorted, only what's confirmed is kept, and some claims get checked locally. All of it is compressed into a compact guide for an LLM: what, how, and by what rules to write for a specific generative model.

The result isn't a research archive — it's a practical instruction you can actually use in production.

Why this page exists

I originally started building skills for my own local pipeline. As the pipeline grew more complex and the base expanded, I wanted to present it in a more interesting way. It occurred to me that research like this

• could be useful to beginners too,
• looks good as part of a portfolio,
• is a useful way to see how automation gets implemented in GitHub projects.

What's next

The catalog will keep growing as I

• add new models
• refine the skill-writing pipeline
• work through the accumulated to-do list of hypothesis checks

Some skills are already close to production-ready, others remain drafts because they still need more verification.

Example use case

Plugging in a skill keeps the model from drifting into overly complex reasoning and keeps the word count and structure it actually needs for correct image generation.

This matters, for example, in iterative work, where the model tries to find the best prompting variant on its own. Of course, this doesn't replace the human as an artist or as the task's main operator — human vision can't be replaced.

A simple example: trying to "order" a prompt from the model on the theme "A photorealistic image of a Russian village grandmother with pies. Soviet styling. Nostalgia. Like grandma Tonya."

The model's workflow ended up looking like this:

Diagram legend: the numbers in the cards go in the order Age / Russianness / Pies / Photorealism / Nostalgia / Naturalness / LivedIn. These are VLM (Vision Language Model) scores for the corresponding criteria. The green line is the winning chain, the orange dashed line marks key changes in prompt strategy.

Iterating on the approach

1. First attempt: plain LLM processing. I tried searching for data about a model, feeding it to an LLM along with skill-formatting rules, and hoping to get a ready-made instruction. The mistake was that I never defined selection criteria for the knowledge — the LLM just compressed all the found context into one text. Result: the skill looked like a search-results dump full of links, TODO items, and unfiltered discussions. In practice it was useless — there were no focused generation rules in it.

2. Working on criteria, but a narrow sample. I reworked the approach: set clear rules for what counts as practically meaningful knowledge, how to separate confirmed model features from rumors, and how to filter out anything tied to a specific runtime/software. The result got much closer to what I wanted. But a new problem appeared: data was collected manually, one item at a time. Coverage across models and scenarios wasn't enough, the base grew slowly, and many skills stayed in draft due to a lack of sources.

3. Deep research into the architecture. To find the right way to scale the process, I ran a deep research survey across nine different LLMs:

   • claude, Gemini.3.5_flash, kimi, minimax, mistral, perplexity, z.ai, Mercury.5.5, qwen3.7 I gave each the same input — a description of the current pipeline, its problems, and its goals — and compared their recommendations for the architecture of an autonomous skill factory.

   The key takeaway: a manual/agentic pipeline (gather sources → read them → write the skill) doesn't scale. What's needed is a deterministic code base where every step is formalized and reproducible.

   That led to the next iteration — a Python pipeline for automatically distilling skills from raw sources: turning the source-curator → distiller → creator → reviewer process into code — source ingestion, extraction of atomic claims, deduplication and contradiction detection, trust scoring, and draft skill generation.

---

Link to the catalog page

---