القائمة
Use when creating, sourcing, processing, converting, organizing, wiring, or documenting visual assets for Chaos Redux.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | chaos-redux-event-assets |
| description | Use when creating, sourcing, processing, converting, organizing, wiring, or documenting visual assets for Chaos Redux. |
Use this skill when a Chaos Redux task requires final visual assets.
This includes event assets, UI assets, focus tree assets, country assets, achievement assets, generated icons, sourced event art, generated icon art, animated sprites, animated portraits, sprite sheets, GIF previews, and any asset package that must be wired into the mod.
The goal is to turn asset needs from an event spec into real HOI4-ready files.
The asset workflow must produce:
Do not leave assets as loose generated or downloaded images.
If an asset is used by the event, it must be processed, placed, documented, and handed off so the main agent can wire it cleanly.
Use this skill for:
Use this skill when the user asks the agent to create, source, process, or wire final visual assets.
Use this skill when the implementation task includes generated, sourced, or user-provided PNG files that must be turned into HOI4-ready assets.
Use chaos-redux-frame-animation together with this skill when an asset needs animation. Animated final assets must come from planned source frames, not from moving, scaling, rotating, warping, blurring, recoloring, or filtering one still image.
When actual files must be created, route the work through narrow project subagents instead of one broad asset worker.
The main agent decides which subagent to spawn, gives it a bounded asset prompt, reviews the output, and performs final wiring.
Use:
chaosx_asset_source_researcher for real or archival image sourcing, real leader portraits, historical flags, historically attested symbols, user-provided source photos, and report/news/super-event images that must depict a real photographed person, place, object, or historical documentchaosx_generated_event_art for generated non-icon event art, including fictional or alternate-history report images, news images, super-event images, fictional portraits, fictional flags, faction emblems, UI panels, dossier art, and progression-state base artchaosx_icon_artist for focus icons, idea icons, national spirit icons, officer corps spirit icons, decision icons, decision category icons, achievement icons, and tech iconsFor animated work, route by asset type first. Then require the chosen asset subagent to follow chaos-redux-frame-animation for frame plans, per-frame source art, normalization, contact sheets, preview GIFs, frame sheets, static fallbacks, and animation handoffs.
Asset subagents may create:
docs/assets/<event_id>_<event_slug>/gfx_handoff.mdAsset subagents must not edit .gfx, localisation, GUI, event, focus, idea, decision, scripted effect, scripted trigger, on_action, history, country, or spreadsheet files unless the parent explicitly grants that scope.
The main agent owns final .gfx sprite definitions, gameplay references, docs alignment, spreadsheet alignment, and validation.
A good parent prompt to an asset subagent includes the event id, asset list, asset type, target size, source mode, final DDS folder, sprite name if already registered, reference folder, visual direction, source constraints, and anything the subagent must mark blocked instead of substituting.
Event-owned final assets should be grouped under an event-scoped folder whenever the engine surface uses explicit sprite or texture paths.
Use this folder form:
<event_id>_<event_slug>
Place the event folder directly under the asset category folder, for example gfx/event_pictures/014_cannibalism/ or gfx/interface/ideas/014_cannibalism/. Do not insert a project namespace layer such as gfx/event_pictures/chaos_redux/014_cannibalism/; the mod root already provides the project namespace.
Do not leave new event assets loose in category roots such as gfx/event_pictures/, gfx/super_events/, gfx/interface/ideas/, gfx/interface/goals/, gfx/interface/decisions/, or gfx/leaders/ unless that root placement is an engine-facing lookup requirement.
Root-only and engine-convention exceptions:
gfx/achievements/ must keep achievement DDS files directly in the root. Do not create gfx/achievements/<event_id>_<event_slug>/ subfolders unless a new engine behavior has been verified locally. Achievement filenames must match the full achievement ids from common/achievements/, so event-owned achievement ids and triplet filenames should use <event_id>_<event_slug>_<achievement_name>{,_grey,_not_eligible}.dds or the exact established id if it includes an ordinal.gfx/flags/, gfx/flags/medium/, and gfx/flags/small/ must keep HOI4 tag/ideology filenames. Do not put flags into event folders; use cosmetic tags or route-specific tag filenames when an event needs transformed flags.Shared or non-event systems may use a clear shared/system folder. Do not force shared assets into an event folder just to avoid a root directory.
When moving or adding an asset, update every .gfx, .gui, event, idea, decision, focus, localisation, and documentation reference that names the old path or sprite. Keep sprite names stable unless the engine-facing identifier itself has to change, as with achievement ids.
Super-event audio follows the chaos-redux-super-events convention. Final music belongs under music/<event_id>_<event_slug>/super_event_<super_event_id>_<super_event_name>.ogg, and matching sound-channel files belong under sound/<event_id>_<event_slug>/super_event_<super_event_id>_<super_event_name>.wav. Do not create persistent music/source/ or music/super_events/ folders; preserve source downloads under docs/assets source-audio paths instead.
Choose the source mode based on asset type.
Do not default event art to maps, cartographic overlays, arrows, staff tables, conference rooms, or generic war-room compositions unless that is the strongest visual for the specific asset.
For Chaos Redux, many event visuals should focus on the actor, force, symbol, ritual, creature, crowd, machine, government, army, leader, or strange condition behind the event. The image should usually make the event feel active and dangerous, not merely show that territory changed.
Prefer visuals that show:
Avoid making the main visual read like:
Maps may still appear as secondary props when useful, but they should rarely be the main visual idea for fictional, alternate-history, high-chaos, supernatural, symbolic, or strange event assets.
$imagegen for generated symbolic or fictional assetsUse Codex's official $imagegen skill by default for:
When creating generated assets, follow the $imagegen skill workflow. Do not define a separate image generation route in this skill.
For transparent icons, ask $imagegen for the required transparent output and follow the $imagegen skill's transparent image workflow. The final PNG must have real transparency, no fake checkerboard, no white halo, no white outline, and no opaque square background unless the asset type explicitly uses a painted backdrop.
If $imagegen is unavailable, report that clearly and stop before using an alternate route.
For generated animated assets, use $imagegen through chaos-redux-frame-animation. Each animation frame must be generated or edited as its own source frame according to a frame plan. Do not use local filters, transforms, glow pulses, or offsets as the source of final motion.
Report images, news images, and super-event images may be either internet-sourced or generated.
Use internet-sourced imagery when the asset must show a real photographed person, specific real battle, real place, real object, real newspaper, real poster, real map, real archive item, or other verifiable historical material.
Use $imagegen when the event is fictional, alternate-history, symbolic, supernatural, high-chaos, or when a unique scene is more important than matching an existing archive image. Generated event-photo assets should be prompted as period-authentic documentary material, not modern cinematic concept art.
For generated World War II-era report/news/super-event images:
Follow the repository web research rules from AGENTS.md when searching for source images.
For internet-sourced event photo assets that are meant to represent the World War II era, search for period-matching source imagery from roughly 1936 to 1945 unless the event spec gives a narrower date range. Prefer contemporary photographs, war correspondents' photographs, press agency images, propaganda posters, maps, newspapers, official records, government or military archive images, museum scans, library scans, and period illustrations. Do not use modern photographs, reenactment images, film stills, AI-looking reconstructions, postwar uniforms, streets, weapons, vehicles, buildings, colorized tourist photos, reenactments, or modern props when they do not fit the era. If no suitable period source can be found, either generate a period-authentic fictional/documentary image when the asset does not require a real source, or mark the asset as blocked or needs_user_review.
Record the image source, source link, author or archive if available, license or public domain status if available, estimated date or date range, why the image fits the World War II era, and any uncertainty in the manifest.
Do not generate a leader portrait for a real person.
For real people, use a real source image from the internet or a user-provided image, then crop, resize, process, convert, and document it. Use the repository web research tools when a source image is needed, and prefer public domain, archival, official, or clearly licensed images. If the person belongs to the World War II setting, prefer contemporary portraits, wartime photographs, news photographs, official portraits, military archive images, passport or identity photos, or archival illustrations. Do not use modern actors, reenactors, statues, cosplay, later fictional depictions, postwar images, or modern images that do not fit the era unless the user explicitly approves them as placeholders.
Real leader portraits should be processed toward the HOI4 portrait style rather than left as raw photos: bust or upper-torso crop, face readable, subdued contrast, mild painterly or period texture, HOI4-like color grading, no modern UI artifacts, no hard white cutout halo, and no over-smoothed face. Do not change the person's identity or generate missing facial features.
Record the source link, author or archive if available, license or public domain status if available, source image path, processed PNG path, final DDS path, and sprite name
For generated or sourced one-person leader portraits, the asset handoff must identify the portrait's gender presentation and any matching leader-name pool requirement. Female-presenting portraits must not be paired with male names and should require female = yes where a country leader is created directly. Male-presenting portraits must not be paired with female names or female = yes. Council, board, office, crowd, and symbolic-institution portraits should keep institutional leader names instead of personal random-name pools.
Fictional leaders, invented councils, collective bodies, supernatural leaders, and symbolic regime portraits must use $imagegen.
Generated leader portraits should follow HOI4 leader portrait conventions: 156x210 final DDS unless an existing sprite uses another size, bust or upper-torso framing, strong face or governing-body focal point, subdued painterly finish, period-appropriate uniform or civilian clothing, transparent or HOI4-compatible portrait background as required by the existing asset pattern, and no text, labels, watermarks, modern UI, or meme-like exaggeration.
For generated one-person leader portraits, record the portrait's apparent gender presentation in the manifest and handoff. Female-presenting portraits require female leader-name pools and female leader metadata where the implementation surface supports it. Male-presenting portraits require male leader-name pools and must not be paired with female metadata. Never hand off a portrait in a way that lets implementation randomly assign names from the opposite gender pool. Council, committee, junta, crowd, office, or symbolic-body portraits should be marked as institutional leaders and use institutional names instead of personal random-name pools.
For council or collective leaders, use one clear symbolic council portrait rather than a cluttered crowd. Keep the subject readable at leader portrait size and document that the leader is fictional or collective.
If the user provides an image, treat it as a source asset.
Record that the image was user-provided in the manifest.
Still crop, resize, convert, place, wire, and document it like any other source asset.
This skill includes reference images that show how different Chaos Redux asset types should look.
Before generating, sourcing, processing, or wiring an asset, inspect the relevant reference folder for that asset type. Use the examples to match style, framing, contrast, readability, scale, texture, and HOI4 presentation.
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/ideas
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/news_event_images
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/report_event_images
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/super_event_images
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/tech_icons
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/achievements
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/decisions
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/flags
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/focuses
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/special_projects
Reference mapping:
assets/ideasgfx/interface/officer_corp/spirits/. Final assets should be 45x45 DDS files with transparent backgrounds, no frames, no painted backdrop, no full-canvas opaque pixels, a readable dark or black outline, and a slight drop shadow. Wire them as GFX_idea_<spirit_id> sprites from a .gfx file.assets/news_event_imagesassets/report_event_imagesassets/super_event_imagesassets/tech_iconsassets/achievementsassets/decisionsassets/flagsassets/focusesIf a relevant reference folder exists, do not generate, source, crop, process, or wire new artwork until you have inspected it.
Never copy reference assets directly. Use them as style and formatting guidance.
If the needed asset type has no matching reference folder, inspect the closest relevant folder and existing Chaos Redux or vanilla assets before choosing a style.
Do not create core artwork from simple shapes, placeholders, contact sheets, layout-only mockups, empty UI boxes, or generated charts. Final art must be real generated, sourced, or user-provided artwork, not circles, rectangles, lines, gradients, geometric diagrams, or other primitive-shape stand-ins.
For super-event images, this rule is strict: final art must be a real scene, archival image, painted illustration, or generated documentary-style image. Do not use symbolic diagrams, flat icons, abstract geometry, title cards, or UI-like compositions as the final super-event image unless the user explicitly requests that exact visual approach and the exception is documented.
Use $imagegen for generated artwork and follow the $imagegen skill workflow for the source image.
Generated artwork must be real source art that can be processed into the final game asset. Final assets must be clean: must not have sticking artifacts, an icon is centered in the image, etc. Do not use contact sheets, review boards, or layout drafts as final source art.
Small gameplay icons must be readable at their final in-game size.
For every generated icon, follow the $imagegen skill's transparent image workflow. Preserve the original generated image, create a processed PNG preview, convert to DDS, and validate the final appearance over a checker background before treating the icon as complete.
The final icon should have transparent unused canvas, no fake checker or matte pixels, no transparent holes inside the painted subject, a slight black outline, a subtle drop shadow, and a centered subject that remains readable at final size.
Generated icon packages must keep visible $imagegen source evidence: save the source atlas or source PNGs, record the prompt and source mode in the manifest, process to real transparent backgrounds, and include a contact sheet that shows final alignment, dimensions, transparency, and absence of white matte or opaque square backgrounds. Do not mark a generated icon complete if the final art is a primitive local drawing, a resized unrelated icon, or a locally assembled shape substitute instead of imagegen or sourced artwork.
Focus icons, idea icons, national spirit icons, officer corps spirit icons, decision icons, decision category icons, achievement icons, and tech icons are separate asset types.
Never treat focus, idea, and decision icons as interchangeable.
Do not create focus icons first and then satisfy idea icons or decision icons by resizing, cropping, shrinking, recoloring, padding, or lightly editing the focus icon. This is not a valid asset workflow.
Each icon type must have its own asset-type-specific brief, reference inspection, source artwork, prompt or source choice, crop, target size, filename prefix, manifest entry, and final DDS output.
Shared visual themes are allowed only when every icon is still designed for its own in-game use:
If a mechanic needs matching focus, idea, and decision visuals, build them as a coordinated icon family. A coordinated family can share subject matter, symbols, colors, and lore cues, but each member still needs separate source art or a separate generated output designed for its target size and UI role.
The manifest must record the exact asset type for every icon and should note when icons are part of a coordinated family. Do not mark an icon complete if it only exists as a resized version of another icon type.
For every asset package:
$imagegenchaos-redux-frame-animation before ordinary static processing. Write the animation brief and frame plan, create or approve the static fallback, generate or source every frame, then normalize the frame sequence.$imagegen assets, write a specific image generation prompt and create the base artwork by following the official $imagegen skill.gfx_handoff.md for any asset that needs a sprite definition.Do not mark assets complete until the DDS files exist, the manifest is written, and the main agent has enough handoff information to wire every sprite without guessing.
When an improvement addendum asks for richer presentation, the asset handoff should name the visual states instead of asking for generic polish. A good asset request says what the player sees before activation, while active, when locked, when dangerous, when complete, and when the route has failed.
For scripted GUI, plan asset families. A panel usually needs a background, header, button states, value icons, warning indicators, progress frames, locked overlays, selected overlays, hover states, and any animated glow, particle, float, or pulse layers. The main agent owns .gui and .gfx wiring, but the asset package must provide clear sprite names, sizes, frame counts, static fallbacks, and contact sheets.
When creating a new asset package, use a stable working folder.
Recommended working structure:
docs/assets/<event_id>_<event_slug>/
manifest.md
prompts/
source_png/
processed_png/
contact_sheets/
notes/
Final DDS files must be moved into the correct gameplay asset folders.
Do not keep final assets under docs/assets/.
Every asset package must include a markdown manifest.
Recommended path:
docs/assets/<event_id>_<event_slug>/manifest.md
The manifest must list every asset.
Each asset entry should include:
$imagegen, internet source image, or user-provided source image$imagegen.gfx fileUse not_needed, planned, sourced, generated, processed, converted, handed_off, wired, complete, needs_user_review, or blocked as asset statuses.
Use these sizes unless the event spec or an existing repo pattern gives a better project-specific requirement.
Use other sizes when the event's UI or asset type requires it.
When unsure, inspect the existing Chaos Redux pattern and vanilla HOI4 assets before choosing.
Use lowercase snake_case.
Keep names stable once they are wired into .gfx.
Recommended filename prefixes:
idea_goal_decision_decision_category_report_event_news_event_super_event_achievement_leader_For event-specific assets, include the event id or slug where useful. For example, all idea assets related to an event should go into one folder of that event.
Every $imagegen prompt should be specific enough to produce usable game art.
A good prompt should include:
Do not ask for vague "cool icon" style outputs.
Do not rely on text inside generated images. Generated text is unreliable.
Prefer strong symbols, clear silhouettes, and readable composition.
For transparent icon prompts, explicitly request a transparent canvas, no fake checkerboard, no white rim, no white/colored outline, no glow, no sticker border, no opaque square background, and a clean silhouette suitable for HOI4 UI.
When using internet source images:
For public-facing or uncertain assets, keep the manifest honest about the source status, date uncertainty, and World War II-era fit uncertainty.
Report event images may use internet-sourced imagery or generated period-documentary imagery. Prefer generated report images when the event needs a unique fictional or alternate-history scene, staged document, invented location, or more specific visual than archive search can reliably provide. Use real sources when the image must depict a real person, real historical scene, or real archival document.
Report event images should look like documentary-style photographs, field documentation, or period documentary material.
For World War II-era subjects, prefer contemporary photographs, war correspondents' photographs, press agency images, propaganda posters, newspapers, maps, official records, military archive images, museum or library scans, or period illustrations. Do not use modern reenactment photos or modern documentary photos that visually belong to a later era.
Use:
Target size:
210x176
Report event images must be black and white with sepia applied. Do not leave report event images in full colour unless the user explicitly requests a colour exception, and record that exception in the manifest.
Report-event images use a finished 210x176 RGBA canvas. The source photograph is processed as a slightly tilted documentary card with transparent edge space and a soft drop shadow. The transparent corners are part of the style.
Do not ask $imagegen to create the tilted card. Generate or source the documentary photograph first, then apply the card treatment locally. This keeps the tilt, shadow, and margins consistent.
python tools/process_report_event_image.py source.png processed_report_event.png
python tools/process_report_event_image.py source_folder processed_folder
The script performs cover crop, black-and-white conversion, sepia application, grain, paper border, deterministic tilt, transparent canvas margin, and soft shadow. It writes RGBA PNG output. Convert the processed PNG to DDS through the normal repo workflow.
Validation:
210x176210x176Generated report images must still receive this local report-card treatment.
News event images may use internet-sourced imagery or generated period-news imagery. Prefer generated news images when the event needs a unique fictional or alternate-history scene, invented crisis, or scene that is unlikely to exist in archives. Use real sources when the image must depict a real person, real historical scene, or real archival item.
News images should look like black-and-white documentary photographs or period news illustrations.
For World War II-era subjects, prefer contemporary newspapers, news photographs, war correspondents' photographs, press agency images, propaganda posters, maps, official visual records, military archive images, museum or library scans, or period illustrations. Do not use modern reenactment photos, modern news photos, film stills, or later images that do not fit the era.
Use:
Target size:
397x153
News images must be black and white.
Generated news images must be converted to black and white during processing, with period press contrast/grain and no modern color remnants. Record the source link and license or public domain status for internet-sourced images, or the generation prompt and source-mode rationale for generated images.
Super-event images may use internet-sourced imagery or generated art. Prefer generated super-event images for fictional, alternate-history, symbolic, supernatural, high-chaos, or emotionally specific moments where a unique composed image better fits the super-event role. Use internet sources when the image must depict a real historical person, real photographed event, or real archival artifact.
Super-event images should have:
Target size:
457x328
If a super-event needs music, use chaos-redux-super-events and research suitable public domain or clearly licensed music. Final audio should use the event-scoped music/<event_id>_<event_slug>/ and sound/<event_id>_<event_slug>/ layout from that skill. Never create event or super-event audio from generated test tones, primitive waveforms, beeps, noise beds, or local oscillator output; that includes sine, square, triangle, and sawtooth waveforms.
For each track, document:
Do not claim public domain status without checking.
If the license is unclear, mark it as uncertain or unsuitable.
Idea and national spirit icons should look like compact HOI4-style icon art.
They should have:
Target size:
64x64
Use idea_ filename prefix.
These icons usually do not need the full focus icon frame.
Do not derive idea or national spirit icons from focus icons. They must be designed as 64x64 spirit-style icons from their own prompt or source art, even when they share a theme with a focus.
Use $imagegen for the base artwork unless the user provides or requests a specific source image.
Follow the $imagegen skill's transparent image workflow when the icon should have a transparent background.
Inspect C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/ideas before generating or processing idea icons.
Focus icons should look like normal HOI4 focus icons.
They should have:
Target size:
94x86
Use goal_ filename prefix.
Do not make focus icons look like generic generated thumbnails.
Do not create a focus icon as the master artwork for idea icons, decision icons, or other smaller icon types. A focus icon can share a theme with those icons, but it must remain a separate focus-specific asset.
Every focus icon should support the focus tree's story, ideology, or gameplay purpose.
Use $imagegen for the base artwork unless the user provides or requests a specific source image.
Follow the $imagegen skill's transparent image workflow when the icon should have a transparent background.
Inspect C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/focuses before generating or processing focus icons.
Decision icons must remain readable at very small size.
Use:
Target size:
32x32
Use decision_ filename prefix.
Do not derive decision icons from focus icons or idea icons. They must be composed for 32x32 readability from their own prompt or source art.
Decision category icons may use:
decision_category_
Use $imagegen for the base artwork unless the user provides or requests a specific source image.
Follow the $imagegen skill's transparent image workflow when the icon should have a transparent background.
Inspect C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/decisions before generating or processing decision icons.
Achievement icons should be compact and readable at 64x64.
Generate the completed achievement icon first with $imagegen.
Then create:
C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/achievements/overlay.png on topThe variants may be created after the completed icon exists.
Do not create not-eligible achievement icons by red-tinting, filtering, darkening, recoloring, or manually redrawing the grey icon. If the overlay file is missing or cannot be applied cleanly, stop and report the asset as blocked instead of substituting another treatment.
Target size:
64x64
Use an achievement_ prefix for source or intermediate art when it helps distinguish the asset type.
For Chaos Redux final files, achievements are a root-only exception. Put completed, grey, and not-eligible DDS files directly under gfx/achievements/, and name them after the exact achievement id registered in common/achievements/:
gfx/achievements/<achievement_id>.dds
gfx/achievements/<achievement_id>_grey.dds
gfx/achievements/<achievement_id>_not_eligible.dds
When renaming or adding achievement ids, update common/achievements/, localisation/english/chaosx_achievements_l_english.yml, interface/chaosx_achievements.gfx, the three DDS variants in gfx/achievements/, and any docs or manifests that list the final DDS paths. If the achievement registry owns a single unique_id, keep it as one root-level registry file and group event-owned achievements by event section inside the file instead of splitting it into per-event achievement files.
Inspect C:/Users/klimp/OneDrive/Documents/Paradox Interactive/Hearts of Iron IV/mod/chaos_redux/.agents/skills/chaos-redux-event-assets/assets/achievements before generating or processing achievement icons.
Flags should use clean symbolic designs that look like intentional flag art, not simple-shape placeholders, palette swaps, ugly filters, or flipped/recolored variants.
They must remain readable at HOI4 sizes.
Required flag sizes:
HOI4 flag TGAs must use the same origin/header convention as vanilla flags. Validate with file; completed flag TGAs should read as Targa image data at the correct size and must not end with - top. If a flag displays upside down in-game while the artwork looks correct in an image viewer, fix the TGA encoding/origin on the flag files themselves. Do not add custom UI sprites, scripted-localisation routing, DDS display copies, or other workarounds for flag orientation.
Avoid overly detailed symbols.
Avoid generated text unless the design absolutely requires it and the final output is manually checked.
Always use $imagegen for fictional flags and user-provided or internet source images for historical or real-world flags.
For existing countries that already have game-provided or repository-approved base flags, do not replace the no-suffix base flag as part of an ideology pass. Keep the base flag unchanged, or restore it from the approved prior asset if an asset pass damaged it, unless the user explicitly asks for that base flag to be redone or the country receives a deliberate focus/event/cosmetic-tag transformation. Ideology variants should be separate assets for _communism, _democratic, _fascism, and _neutrality, not mutations of the base flag with one small shape, a palette swap, a color filter, a vertical flip, or a copied emblem.
For focus-tree or event route flag changes, use explicit cosmetic tags or route-specific flag files and document the trigger/focus that changes the flag. Do not create default flag overrides or new base flags for vanilla-supported or already-existing countries just because they participate in an event.
Historical or historically grounded flags must use sourced motifs, documented heraldry, period symbols, or clearly explained alternate-history synthesis. If no directly attested flag exists, state that in the manifest and produce a historically grounded design from relevant motifs instead of inventing unrelated symbols.
Generated fictional or alternate-history flag variants must come from generated/source artwork and then be processed into final flag sizes. Do not hand-draw final flags from basic rectangles, circles, stars, arrows, or random emblems unless those shapes are part of a researched or generated source design.
Before marking any flag complete, verify normal, medium, and small TGA files:
file output must not show - topFor real people, do not generate leader portraits with $imagegen.
Use a real source image from the internet or a user-provided image, then crop, resize, process, convert, and document it.
Record:
For fictional people, non-human beings, supernatural entities, aliens, zombies, monsters, symbolic leaders, or other invented characters, $imagegen may be used to create the base portrait.
Leader portraits should match the intended Chaos Redux visual direction for the character or country.
Target size:
156x210
Inspect the closest relevant reference folder and existing Chaos Redux portraits before generating or processing fictional leader portraits.
Leader portraits can be animated for special routes, high-chaos leaders, supernatural leaders, rare formables, major transformations, or dramatic council reveals. They should not be required for ordinary advisors or every normal country leader.
Animated leader portrait packages must include:
For UI panels, dossier windows, ledgers, investigation boards, and similar assets, separate artwork from functional UI.
Use $imagegen for:
Use normal UI editing for:
Do not let generated art decide exact interactive layout.
The implementation must still follow HOI4 UI rules and existing repo patterns.
For a decision category with a scripted GUI or mechanic window, the asset handoff should cover the full interface state set.
Useful assets include:
The asset prompt should state which sprites are decorative and which represent mechanic state. State-driven sprites need clear names that match the mechanic value or route state.
Progression-state variants may include:
Progression-state variants should use the same target size as the base asset.
Every formable nation needs visible identity assets.
Asset planning should cover:
Historical or culturally attested formable symbols need source review. Fictional, alternate-history, supernatural, and high-chaos variants may use generated art with clear manifest notes.
Use chaos-redux-frame-animation for every final animated visual asset. Some Chaos Redux mechanics should have animated visual layers when motion improves readability, atmosphere, or feedback. Examples include floating seals, glowing route emblems, particle drift, meter pulses, warning frames, active-button glows, occult pressure effects, sponsor influence networks, and final formable proclamations.
Animated leader portraits should be handled as major identity assets. Real people require sourced base images. Fictional or impossible leaders can be generated. The asset handoff must say whether the animation is subtle, such as breathing light or smoke, or symbolic, such as eye glow, map shadow, glitch, or spectral overlay. The portrait should still read clearly at in-game size.
Final animated assets must be built from planned source frames. Do not create final animation by taking one still image and shifting, scaling, rotating, warping, blurring, recoloring, brightening, or pulsing it with a script. Local scripts may normalize, align, crop, resize, assemble sheets, create previews, and convert frames after the real frames exist.
Final PNG assets must be converted to DDS using the repository's standard DDS conversion workflow.
The output must be compatible with Chaos Redux's expected 32-bit BGRA or B8G8R8A8-style DDS workflow.
If conversion fails, stop and report the error. Do not invent another conversion route unless the user approves it.
After conversion, confirm that:
.gfx path points to the DDSDo not leave only PNG files when the game expects DDS.
.gfx handoff and main-agent wiringAsset subagents do not edit .gfx files by default.
When an asset needs a sprite definition, the asset package must include a handoff note for the main agent.
Recommended path:
docs/assets/<event_id>_<event_slug>/gfx_handoff.md
The handoff must include:
.gfx file.If the main agent already registered .gfx sprites or texture paths before requesting art, the asset subagent must follow those filenames, sprite names, DDS paths, and target sizes exactly. It should only propose names or paths when they were not provided.
The main agent then:
.gfx file if one exists.When wiring event-owned sprite-backed art, the texture path should point to the event-scoped folder for that asset category. If an asset must stay root-only, document the engine reason in the handoff or manifest.
Do not create a new .gfx file if an existing one is clearly the right place. If a new .gfx file is needed, the main agent must name it consistently and document why.
When generated or sourced assets are part of an event or mechanic, update the relevant docs.
The docs should mention:
.gfx file the main agent should use or has usedDo not leave the docs describing old or missing assets.
When an asset package contains many generated or sourced images, create a contact sheet for review.
Contact sheets are for review only.
Do not use contact sheets as final game assets.
The contact sheet should make it easy to see:
If an asset cannot be created or processed cleanly, mark it as blocked.
Record:
Do not invent a substitute asset unless the user explicitly approves it.
Before finishing, confirm:
$imagegen for generated symbolic, fictional, alternate-history, or unique report/news/super-event assets. internet or user-provided source images for real historical materials. and real source images for real leader portraits.gfx_handoff.md exists for every asset that needs a sprite definition, and the main agent has enough information to wire it.$imagegen are clearly marked as fictional or generated in the manifest.chaos-redux-frame-animation, has real source frames, has a static fallback, and has no transform-only final motion.Use when designing, implementing, auditing, or fixing Hearts of Iron IV decisions, missions, timed objectives, decision categories, and mission localisation.
Use when designing, implementing, auditing, or fixing Hearts of Iron IV national focus trees.
Use when implementing or updating Chaos Redux events.
Use when expanding Chaos Redux event ideas into detailed specifications before implementation.
Use when designing, researching, wiring, or documenting Chaos Redux super-events.
Use when coordinating custom Codex subagents for Chaos Redux implementation, asset production, super-event research, audits, active small patches, planning handoffs, or documentation work.