hand-drawn-styles: a prompt recipe library for hand-drawn image styles

The problem: style descriptions drift every time you write them

Anyone generating illustrations with an image model runs into the same friction. You describe a crayon drawing once, like the result, and then cannot reproduce it a week later because you paraphrased the style paragraph from memory. The subject changes, the style description changes with it, and the output wanders.

hand-drawn-styles attacks that specific problem. It is not an image generator and does not pretend to be one. The README states the project handles style selection, fills your content into a recipe, and outputs the final prompt, while image generation stays with whatever model you already use, naming gpt-image, Jimeng and Midjourney as examples. The audience is people who write or illustrate with an agent that can read custom instructions: Claude Code, Cursor, Codex CLI, Gemini CLI, Cline and Windsurf are all listed as supported hosts.

The scope boundary is deliberate and worth noting. The README says the project does not take over article writing or publishing. If you wanted a pipeline that writes the post and draws the header, this is only the second half.

How the recipe library works: PROTOCOL.md plus STYLES.md

The architecture is two plain text files. PROTOCOL.md holds the execution flow: choosing a style, handling aspect ratio, inferring placeholders, and formatting output. STYLES.md holds the recipes themselves. Both are described as tool-agnostic, which is why the same content can be wired into Cursor rules, an AGENTS.md, or a Cline custom instruction file. SKILL.md for Claude Code and AGENTS.md for Codex and Gemini are described as thin adapter layers that point at the two core files rather than duplicating them.

There are 18 integer-numbered styles plus a variant numbered 3.1, so 19 recipes in total. Each has a Chinese name and English aliases, so `ghibli`, `3`, and the Chinese name all resolve to the same recipe. The styles are grouped by intent rather than by medium: line-and-explanation styles (1, 4, 6), deliberately bad drawing (2, 5), traditional and retro texture (8, 9), animation concept work (11, 12, 16, 17), and so on.

Placeholder handling is the part that saves the most typing. Recipes contain slots such as the subject, title word, main color, count and panel list, and the README states the agent infers these from your description instead of asking you to fill them in. Aspect ratio is not hard-locked: if you supply one it is used, and if you do not, pure style recipes inject nothing while layout styles 1 and 4 inject only soft structural hints like a multi-panel grid, with no fixed numbers written in.

Installing hand-drawn-styles and running a first prompt

The README gives a conversational install for agent tools. You send the repository URL to the agent and it installs the skill. The recommendation is to install the full repository rather than copying text fragments, because style 3.1 depends on a reference anchor image and the render script.

帮我安装这个 Skill：https://github.com/threerocks/hand-drawn-styles

For Claude Code specifically, the README shows cloning the repository directly into the skills directory, where SKILL.md is picked up automatically.

git clone https://github.com/threerocks/hand-drawn-styles.git ~/.claude/skills/hand-drawn

For Cursor, the instructions are to place PROTOCOL.md and STYLES.md into the project's `.cursor/rules/` directory or copy them into `.cursorrules`. Codex CLI, Gemini CLI and Jules point their AGENTS.md or GEMINI.md at the two core files. Cline, Windsurf and Continue take the same two files merged into their rules or custom instructions.

Once wired up, the trigger is conversational. Asking for a hand-drawn cat in the rain without naming a style makes the agent list the menu for you to pick from. Naming a style by number, Chinese name or English alias goes straight to output. The render script is the more reproducible route when Python is available, and the README's example invokes style 3.1 with a subject, a text instruction, an aspect ratio and JSON output.

python3 scripts/render_prompt.py \
  --style 3.1 \
  --subject '爸爸把零食袋放回柜子,男孩站在旁边看着' \
  --text '不加任何文字' \
  --aspect 3:4 \
  --format json

The README states that style 3.1 outputs a formal JSON package named `family-crayon-card-v3` containing the prompt, input replay information, per-image required references, and a mandatory three-stage workflow: base generation, then `scribble-correction`, then `scribble-chaos-correction`, where only the third stage produces the final image. Plain text output is restricted to an explicit `--format text --text-only-preview` and the README says it must not be used for production image generation.

Style 3.1 is where the design gets heavy

Most recipes in this library are text you can copy anywhere. Style 3.1 is not. The README describes it as requiring an anchor image at `assets/style-3.1/anchor-family.png`, and the renderer validates both the fixed dimensions and the decoded pixel SHA-256 of that anchor. Metadata changes do not change style identity, but the pixel hash is what the style is anchored to. That is a real constraint: if you re-export the PNG through a tool that alters pixels, you break the anchor.

The three-stage workflow is the other cost. Base generation and `scribble-correction` both produce intermediate images only, and the README is explicit that the third stage is the final output. Any tool that cannot execute a multi-stage workflow with reference images cannot run this style at all. The README also warns against maintaining a second set of rules for lines, facial features, color, paper texture or scribble correction inside your own project, which is sensible but means style 3.1 is effectively all-or-nothing.

The README does not document what happens when the anchor validation fails, and it does not describe a rollback path for a partially completed three-stage run. Those are gaps worth knowing about before you build on it.

The trade-off: a recipe library, not a unified palette

The design principles section is unusually candid about a choice that cuts both ways. The project keeps each style's native layout and structure rather than flattening everything into interchangeable filters. Style 5 keeps its vertical N-panel infographic shape; style 1 keeps its rounded panel comic format. That fidelity is why the styles look like the reference examples rather than like a generic house style.

The cost is that styles are not swappable. You cannot take a prompt written for style 14 and expect style 9 to accept the same structure, because the layout hints differ per recipe. If your workflow needs one template with a color knob, this library is the wrong shape for you. If your workflow needs a specific look reproduced faithfully, the per-style structure is the point.

A second trade-off sits in the placeholder inference. Letting the agent infer the subject, title and color from your description removes form-filling, but it also means the quality of the final prompt depends on how clearly you wrote the request. The README describes the mechanism but does not describe any validation step that catches a bad inference before the prompt is emitted.

Where hand-drawn-styles is the wrong tool

If you want to type a sentence and receive a picture, this project adds a step rather than removing one. It deliberately stops at the prompt. You still need an image model, and you still need to paste or route the prompt into it.

The second wrong-fit case is a team that cannot run Python and needs style 3.1. The README states that style 3.1's production path is the JSON call package with the three-stage workflow, and that plain text output is explicitly not for production image generation. Without the renderer, you lose the reproducibility that the script exists to provide.

There is also a language consideration. The recipes and the style names are written in Chinese, with English aliases provided. If your agent or your reviewers work only in English, the aliases cover invocation, but the recipe bodies themselves are Chinese text, and the README's examples are Chinese. That is not a defect, but it is a real friction point for an English-only team that wants to edit recipes rather than just call them.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-04, so it is recent. There are no retrieved releases, which means there is no versioned changelog to read before upgrading. Updates arrive as commits to PROTOCOL.md, STYLES.md and the scripts directory.

That has a practical consequence for anyone who edits the recipes locally. Because the core is two text files that you copy into Cursor rules, an AGENTS.md or a custom instruction file, local edits will diverge from upstream and there is no documented merge path. The README's advice to install the full repository rather than copying fragments reduces this problem for Claude Code, where the repository sits in the skills directory and updates with a git pull, but not for the copy-based integrations.

The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are preserved. That is a permissive licence, but if you redistribute the recipes inside a product, the notice requirement still applies. Nothing here is legal advice; read the LICENSE file in the repository for the actual terms.

Editorial conclusion

Adopt it if you already have an image model and keep rewriting the same style description by hand; the recipe files plus scripts/render_prompt.py are a cheaper way to hold a style steady. Skip it if you need a single command that returns a picture, or if you cannot run Python and need style 3.1, whose JSON call package and three-stage workflow are the documented production path. Before committing, verify two things yourself: that your agent tool reads PROTOCOL.md and STYLES.md from wherever you place them, and that style 3.1's anchor-family.png decodes to the pixel hash the renderer expects, since the README states metadata changes do not alter style identity but pixel changes do.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. threerocks/hand-drawn-styles on GitHub