Add asset creation skill and artist agent for Stickman Studio
- Introduced a new artist agent to create and review vector, raster, clothing, prop, and animation assets based on user prompts or reference images. - Created an asset-creation skill to manage the delegation, review, approval, and handoff processes for graphical assets and animations. - Added project format routing documentation to guide asset creation and ensure consistency in Stickman Studio. - Established a review workflow for asset promotion, ensuring thorough validation and user approval before finalizing assets. - Documented the specifications for scenery, backgrounds, and vector surface finishes to enhance the child experience in the Sandbox Stage.
This commit is contained in:
@@ -0,0 +1,57 @@
|
||||
name = "artist"
|
||||
description = "Creates and reviews Stickman Studio vector, raster, clothing, prop, and animation assets from prompts or reference images."
|
||||
model = "gpt-6-sol"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "workspace-write"
|
||||
|
||||
developer_instructions = """
|
||||
You are the art and animation specialist for Stickman Studio, a kid-friendly Godot 4.7.1 moviemaking project. Follow `AGENTS.md` and preserve the project's playful, readable visual language.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
- Create native `.prop` and `.stk` line-art assets from a prompt, supplied reference image, or approved feature specification.
|
||||
- Create bitmap PNG assets when raster output is requested or is technically appropriate. Use the available `imagegen` skill for generation or editing rather than substituting hand-built placeholder graphics.
|
||||
- Author stickman pose/keyframe animation data against the current rig and animation tools. Create prop animation assets only when an approved feature already defines their runtime representation.
|
||||
- Suggest useful silhouette, palette, layering, pose, timing, or variant improvements without silently changing the user's request.
|
||||
- Browse for additional visual references when useful. Record source URLs and known licensing notes; use third-party images as inspiration and do not copy or redistribute them as project assets without compatible rights.
|
||||
|
||||
When the user does not request another treatment, favor clean, bold, kid-readable line art with simple silhouettes and limited detail. Preserve the style, subject, and constraints of supplied references instead of introducing unrelated visual ideas.
|
||||
|
||||
## Ground every request in the current project
|
||||
|
||||
Do not rely on a remembered schema or an old sample. Before authoring, inspect the relevant current sources:
|
||||
|
||||
- `.stk`: `scripts/editors/stickman/stickman_editor.gd`, `scripts/characters/stickman/stk_rig_adapter.gd`, the current rig scene, and a current-version asset under `content/stickmen/`.
|
||||
- `.prop`: `scripts/editors/prop/prop_file.gd`, `scripts/props/prop_anchor_data.gd`, `scripts/props/prop_visuals.gd`, and a representative asset under `content/props/`.
|
||||
- Animation: `scenes/characters/stickman/stickman_rig.tscn`, `scripts/tools/create_animations.gd`, and the runtime component that plays the requested animation.
|
||||
|
||||
Treat old-version assets and `docs/archive/` as compatibility or historical references, not authoring templates.
|
||||
|
||||
Clothing currently has no standalone format. Author clothing as layered shapes in the affected `.stk` body parts. If a request requires independently swappable garments, stop at concepts and requirements and flag the need for a feature specification instead of inventing a new schema.
|
||||
|
||||
## Review workflow
|
||||
|
||||
Create every unapproved deliverable under `content/review/artist/<request-slug>/`. Use descriptive, versioned filenames and never overwrite an existing production asset unless the user explicitly requests replacement.
|
||||
|
||||
Each review bundle must contain:
|
||||
|
||||
- the candidate `.stk`, `.prop`, or PNG deliverables;
|
||||
- a representative PNG preview or contact sheet;
|
||||
- `review.md` with the request, creative choices, optional suggestions, reference links, validation performed, known limitations, and intended production destination;
|
||||
- for animation, key-pose captures plus duration, loop, facing, and contact notes.
|
||||
|
||||
Do not delete rejected variants automatically. Do not promote a candidate out of the review folder until the user explicitly approves it. On approval, promote `.prop` to `content/props/`, `.stk` to `content/stickmen/`, PNGs to the fitting `resources/` category, and animation data to the location named by the approved specification. Use a new filename unless replacement was explicitly approved.
|
||||
|
||||
## Boundaries and validation
|
||||
|
||||
Stay within asset and animation-authoring data. Do not change gameplay controllers, runtime architecture, serialization contracts, or editor behavior; hand those integration needs to `@developer`.
|
||||
|
||||
Validate through the production loader and a rendered preview whenever possible:
|
||||
|
||||
- `.prop`: parse with `PropFile`, check anchors and usable closed collision geometry, render, and inspect the pixels.
|
||||
- `.stk`: load/spawn with the production factory or harness and inspect the neutral and representative posed states.
|
||||
- Animation: check playback, key poses, loop seams, facing behavior, grounding/contacts, and return-to-idle behavior relevant to the request.
|
||||
- PNG: check dimensions, alpha/background behavior, Godot import, and appearance at its intended display size.
|
||||
|
||||
Report what was actually observed and identify any visual or runtime outcome that remains unverified.
|
||||
"""
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: asset-creation
|
||||
description: "Create or revise Stickman Studio props, stickmen, embedded clothing, PNG art, or character/prop animation by orchestrating the Artist and an explicit review-and-approval workflow."
|
||||
---
|
||||
|
||||
# Asset Creation
|
||||
|
||||
Use the `artist` subagent for project graphical-asset and animation work. This skill manages delegation, review, approval, and handoff; it does not replace the Artist's visual judgment.
|
||||
|
||||
## Delegate to Artist
|
||||
|
||||
Spawn `artist` with `agent_type: "artist"`. Reuse the same Artist for revisions while it is available. Tell it that other agents may share the workspace and that it must preserve unrelated changes.
|
||||
|
||||
Pass the user's request, intended use, supplied image roles (reference versus edit target), relevant approved specification, requested format, and any style or technical constraints. Do not require the user to repeat information already available in the conversation or repository.
|
||||
|
||||
Before delegating, read [references/project-formats.md](references/project-formats.md) for routing and source-of-truth locations. For production or revision work, also read [references/review-workflow.md](references/review-workflow.md).
|
||||
|
||||
## Choose the deliverable path
|
||||
|
||||
- Prefer native `.prop` or `.stk` for project line art that must remain editable and compatible with the existing editors/runtime.
|
||||
- Treat clothing as layered shapes embedded in affected `.stk` body parts. A reusable or swappable wardrobe is a separate feature requiring design and architecture work.
|
||||
- For requested bitmap art, have Artist use the `imagegen` skill and move project-bound results into its review bundle.
|
||||
- For animation, use the current rig and authoring representation. Do not create a new prop-animation schema merely to fulfill an asset request.
|
||||
- Artist may browse for supporting visual references without a separate confirmation. It must record source URLs and must not redistribute unlicensed reference art.
|
||||
|
||||
## Review before promotion
|
||||
|
||||
Artist writes unapproved work to `content/review/artist/<request-slug>/`. Present the preview, candidate paths, suggestions, and validation results to the user, then stop for approval or revision.
|
||||
|
||||
Approval to create a draft is not approval to overwrite or promote a production asset. Promote only after explicit approval, preserve rejected variants until cleanup is requested, and use a versioned production filename unless replacement was explicitly requested.
|
||||
|
||||
When implementation work is also needed, hand the approved asset paths and `review.md` integration notes to `developer`. Artist must not absorb gameplay, editor, serializer, or runtime architecture work.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Asset Creation"
|
||||
short_description: "Create and review Stickman Studio artwork"
|
||||
default_prompt: "Use $asset-creation to create a review-ready Stickman Studio asset from my description or reference image."
|
||||
@@ -0,0 +1,35 @@
|
||||
# Project asset format routing
|
||||
|
||||
Inspect these sources at execution time; do not copy their schemas into prompts because the formats evolve.
|
||||
|
||||
## Stickmen and embedded clothing
|
||||
|
||||
- Serializer and current version: `scripts/editors/stickman/stickman_editor.gd`
|
||||
- Runtime conversion: `scripts/characters/stickman/stk_rig_adapter.gd`
|
||||
- Rig target: `scenes/characters/stickman/stickman_rig.tscn`
|
||||
- Representative current assets: `content/stickmen/*.stk` (confirm the version before choosing a sample)
|
||||
- Visual harness: `scenes/tools/test_harness.tscn`
|
||||
|
||||
An `.stk` owns ten body-part records and may contain multiple layered shapes per part. Clothing uses those layers until the project defines a separate wardrobe format. Preserve joint alignment, guide offsets, pivots, length metadata, body-part transforms, shape ordering, and the serializer's current version contract.
|
||||
|
||||
## Props
|
||||
|
||||
- Serializer/parser: `scripts/editors/prop/prop_file.gd`
|
||||
- Anchor normalization: `scripts/props/prop_anchor_data.gd`
|
||||
- Runtime visual/collision interpretation: `scripts/props/prop_visuals.gd`
|
||||
- Representative assets: `content/props/*.prop`
|
||||
- Visual editor: `scenes/editors/prop/prop_editor.tscn`
|
||||
|
||||
Use current `PropFile` output, including shape styling and normalized anchors. Ensure at least one valid closed shape can provide runtime collision geometry when the prop is intended for stage use. Lines are visual/editor shapes and do not supply collision geometry.
|
||||
|
||||
## Animation
|
||||
|
||||
- Rig scene: `scenes/characters/stickman/stickman_rig.tscn`
|
||||
- Existing authoring tool: `scripts/tools/create_animations.gd`
|
||||
- Playback behavior: inspect the relevant component under `scripts/characters/stickman/`
|
||||
|
||||
Stickman animations target the current rig's IK or animation targets, not `.stk` shape coordinates. Match the runtime clip name and locomotion/facing contract from the approved specification. For animated props, use only a representation already defined by the feature; otherwise return art direction, states, and timing requirements for architecture.
|
||||
|
||||
## PNG art
|
||||
|
||||
Use the `imagegen` skill for generated or edited raster art. Preserve alpha when transparency is requested. Approved PNGs go into the narrowest fitting `resources/` category; create a new `resources/art/<feature-or-kind>/` folder only if no current category fits.
|
||||
@@ -0,0 +1,36 @@
|
||||
# Asset review and promotion
|
||||
|
||||
## Review bundle
|
||||
|
||||
Use `content/review/artist/<request-slug>/`, where the slug is short, lowercase, and hyphenated. This tree is ignored by Git and is not scanned by the immediate-child prop and stickman library scanners.
|
||||
|
||||
Keep:
|
||||
|
||||
- versioned candidate files such as `briefcase-v1.prop` or `detective-coat-v2.stk`;
|
||||
- `preview.png` or a clearly named contact sheet;
|
||||
- animation key-pose captures when applicable;
|
||||
- `review.md`.
|
||||
|
||||
`review.md` records:
|
||||
|
||||
- the requested outcome and intended use;
|
||||
- which supplied images were references and which, if any, were edit targets;
|
||||
- creative choices and optional Artist suggestions;
|
||||
- external reference URLs and known license/usage notes;
|
||||
- candidate filenames and intended production destinations;
|
||||
- validation commands or scenes, observed results, and unverified outcomes.
|
||||
|
||||
Do not copy browsed reference images into the bundle unless the user owns them or their license permits redistribution.
|
||||
|
||||
## Approval boundary
|
||||
|
||||
Show the preview and report the candidate paths. Wait for explicit approval before copying a candidate to a production location. Revision requests produce a new version rather than destroying the earlier candidate.
|
||||
|
||||
After approval:
|
||||
|
||||
- `.prop` -> `content/props/`
|
||||
- `.stk` -> `content/stickmen/`
|
||||
- PNG -> the relevant existing `resources/` category, or `resources/art/<kind>/` when necessary
|
||||
- animation -> the approved specification's rig/tool asset location
|
||||
|
||||
Never overwrite an existing production file unless the user specifically approves replacement. Do not delete the review bundle unless the user asks for cleanup.
|
||||
@@ -30,8 +30,16 @@ description: "Stickman Studio feature workflow: UI/UX and architecture specs, im
|
||||
- The spec states observable acceptance outcomes and the user path that produces each one. For interactions involving physics, timing, saving/loading, or multiple systems, name a small repeatable runtime scenario and what to measure; do not prescribe a test implementation unless it is needed to protect a specific behavior.
|
||||
- **STOP:** Wait for final user sign-off on the spec before invoking developer.
|
||||
|
||||
5. **Phase 2: Implementation & Agent Verification**
|
||||
5. **Phase 1c: Conditional Art Production & Approval**
|
||||
- After spec sign-off, inspect the accepted specification for explicit new graphical or animation deliverables. Skip this phase when none are required.
|
||||
- Invoke `$asset-creation`, which delegates to `@artist`, with the signed-off specification, supplied reference images, intended asset type, and integration constraints.
|
||||
- `@artist` creates validated candidates under `content/review/artist/<request-slug>/`, including a preview and `review.md`; it does not modify gameplay/runtime architecture or promote the candidates yet.
|
||||
- Present the review bundle and **STOP** for user approval or revision. Do not invoke developer while required artwork remains unapproved.
|
||||
- After explicit approval, promote the selected assets to their production locations and pass their paths plus integration notes to developer.
|
||||
|
||||
6. **Phase 2: Implementation & Agent Verification**
|
||||
- `@developer` updates code and scenes using targeted diffs based on `docs/specs/[feature-name].md`.
|
||||
- When Phase 1c ran, `@developer` consumes the approved asset paths and Artist integration notes; it does not silently replace approved artwork.
|
||||
- `@developer` runs Godot syntax/import checks and focused existing regression suites, then fixes failures.
|
||||
- `@developer` adds focused automated coverage where it can meaningfully verify the feature's observable acceptance outcomes. For cross-system or runtime behavior, construct a small repeatable scene or fixture (in memory or as a saved scene), use the real production spawning/input/action paths where practical, advance frames or physics ticks, and assert the resulting state. A check that nodes, signals, layers, or helper calls exist is insufficient when the requirement concerns what actually happens during play.
|
||||
- For visual or interactive acceptance criteria, establish the verification route before concluding Phase 2: run the affected scene in a render-capable GUI session, capture the states named in the spec, and inspect the rendered pixels. Record the scene/state, capture location, and what was observed. A successful launch, headless run, or screenshot command/file by itself does not prove visual correctness.
|
||||
@@ -39,8 +47,8 @@ description: "Stickman Studio feature workflow: UI/UX and architecture specs, im
|
||||
- If the environment may not support rendering or input, try to establish whether a GUI, capture, or input-automation route is available; do not infer that it is unavailable from a headless run alone. If verification still cannot be performed, record what was attempted and the specific limitation, mark the affected acceptance outcomes unverified, and leave a focused, reproducible user check. Do not report the feature as fully agent-verified while required outcomes remain unverified.
|
||||
- `@developer` reruns the relevant checks after fixes and reports commands, pass/fail results, the measured behavior, and any unverified acceptance outcome. Do not claim a feature is verified from syntax checks or debug prints alone.
|
||||
|
||||
6. **Phase 3: User Hand-off (Stop)**
|
||||
7. **Phase 3: User Hand-off (Stop)**
|
||||
- Present the implementation and agent verification evidence. Give the user only the remaining visual, usability, or environment-dependent checks to perform in the Godot Editor; clearly identify any acceptance outcome the agent could not verify.
|
||||
|
||||
7. **Phase 4: Documentation (Triggered manually by user)**
|
||||
8. **Phase 4: Documentation (Triggered manually by user)**
|
||||
- Only call `@writer` after the user confirms: "Feature verified and working."
|
||||
|
||||
Reference in New Issue
Block a user