Model or dataset
gongnyang/gongnyang-prompt-kit avatar
gongnyang/gongnyang-prompt-kit

gongnyang-prompt-kit: the title says VOL.2, the only release is v3.0.0, and the body describes v4.0

막연한 요청을 gpt-image-2 완성 프롬프트로 컴파일하는 Claude Code 스킬 — 네거티브 금지·결과 기반 서술·검증 스크립트·C1~C10

327 stars53 forksJavaScriptMIT

At a glance

What is it?
A prompt compilation skill for one image model, built around a routing table that maps a vague request to one numbered pattern, a set of seven iron rules, and a Node script that refuses prompts containing negatives outside a seven item whitelist. The engineering here is unusually specific and the version bookkeeping is not.
Who is it for?
This kit is worth reading if you generate images with a model that renders negatives literally, because the entire negative-prompt discipline, the whitelist of seven exceptions and the checker that enforces it are the reusable part, and they apply to any model with the same failure. Two practical notes.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 67 days ago.
What is it written in?
Mainly JavaScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 2, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Three version numbers in one repository

The heading says volume two.

The release list has one entry, a version three release titled as a refactor to a single routing table structure, tagged in July 2026.

One section of the body is headed with a version four and announces seven new patterns, of which four are numbered in the promo range and three in the typography range.

So the title, the only tag, and the newest content section carry three different numbers. The volume number in the heading is a series label rather than a software version, which is a legitimate thing to have, but a reader arriving from the releases page and a reader arriving from the heading will disagree about what they are running.

The last commit is from late July 2026, about two months ago, and there is no second release. So the seven new patterns announced in the version four section have never shipped in a tagged build.

The routing table itself is a single table in the skill file, and the readme carries a mirrored copy of it explicitly labelled as a reader-only mirror. That is a good decision, and it creates the one maintenance obligation the design carries: two copies of a routing table that have to stay in step.

Two demo sites on two different account prefixes

The demo link in the readme points at one static hosting account. The homepage recorded for the repository points at a different one.

Both URLs end in the same repository name, and both are on the static pages domain of a code hosting service. They differ in the account prefix before the domain, which means they are two different people's accounts.

The readme links the demo site three separate times, including once at the end of the gallery section, and the recorded homepage is the other URL. So the canonical link and the recorded link disagree, and nothing in the readme explains the relationship between the two.

Language coverage is three files: the readme you are reading, an English one and a Japanese one, both linked from the header.

The rest of the root is a release guide, a documentation directory, an examples directory and a skills directory. There is no package manifest and no dependency file, because the kit is not an installed package: it is a folder of markdown plus one script that you point your coding tool at.

The gallery is a grid of tables with nothing in them

The readme's most persuasive structure is a set of image tables, and most of the cells are empty.

There is a two-column comparison table whose entire purpose is to show the same one-line request rendered with and without the kit. Both cells are blank.

There is a best-cut section with two rows of three columns, six cells, all blank.

The new-patterns section has seven named patterns with a one-line description of each, laid out in tables whose image cells are also blank. So the descriptions are there and the images are not.

The structure implies the images were once present and were stripped, or that they were meant to be added. Either way, a reader looking for evidence that the kit works finds headings and prose.

What is not missing is the record layer underneath. The compiled prompts are committed as line-delimited JSON files, one for the main showcase, one for the seven new patterns with forty-nine records, one for the typography posters, and one sample file. So the text half of every example is in the repository and the picture half is not, which means the claims are reproducible even though the illustrations are not.

The gallery is also described with numbers: twenty-one before and after pairs, seventeen typography patterns, twelve promo cuts, and twelve cuts of one look preset.

The negative-prompt discipline is a workaround for one model behaviour

The first iron rule is the most interesting thing in the file, and it is empirical rather than stylistic.

The claim is that the target image model renders a scene negative. Writing a prompt that excludes a crowd does not remove the crowd, it renders the word. So the entire negative-prompt vocabulary is unusable for scene content, and everything must be re-expressed positively.

The rule's own description says so directly: these are not rules for making output look good, they are rules that block habits of not getting output.

There are exactly two exceptions, and both are narrow. The first is a text-render guard with a whitelist of seven items, and it applies only when the prompt renders text. The second is a compliance pair for one specific format, and only when explicitly declared, with the canonical definition living in a single section of one reference file.

The checker enforces the boundary. Any negative sentence outside the whitelist is caught as an error, and the error carries a hint for rewriting it positively rather than just saying no.

This is the most portable idea in the repository. Any model that renders exclusions literally will reproduce it, and the whitelist of seven is small enough to audit by hand.

Six pixel sizes cover eight aspect ratios, and automatic sizing is banned

The size rule is a lock, and the table is short enough to memorise.

Square maps to one size. The three portrait ratios, two to three, three to four and four to five, all map to the same single pixel size, so one canvas serves three ratios. The two horizontal ratios, three to two and four to three, likewise share one. Then one widescreen size, one vertical size, and one large square reserved for dense or multi-cut work.

That is six pixel dimensions covering eight aspect ratios. It is a sensible design for a model that only accepts a small set of canvas sizes, and it means choosing an aspect ratio in the prompt is choosing one of six numbers.

Two prohibitions sit alongside it. The automatic setting is banned outright. And a leading bracket in the prompt is banned, so the aspect ratio cannot be prepended as metadata. There must be exactly one aspect token, and it goes at the end.

The checker enforces the lock. A size violation is an error, and so is a leftover slot token from the router, which is the failure mode you would expect from a system that fills a template.

What the file does not say is why automatic is banned. Given that the surrounding rules are all explained by observed model behaviour, this one reads as an omission.

Compositing text onto the generated image is forbidden outright

One rule is written as an absolute prohibition, and it is the one rule in the file with no exception lane.

Text is to be rendered inside the image by the model, using quoted copy, role labels and a free-form composition zone. The rule then forbids compositing text onto the generated file with code, naming three specific libraries as the things not to do. The stated reason is that the font, the kerning and the tone of a composited layer clash with the image underneath.

The consequence is stated too, and it is the expensive part. A text error can only be fixed by editing the prompt and regenerating. There is no patch step.

That is a real cost. Text in images is where image models fail most often, and the rule removes the cheap fix in exchange for typographic consistency you would otherwise get by drawing the text yourself. Whether that trade is right depends entirely on whether you are producing one poster or two hundred.

The same instinct runs through two more rules. Equipment specifications are rewritten as described outcomes, on the grounds that the model does not know a camera model. And one row, one cut, one call: multiple cuts are made as multiple rows rather than as a grid on one canvas.

The three related bans are all about not passing the model a term it will render literally.

One script, two severities, and two fixtures that exist to fail

The whole verification surface is a single file with four invocation modes:

bash
node skills/image-prompt/scripts/check_prompt.mjs examples/poster.txt        # 텍스트 모드
node skills/image-prompt/scripts/check_prompt.mjs --tier 2 examples/hwabo_formatB.txt
node skills/image-prompt/scripts/check_prompt.mjs --jsonl examples/prompts.sample.jsonl
node skills/image-prompt/scripts/check_prompt.mjs --test                     # 회귀 셀프테스트

Text mode checks one file. A tier flag checks against a specific tier's rules. A line-delimited mode batches a file of prompts. And a self-test flag runs the checker's own regression suite, which is the only test in the repository.

The return value is a small object with an ok flag, the detected format, the detected tier, and two arrays.

The split between them is the design. Errors are the things that must not pass: negatives outside the whitelist, a leading bracket, retired vocabulary from an older diffusion model, size-lock violations, and leftover slot tokens. Warnings are style problems: empty adjectives, a missing colour value.

And the examples directory contains two files whose names say they are meant to fail, one for an out-of-tier negative and one for a bad poster. Committing fixtures that exist to be rejected is the right way to keep a checker honest, and the pair names tell you what the checker is actually for.

The checker is free and local, the generation is not, and it lives in another repository

The install is two commands: clone the repository, and create a symbolic link from a folder in your coding tool's skills directory into the repository's skill folder.

A symbolic link rather than a copy is the right choice and the readme says why: repository updates are picked up automatically. The cost is that there is no version pin, so a pull at the wrong moment changes the rules your prompts are compiled against.

What is free is stated precisely. Running the checker needs only a JavaScript runtime. Going all the way to an image needs a login to a separate command line tool plus a paid assistant subscription.

So the kit covers prompt authoring and stops there. Generation is explicitly out of scope, and the readme delegates it twice: bulk generation to a named skill in a different repository, and single images to the command line tool directly.

That division is the honest shape of the project. Everything hard is free, reproducible and checkable, and the expensive step is somebody else's product.

The structural choice underneath is worth noting too. The core skill file keeps only what loads every time, and the deep material is split into reference files that are read only when the routing table points at them, which the readme names as progressive disclosure.

Editorial conclusion

This kit is worth reading if you generate images with a model that renders negatives literally, because the entire negative-prompt discipline, the whitelist of seven exceptions and the checker that enforces it are the reusable part, and they apply to any model with the same failure. Two practical notes. The checker is free and local but generation needs a paid assistant subscription and a second tool, so the skill covers prompt authoring and nothing else. And pick your size from the six-entry lock rather than letting the model choose, because the automatic setting is explicitly banned for a reason the file states but does not explain.

Frequently asked questions

What does gongnyang-prompt-kit actually do?

It is a skill for a coding agent that compiles a vague one-line request into a finished image prompt for one image model. A routing table maps the request signal to a single numbered pattern, only that pattern's reference file is read, and a Node script then checks the result. The readme states generation itself is out of scope.

Why does gongnyang-prompt-kit ban negative prompts?

Because the target model renders the exclusion instead of applying it, so a prompt that says no crowd produces a crowd. The rule is that all scene exclusions must be re-expressed positively. Two narrow exceptions exist: a text-render guard with a whitelist of seven items that applies only when the prompt renders text, and one compliance pair that applies only when explicitly declared.

How do I install gongnyang-prompt-kit?

Clone the repository and create a symbolic link from your coding tool's skills directory into the repository's skill folder, pointing at the image prompt skill. A link rather than a copy means repository updates are picked up automatically. Running the checker needs only Node.js; generating an image additionally needs a command line tool login and a paid assistant subscription.

What image sizes does gongnyang-prompt-kit allow?

Six pixel dimensions covering eight aspect ratios: square, one portrait size shared by three ratios, one horizontal size shared by two ratios, one widescreen size, one vertical size, and one large square for dense or multi-cut work. The automatic setting is banned, a leading aspect bracket in the prompt is banned, and exactly one aspect token goes at the end. A size violation is reported as an error.

Can I fix a typo in text rendered inside a gongnyang-prompt-kit image?

Not by editing the file. The rules forbid compositing text onto the generated image with code, naming three specific libraries, because the font, kerning and tone clash. A text error is fixed by editing the prompt and regenerating, so there is no cheap patch step for the failure mode image models have most.

Official sources

  1. gongnyang/gongnyang-prompt-kit on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/gongnyang-gongnyang-prompt-kit.svg)](https://hysenlabs.com/projects/gongnyang-gongnyang-prompt-kit)