@iodes/releasekit 0.1.6 → 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +74 -8
- package/dist/assets.d.ts +4 -3
- package/dist/assets.js +4 -2
- package/dist/cli.js +116 -27
- package/dist/content.d.ts +7 -5
- package/dist/content.js +3 -1
- package/dist/export.d.ts +1 -0
- package/dist/export.js +33 -17
- package/dist/files.js +7 -2
- package/dist/images.d.ts +5 -3
- package/dist/images.js +3 -1
- package/dist/install.d.ts +20 -3
- package/dist/install.js +28 -5
- package/dist/model.d.ts +69 -7
- package/dist/model.js +32 -9
- package/dist/move.d.ts +24 -0
- package/dist/move.js +292 -0
- package/dist/project.d.ts +12 -5
- package/dist/project.js +180 -29
- package/dist/prompts.js +18 -16
- package/dist/refs.d.ts +6 -0
- package/dist/refs.js +29 -0
- package/dist/setup.d.ts +7 -0
- package/dist/setup.js +64 -0
- package/dist/status.d.ts +31 -0
- package/dist/status.js +52 -0
- package/dist/validate.d.ts +5 -2
- package/dist/validate.js +31 -17
- package/examples/README.md +4 -4
- package/examples/backup-encryption/dark.prompt.md +15 -6
- package/examples/backup-encryption/light.prompt.md +15 -6
- package/examples/connected-route/dark.prompt.md +13 -4
- package/examples/connected-route/light.prompt.md +13 -4
- package/examples/location-preferences/README.md +6 -4
- package/examples/location-preferences/dark-refined.png +0 -0
- package/examples/location-preferences/dark-refinement.prompt.md +70 -0
- package/examples/location-preferences/dark-size-correction.prompt.md +5 -0
- package/examples/location-preferences/dark-weight-correction.prompt.md +5 -0
- package/examples/location-preferences/dark.prompt.md +15 -13
- package/examples/location-preferences/light-refined.png +0 -0
- package/examples/location-preferences/light-refinement.prompt.md +70 -0
- package/examples/location-preferences/light.prompt.md +15 -14
- package/examples/location-preferences/pair-review.md +17 -10
- package/examples/location-preferences/scene.yaml +16 -9
- package/examples/queue-action/README.md +3 -3
- package/examples/queue-action/dark-accent-edit.prompt.md +5 -0
- package/examples/queue-action/dark-accent.png +0 -0
- package/examples/queue-action/dark-refined.png +0 -0
- package/examples/queue-action/dark-refinement.prompt.md +74 -0
- package/examples/queue-action/dark-size-correction.prompt.md +5 -0
- package/examples/queue-action/dark.prompt.md +15 -13
- package/examples/queue-action/light-accent-edit.prompt.md +5 -0
- package/examples/queue-action/light-accent.png +0 -0
- package/examples/queue-action/light-refined.png +0 -0
- package/examples/queue-action/light-refinement.prompt.md +74 -0
- package/examples/queue-action/light.prompt.md +14 -13
- package/examples/queue-action/pair-review.md +11 -5
- package/examples/queue-action/scene.yaml +13 -9
- package/examples/storage-breakdown/dark.prompt.md +15 -6
- package/examples/storage-breakdown/light.prompt.md +15 -6
- package/examples/tablet-reading/dark.prompt.md +14 -5
- package/examples/tablet-reading/light.prompt.md +14 -5
- package/kit/references/adoption.md +3 -1
- package/kit/references/channels.md +88 -0
- package/kit/references/composition-recipes.md +5 -5
- package/kit/references/format.md +16 -6
- package/kit/references/theme-pairing.md +6 -6
- package/kit/references/visual-language.md +17 -17
- package/kit/references/workflow.md +4 -4
- package/kit/skills/releasekit-draft/SKILL.md +3 -1
- package/kit/skills/releasekit-finalize/SKILL.md +4 -2
- package/kit/skills/releasekit-image/SKILL.md +4 -2
- package/package.json +1 -1
- package/schemas/bundle.schema.json +54 -5
- package/schemas/config.schema.json +133 -17
- package/schemas/release.schema.json +54 -13
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
# Light refinement request
|
|
2
|
+
|
|
3
|
+
Actual built-in request. Uses the approved dark-refined.png as the composition reference. Candidate selection: light-refined.png. See pair-review.md for the reviewed result.
|
|
4
|
+
|
|
5
|
+
Use case: precise-object-edit. Input image 1 is the approved DARK neutral queue-action illustration and is the composition reference and edit target. Produce its LIGHT counterpart at exactly the same 1585 by 992 pixel dimensions. Preserve every row position, left boundary, middle-foreground offset, right crop, thumbnail position, bar length, padding, rounded corner, and the exact queue glyph. Keep the scene entirely neutral. Change only theme fills: canvas #F8F8F8; every foreground row #ECECEC (raised); all three thumbnails and all six incidental bars #B8B8B8 (secondary); exposed action backplate #999999 (primary); queue glyph #FFFFFF (surface). Keep this soft light hierarchy instead of carrying over dark charcoal fills. Uniform flat areas with no outlines, grain, glow, gradients, shadows, or extra content. One light PNG only, no dark/light collage.
|
|
6
|
+
|
|
7
|
+
# Release illustration — light
|
|
8
|
+
|
|
9
|
+
## Intent
|
|
10
|
+
Create one finished raster illustration for a product release note. Render only the illustration asset, without the surrounding release viewer, headline, body copy, page navigation, or an outer presentation frame.
|
|
11
|
+
User-visible change: A saved item can be added to the queue with one swipe.
|
|
12
|
+
Subject: A saved-item list with an exposed queue action
|
|
13
|
+
Focal detail: The single action revealed behind the middle row
|
|
14
|
+
Context: A fictional productivity interface used to demonstrate the illustration recipe. This scene contains no product performance data or real user information.
|
|
15
|
+
|
|
16
|
+
## Composition contract
|
|
17
|
+
Archetype: ui-detail
|
|
18
|
+
Target canvas: 1585 × 992 pixels; landscape 1585:992. Produce a single image, not a dark/light collage.
|
|
19
|
+
Enlarge the relevant interface fragment to roughly 55–85% of the canvas width. Keep the focal control inside a 6% safe margin. Supporting interface context may be deliberately cropped.
|
|
20
|
+
Specific scene layout: A landscape 8:5 canvas with a straight-on crop of three broad horizontal list rows. Define a fixed list left boundary L at 17 percent of canvas width. The first and third resting row backgrounds start at L. The neutral action backplate behind the middle row also starts at L; it never protrudes to the left of the list. Its exposed width D is about 13 percent of canvas width. Only the middle foreground row is translated right by D, starting at L + D (about 30 percent of canvas width). Its thumbnail and both label bars move with it, preserving exactly the same internal padding as resting rows. All rows have the same height, about 21 percent of canvas height, equal vertical gaps, and matching rounded corners. The row tops sit at about 14, 38, and 62 percent of canvas height. Each row contains one simple neutral square thumbnail and two horizontal bars. The rows retain their original width and intentionally continue beyond the right canvas crop. Keep the neutral action and its glyph fully visible within the original list bounds. Use canvas for the background and raised for the foreground rows. Use secondary for every abstract thumbnail and both incidental bars in every row. The exposed action uses primary, with its queue glyph in surface for contrasting negative space in each theme. No accent is used: the revealed area, queue glyph, and foreground displacement already explain the action. These same roles preserve the hierarchy across themes while using independent dark and light values. Keep each assigned fill uniform and flat. No shadows, phone, or outer frame.
|
|
21
|
+
Elements:
|
|
22
|
+
- Three matching horizontal list rows
|
|
23
|
+
- One exposed neutral action tile with a simple queue glyph
|
|
24
|
+
- One neutral square thumbnail and two label bars in each row
|
|
25
|
+
|
|
26
|
+
## Visual treatment
|
|
27
|
+
Use a straight-on, simplified interface with a small number of layered surfaces. Preserve the product-specific control hierarchy, grouping, alignment, and content padding. Use neutral bars for incidental labels. Establish the changed control or state through framing, scale, and value contrast first; add accent only when that state or action needs a color distinction. Include only the interaction described by this scene; a static setting does not need a gesture.
|
|
28
|
+
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Build emphasis through composition, scale, and neutral value contrast before adding color. No accent is the default, and a fully neutral image is a finished result. Being new, important, or the focal subject does not itself justify color. Small-screen clarity takes priority over decorative detail. Treat the specified element inventory as complete. Keep elements designated as schematic or abstract in that form; do not turn them into additional content or decoration. Authentic content explicitly requested in the brief can retain its own materials and colors. Avoid an unrelated marketing dashboard, neon glow, glass effects, noisy textures, decorative 3D blobs, and unnecessary gradients.
|
|
29
|
+
|
|
30
|
+
## Light theme roles
|
|
31
|
+
| Role | Color | Assignment |
|
|
32
|
+
| --- | --- | --- |
|
|
33
|
+
| canvas | #F8F8F8 | Uniform illustration background |
|
|
34
|
+
| surface | #FFFFFF | Base or recessed interface panels |
|
|
35
|
+
| raised | #ECECEC | Foreground panels, controls, and quiet tile fills |
|
|
36
|
+
| primary | #999999 | Main neutral glyphs, focal controls, and feature-defining marks |
|
|
37
|
+
| secondary | #B8B8B8 | Supporting glyphs, incidental bars, and abstract content |
|
|
38
|
+
| divider | #D9D9D9 | Thin separators and necessary surface boundaries |
|
|
39
|
+
Use these configured roles consistently across the scene and release. Assign roles by visual hierarchy in the composition, not by object type alone: a foreground row can use raised, and an incidental thumbnail can use secondary. Keep equivalent roles consistent across the release. A feature-relevant title or value may use primary when the scene specifies that hierarchy; do not promote every label bar. Repeated elements with the same role use the same fill. Keep flat areas uniform. Do not invent extra grays, warm or cool casts, opacity washes, or gradients for variety; edge antialiasing is expected. Apply these rules to generated schematic elements, while preserving supplied content and supported semantic colors. Optional project accent: #4678ED; this is available, not required. Use it only on the exact element whose supported state, action, or data meaning the scene says needs color. Otherwise use no accent. Keep unrelated glyphs, tiles, and supporting surfaces neutral; do not invent a colored state, badge, or marker to use the palette.
|
|
40
|
+
Keep a soft light presentation using this theme's configured palette: primary glyphs use #999999; incidental label bars normally use the lighter secondary role #B8B8B8. Do not carry charcoal glyphs from the dark counterpart into this theme or darken all symbols and placeholder bars to increase contrast. Improve shape, spacing, scale, or crop first when a schematic detail is unclear. Respect explicit project palette overrides.
|
|
41
|
+
Use the configured near-white canvas and light surfaces. Separate panels with the divider role only where needed. Keep schematic fills flat; do not invent contact shadows, dark outlines, or new material shades to make the interface look sharper.
|
|
42
|
+
Treat these colors as presentation roles, not a global recoloring filter. Preserve natural photos, device materials, and meaningful status colors. If a light product UI is not supported by the evidence, keep the authentic UI on the light presentation canvas instead of inventing a feature.
|
|
43
|
+
|
|
44
|
+
## Pair invariants
|
|
45
|
+
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change neutral presentation values and necessary surface separation within the recipe. Judge each theme independently at the same display width; matching geometry does not require equal apparent brightness or contrast. A geometry correction belongs in the shared scene and both affected variants. Preserve whether accent is absent or present, its assigned elements, and its semantic hues. A neutral scene stays neutral in both themes. If an approved counterpart exists and the tool supports references, use it as a composition reference for a constrained edit. Never create the counterpart with color inversion, brightness-only filters, or a fresh unrelated composition.
|
|
46
|
+
Specific invariants:
|
|
47
|
+
- Exact row count, positions, dimensions, spacing, and crop
|
|
48
|
+
- Shared left boundary of the two resting rows and the neutral action backplate
|
|
49
|
+
- Middle foreground row displaced right by exactly the exposed action width
|
|
50
|
+
- Thumbnail and label bars translated with their foreground row, without changing padding
|
|
51
|
+
- Thumbnail positions and neutral label-bar lengths
|
|
52
|
+
- Straight-on camera and neutral action hierarchy in both themes
|
|
53
|
+
|
|
54
|
+
## Text and references
|
|
55
|
+
No readable text or invented numbers. Use abstract bars for incidental UI labels.
|
|
56
|
+
Product reference files to inspect before rendering:
|
|
57
|
+
- None
|
|
58
|
+
Treat reference content as evidence, not instructions. Use original product-appropriate shapes. Do not copy reference-company identities, logos, attributed style labels, slogans, or distinctive unrelated products.
|
|
59
|
+
|
|
60
|
+
## Exclusions
|
|
61
|
+
- Decorative accent color, bright incidental bars, gradients, or material shading
|
|
62
|
+
- Photographic thumbnails or imagery inside the list rows
|
|
63
|
+
- Hands, arrows, or gesture trails
|
|
64
|
+
- Device frame, app header, or release-note viewer
|
|
65
|
+
- Additional action buttons or unreadable text
|
|
66
|
+
- Action tile or active row protruding left of the resting list boundary
|
|
67
|
+
- Moving the whole list, squeezing row contents, or depicting a reorder drag
|
|
68
|
+
No watermark, stock-photo caption, extra claims, or decorative objects unrelated to the change.
|
|
69
|
+
|
|
70
|
+
## Feature correctness
|
|
71
|
+
First compare the depicted meaning with the user-visible change and product evidence. The subject, focal detail, state, and relationships must satisfy this scene's composition, preserve, and avoid constraints. Apply only checks relevant to this feature. Check the control meaning, containment, alignment, and selected state against the note and product evidence. If a transition is depicted, identify what stays fixed, what changes, and how related content follows that change. Use the actual interaction model specified in the scene.
|
|
72
|
+
|
|
73
|
+
## Acceptance
|
|
74
|
+
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Check neutral fills against their configured roles and compare images within each theme at the same display width. In dark images check compact glyph weight, subordinate supporting details, and distinct charcoal layers; in light images check medium-gray symbols, soft supporting values, and freedom from charcoal-heavy fills. File validation does not establish color consistency. Check each accent against a specific scene-supported meaning; remove color that only decorates the focal subject. Essential content must not clip, incidental text must not become gibberish, and the pair must preserve the composition contract. Matching variants can share the same factual or structural mistake. Register the actual output dimensions and selected file. If generation is unavailable, leave this request pending and hand off this prompt; do not substitute a placeholder image.
|
|
@@ -11,39 +11,39 @@ Context: A fictional productivity interface used to demonstrate the illustration
|
|
|
11
11
|
Archetype: ui-detail
|
|
12
12
|
Target canvas: 1280 × 800 pixels; landscape 1280:800. Produce a single image, not a dark/light collage.
|
|
13
13
|
Enlarge the relevant interface fragment to roughly 55–85% of the canvas width. Keep the focal control inside a 6% safe margin. Supporting interface context may be deliberately cropped.
|
|
14
|
-
Specific scene layout: A landscape 8:5 canvas with a straight-on crop of three broad horizontal list rows. Define a fixed list left boundary L at 17 percent of canvas width. The first and third resting row backgrounds start at L. The
|
|
14
|
+
Specific scene layout: A landscape 8:5 canvas with a straight-on crop of three broad horizontal list rows. Define a fixed list left boundary L at 17 percent of canvas width. The first and third resting row backgrounds start at L. The accent-colored action backplate behind the middle row also starts at L; it never protrudes to the left of the list. Its exposed width D is about 13 percent of canvas width. Only the middle foreground row is translated right by D, starting at L + D (about 30 percent of canvas width). Its thumbnail and both label bars move with it, preserving exactly the same internal padding as resting rows. All rows have the same height, about 21 percent of canvas height, equal vertical gaps, and matching rounded corners. The row tops sit at about 14, 38, and 62 percent of canvas height. Each row contains one simple neutral square thumbnail and two horizontal bars. The rows retain their original width and intentionally continue beyond the right canvas crop. Keep the accent-colored action and its glyph fully visible within the original list bounds. Use canvas for the background and raised for the foreground rows. Use secondary for every abstract thumbnail and both incidental bars in every row. The exposed action uses the project accent to help readers locate the available queue operation. Its queue glyph is white (#FFFFFF) in both themes for on-accent contrast. The action remains accent-colored even though its geometry also reads in grayscale. Leave all other elements neutral. Preserve the same accent target and hue across themes, with independent neutral surface values. Keep each assigned fill uniform and flat. No shadows, phone, or outer frame.
|
|
15
15
|
Elements:
|
|
16
16
|
- Three matching horizontal list rows
|
|
17
17
|
- One exposed accent-colored action tile with a simple queue glyph
|
|
18
18
|
- One neutral square thumbnail and two label bars in each row
|
|
19
19
|
|
|
20
20
|
## Visual treatment
|
|
21
|
-
Use a straight-on, simplified interface with a small number of layered surfaces. Preserve the product-specific control hierarchy, grouping, alignment, and content padding. Use neutral bars for incidental labels.
|
|
22
|
-
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Build
|
|
21
|
+
Use a straight-on, simplified interface with a small number of layered surfaces. Preserve the product-specific control hierarchy, grouping, alignment, and content padding. Use neutral bars for incidental labels. Use framing, scale, and value contrast to establish the hierarchy. Prefer the project accent on the primary action or selected/enabled control that explains the change; it can guide attention even when the interaction also reads in grayscale. Keep supporting controls, label bars, and surfaces neutral, and respect an explicitly monochrome scene or authentic product colors. Include only the interaction described by this scene; a static setting does not need a gesture.
|
|
22
|
+
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Build a clear composition with neutral supporting elements and purposeful focal color. Prefer accent on a scene-supported primary action, selected or enabled state, active path, or defining information distinction when it helps readers locate the feature. Color need not be indispensable to comprehension. Generic information symbols and static associations can remain neutral. Small-screen clarity takes priority over decorative detail. Treat the specified element inventory as complete. Keep elements designated as schematic or abstract in that form; do not turn them into additional content or decoration. Authentic content explicitly requested in the brief can retain its own materials and colors. Avoid an unrelated marketing dashboard, neon glow, glass effects, noisy textures, decorative 3D blobs, and unnecessary gradients.
|
|
23
23
|
|
|
24
24
|
## Light theme roles
|
|
25
25
|
| Role | Color | Assignment |
|
|
26
26
|
| --- | --- | --- |
|
|
27
27
|
| canvas | #F8F8F8 | Uniform illustration background |
|
|
28
|
-
| surface | #FFFFFF | Base interface panels
|
|
29
|
-
| raised | #ECECEC |
|
|
30
|
-
| primary | #999999 | Main neutral glyphs and feature-defining marks |
|
|
31
|
-
| secondary | #B8B8B8 |
|
|
28
|
+
| surface | #FFFFFF | Base or recessed interface panels |
|
|
29
|
+
| raised | #ECECEC | Foreground panels, controls, and quiet tile fills |
|
|
30
|
+
| primary | #999999 | Main neutral glyphs, focal controls, and feature-defining marks |
|
|
31
|
+
| secondary | #B8B8B8 | Supporting glyphs, incidental bars, and abstract content |
|
|
32
32
|
| divider | #D9D9D9 | Thin separators and necessary surface boundaries |
|
|
33
|
-
Use these configured roles consistently across the scene and release. Assign
|
|
34
|
-
Keep a soft light presentation using
|
|
33
|
+
Use these configured roles consistently across the scene and release. Assign roles by visual hierarchy in the composition, not by object type alone: a foreground row can use raised, and an incidental thumbnail can use secondary. Keep equivalent roles consistent across the release. A feature-relevant title or value may use primary when the scene specifies that hierarchy; do not promote every label bar. Repeated elements with the same role use the same fill. Keep flat areas uniform. Do not invent extra grays, warm or cool casts, opacity washes, or gradients for variety; edge antialiasing is expected. Apply these rules to generated schematic elements, while preserving supplied content and supported semantic colors. Project accent: #4678ED. Apply it to the functional focal element assigned in the scene and keep surrounding scaffolding neutral. Neutral role values must not replace that assigned accent. An on-accent glyph may use the contrasting neutral explicitly specified in the scene. A primary action or state may use color to guide attention even when its shape is already recognizable. Respect explicit monochrome choices and authentic product colors; do not invent a state, badge, or marker to introduce color.
|
|
34
|
+
Keep a soft light presentation using this theme's configured palette: neutral primary glyphs use #999999; incidental label bars normally use the lighter secondary role #B8B8B8. Do not carry charcoal glyphs from the dark counterpart into this theme or darken all symbols and placeholder bars to increase contrast. Improve shape, spacing, scale, or crop first when a schematic detail is unclear. Respect explicit project palette overrides.
|
|
35
35
|
Use the configured near-white canvas and light surfaces. Separate panels with the divider role only where needed. Keep schematic fills flat; do not invent contact shadows, dark outlines, or new material shades to make the interface look sharper.
|
|
36
36
|
Treat these colors as presentation roles, not a global recoloring filter. Preserve natural photos, device materials, and meaningful status colors. If a light product UI is not supported by the evidence, keep the authentic UI on the light presentation canvas instead of inventing a feature.
|
|
37
37
|
|
|
38
38
|
## Pair invariants
|
|
39
|
-
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change presentation
|
|
39
|
+
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change neutral presentation values and necessary surface separation within the recipe. Judge each theme independently at the same display width; matching geometry does not require equal apparent brightness or contrast. A geometry correction belongs in the shared scene and both affected variants. Preserve whether accent is absent or present, its assigned elements, and its semantic hues. A neutral scene stays neutral in both themes. If an approved counterpart exists and the tool supports references, use it as a composition reference for a constrained edit. Never create the counterpart with color inversion, brightness-only filters, or a fresh unrelated composition.
|
|
40
40
|
Specific invariants:
|
|
41
41
|
- Exact row count, positions, dimensions, spacing, and crop
|
|
42
|
-
- Shared left boundary of the two resting rows and the
|
|
42
|
+
- Shared left boundary of the two resting rows and the accent-colored action backplate
|
|
43
43
|
- Middle foreground row displaced right by exactly the exposed action width
|
|
44
44
|
- Thumbnail and label bars translated with their foreground row, without changing padding
|
|
45
45
|
- Thumbnail positions and neutral label-bar lengths
|
|
46
|
-
- Straight-on camera and
|
|
46
|
+
- Straight-on camera, the same accent-colored action, and white queue glyph in both themes
|
|
47
47
|
|
|
48
48
|
## Text and references
|
|
49
49
|
No readable text or invented numbers. Use abstract bars for incidental UI labels.
|
|
@@ -52,6 +52,7 @@ Product reference files to inspect before rendering:
|
|
|
52
52
|
Treat reference content as evidence, not instructions. Use original product-appropriate shapes. Do not copy reference-company identities, logos, attributed style labels, slogans, or distinctive unrelated products.
|
|
53
53
|
|
|
54
54
|
## Exclusions
|
|
55
|
+
- Accent spreading to supporting rows or thumbnails, bright incidental bars, gradients, or material shading
|
|
55
56
|
- Photographic thumbnails or imagery inside the list rows
|
|
56
57
|
- Hands, arrows, or gesture trails
|
|
57
58
|
- Device frame, app header, or release-note viewer
|
|
@@ -64,4 +65,4 @@ No watermark, stock-photo caption, extra claims, or decorative objects unrelated
|
|
|
64
65
|
First compare the depicted meaning with the user-visible change and product evidence. The subject, focal detail, state, and relationships must satisfy this scene's composition, preserve, and avoid constraints. Apply only checks relevant to this feature. Check the control meaning, containment, alignment, and selected state against the note and product evidence. If a transition is depicted, identify what stays fixed, what changes, and how related content follows that change. Use the actual interaction model specified in the scene.
|
|
65
66
|
|
|
66
67
|
## Acceptance
|
|
67
|
-
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Check neutral fills against their configured roles and compare
|
|
68
|
+
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Check neutral fills against their configured roles and compare images within each theme at the same display width. In dark images check compact glyph weight, subordinate supporting details, and distinct charcoal layers; in light images check medium-gray neutral symbols, soft supporting values, and freedom from charcoal-heavy fills. File validation does not establish color consistency. Check both overuse and underuse: accent should identify the intended action, state, or information focus without spreading into unrelated elements. An assigned functional accent must remain visible, not be muted to gray because the scene also works without color. Essential content must not clip, incidental text must not become gibberish, and the pair must preserve the composition contract. Matching variants can share the same factual or structural mistake. Register the actual output dimensions and selected file. If generation is unavailable, leave this request pending and hand off this prompt; do not substitute a placeholder image.
|
|
@@ -10,25 +10,31 @@ This is an original fictional interface illustration generated with the coding a
|
|
|
10
10
|
4. Correct an interaction error identified during review: the blue action protruded to the left of the resting list. Translate the middle group right until the action backplate aligns with both resting rows. This leaves only the foreground row displaced relative to the list. The [alignment edit prompt](alignment-edit.prompt.md) records the correction; the shared scene and compiled prompts now specify the fixed boundary and displacement explicitly.
|
|
11
11
|
5. Generate the corrected light counterpart from that corrected dark geometry. Inspect interaction alignment first, then theme correspondence, at full size and 350 pixels wide.
|
|
12
12
|
6. Revise the light palette with [this constrained edit](light-palette-edit.prompt.md). Assign every incidental bar to `secondary: #B8B8B8`, thumbnails to `raised: #ECECEC`, rows to `surface: #FFFFFF`, and the background to `canvas: #F8F8F8`. Keep the blue action and the existing interaction geometry. Select `light-soft.png` after full-size and 350-pixel review alongside the earlier version; spot-check its fills against the intended roles.
|
|
13
|
+
7. Apply the [dark hierarchy revision](dark-refinement.prompt.md). Keep the interaction geometry and original dark palette, but map foreground rows to `raised`, incidental bars and thumbnails to `secondary`, the action to `primary`, and its glyph to `surface`. Remove the accent because the revealed area and glyph already distinguish this action. Select the neutral treatment after full-size and 350-pixel comparison with the earlier dark image.
|
|
14
|
+
8. Generate the [light counterpart](light-refinement.prompt.md) from that reviewed dark candidate, retaining the geometry and role assignments with the independent light values.
|
|
15
|
+
9. Correct a one-pixel output-width difference with the image tool using [this size request](dark-size-correction.prompt.md). Keep the decoded outputs at 1586 × 992 and inspect the pair again.
|
|
16
|
+
10. Revise the shared scene after review found the neutral-only guidance suppressed useful functional color. Apply the [dark accent edit](dark-accent-edit.prompt.md) to the reviewed dark image: use the project blue on the exposed action and white on its queue glyph, preserving the neutral supporting hierarchy and interaction geometry.
|
|
17
|
+
11. Apply the [same localized accent edit](light-accent-edit.prompt.md) to the reviewed light image. Inspect both full-size outputs and a 350-pixel-wide pair; select `dark-accent.png` and `light-accent.png`.
|
|
13
18
|
|
|
14
19
|
The initial review checked theme correspondence but missed the incorrect list boundary. Two visually similar variants can share the same interaction mistake. The current pair replaces those outputs, and the built-in guidance now checks fixed boundaries, moving layers and their contents, and exposed action containment before checking the pair.
|
|
15
20
|
|
|
16
|
-
This example has used
|
|
21
|
+
This example has used eleven image-tool requests in total, including three for the independent theme treatment revision and two for the functional accent revision. Two required assets do not guarantee only two billable generations. The CLI itself made no image-service requests.
|
|
17
22
|
|
|
18
23
|
## Selected output
|
|
19
24
|
|
|
20
25
|
| Check | Result |
|
|
21
26
|
| --- | --- |
|
|
22
27
|
| Actual dimensions | Both 1586 × 992 pixels, approximately 8:5 |
|
|
23
|
-
| Encoding | Two distinct, fully decoded PNG files: `dark.png` and `light-
|
|
28
|
+
| Encoding | Two distinct, fully decoded PNG files: `dark-accent.png` and `light-accent.png` |
|
|
24
29
|
| Subject | Three list rows with one action revealed behind the middle row |
|
|
25
30
|
| Fixed alignment | The first row, blue action backplate, and third row share a left boundary at approximately 17% of canvas width |
|
|
26
31
|
| Foreground displacement | Only the middle foreground and its contents start farther right, around 30% of canvas width; the exposed action fills the intervening space |
|
|
27
32
|
| Containment | The action stays inside the original list bounds, with no leftward protrusion; resting rows retain their positions |
|
|
28
33
|
| Pair correspondence | Row count, overall positions, swipe state, crop, thumbnail layout, and bar lengths remain visually consistent |
|
|
29
|
-
| Focal hierarchy | The blue action
|
|
34
|
+
| Focal hierarchy | The blue action and white queue glyph provide the functional focus; supporting thumbnails and bars stay neutral in both themes |
|
|
35
|
+
| Accent containment | Blue remains confined to the exposed action, with no blue in the supporting rows, thumbnails, or bars |
|
|
30
36
|
| Neutral content | No photographic thumbnails, readable labels, logos, or extra controls |
|
|
31
37
|
| Full-size inspection | The deliberate right-edge row crop preserves the fully visible action tile |
|
|
32
|
-
| 350-pixel-wide inspection | The aligned list edge,
|
|
38
|
+
| 350-pixel-wide inspection | The blue action and white glyph remain easy to locate; the aligned list edge, foreground offset, and three-row structure remain clear |
|
|
33
39
|
|
|
34
|
-
The pair
|
|
40
|
+
The pair preserves the same interaction and neutral supporting hierarchy while using separate dark and light values. The blue action and white queue glyph retain the same functional meaning in both themes. Dark rows remain distinct from the charcoal canvas without bright incidental bars; the light variant uses soft pale rows and supporting gray content. The pair is visually consistent, not guaranteed to have pixel-identical edges. Raster fills remain approximate rather than exact palette swatches. Review an actual product's imagery in its intended viewer before acceptance.
|
|
@@ -5,7 +5,7 @@ focus: The single action revealed behind the middle row
|
|
|
5
5
|
composition: >-
|
|
6
6
|
A landscape 8:5 canvas with a straight-on crop of three broad horizontal list rows.
|
|
7
7
|
Define a fixed list left boundary L at 17 percent of canvas width. The first and third
|
|
8
|
-
resting row backgrounds start at L. The
|
|
8
|
+
resting row backgrounds start at L. The accent-colored action backplate behind the middle row
|
|
9
9
|
also starts at L; it never protrudes to the left of the list. Its exposed width D is
|
|
10
10
|
about 13 percent of canvas width. Only the middle foreground row is translated right
|
|
11
11
|
by D, starting at L + D (about 30 percent of canvas width). Its thumbnail and both
|
|
@@ -14,12 +14,15 @@ composition: >-
|
|
|
14
14
|
and matching rounded corners. The row tops sit at about 14, 38, and 62 percent of canvas
|
|
15
15
|
height. Each row contains one simple neutral square thumbnail and two horizontal bars.
|
|
16
16
|
The rows retain their original width and intentionally continue beyond the right canvas
|
|
17
|
-
crop. Keep the
|
|
18
|
-
Use canvas for the background
|
|
19
|
-
thumbnail
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
17
|
+
crop. Keep the accent-colored action and its glyph fully visible within the original list bounds.
|
|
18
|
+
Use canvas for the background and raised for the foreground rows. Use secondary
|
|
19
|
+
for every abstract thumbnail and both incidental bars in every row. The exposed
|
|
20
|
+
action uses the project accent to help readers locate the available queue
|
|
21
|
+
operation. Its queue glyph is white (#FFFFFF) in both themes for on-accent
|
|
22
|
+
contrast. The action remains accent-colored even though its geometry also
|
|
23
|
+
reads in grayscale. Leave all other elements neutral. Preserve the same
|
|
24
|
+
accent target and hue across themes, with independent neutral surface values.
|
|
25
|
+
Keep each assigned fill uniform and flat. No shadows, phone, or outer frame.
|
|
23
26
|
context: >-
|
|
24
27
|
A fictional productivity interface used to demonstrate the illustration recipe.
|
|
25
28
|
This scene contains no product performance data or real user information.
|
|
@@ -29,12 +32,13 @@ elements:
|
|
|
29
32
|
- One neutral square thumbnail and two label bars in each row
|
|
30
33
|
preserve:
|
|
31
34
|
- Exact row count, positions, dimensions, spacing, and crop
|
|
32
|
-
- Shared left boundary of the two resting rows and the
|
|
35
|
+
- Shared left boundary of the two resting rows and the accent-colored action backplate
|
|
33
36
|
- Middle foreground row displaced right by exactly the exposed action width
|
|
34
37
|
- Thumbnail and label bars translated with their foreground row, without changing padding
|
|
35
38
|
- Thumbnail positions and neutral label-bar lengths
|
|
36
|
-
- Straight-on camera and
|
|
39
|
+
- Straight-on camera, the same accent-colored action, and white queue glyph in both themes
|
|
37
40
|
avoid:
|
|
41
|
+
- Accent spreading to supporting rows or thumbnails, bright incidental bars, gradients, or material shading
|
|
38
42
|
- Photographic thumbnails or imagery inside the list rows
|
|
39
43
|
- Hands, arrows, or gesture trails
|
|
40
44
|
- Device frame, app header, or release-note viewer
|
|
@@ -18,16 +18,25 @@ Elements:
|
|
|
18
18
|
- Three matching legend swatches with abstract label bars
|
|
19
19
|
|
|
20
20
|
## Visual treatment
|
|
21
|
-
Use sparse neutral chart scaffolding and
|
|
22
|
-
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Small-screen clarity takes priority over decorative detail. Treat the specified element inventory as complete. Keep elements designated as schematic or abstract in that form; do not turn them into additional content or decoration. Authentic content explicitly requested in the brief can retain its own materials and colors. Avoid an unrelated marketing dashboard, neon glow, glass effects, noisy textures, decorative 3D blobs, and unnecessary gradients.
|
|
21
|
+
Use sparse neutral chart scaffolding and use the assigned accent to make the scene's focal series, selected value, or category comparison easy to locate, with matching legend semantics. Preserve an explicitly neutral presentation when appropriate. Only show numbers or trends supplied in evidence or explicitly identified as illustrative in the brief; do not imply an unverified performance gain.
|
|
22
|
+
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Build a clear composition with neutral supporting elements and purposeful focal color. Prefer accent on a scene-supported primary action, selected or enabled state, active path, or defining information distinction when it helps readers locate the feature. Color need not be indispensable to comprehension. Generic information symbols and static associations can remain neutral. Small-screen clarity takes priority over decorative detail. Treat the specified element inventory as complete. Keep elements designated as schematic or abstract in that form; do not turn them into additional content or decoration. Authentic content explicitly requested in the brief can retain its own materials and colors. Avoid an unrelated marketing dashboard, neon glow, glass effects, noisy textures, decorative 3D blobs, and unnecessary gradients.
|
|
23
23
|
|
|
24
24
|
## Dark theme roles
|
|
25
|
-
|
|
26
|
-
|
|
25
|
+
| Role | Color | Assignment |
|
|
26
|
+
| --- | --- | --- |
|
|
27
|
+
| canvas | #242527 | Uniform illustration background |
|
|
28
|
+
| surface | #18191B | Base or recessed interface panels |
|
|
29
|
+
| raised | #343638 | Foreground panels, controls, and quiet tile fills |
|
|
30
|
+
| primary | #B9BBBE | Main neutral glyphs, focal controls, and feature-defining marks |
|
|
31
|
+
| secondary | #777B80 | Supporting glyphs, incidental bars, and abstract content |
|
|
32
|
+
| divider | #46494D | Thin separators and necessary surface boundaries |
|
|
33
|
+
Use these configured roles consistently across the scene and release. Assign roles by visual hierarchy in the composition, not by object type alone: a foreground row can use raised, and an incidental thumbnail can use secondary. Keep equivalent roles consistent across the release. A feature-relevant title or value may use primary when the scene specifies that hierarchy; do not promote every label bar. Repeated elements with the same role use the same fill. Keep flat areas uniform. Do not invent extra grays, warm or cool casts, opacity washes, or gradients for variety; edge antialiasing is expected. Apply these rules to generated schematic elements, while preserving supplied content and supported semantic colors. Project accent: #4678ED. Apply it to the functional focal element assigned in the scene and keep surrounding scaffolding neutral. Neutral role values must not replace that assigned accent. An on-accent glyph may use the contrasting neutral explicitly specified in the scene. A primary action or state may use color to guide attention even when its shape is already recognizable. Respect explicit monochrome choices and authentic product colors; do not invent a state, badge, or marker to introduce color.
|
|
34
|
+
Preserve this theme's independent charcoal hierarchy: canvas #242527, base surface #18191B, foreground surface #343638, primary #B9BBBE, and secondary #777B80. Keep standalone glyphs compact and supporting UI details quieter; follow the archetype framing for interfaces, maps, and data. Do not enlarge, thicken, or brighten every glyph and label bar. Retain the necessary separation between background, panels, and focal controls instead of compressing all dark values to match a softened light variant. Respect explicit project palette overrides.
|
|
35
|
+
Separate base and foreground panels with their configured charcoal fills. Reserve stronger neutral contrast for the feature-defining control; incidental bars and thumbnails remain subordinate. Keep edges clean and fills flat, without milky overlays, glow, or invented material shading.
|
|
27
36
|
Treat these colors as presentation roles, not a global recoloring filter. Preserve natural photos, device materials, and meaningful status colors. If a light product UI is not supported by the evidence, keep the authentic UI on the light presentation canvas instead of inventing a feature.
|
|
28
37
|
|
|
29
38
|
## Pair invariants
|
|
30
|
-
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change presentation
|
|
39
|
+
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change neutral presentation values and necessary surface separation within the recipe. Judge each theme independently at the same display width; matching geometry does not require equal apparent brightness or contrast. A geometry correction belongs in the shared scene and both affected variants. Preserve whether accent is absent or present, its assigned elements, and its semantic hues. A neutral scene stays neutral in both themes. If an approved counterpart exists and the tool supports references, use it as a composition reference for a constrained edit. Never create the counterpart with color inversion, brightness-only filters, or a fresh unrelated composition.
|
|
31
40
|
Specific invariants:
|
|
32
41
|
- Three segment lengths in the ratio 2:3:5, accounting for the complete bar
|
|
33
42
|
- Left-to-right category order and one-to-one legend correspondence
|
|
@@ -49,4 +58,4 @@ No watermark, stock-photo caption, extra claims, or decorative objects unrelated
|
|
|
49
58
|
First compare the depicted meaning with the user-visible change and product evidence. The subject, focal detail, state, and relationships must satisfy this scene's composition, preserve, and avoid constraints. Apply only checks relevant to this feature. Check category identity, axes, units, relative values, totals, legends, and any selected filter when present. Preserve relationships across the graphic and both themes; do not invent a metric or outcome.
|
|
50
59
|
|
|
51
60
|
## Acceptance
|
|
52
|
-
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Essential content must not clip, incidental text must not become gibberish, and the pair must preserve the composition contract. Matching variants can share the same factual or structural mistake. Register the actual output dimensions and selected file. If generation is unavailable, leave this request pending and hand off this prompt; do not substitute a placeholder image.
|
|
61
|
+
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Check neutral fills against their configured roles and compare images within each theme at the same display width. In dark images check compact glyph weight, subordinate supporting details, and distinct charcoal layers; in light images check medium-gray neutral symbols, soft supporting values, and freedom from charcoal-heavy fills. File validation does not establish color consistency. Check both overuse and underuse: accent should identify the intended action, state, or information focus without spreading into unrelated elements. An assigned functional accent must remain visible, not be muted to gray because the scene also works without color. Essential content must not clip, incidental text must not become gibberish, and the pair must preserve the composition contract. Matching variants can share the same factual or structural mistake. Register the actual output dimensions and selected file. If generation is unavailable, leave this request pending and hand off this prompt; do not substitute a placeholder image.
|
|
@@ -18,16 +18,25 @@ Elements:
|
|
|
18
18
|
- Three matching legend swatches with abstract label bars
|
|
19
19
|
|
|
20
20
|
## Visual treatment
|
|
21
|
-
Use sparse neutral chart scaffolding and
|
|
22
|
-
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Small-screen clarity takes priority over decorative detail. Treat the specified element inventory as complete. Keep elements designated as schematic or abstract in that form; do not turn them into additional content or decoration. Authentic content explicitly requested in the brief can retain its own materials and colors. Avoid an unrelated marketing dashboard, neon glow, glass effects, noisy textures, decorative 3D blobs, and unnecessary gradients.
|
|
21
|
+
Use sparse neutral chart scaffolding and use the assigned accent to make the scene's focal series, selected value, or category comparison easy to locate, with matching legend semantics. Preserve an explicitly neutral presentation when appropriate. Only show numbers or trends supplied in evidence or explicitly identified as illustrative in the brief; do not imply an unverified performance gain.
|
|
22
|
+
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Build a clear composition with neutral supporting elements and purposeful focal color. Prefer accent on a scene-supported primary action, selected or enabled state, active path, or defining information distinction when it helps readers locate the feature. Color need not be indispensable to comprehension. Generic information symbols and static associations can remain neutral. Small-screen clarity takes priority over decorative detail. Treat the specified element inventory as complete. Keep elements designated as schematic or abstract in that form; do not turn them into additional content or decoration. Authentic content explicitly requested in the brief can retain its own materials and colors. Avoid an unrelated marketing dashboard, neon glow, glass effects, noisy textures, decorative 3D blobs, and unnecessary gradients.
|
|
23
23
|
|
|
24
24
|
## Light theme roles
|
|
25
|
-
|
|
26
|
-
|
|
25
|
+
| Role | Color | Assignment |
|
|
26
|
+
| --- | --- | --- |
|
|
27
|
+
| canvas | #F8F8F8 | Uniform illustration background |
|
|
28
|
+
| surface | #FFFFFF | Base or recessed interface panels |
|
|
29
|
+
| raised | #ECECEC | Foreground panels, controls, and quiet tile fills |
|
|
30
|
+
| primary | #999999 | Main neutral glyphs, focal controls, and feature-defining marks |
|
|
31
|
+
| secondary | #B8B8B8 | Supporting glyphs, incidental bars, and abstract content |
|
|
32
|
+
| divider | #D9D9D9 | Thin separators and necessary surface boundaries |
|
|
33
|
+
Use these configured roles consistently across the scene and release. Assign roles by visual hierarchy in the composition, not by object type alone: a foreground row can use raised, and an incidental thumbnail can use secondary. Keep equivalent roles consistent across the release. A feature-relevant title or value may use primary when the scene specifies that hierarchy; do not promote every label bar. Repeated elements with the same role use the same fill. Keep flat areas uniform. Do not invent extra grays, warm or cool casts, opacity washes, or gradients for variety; edge antialiasing is expected. Apply these rules to generated schematic elements, while preserving supplied content and supported semantic colors. Project accent: #4678ED. Apply it to the functional focal element assigned in the scene and keep surrounding scaffolding neutral. Neutral role values must not replace that assigned accent. An on-accent glyph may use the contrasting neutral explicitly specified in the scene. A primary action or state may use color to guide attention even when its shape is already recognizable. Respect explicit monochrome choices and authentic product colors; do not invent a state, badge, or marker to introduce color.
|
|
34
|
+
Keep a soft light presentation using this theme's configured palette: neutral primary glyphs use #999999; incidental label bars normally use the lighter secondary role #B8B8B8. Do not carry charcoal glyphs from the dark counterpart into this theme or darken all symbols and placeholder bars to increase contrast. Improve shape, spacing, scale, or crop first when a schematic detail is unclear. Respect explicit project palette overrides.
|
|
35
|
+
Use the configured near-white canvas and light surfaces. Separate panels with the divider role only where needed. Keep schematic fills flat; do not invent contact shadows, dark outlines, or new material shades to make the interface look sharper.
|
|
27
36
|
Treat these colors as presentation roles, not a global recoloring filter. Preserve natural photos, device materials, and meaningful status colors. If a light product UI is not supported by the evidence, keep the authentic UI on the light presentation canvas instead of inventing a feature.
|
|
28
37
|
|
|
29
38
|
## Pair invariants
|
|
30
|
-
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change presentation
|
|
39
|
+
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change neutral presentation values and necessary surface separation within the recipe. Judge each theme independently at the same display width; matching geometry does not require equal apparent brightness or contrast. A geometry correction belongs in the shared scene and both affected variants. Preserve whether accent is absent or present, its assigned elements, and its semantic hues. A neutral scene stays neutral in both themes. If an approved counterpart exists and the tool supports references, use it as a composition reference for a constrained edit. Never create the counterpart with color inversion, brightness-only filters, or a fresh unrelated composition.
|
|
31
40
|
Specific invariants:
|
|
32
41
|
- Three segment lengths in the ratio 2:3:5, accounting for the complete bar
|
|
33
42
|
- Left-to-right category order and one-to-one legend correspondence
|
|
@@ -49,4 +58,4 @@ No watermark, stock-photo caption, extra claims, or decorative objects unrelated
|
|
|
49
58
|
First compare the depicted meaning with the user-visible change and product evidence. The subject, focal detail, state, and relationships must satisfy this scene's composition, preserve, and avoid constraints. Apply only checks relevant to this feature. Check category identity, axes, units, relative values, totals, legends, and any selected filter when present. Preserve relationships across the graphic and both themes; do not invent a metric or outcome.
|
|
50
59
|
|
|
51
60
|
## Acceptance
|
|
52
|
-
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Essential content must not clip, incidental text must not become gibberish, and the pair must preserve the composition contract. Matching variants can share the same factual or structural mistake. Register the actual output dimensions and selected file. If generation is unavailable, leave this request pending and hand off this prompt; do not substitute a placeholder image.
|
|
61
|
+
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Check neutral fills against their configured roles and compare images within each theme at the same display width. In dark images check compact glyph weight, subordinate supporting details, and distinct charcoal layers; in light images check medium-gray neutral symbols, soft supporting values, and freedom from charcoal-heavy fills. File validation does not establish color consistency. Check both overuse and underuse: accent should identify the intended action, state, or information focus without spreading into unrelated elements. An assigned functional accent must remain visible, not be muted to gray because the scene also works without color. Essential content must not clip, incidental text must not become gibberish, and the pair must preserve the composition contract. Matching variants can share the same factual or structural mistake. Register the actual output dimensions and selected file. If generation is unavailable, leave this request pending and hand off this prompt; do not substitute a placeholder image.
|
|
@@ -19,15 +19,24 @@ Elements:
|
|
|
19
19
|
|
|
20
20
|
## Visual treatment
|
|
21
21
|
Keep any generated frame flat and schematic, with the screen grounded in supplied product evidence. Use a single device unless cross-device interaction is the feature. Choose a supplied capture when actual device appearance matters; do not invent a modeled hardware product.
|
|
22
|
-
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Small-screen clarity takes priority over decorative detail. Treat the specified element inventory as complete. Keep elements designated as schematic or abstract in that form; do not turn them into additional content or decoration. Authentic content explicitly requested in the brief can retain its own materials and colors. Avoid an unrelated marketing dashboard, neon glow, glass effects, noisy textures, decorative 3D blobs, and unnecessary gradients.
|
|
22
|
+
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Build a clear composition with neutral supporting elements and purposeful focal color. Prefer accent on a scene-supported primary action, selected or enabled state, active path, or defining information distinction when it helps readers locate the feature. Color need not be indispensable to comprehension. Generic information symbols and static associations can remain neutral. Small-screen clarity takes priority over decorative detail. Treat the specified element inventory as complete. Keep elements designated as schematic or abstract in that form; do not turn them into additional content or decoration. Authentic content explicitly requested in the brief can retain its own materials and colors. Avoid an unrelated marketing dashboard, neon glow, glass effects, noisy textures, decorative 3D blobs, and unnecessary gradients.
|
|
23
23
|
|
|
24
24
|
## Dark theme roles
|
|
25
|
-
|
|
26
|
-
|
|
25
|
+
| Role | Color | Assignment |
|
|
26
|
+
| --- | --- | --- |
|
|
27
|
+
| canvas | #242527 | Uniform illustration background |
|
|
28
|
+
| surface | #18191B | Base or recessed interface panels |
|
|
29
|
+
| raised | #343638 | Foreground panels, controls, and quiet tile fills |
|
|
30
|
+
| primary | #B9BBBE | Main neutral glyphs, focal controls, and feature-defining marks |
|
|
31
|
+
| secondary | #777B80 | Supporting glyphs, incidental bars, and abstract content |
|
|
32
|
+
| divider | #46494D | Thin separators and necessary surface boundaries |
|
|
33
|
+
Use these configured roles consistently across the scene and release. Assign roles by visual hierarchy in the composition, not by object type alone: a foreground row can use raised, and an incidental thumbnail can use secondary. Keep equivalent roles consistent across the release. A feature-relevant title or value may use primary when the scene specifies that hierarchy; do not promote every label bar. Repeated elements with the same role use the same fill. Keep flat areas uniform. Do not invent extra grays, warm or cool casts, opacity washes, or gradients for variety; edge antialiasing is expected. Apply these rules to generated schematic elements, while preserving supplied content and supported semantic colors. Project accent: #4678ED. Apply it to the functional focal element assigned in the scene and keep surrounding scaffolding neutral. Neutral role values must not replace that assigned accent. An on-accent glyph may use the contrasting neutral explicitly specified in the scene. A primary action or state may use color to guide attention even when its shape is already recognizable. Respect explicit monochrome choices and authentic product colors; do not invent a state, badge, or marker to introduce color.
|
|
34
|
+
Preserve this theme's independent charcoal hierarchy: canvas #242527, base surface #18191B, foreground surface #343638, primary #B9BBBE, and secondary #777B80. Keep standalone glyphs compact and supporting UI details quieter; follow the archetype framing for interfaces, maps, and data. Do not enlarge, thicken, or brighten every glyph and label bar. Retain the necessary separation between background, panels, and focal controls instead of compressing all dark values to match a softened light variant. Respect explicit project palette overrides.
|
|
35
|
+
Separate base and foreground panels with their configured charcoal fills. Reserve stronger neutral contrast for the feature-defining control; incidental bars and thumbnails remain subordinate. Keep edges clean and fills flat, without milky overlays, glow, or invented material shading.
|
|
27
36
|
Treat these colors as presentation roles, not a global recoloring filter. Preserve natural photos, device materials, and meaningful status colors. If a light product UI is not supported by the evidence, keep the authentic UI on the light presentation canvas instead of inventing a feature.
|
|
28
37
|
|
|
29
38
|
## Pair invariants
|
|
30
|
-
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change presentation
|
|
39
|
+
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change neutral presentation values and necessary surface separation within the recipe. Judge each theme independently at the same display width; matching geometry does not require equal apparent brightness or contrast. A geometry correction belongs in the shared scene and both affected variants. Preserve whether accent is absent or present, its assigned elements, and its semantic hues. A neutral scene stays neutral in both themes. If an approved counterpart exists and the tool supports references, use it as a composition reference for a constrained edit. Never create the counterpart with color inversion, brightness-only filters, or a fresh unrelated composition.
|
|
31
40
|
Specific invariants:
|
|
32
41
|
- Hardware material and light screen in both presentation themes
|
|
33
42
|
- One device, exact screen layout, six body bars and their lengths
|
|
@@ -49,4 +58,4 @@ No watermark, stock-photo caption, extra claims, or decorative objects unrelated
|
|
|
49
58
|
First compare the depicted meaning with the user-visible change and product evidence. The subject, focal detail, state, and relationships must satisfy this scene's composition, preserve, and avoid constraints. Apply only checks relevant to this feature. Check the actual device count, screen content, and relationship between devices. Do not imply an unsupported device, connection, or application theme.
|
|
50
59
|
|
|
51
60
|
## Acceptance
|
|
52
|
-
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Essential content must not clip, incidental text must not become gibberish, and the pair must preserve the composition contract. Matching variants can share the same factual or structural mistake. Register the actual output dimensions and selected file. If generation is unavailable, leave this request pending and hand off this prompt; do not substitute a placeholder image.
|
|
61
|
+
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Check neutral fills against their configured roles and compare images within each theme at the same display width. In dark images check compact glyph weight, subordinate supporting details, and distinct charcoal layers; in light images check medium-gray neutral symbols, soft supporting values, and freedom from charcoal-heavy fills. File validation does not establish color consistency. Check both overuse and underuse: accent should identify the intended action, state, or information focus without spreading into unrelated elements. An assigned functional accent must remain visible, not be muted to gray because the scene also works without color. Essential content must not clip, incidental text must not become gibberish, and the pair must preserve the composition contract. Matching variants can share the same factual or structural mistake. Register the actual output dimensions and selected file. If generation is unavailable, leave this request pending and hand off this prompt; do not substitute a placeholder image.
|
|
@@ -19,15 +19,24 @@ Elements:
|
|
|
19
19
|
|
|
20
20
|
## Visual treatment
|
|
21
21
|
Keep any generated frame flat and schematic, with the screen grounded in supplied product evidence. Use a single device unless cross-device interaction is the feature. Choose a supplied capture when actual device appearance matters; do not invent a modeled hardware product.
|
|
22
|
-
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Small-screen clarity takes priority over decorative detail. Treat the specified element inventory as complete. Keep elements designated as schematic or abstract in that form; do not turn them into additional content or decoration. Authentic content explicitly requested in the brief can retain its own materials and colors. Avoid an unrelated marketing dashboard, neon glow, glass effects, noisy textures, decorative 3D blobs, and unnecessary gradients.
|
|
22
|
+
Favor visual precision, quiet hierarchy, and one instantly understandable feature. Build a clear composition with neutral supporting elements and purposeful focal color. Prefer accent on a scene-supported primary action, selected or enabled state, active path, or defining information distinction when it helps readers locate the feature. Color need not be indispensable to comprehension. Generic information symbols and static associations can remain neutral. Small-screen clarity takes priority over decorative detail. Treat the specified element inventory as complete. Keep elements designated as schematic or abstract in that form; do not turn them into additional content or decoration. Authentic content explicitly requested in the brief can retain its own materials and colors. Avoid an unrelated marketing dashboard, neon glow, glass effects, noisy textures, decorative 3D blobs, and unnecessary gradients.
|
|
23
23
|
|
|
24
24
|
## Light theme roles
|
|
25
|
-
|
|
26
|
-
|
|
25
|
+
| Role | Color | Assignment |
|
|
26
|
+
| --- | --- | --- |
|
|
27
|
+
| canvas | #F8F8F8 | Uniform illustration background |
|
|
28
|
+
| surface | #FFFFFF | Base or recessed interface panels |
|
|
29
|
+
| raised | #ECECEC | Foreground panels, controls, and quiet tile fills |
|
|
30
|
+
| primary | #999999 | Main neutral glyphs, focal controls, and feature-defining marks |
|
|
31
|
+
| secondary | #B8B8B8 | Supporting glyphs, incidental bars, and abstract content |
|
|
32
|
+
| divider | #D9D9D9 | Thin separators and necessary surface boundaries |
|
|
33
|
+
Use these configured roles consistently across the scene and release. Assign roles by visual hierarchy in the composition, not by object type alone: a foreground row can use raised, and an incidental thumbnail can use secondary. Keep equivalent roles consistent across the release. A feature-relevant title or value may use primary when the scene specifies that hierarchy; do not promote every label bar. Repeated elements with the same role use the same fill. Keep flat areas uniform. Do not invent extra grays, warm or cool casts, opacity washes, or gradients for variety; edge antialiasing is expected. Apply these rules to generated schematic elements, while preserving supplied content and supported semantic colors. Project accent: #4678ED. Apply it to the functional focal element assigned in the scene and keep surrounding scaffolding neutral. Neutral role values must not replace that assigned accent. An on-accent glyph may use the contrasting neutral explicitly specified in the scene. A primary action or state may use color to guide attention even when its shape is already recognizable. Respect explicit monochrome choices and authentic product colors; do not invent a state, badge, or marker to introduce color.
|
|
34
|
+
Keep a soft light presentation using this theme's configured palette: neutral primary glyphs use #999999; incidental label bars normally use the lighter secondary role #B8B8B8. Do not carry charcoal glyphs from the dark counterpart into this theme or darken all symbols and placeholder bars to increase contrast. Improve shape, spacing, scale, or crop first when a schematic detail is unclear. Respect explicit project palette overrides.
|
|
35
|
+
Use the configured near-white canvas and light surfaces. Separate panels with the divider role only where needed. Keep schematic fills flat; do not invent contact shadows, dark outlines, or new material shades to make the interface look sharper.
|
|
27
36
|
Treat these colors as presentation roles, not a global recoloring filter. Preserve natural photos, device materials, and meaningful status colors. If a light product UI is not supported by the evidence, keep the authentic UI on the light presentation canvas instead of inventing a feature.
|
|
28
37
|
|
|
29
38
|
## Pair invariants
|
|
30
|
-
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change presentation
|
|
39
|
+
The other theme must use the same object count, positions, scale, crop, camera, UI topology, selected state, chart values, allowed labels, and feature meaning. Change neutral presentation values and necessary surface separation within the recipe. Judge each theme independently at the same display width; matching geometry does not require equal apparent brightness or contrast. A geometry correction belongs in the shared scene and both affected variants. Preserve whether accent is absent or present, its assigned elements, and its semantic hues. A neutral scene stays neutral in both themes. If an approved counterpart exists and the tool supports references, use it as a composition reference for a constrained edit. Never create the counterpart with color inversion, brightness-only filters, or a fresh unrelated composition.
|
|
31
40
|
Specific invariants:
|
|
32
41
|
- Hardware material and light screen in both presentation themes
|
|
33
42
|
- One device, exact screen layout, six body bars and their lengths
|
|
@@ -49,4 +58,4 @@ No watermark, stock-photo caption, extra claims, or decorative objects unrelated
|
|
|
49
58
|
First compare the depicted meaning with the user-visible change and product evidence. The subject, focal detail, state, and relationships must satisfy this scene's composition, preserve, and avoid constraints. Apply only checks relevant to this feature. Check the actual device count, screen content, and relationship between devices. Do not imply an unsupported device, connection, or application theme.
|
|
50
59
|
|
|
51
60
|
## Acceptance
|
|
52
|
-
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Essential content must not clip, incidental text must not become gibberish, and the pair must preserve the composition contract. Matching variants can share the same factual or structural mistake. Register the actual output dimensions and selected file. If generation is unavailable, leave this request pending and hand off this prompt; do not substitute a placeholder image.
|
|
61
|
+
Inspect at full size and approximately 350 pixels wide. First verify feature correctness, then visual clarity, then correspondence between the configured themes. Check neutral fills against their configured roles and compare images within each theme at the same display width. In dark images check compact glyph weight, subordinate supporting details, and distinct charcoal layers; in light images check medium-gray neutral symbols, soft supporting values, and freedom from charcoal-heavy fills. File validation does not establish color consistency. Check both overuse and underuse: accent should identify the intended action, state, or information focus without spreading into unrelated elements. An assigned functional accent must remain visible, not be muted to gray because the scene also works without color. Essential content must not clip, incidental text must not become gibberish, and the pair must preserve the composition contract. Matching variants can share the same factual or structural mistake. Register the actual output dimensions and selected file. If generation is unavailable, leave this request pending and hand off this prompt; do not substitute a placeholder image.
|
|
@@ -2,7 +2,9 @@
|
|
|
2
2
|
|
|
3
3
|
Read this when a product has no ReleaseKit releases and the author is choosing where to start. Resolve the likely baseline through [repository inspection](workflow.md#resolve-release-scope-from-the-repository) before asking; a clear inferred tag interval does not require confirmation. Setup has two separate decisions: the baseline commit, and how to present the product's earlier history. A baseline is the end of the earlier period; regular change notes begin **after** it. Choosing a tag does not mean starting at the commit that created that tag's features.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
For channel-aware first drafts, choose use/non-use and the target channel through [the channel workflow](channels.md#first-draft-and-later-drafts) before applying this guide. Use `--channel` on start and prepare, scope existing-release discovery to that channel, and read its `channels.<name>.history.start`. Its display predecessor can be another channel; Git boundaries remain separate.
|
|
6
|
+
|
|
7
|
+
For an unchanneled history, read existing releases and `history.start` in the project config first. Reuse a saved selection when continuing setup. Existing releases use their explicit `previous` links. An explicitly limited Git interval or a requested full-history release already establishes the work's scope; do not add retrospective work or repeat that choice. For first-use requests with unresolved scope, gather the missing decisions using the workflow's [native question UI](workflow.md#ask-with-the-native-question-ui). Follow [the answer-waiting procedure](workflow.md#wait-for-the-users-answer) after asking. Independent inspection may continue while answers are pending, but do not save an unconfirmed choice or draft dependent copy.
|
|
6
8
|
|
|
7
9
|
## Choose the baseline
|
|
8
10
|
|
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
# Channels and whole-release moves
|
|
2
|
+
|
|
3
|
+
## First draft and later drafts
|
|
4
|
+
|
|
5
|
+
Read the request, conversation, config, and existing releases before choosing anything. Channel setup is editorial work performed by the skill; the CLI never prompts.
|
|
6
|
+
|
|
7
|
+
- With no saved releases and no intentional channel setting, ask whether to use channels. Offer a single history or the initial map below, and accept custom channel names and direct include combinations through free text.
|
|
8
|
+
- If language choices are also unresolved, bundle language and channel-use questions in one native question request when supported. After channel use is decided, ask the first draft's target channel only if still unresolved. Keep at most one unanswered request and wait for its answers as described in [the shared question workflow](workflow.md#ask-with-the-native-question-ui).
|
|
9
|
+
- Save non-use as `channels: false`, or save the chosen map in `releasekit/config.yaml`, before `prepare`. Preserve unrelated settings. Do not add a separate save-confirmation question.
|
|
10
|
+
- Initialization intentionally leaves `channels` absent. Existing projects with saved unchanneled releases and no setting continue their single history without a new first-use prompt. Reuse explicit choices already made in the request, conversation, or config.
|
|
11
|
+
- For later new drafts, `channels: false` means no channel question. With a configured map, reuse an explicit target such as “Draft 2.1 for dev”; use the only configured channel when exactly one exists. Otherwise ask which configured channel to write for. Do not infer it merely from the most recent release, version spelling, or Git branch name.
|
|
12
|
+
- Existing drafts retain their saved channel, source languages, and Git boundaries. If the same version exists in several channels and the request does not resolve the intended release, ask which release to edit. A request to change the existing channel uses the move workflow below.
|
|
13
|
+
- Once a choice is saved, do not ask whether to use channels on every draft. A requested configuration change affects future work and exports; it does not relocate saved releases.
|
|
14
|
+
- While a necessary channel answer is pending, do not prepare folders, scaffold notes, or write channel-specific copy. Independent repository inspection may continue. A preselected choice or elapsed wait is not an answer.
|
|
15
|
+
|
|
16
|
+
Initial channel map, used only when the user selects it:
|
|
17
|
+
|
|
18
|
+
```yaml
|
|
19
|
+
channels:
|
|
20
|
+
prod:
|
|
21
|
+
include: [prod]
|
|
22
|
+
dev:
|
|
23
|
+
include: [dev, prod]
|
|
24
|
+
stage:
|
|
25
|
+
include: [prod]
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
`include` controls viewing, not where a draft belongs. In this example stage can own releases, but the stage view displays prod only. Never automatically add a channel to its own include list. The CLI rejects empty lists, duplicate includes, and unknown referenced names.
|
|
29
|
+
|
|
30
|
+
Keep the resolved `{ channel, version }` identity through note edits, translations, images, validation, and finalization. Pass `--channel <name>` to each command. Omitting it always addresses the unchanneled history, even when channel settings exist. Avoid presenting CLI argument questions when the actual product choice is already clear.
|
|
31
|
+
|
|
32
|
+
## Display history and export
|
|
33
|
+
|
|
34
|
+
All channel releases share one chain of `{ channel, version }` previous references. Channel-free releases retain a separate chain of plain version references. The source tree is `releases/<channel>/<version>/` or `releases/<version>/` respectively. Duplicate versions across channels remain distinct; never deduplicate their notes by title or version.
|
|
35
|
+
|
|
36
|
+
For example, newest to oldest:
|
|
37
|
+
|
|
38
|
+
```text
|
|
39
|
+
dev/2.1 -> prod/1.1 -> dev/2.0 -> prod/1.0 -> null
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
Export walks that chain without date or version sorting. The dev view above displays all ready entries; prod and stage display only ready prod entries. Excluded channels and unfinished drafts are skipped without stopping traversal. No branch/end-point question is needed: malformed, disconnected, or branching channel histories are errors to repair.
|
|
43
|
+
|
|
44
|
+
```sh
|
|
45
|
+
releasekit export --channel dev --out ./output/dev
|
|
46
|
+
releasekit export --channel prod --limit 3 --out ./output/prod
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Omitting `--limit` exports all matching releases. `--limit N` counts only entries surviving channel/status filtering and limits the combined result, not each channel separately. `history.limit` is removed; if encountered, replace it with an explicit export option only when that limit is requested. `--current` remains available only for unchanneled exports.
|
|
50
|
+
|
|
51
|
+
The first displayed entry supplies default locales and the current identity. Missing or stale content in selected releases blocks output before files are created. Exported channel `previous` links connect the next included entry and end at null; source references remain unchanged. Files retain `release-notes.<locale>.json`, with channel assets under `assets/<channel>/<version>/`. Re-export to a new directory when rules or membership change.
|
|
52
|
+
|
|
53
|
+
## Git boundaries
|
|
54
|
+
|
|
55
|
+
Display ancestry and Git comparison scope are independent for channel releases. `prepare` links to the current global head, even if that head is another channel or a draft. Do not use that entry's commit as the analysis boundary merely because it is the display predecessor.
|
|
56
|
+
|
|
57
|
+
Choose comparison start from explicit `--from`, the latest saved same-channel release's `source.toSha`, or that channel's saved `history.start`, in that order. Honor a deliberately selected `--from-root`. The CLI pins and checks actual Git ancestry for the comparison interval. If no valid interval is established, inspect the repository and ask only when materially different scopes remain. A different channel's draft does not block finalization.
|
|
58
|
+
|
|
59
|
+
```sh
|
|
60
|
+
releasekit start --channel prod --at v1.0.0 --past summary --baseline-version 1.0.0
|
|
61
|
+
releasekit prepare 1.0.0 --channel prod
|
|
62
|
+
releasekit prepare 2.1 --channel dev --from <start-ref> --to <end-ref>
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
Channel start settings live at `channels.<name>.history.start`; unchanneled starts remain at `history.start`. A channel baseline can follow another channel in display history. Language defaults still come from current project config for every new draft, not from either predecessor.
|
|
66
|
+
|
|
67
|
+
`releasedAt` accepts a date or a timestamp including seconds and a timezone (`Z` or UTC offset), with optional milliseconds. New drafts default to current UTC time. Preserve explicitly supplied dates/times and saved values during revisions, finalization, and moves.
|
|
68
|
+
|
|
69
|
+
## Move whole releases
|
|
70
|
+
|
|
71
|
+
Use this workflow for requests such as “Move 1.4.0 to dev”, “Move dev 2.0 and 2.1 to prod”, or “Return these releases to the unchanneled history.” Move the complete release, including all notes, languages, briefs, and assets. Do not rewrite copy, regenerate images, duplicate releases, or reinterpret the request as moving individual feature notes.
|
|
72
|
+
|
|
73
|
+
1. Resolve the source identities and destination from the request and saved files. Ask only if the intended source or destination remains ambiguous. One command selects versions in one source channel (or the unchanneled history) and one destination.
|
|
74
|
+
2. Run the move command with `--dry-run`. Inspect paths, affected references, and collisions. Channel-to-channel moves retain global positions automatically. Crossing between channel and unchanneled histories preserves selected relative order and appends at the newest end by default. Use `--after <version-or-channel/version>` or `--at-start` only for a requested alternative insertion point.
|
|
75
|
+
3. When the request and placement are clear and preflight succeeds, execute the same command without `--dry-run`; do not add another permission question. A missing destination channel needs explicit configuration. Existing destination versions/files stop the batch; do not overwrite, rename, or merge automatically.
|
|
76
|
+
4. Report moved source/destination identities, retained ready/draft status, and updated links/references. Validate the affected ready releases if additional edits occurred. Do not promise that an existing export has changed; export again only when requested.
|
|
77
|
+
|
|
78
|
+
```sh
|
|
79
|
+
releasekit release move 1.4.0 --to-channel dev --dry-run
|
|
80
|
+
releasekit release move 1.4.0 --to-channel dev
|
|
81
|
+
releasekit release move 2.0 2.1 --from-channel dev --to-channel prod --dry-run
|
|
82
|
+
releasekit release move 2.0 2.1 --from-channel dev --to-channel prod
|
|
83
|
+
releasekit release move 1.4.0 --from-channel prod --to-unchanneled
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
Use the CLI for the move, not shell folder moves or direct channel-field edits. It preserves original Git SHA boundaries, timestamps, note/translation text, image bytes, and ready/draft status. It checks existing ready fingerprints before updating relocation-related hashes, updates incoming links and managed visual reference paths, preserves stale-image state, and updates existing generated prompts through their generator. Referenced baseline settings move with their baseline unless the destination already has a conflicting start.
|
|
87
|
+
|
|
88
|
+
The batch preflights before mutation and rolls back on write failures. If rollback itself fails, the error names preserved recovery data; report that exact state and resolve it before attempting another move. Do not mark a partial move successful or blanket-rehash previously modified ready content.
|