Skip to content

chore: publish 1 skill (craft-game-floors) #106

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pre-shared-workflows-auth wants to merge 1 commit into from
Closed

chore: publish 1 skill (craft-game-floors) #106

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions skills/craft-game-floors/SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Security notes: craft-game-floors

This skill has the agent run C# inside the user's open Unity Editor (applying the craft floors:
materials, lighting, UI, audio, captures) and, for the live floor, wire Unity Gaming Services
calls in the user's own project. Automated skill scanners flag these as powerful capabilities.
They are intentional, and limited by the safeguards below.

## Accepted risks

| Risk | Capability | Why it is accepted |
|---|---|---|
| `SEC_POWER_CAP` | Runs C# in the user's open Editor | It only reaches the Editor the user already has open, on their own machine, as that user, behind the Pipeline capability gate. No code fetched from a remote source is run — the agent runs C# written from this skill's own references, which also require a restore point before project changes. |
| `SEC_CLOUD` | Wires Cloud Save / Leaderboards / Remote Config client calls (the live floor) | Only against the project's own cloud id, only when a live identity probe succeeds, and declining any floor is one word. Provisioning that needs credentials or the Editor UI is named as a human step, never automated. |

## Mitigations

- **Restore point first.** The skill requires a rollback point (a clean commit, or one it creates)
before changing the project.
- **Floors are declinable.** Every floor reverses on a word; declines are recorded, not argued.
- **Only the user's own Editor and project.** Everything runs on this machine as this user.
- **No remote code.** All executed C# comes from this skill's references.
- **Mechanics route to their owners.** Mixer routing, UI construction, backend integration, and
import settings go to their dedicated skills rather than being improvised here.
134 changes: 134 additions & 0 deletions skills/craft-game-floors/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,134 @@
---
name: craft-game-floors
description: "Makes a Unity game look and feel finished: art style, lighting, juice, sound, menus, saves and look scoring. Use when building a new game's first playable version, or when a game looks like programmer art, feels flat or silent, or needs polish."
allowed-tools:
- Bash
- Read
- Write
- Edit
---

# Craft Game Floors

A functional game that looks and feels like programmer art reads as a failure to the person who
asked for it. This skill is the craft layer: **floors** — disciplines where every game needs a
minimum and the engine's defaults are unacceptable — each carried by a reference below with
opinionated values, worked examples to imitate, and a verify step. The floors are the heart of the
**paved** path (Unity's default scaffolding for agent-built games: assumptions declared up front,
reversible on a word); in this skill, "paved" simply means these floors are always on unless the
user declines one.

**Before starting any floor or diagnosis, open and read the matching reference below and the Unity
docs pages it links** — your engine knowledge may be out of date, wrong, or for a different
version. Name the files and pages you read in your report. **Do only what's asked. Don't change
unrelated assets or files. Avoid long explanations.**

Two ways in, same floors:

- **During project creation** — the `new-unity-project` skill loads this one and carries the
floors through the build in the order below.
- **Mid-project, on any craft ask** ("fix the look", "add sound", "it feels flat", "make a title
screen", "score it") — jump straight to the matching reference, after the mid-flow check below.

**Scope by the ask**: a request that authorizes changes ("fix", "add", "polish") gets the floor
applied; an assessment-only ask ("score it", "what should I fix?") gets the scored board and
recommendations, with no project modifications until the user says go.

## Entering mid-flow

The references assume an **art bible** (style statement + fixed palette) and, where audio meets
UI, the **mixer handshake** (exposed params `MusicVol`/`SFXVol`). On an existing project, run
these in order before the asked-for floor:

1. **Restore point** — confirm a clean commit to roll back to, or create one, before any change.
2. **Render pipeline** — read `GraphicsSettings.currentRenderPipeline`: the look floors' verifies
are written for URP; on Built-in or HDRP, apply the opinions, name the pipeline gap, and skip
the URP-typed checks.
3. **Art bible** — look for a `Palette` type or an art-bible note (CLAUDE.md, docs); if none
exists, write the three-line bible from the game's current look first — retro-tinting later is
the expensive order.
4. **Identity (live floor only)** — verify player identity with a live probe (services
initialized and a PlayerId present), never by assuming an earlier setup step ran.
5. **Scope the done gate** to the surface you touched: a title-screen session scores the shell
and look axes, not the whole board.

**A floor fills an engine default, never a developer's choice.** If the project already has its
own controller, camera, shader, palette or style, keep it, apply only the floor's opinions that
don't conflict, and name the difference in the report. Write an art bible only from choices the
developer has made, and ask before adding one mid-project.

## The floors — numbered in build order, read each at its moment

1. [art-direction](references/art-direction.md) — before the first material, light, or UI element
2. [scene-lighting](references/scene-lighting.md) — with the visual baseline (3D)
3. [toon-shading](references/toon-shading.md) — when the art bible picks a cel/toon style (3D)
4. [camera-rigs](references/camera-rigs.md) — first gameplay camera (has a 2D section)
5. [placeholder-assets](references/placeholder-assets.md) — first missing asset
6. [character-motion](references/character-motion.md) — first moving character (3D-leaning)
7. *(the playable loop lands here — loop before content, one system per pass)*
8. [game-feel](references/game-feel.md) — the feel pass, after the loop
9. [vfx](references/vfx.md) — with the feel pass (has a 2D section)
10. [game-audio](references/game-audio.md) — before done
11. [game-shell](references/game-shell.md) — before done (2D backdrop delta). Before the first TextMeshPro text, import TMP Essentials (see the reference's failure table).
12. [live-floor](references/live-floor.md) — with the shell (services before gameplay code)
13. [visual-scorecard](references/visual-scorecard.md) — **the done gate, always last; run it once a playable loop exists.** During project creation, stop at the lit-baseline capture and skip the gate.

Mid-project asks enter at the matching number and pull earlier floors only as the mid-flow check
requires (the bible, the pipeline, the identity probe).

**Resolving `<VERSION>` in the references' doc links** — prefer WebFetch of the exact page over
WebSearch: for `docs.unity.com/en-us/engine/<VERSION>` manual and script-reference pages, use the
project's Editor stream (e.g. `6000.3`) from `ProjectSettings/ProjectVersion.txt`, and the same
stream for the remaining `docs.unity3d.com/<VERSION>/Documentation` pages; for
`docs.unity3d.com/Packages/<package>@<VERSION>` pages, use the installed package's major.minor
from `Packages/manifest.json` or the `Library/PackageCache` folder name; the
`docs.unity.com/en-us/<service>.md` services pages are unversioned.

Routing follows the game's 2D/3D nature; **the 2D look floor (sprite art direction, 2D lights,
sprite placeholders) is not yet covered** — on a 2D game, say so at those beats rather than
applying 3D instructions. The scorecard's 2D anchor set still applies.

## The boundary (what this skill is not)

This skill owns **opinionated creation and floors** — which values, in what order, to what bar.
Catalog neighbours own **mechanics on existing setups**: volume/post mechanics →
`urp-postprocessing` · routing sources into existing mixer groups → `audio-setup-mixers` · audio
import/memory → `optimize-audio` · UI framework choice and construction → `ui` · font assets →
`optimize-text-mesh-pro` · backend services → `build-live-game` · pixel-perfect 2D →
`2d-pixel-perfect`. When an ask is purely mechanical, route there; when it's "make it good," it's
this skill, which then delegates the mechanics. If this index wants to grow, the new thing is a
catalog skill routed by the prompt, not another floor — a floor must apply to *every* game.

## The done gate

A craft session ends with [visual-scorecard](references/visual-scorecard.md)'s board — scored
frames, not a green compile. In order:

1. **Score** all six axes per the scorecard. All six at 3 or better is the floor.
2. **Fix pass** — anything below 3 gets its fix before done (assessment-only asks: scores and
recommendations, no fixes). If a fix doesn't work, reread the relevant reference and its
linked documentation before trying variations.
3. **Console** — confirm zero console errors.
4. **Play check** — enter Play mode and check the touched behavior with `Debug.Log` lines you
added for the purpose. If the fix pass or this check fails, reread the relevant reference and
its linked documentation before trying variations.

## Final report

State: which floors ran and which references were read · the board (or the scoped axes) before and
after the fix pass · every incidental side effect — packages installed, files or settings edited,
assets imported — and any follow-up the user needs · any floor skipped or gap named (the 2D look
floor, a declined install, a missing neighbour skill), so the user knows what deeper guidance was
skipped.

## Common mistakes

- **Polishing without a bible** — fixing one object's look against no palette; write the
three-line bible first, even mid-project.
- **Replacing a developer's choice with a floor recipe** — an existing custom controller,
camera, shader or palette stays; the fix pass never swaps it for the floor's default.
- **Treating a floor as a feature** — floors are defaults; the user declines one with a word, and
the decline is recorded in the report, never argued.
- **Running the mechanics from memory** when a neighbour skill owns them — route and delegate.
- **Skipping the done gate** because the change was small — scope it down instead.
- **Applying 3D look instructions to a 2D game** — name the gap instead.
85 changes: 85 additions & 0 deletions skills/craft-game-floors/references/art-direction.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
# Art Direction

> Craft reference for the `craft-game-floors` skill. **Load:** before the first material, light, or UI element exists — in the creation flow, that is the start of the build (the paved default path); in an ad-hoc session, load it first whenever no art bible or `Palette` source exists yet, because every other floor depends on this one.

## The art bible — three lines, written first

Before the first material, write and print:

1. **Style statement** — one sentence ("Cel-shaded storybook interior: soft toon bands, chunky outlines, warm afternoon light").
2. **Palette** — 5–6 hex values + one accent, each named for its job (floor, walls, character-primary, character-secondary, props, shadow, accent/XP). Derive from the prompt's mood; keep saturation in one family.
3. **Mood** — the light source story ("late sun through windows, cool shadow bounce").

## Three worked bibles — imitate, then vary

Copy the closest one and re-derive the hexes from the prompt's own nouns; never ship these verbatim twice.

**Hearthside** (cozy interior)

- Style: "Cel-shaded storybook café: soft toon bands, chunky outlines, everything slightly rounded."
- Palette: floor `#8A6F4D` honeyed oak · walls `#E8D9BE` cream plaster · character-primary `#C96F4A` terracotta · character-secondary `#F4E7CE` oat · props `#5E7B5A` sage · shadow `#6B7A8F` cool slate · accent `#F2B134` amber.
- Mood: late sun through west windows; cool blue-gray shadow bounce; lamps warm the corners.

**Neon Ricochet** (bright arcade)

- Style: "Flat-shaded neon arcade: saturated shapes on near-black courts; everything that scores, glows."
- Palette: floor `#141A2E` ink navy · bounds `#253057` midnight · character-primary `#19D3F0` electric cyan · character-secondary `#F037A5` hot magenta · props `#7A5CF0` violet · shadow `#0B0F1E` abyss · accent `#F7E04B` laser yellow.
- Mood: no sun — the pieces are the light source; dim cool key, emissives and glow carry the frame.

**Derelict Signal** (moody sci-fi)

- Style: "Grounded sci-fi interior: desaturated steel broken by one signal color, hard light through grates."
- Palette: floor `#3A3F46` deck gunmetal · walls `#2A2E35` hull plate · character-primary `#C8CCD4` worn ceramic · character-secondary `#5A6472` slate · props `#4E5A50` olive drab · shadow `#1C2026` void blue · accent `#FF6A2B` signal orange.
- Mood: one hard cool key through ceiling grates; the accent reads as emergency lighting; shadows stay deep but blue, never black.

## Palette as the single source

Author one `Palette.cs` (static Color fields from the hex values) or a ScriptableObject. **Every** color in the project reads from it: materials, fog, light tints, particles, UI, text. The test is absolute: `Color.gray`, default Lit material, and default skybox never appear in a capture.

## Style is a system, not a shader on the hero

Whatever the style is, it covers *everything in frame*: character, walls, props, floor, sky, UI. The proven failure mode is a cel-shaded character in a default-lit room — the game reads as broken exactly at the seam. When the bible picks a toon pass, the pass applies frame-wide.

## Primitive characters that still read

Agent-built characters are assembled from primitives. Rules that make them charming instead of sad:

- **Silhouette first** — the character must be identifiable filled flat black. Exaggerate the identifying features (ears, tail, snout) ~30% past realistic.
- **Taper and tilt** — scale limb primitives asymmetrically (0.8× at the far end) and tilt joints a few degrees; nothing organic is axis-aligned.
- **Two-tone minimum** — body primary + belly/face secondary from the palette, plus dark accents (paw tips, ear interiors).
- **Nothing is statuary** — an idle character breathes: a 2–3 line sine bob on the body and a slow tail sway. Cheap, transformative.

## Worked character: Scout, the fox courier

A complete build to imitate. Parent chest, head, legs, and tail to the body; snout, nose, and ears to the head. Scales are local (x, y, z) against a body ~1 unit long; rotations in degrees; palette roles come from the active bible.

| # | Part | Primitive | Scale | Placement and tilt | Palette role |
|---|---|---|---|---|---|
| 1 | Body (root) | Sphere | 0.50, 0.42, 0.62 | egg lying along +Z | character-primary |
| 2 | Chest | Sphere | 0.34, 0.30, 0.30 | embedded front-under of body | character-secondary |
| 3 | Head | Sphere | 0.32, 0.30, 0.32 | above body front; pitch down 6 | character-primary |
| 4 | Snout | Sphere | 0.14, 0.10, 0.20 | head front; pitch up 4 | character-secondary |
| 5 | Nose | Cube | 0.05 uniform | snout tip; yaw 45 (diamond) | shadow |
| 6 | Ears ×2 | Cube | 0.10, 0.18, 0.04 | head top; roll ±12 outward | primary; inner face shadow |
| 7 | Legs ×4 | Capsule | 0.09, 0.16, 0.09 | under body corners; tilt 3–5 off vertical | character-primary |
| 8 | Paw tips ×4 | Sphere | 0.072 uniform | leg ends (the 0.8× taper) | shadow |
| 9 | Tail | Capsule | 0.12, 0.30, 0.12 | body rear; pitch back 55 | character-primary |
| 10 | Tail tip | Sphere | 0.10 uniform | tail end | character-secondary |

Idle: sine-bob the body ±2% of its height at ~0.6 Hz; sway the tail ±8° at ~0.3 Hz. The 0.18-tall ears are the ~30% silhouette exaggeration — keep it.

## Environment floor

No bare planes. Every room gets: floor material distinct from walls, baseboard/trim geometry at wall joins, 2–3 props scaled against the character, and one light-story element (window, lamp).

## Verify

Machine check first, capture second:

- Eval (via `unity-cli`): walk every `Renderer` and assert no `sharedMaterial` named `Default-Material`, and that `RenderSettings.skybox` is a palette-derived material, not the template sky. Any hit names its object. **Scope the fixes by the ask**: hits on the surface the request authorized get fixed before capturing (a full-look pass authorizes everything; a title-screen ask authorizes the title backdrop); hits outside that scope are never edited uninvited — report them as follow-up recommendations instead.
- Grep the project scripts for literal `Color.` constants outside the `Palette` source; a hit means the single source is being bypassed.
- Capture the character beside a doorway: scale and palette read together. A gray or default-lit surface in the frame fails the bible, not the capture.

## Expansion scope

Reference palettes per genre/mood beyond these three, texture and detail passes, integration with generated 2D/3D assets, style-transfer onto imported models, per-platform color calibration.
Loading
Loading