# I Cant Draw

> i-cant-draw

- Skill: `adinathchaudhari/i-cant-draw` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add adinathchaudhari/i-cant-draw`
- Raw SKILL.md: https://api.skillmd.com/api/skills/adinathchaudhari/i-cant-draw/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: AdinathChaudhari (https://skillmd.com/u/adinathchaudhari)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/adinathchaudhari/i-cant-draw

---


# i-cant-draw

You produce a finished image-generation prompt for **one** engine the user selects. You do not generate the image; you generate the *prompt* (plus the config for that engine) and hand it over — or call the image tool if you have one.

Each engine has its own self-contained guide. You load exactly one. Nothing from the other engine's guide applies, so there are no conflicting rules to reconcile.

## The flow

1. **Model — resolve this first.** Which engine: **ChatGPT** (OpenAI GPT Image) or **Gemini** (Google Nano Banana)?
   - If the user named one, use it.
   - If not, ask one short question: *"ChatGPT or Gemini?"* Do not proceed on a guess — the two need different config (aspect ratio, model IDs, editing API), and picking wrong wastes the prompt.
2. **Scene — get the intent.** What is the image (subject, purpose, any must-haves like text, colours, orientation)? Take whatever the user gives; you will enrich the vague parts using the engine guide. Ask only if you cannot tell the core subject.
3. **Generate — build from the engine's guide.** Read the matching file, then write the prompt by following it exactly:
   - **ChatGPT →** read `references/chatgpt.md`
   - **Gemini →** read `references/gemini.md`

## Universal rules (true for both engines)

These hold regardless of engine — both OpenAI and Google state them explicitly. Apply them always; the engine guide adds the model-specific config on top.

- **Describe the scene in natural-language sentences; don't list keywords.** A narrative sentence beats a comma-salad of tags. This is the opposite of Midjourney/Stable Diffusion habits.
- **Be specific.** Underspecified prompts don't fail — they get silently filled with the model's guesses. Name anything you care about, with concrete material/light/colour/framing detail, not vague adjectives ("beautiful", "8K", "epic").
- **Order it the way the image is built:** background/scene → subject → action → composition/framing → style/medium → lighting → colour → mood → constraints (last). State the intended use early.
- **One medium, one framing** per prompt. No "photorealistic" + "flat cartoon"; no "close-up" + "wide shot".
- **Phrase exclusions positively.** Neither engine has a working negative-prompt field, and naming a thing to exclude tends to summon it. Say "an empty street", not "no cars". Keep any "no watermark, no extra text" as a short trailing clause.
- **No Midjourney/SD syntax** (`--ar`, `--v`, `::2`, `(word:1.5)`, seeds) — ignored or rendered as literal text by both.
- **Quote in-image text verbatim**, keep it short, and specify placement and font *style*.
- **Edit in small deltas.** One change per turn, and restate what must stay the same.

## Output shape

When you generate, emit exactly this:

1. **The prompt** — natural-language, ready to paste into the chosen tool.
2. **Config** — a short block of the engine's real settings (model, size/aspect ratio, quality, etc.), taken from that engine's guide.
3. *(Optional)* one **Refine** hint — a follow-up phrasing the user can send to iterate.

Do not include the other engine's config. Do not explain the rules back to the user unless asked — just deliver the prompt.

## Then what

Open the engine guide for the full formula, the dimension vocabulary, text handling, editing and consistency workflow, API/config reference, anti-patterns, content policy, worked examples, and the pre-send checklist. Follow that guide; this file is only the router.