skill-prompt-generator: a twelve-skill system for composing image prompts from an element library

An element library first, a prompt generator second

The architecture is easier to understand if you start with the data rather than the code. A SQLite file at `extracted_results/elements.db` holds what the project calls the Universal Elements Library, 1,246 entries, plus 675 source prompts contributed by more than 260 creators. The elements are categorised into domains with counts that are stated precisely enough to be useful: portrait photography at 502, design at 166 including five complete templates, interior at 79, product at 78, art at 70, video at 49, common photography technique at 208, creative at 37, scenario at 34, utility at 10, prompt writing at 9, and lifestyle at 4.

That last number is worth pausing on. A domain with four elements is a rounding error, and its presence says the taxonomy was built by extracting from real prompts rather than designed top-down. It also means domain balance is uneven, so a request routed to lifestyle will produce something much thinner than a portrait request.

On top of that sits `prompt_framework.yaml`, the portrait framework definition, and three Python modules that do the real work: `intelligent_generator.py` for generation, `framework_loader.py` for loading the framework, and `element_db.py` for database access. The project's own framing is that this is not an ordinary Python tool but a complete skills system, and the Python layer is the implementation detail rather than the interface.

The intelligence claims are specific enough to evaluate. Semantic understanding separates subject, style and atmosphere. Common-sense reasoning infers plausible attributes, the README's example being that ethnicity implies eye colour. A consistency check detects and repairs logical conflicts before you ever see the prompt. Those three are the features that distinguish this from random sampling, and they are also the three most expensive to verify, since none of them is described in enough detail to reason about its failure modes.

Twelve skills and the routing layer that decides which one runs

Users are meant to call skills rather than Python. The agent reads the request, identifies a domain, picks a generation mode, and invokes a specialist. The skill names are listed in the README: `intelligent-prompt-generator`, `art-master`, `design-master`, `product-master`, `video-master`, `universal-learner`, `prompt-analyzer`, `prompt-extractor`, `prompt-generator`, `prompt-master`, `prompt-xray` and `domain-classifier`.

The naming reveals the division of labour. The five master skills map to output domains. `prompt-master` is the dispatcher. `domain-classifier` decides where a request belongs. `prompt-analyzer` and `prompt-xray` inspect existing prompts, and `prompt-extractor` pulls elements back out of them. `universal-learner` closes the loop by feeding new material back into the library.

Three generation modes arrived with version 2.0 and they are not interchangeable. Portrait mode is pure portrait photography and draws on the 502-element portrait domain. Cross-Domain mode is for complex scenes and automatically combines multiple domains, 995 elements in total. Design mode produces posters and cards by fusing SQLite elements with YAML colour schemes, which is where the claimed 200,000-plus combinations come from.

That last number needs scepticism, since it is a product of 37 colour schemes multiplied by border and decoration options rather than 200,000 distinct visual outcomes. The project's own claim about v2.0 is that database utilisation rose from 40.3 percent to 79.9 percent, which is a more honest metric: it means more of the library is reachable, not that the output space doubled.

One detail about the skill set is easy to miss and matters for evaluation. The `.claude/` directory holds `CLAUDE.md` with project rules and routing guidance, so part of the behaviour is prompt-level configuration rather than code. Codex support was contributed separately and lives in `.codex/`, with its own entry guide and routing guide, and the two trees mirror each other.

Cloning, installing dependencies and verifying the skills load

Prerequisites are modest: Claude Code, Python 3.8 or newer, and optionally git. The recommended install is a clone followed by a dependency install:

git clone https://github.com/huangserva/skill-prompt-generator.git
cd skill-prompt-generator
pip install -r requirements.txt

The dependency file is deliberately tiny, and the comments are more informative than the packages themselves. `anthropic>=0.7.0` and `pyyaml>=6.0` are the only hard requirements, with optional entries for `requests` and `pandas` left commented out for people adding web fetching or data analysis. That is a small surface, and it is worth noting the Anthropic SDK is a dependency even though the skills run through an agent rather than calling the API directly.

There is no packaging step, no build command and nothing to compile. Once cloned, the twelve skills under `.claude/skills/` are picked up automatically by Claude Code, which is the whole point of the design: installation is a filesystem fact rather than a command.

The README gives a specific verification procedure, and following it exactly is worth the minute it takes. Run a portrait request and a design request in Claude Code; if the skills load, you get prompts back. If the agent answers from its own knowledge instead, the skills were not detected, and the usual cause is that the project directory is not the working directory Claude Code was launched in.

A ZIP download is offered as the alternative, with the same single install step once unpacked. The difference from a clone is that you will not receive updates, and for a project whose element library is the asset, that is a meaningful difference.

Calling the Python engine directly, both interfaces

The Skills route is recommended, but both Python entry points remain supported and the version 1.0 API is described as fully backward compatible. The v2.0 unified interface is the one to reach for when you need cross-domain or design output:

from core.cross_domain_generator import CrossDomainGenerator

generator = CrossDomainGenerator()
result = generator.generate("龙珠悟空打出龟派气功")

print(result['type'])      # cross_domain
print(result['prompt'])    # 完整提示词
print(result['domains'])   # ['portrait', 'video', 'art', 'common']

generator.close()

The returned dictionary is the interesting part, because it exposes the routing decision rather than hiding it. `type` tells you which of the three modes was selected, and `domains` lists every domain that was combined to produce the result. For a system whose output quality depends on classification, being able to inspect the classification is worth more than the prompt string itself. Both classes expose a `close()` method, which suggests a held database connection rather than a stateless function call.

The version 1.0 interface takes a structured intent dictionary instead of a sentence, which is the opposite design choice. Nothing is inferred from free text; gender, ethnicity and age range are passed explicitly under `subject`, makeup under `styling`, lighting type under `lighting`:

from intelligent_generator import IntelligentGenerator

gen = IntelligentGenerator()

prompt = gen.generate_from_intent({
    'subject': {
        'gender': 'female',
        'ethnicity': 'East_Asian',
        'age_range': 'young_adult'
    },
    'styling': {
        'makeup': 'k_beauty'
    },
    'lighting': {
        'lighting_type': 'natural'
    }
})
print(prompt)
gen.close()

If you are integrating this into a pipeline, the older interface is the more predictable one, because the routing decisions have already been made by your code. The trade-off is that you lose the semantic understanding and consistency checking that the classifier provides.

Design variables, extracted learning and where the limits are

The v2.0 additions beyond routing are a variable sampling system and a design bridge. The `variables/` directory holds three YAML files: 37 colour schemes in `colors.yaml`, border styles in `borders.yaml`, and decorations in `decorations.yaml`. Parameterised elements are the mechanism behind the avoidance of repeats, so successive generations differ in controlled ways rather than by chance. The `design-logic/` directory adds two named aesthetic presets, a warm and cute style and a modern minimal one, and `core/schema_migration_v1.sql` extends the database schema for all of it.

The learning loop deserves a note. `prompt-extractor` pulls elements out of existing prompts and `universal-learner` feeds them back, which is what turns the library from a fixed asset into something that grows from use. This is also the hardest part to evaluate from documentation, because a self-extending library can drift toward whatever you paste into it. The safeguards listed are tagging and library updating inside the Codex learner module, but the quality criteria for what gets learned in are not described.

Being clear about the limits is the useful part here. The library is domain-specific: portrait, design, product, interior, art, video. A request outside those areas has no elements to draw on, and the classifier has to fall back to something. The element counts are uneven enough that thin domains will show it. Version 2.0 is described as fully backward compatible, which is a promise about API shape rather than about output stability.

There is also a licensing gap worth naming plainly. No licence file appears in the tree, and the project page lists none either. A permissive licence was not detected for the element library or the 675 source prompts contributed by outside creators. If you plan to build on this commercially, that is the first thing to resolve with the author, and it is a faster conversation to have now than after shipping.

Editorial conclusion

This is a reference implementation for one specific idea: that prompt quality comes from a curated, queryable element library plus a routing layer, not from a longer instruction to the model. It earns attention if you generate images in volume and want consistent output across a team. It is not a general prompt tool, and the domain classifier means an unrecognised request can be routed somewhere unhelpful. The last push was on 2026-05-10, there are no releases, and the repository records no licence file, which matters if you intend to reuse the element library.

Frequently asked questions

Official sources

1. huangserva/skill-prompt-generator on GitHub
2. Issues
3. README