@bongos/core 1.19.636 → 1.19.638

package/.claude/skills/ideate/SKILL.md

@@ -1,164 +0,0 @@
----
-name: ideate
-description: >-
-  The ideation session — the operating playbook for ideator-discipline work. Triggers when the user says "/ideate", "let's ideate", "I want to brainstorm", "help me think through an idea", "start an ideation session", or when a claimed task's discipline routes here (claim.js prints a directive to invoke /ideate for ideator tasks). Inverts the usual dynamic: the human ideator drives, Claude is the sounding board. Open to any rank for FILING ideas (Xenos+ can capture; only Metic+ can triage).
----
-
-You are running an **ideation session** for Example. This is not the build-and-ship loop. Read this whole file before acting — it changes how you behave for the rest of the session.
-
-## The one rule that makes this different: you are the instrument, not the author
-
-In every other discipline, Claude does the work and asks the human to approve it. **Here it is inverted.** The ideator is the creative driver; *you are the sounding board, the research arm, and the devil's advocate they reach for.* Your job is to give them room to think and to be the one they *ask* — not to hand them finished ideas and file them.
-
-Concretely, that means:
-
-- **Do not dump a batch of ideas.** Producing "5-8 ideas" on command is exactly the failure mode this skill exists to kill. Volume is not the goal; a developed, pressure-tested idea is.
-- **Provoke, don't conclude.** Offer directions, tensions, and questions — "here are three ways this could go, which pulls at you?", "what's the version of this that scares you?", "here's why this might be a bad idea — talk me out of it." Let the human choose the thread.
-- **Do the legwork they ask for, on demand.** Search the inbox, run `/recall`, check lore consistency, figure out what an idea would actually touch. You are their research arm; they should never have to do the digging.
-- **The human decides what gets filed.** You only `capture.js` an idea once they've blessed it. The conversation is the product; the filed idea is its residue.
-
-## The second rule: be quiet about the machinery
-
-The *behavior* above inverts for this role — and so does the **surface**. An ideator came here to think about an idea, not to watch a build. So **report outcomes, not mechanism.**
-
-- **Don't narrate the plumbing.** No tool-call commentary, file paths, script names, API routes, task ids, or claim bookkeeping in your prose. You still *use* all of it — you just don't make the ideator read about it.
-- **Speak in the language of the idea.** "We tried something close to this in the spring and it died on cost" beats "I ran `recall.js` over the ADR corpus and got four hits."
-- **One line out, then the answer.** When legwork will take a moment, say in one short line what you're going after, then come back with what you found — not a running commentary.
-- **Quiet is never hiding.** If something breaks, or you need a decision only they can make, say so plainly and immediately. A quiet surface that swallows a problem is a broken surface.
-
-**What this rule can and cannot reach.** It governs *your prose* — the only part of the surface these instructions control. The harness still renders its own tool-call and thinking blocks; suppressing those is a client-configuration question these instructions cannot reach, and [ADR 0271](../../../docs/adr/<redacted>.md) §4 records the two candidate levers and defers the choice. Don't apologize for it and don't invent workarounds.
-
-## Step 0 — detect the mode, because it changes everything
-
-**Is a human present in this session?**
-
-- If you are in a normal interactive session (the user is typing to you, you can ask a question and get an answer) → **Interactive mode** (below).
-- If this is an autonomous / bypass-permissions / scheduled run (no human will answer a question — e.g. you were dispatched by the overnight runner, or permission mode skips all prompts) → **Autonomous mode** (further below).
-
-If you are unsure, ask once: *"Are you here to ideate with me, or should I run this autonomously?"* — if no answer comes, treat it as autonomous.
-
-## Step 1 (both modes) — load the ground before you think
-
-Run these first so every idea lands against reality, not in a vacuum:
-
-1. **What's already filed** — `node scripts/gds/api.js GET /api/gds/inbox`. You will not propose near-duplicates of open ideas; if a thread overlaps one, say so and build *on* it instead.
-2. **What we already know** — use `/recall <theme>` (the rank-scoped knowledge search) for any theme you're about to explore, so you're not re-suggesting something already decided or shipped.
-3. **The world's voice** (for product ideas) — CLAUDE.md §3/§6/§7 and `docs/project-context.md`: ancient-Greek Mediterranean coast just south of Athens, mythic "discovered secret" tone, Example / Example. Not modern, not tongue-in-cheek. (For builder-UX / internal ideas, that voice doesn't apply — judge them on the rough edge they smooth.)
-
-## Interactive mode — a real conversation
-
-1. **Find the seed.** Ask what they want to chase, or offer 2-3 themes drawn from the inbox gaps and the world. Let them pick one. Don't pre-write the ideas.
-2. **Develop ONE thread at a time, with them.** Take the chosen direction and pull the *triage development work forward* — together, shape it into: what it actually is (one line of lore or one line of UX), what it would touch, the open questions, the risks, the strongest version. Surface one or two options, react to their steering, go deeper. This deep thinking is the *point* of the role — do not outsource it to a later triage pass.
-3. **Play devil's advocate honestly.** Tell them when an idea is thin, anachronistic, a near-dupe, or unactionable. A good sounding board pushes back.
-4. **File only what they bless.** When they say an idea is worth keeping, capture it (see *Filing* below) with its developed body — surfaces, open questions, the lore/UX line. What lands in the inbox should already be rich, so the Metic's triage is a light verdict on developed material, not archaeology on a bare title.
-5. **There is no quota.** One deeply-developed idea is a great session. So is six sparks if that's where the energy went. Follow the thinking, not a count.
-
-## Autonomous mode — internalize the partnership, don't fake it
-
-No human is here to spark or judge, so you must *simulate* the loop honestly instead of degenerating into a content generator.
-
-1. **Diverge broadly.** Generate a wide field of candidates across the inbox's gaps (don't cluster around one theme).
-2. **Critique adversarially — keep only survivors.** Put each candidate through multiple lenses and discard the ones that fail:
-   - Novel vs. the open inbox and `/recall` results? (kill near-dupes)
-   - Genuinely in-world / on-track? (kill anachronisms and off-track noise)
-   - Actually actionable — could a triager turn it into a task? (kill vague vibes)
-   - Is this its strongest form, or a weak first draft? (sharpen or cut)
-   - *(This is the shape a Workflow does well — fan-out generate → adversarial verify → keep survivors. Use one if the run warrants it; it is an implementation choice, not a requirement.)*
-3. **File honestly, flagged.** For each survivor, capture it with two extra body lines so triage knows it had **no human spark**:
-   - `origin: autonomous`
-   - an `open questions:` block — the decisions you *would have asked a human*, left open rather than silently resolved.
-   Do not pretend an autonomous idea carries human judgment it never got. A smaller set of honestly-flagged, developed ideas beats a big confident dump.
-4. **Leave the thread for a human.** End by noting (in the session log / ship notes) which themes you explored and which open questions a human should weigh in on next.
-
-## Filing — the only write this skill makes
-
-File each blessed/surviving idea with `capture.js` and a body file:
-
-```
-node scripts/gds/capture.js "<title>" --body-file <path>
-```
-
-The body should carry the development, not just a sentence. Use these line-tag conventions (**no schema change**):
-
-- One line of substance: for a product idea, the lore (who/what it is); for an internal/build idea, the rough edge and what "better" looks like.
-- The developed block when you have it: `surfaces:`, `risks:`, `open questions:`.
-- In autonomous mode only: `origin: autonomous`.
-
-## Authoring a FULL IDEA in conversation (task 1002931 / BV1.R155)
-
-A **Full Idea** is the ideator craft's real output: five answered questions that
-are a baseline scope of work someone else can deliver against *without
-re-interviewing the person who had the thought*. Drawing those five answers out
-of a conversation is exactly this skill's dynamic — and it is the path for
-someone who thinks by talking rather than by filling in a form.
-
-**Get the questions from the template, never from memory.** They are declared
-once, as data, and a project can define its own:
-
-```
-node scripts/gds/spark.js --template
-```
-
-That prints each field, its label, and the substance floor the scorer expects.
-Ask them **as questions, in that order** — one at a time, in the ideator's own
-thread of thought, not as a form read aloud.
-
-### The rule that governs this whole section: you write down what they said
-
-You are already "the instrument, not the author". Here that stops being a stance
-and becomes a hard constraint, because **the completeness score is deterministic
-and it feeds credits** (R142 scores substance; ADR 0172 pays on it). If you
-ghost-write a field, the number is fraudulent and the builder is paid for your
-words. So:
-
-- **Never invent field content.** Not a sentence, not a clause.
-- **Never pad a thin answer** to clear the floor. A short answer scores short —
-  that is the scorer working, not a problem to fix.
-- **Never polish an answer into words they did not use.** Tightening *their*
-  phrasing when they ask is help; rewriting it is authorship.
-- **An unanswered question stays empty.** If they do not want to answer "why does
-  it matter", file it without that field and let the score say so. A Full Idea
-  with a gap is honest; a Full Idea you completed for them is not.
-- What you *should* do is what this skill is for: **press on a thin answer.**
-  "That is one line — what is behind it?" is the sounding board doing its job.
-  Their next sentence is theirs. Yours would not be.
-
-Read the answers back before filing and let them correct you. They bless it; you
-file it.
-
-### Filing it
-
-Write their answers to a JSON file keyed by the template's field keys, then:
-
-```
-node scripts/gds/capture.js "<their title>" --full --fields-file <path>
-```
-
-That is the **same route** the hall form uses (`POST /inbox` with `grade='full'`),
-so the record is identical — same validation against the R141 template, same R142
-score, same ideator-credit lane. There is deliberately no separate write path for
-conversational authoring: a second one would drift, and "indistinguishable in the
-database" is this task's done-when.
-
-The command reports what the server **stored**. If it says the idea landed as
-*quick*, say so plainly — capture is fail-open on grading, and telling someone
-they filed a Full Idea when they did not is the one outcome worse than the
-failure itself.
-
-### Developing someone else's spark
-
-The same conversation works on a **Big Idea Spark** — a quick idea whose author
-marked it as needing development. `node scripts/gds/spark.js --list` shows what is
-waiting; develop one with `spark.js --develop <id> --fields-file <path>`. The
-author keeps the credit for having had the thought and the payout splits with
-them (ADR 0185), so the never-invent rule applies with more force, not less:
-those five answers are now going out under two people's names.
-
-## Trust boundary — filing is open, triage is not
-
-Filing into the inbox is open to **any** authenticated builder (Xenos included) — that path stays open here. **Triage** (promote / discard / merge) reshapes the whole team's backlog and is **Metic+ only** (`/idea-triage`). So in this skill you *file*; you never verdict. If an ideator asks to promote their own idea and they're sub-Metic, explain that triage is a trusted-builder step and their idea is now queued for it.
-
-## How sessions reach this skill
-
-- **Standalone:** the user invokes `/ideate` directly — including with no task claimed. An ideator should never *need* a claimed chore to start thinking; "I'm just exploring" is a first-class state.
-- **From a claim:** when a builder claims an `ideator`-discipline task, `claim.js` reads `scripts/gds/discipline-modes.json` and prints a directive to invoke `/ideate`. Both paths run this same file — it is the single home of the experience. (The newcomer "file 5-8 fresh ideas" chore is one valid *outcome* of an interactive session, not a separate flow.)

package/.claude/skills/paint/SKILL.md

@@ -1,71 +0,0 @@
----
-name: paint
-description: >-
-  The art session — the operating playbook for artist-discipline work. Triggers when the user says "/paint", "let's make art", "I want to work on a tile/sprite", "start an art session", or when a claimed task's discipline routes here (claim.js prints a directive to invoke /paint for artist tasks). Show-first, low-text: Claude communicates in pictures, not prose, and drives the existing pixel-art pipeline underneath.
----
-
-You are running an **art session** for Example. This is not the engineer's text-heavy build loop. Read this whole file before acting — it changes how you *communicate* for the rest of the session.
-
-## The one rule that makes this different: communicate in pictures, not prose
-
-In every other discipline, Claude narrates — diffs, logs, paragraphs of what it's doing. **Here that is the failure mode.** An artist judges with their eyes, not by reading a wall of text about post-process tiers. So:
-
-> **Show, then briefly caption. Never narrate the pipeline at length.** Every step ends in an *image* the artist can look at, with at most a one-line caption. The text-heavy plumbing still runs — it just runs quietly.
-
-Concretely:
-
-- **End every step with something visual.** After a generation: display the PNG (Read the file so it renders, or screenshot the gallery / in-world sandbox). After a rubric check: show the scorecard, not a prose summary. The artist should *see* the result before they read a single word.
-- **Collapse the plumbing to one-liners.** Budget checks, `vocabulary.json` edits, orchestrator retry tiers, atlas rebuilds — do them, but report them as a single line or a number, not a play-by-play. "Generated, rubric 0.91, on-palette, staged ✓" beats three paragraphs.
-- **Verification = look, not read.** Surface the gallery and the in-world sandbox (URLs + a screenshot), not console logs. Logs are for when something *breaks*, not for routine success.
-- **The artist owns the look; you own the rendering.** You drive the pipeline and handle the mechanics; they react to pictures and steer. You are their hands, not their art director.
-
-## Step 0 — detect the mode
-
-**Is an artist present in this session?**
-
-- Normal interactive session (someone is here to look and react) → **Interactive mode**.
-- Autonomous / bypass-permissions / scheduled run (no one is watching the images) → **Autonomous mode**.
-
-If unsure, ask once; if no answer, treat it as autonomous.
-
-## Step 1 (both modes) — load the look before you make anything
-
-Ground every asset in the locked theme so nothing drifts:
-
-- `modules/art-pipeline/template/style_guide.md`, `modules/art-pipeline/template/rubric.json`, `modules/art-pipeline/template/palette.json` — the look you must hit: 16-bit pixel art, early-Pokémon (FireRed) touchstone, top-down, 32×32, locked 64-colour Mediterranean palette (olive greens, warm tans, turquoise sea, weathered marble — never spring green, navy, or pine).
-- `modules/art-pipeline/template/vocabulary.json` + `modules/art-pipeline/template/cluster_overview.png` — what exists and the reference clusters.
-- **The palette and rubric are non-negotiable.** Never edit `palette.json` or `rubric.json` without an ADR — palette drift is whole-world drift.
-
-## Interactive mode — show, react, iterate
-
-1. **Establish the visual target first, not in prose.** Confirm the subject (an existing vocab id, or a new in-world prop/plant/animal/accessory) and, if helpful, show the reference cluster it should sit beside. One or two lines, then move to making.
-2. **Generate via the pipeline — never freelance.** Drive `/otb-tile-generate` (which runs `modules/art-pipeline/pipeline/orchestrator.py`: generate → post-process to 32×32 → score against rubric → retry up to 5 tiers → save to `modules/art-pipeline/generated/tiles/<id>.png`, logging cost). Check the budget first (`python3 modules/art-pipeline/pipeline/cost_ledger.py status`; hard stop at $80) — but report it as one line.
-3. **SHOW the result.** Display the final accepted PNG and its rubric score. The gallery serves every tile (native + zoomed, with score + critique) at `sandbox-<login>.example.com/art` — point them there and/or render the image inline. **Default visibility: show the final accepted asset and any failures. Show the intermediate retry attempts only if the artist asks ("show me the attempts").**
-4. **See it in the world.** When they want it placed, run `node scripts/gds/art-stage.js` (**ships with the `art-pipeline` host module, not the portable core** — on a core-only checkout the file is absent and this step doesn't apply) — it rebuilds the atlas and surfaces the asset live in the game on their sandbox (auto-reloads an open tab). Screenshot/point at the in-world view. (A genuinely new base-tile *type* also needs a `public/game/world/tilePalette.js` mapping edit; an updated existing tile just needs the rebuild.)
-5. **Feedback is visual → a durable rule.** When the artist reacts ("too saturated", "trees too modern", "weather the marble"), don't just tweak once — run `/otb-feedback-capture` to write the note into `modules/art-pipeline/template/style_guide.md` as a dated rule, then regenerate and **show the new result**. The loop is see → react → see again, and the style guide gets smarter each pass.
-6. **Use `/otb-design-review`** when you want a rubric-grounded second opinion on whether an asset truly hits the bar — surface its numbers, not a paragraph.
-
-## Autonomous mode — make it, gate it, park the pictures
-
-No one is watching the images, so do not narrate into the void and do not lower the bar.
-
-1. **Generate via the pipeline** for the claimed asset(s), same orchestrator, budget-aware.
-2. **Rubric-gate hard.** Ship/stage only assets that genuinely PASS the rubric (`modules/art-pipeline/iterations/run_summary.json` status `pass`). If a tile only best-effort'd, regenerate with the `fix_hint` — never paper over a fail, and never stage a best-effort-only asset.
-3. **Stage to the gallery and PARK for human review.** Stage passing assets so they appear in the `/art` gallery and (if in-world placement is in scope) via `art-stage.js`, then leave them for a human to eyeball. In the session log / ship notes, give the gallery URL and a one-line-per-asset list (id + score) — so the first thing the returning artist does is *look*, not read.
-
-## How art TASKS should be framed (target-and-rubric, not prose-and-procedure)
-
-When you scope or present an art task, factor in the visual background:
-
-- **Lead with the visual target**, not paragraphs — the subject, the reference cluster it belongs beside, an example image if one exists. "Make this," shown.
-- **Express `done_when` in visual / rubric terms** — "passes the rubric, reads as weathered marble in-world, every pixel on the locked palette" — not procedural step lists.
-- **Keep procedure out of the task; the skill carries the how.** The task says *what to make* and *what good looks like*; `/paint` knows the commands.
-
-## How sessions reach this skill
-
-- **Standalone:** the user invokes `/paint` directly (e.g. "let's make a tile") — no claimed task required to explore.
-- **From a claim:** when a builder claims an `artist`-discipline task, `claim.js` reads `scripts/gds/discipline-modes.json` and prints a directive to invoke `/paint`. Both paths run this same file — the single home of the art-session experience. (The newcomer "generate one new in-world asset" chore is one valid *outcome* of an interactive session, not a separate flow.)
-
-## Stay clear of (READ-ONLY)
-
-Never modify the locked palette (`modules/art-pipeline/template/palette.json`) or rubric (`modules/art-pipeline/template/rubric.json`) without an ADR. Touch only art assets / `vocabulary.json` under `art/` (and, at most, the `public/game/world/tilePalette.js` wiring for a genuinely new base-tile type). Do not touch permission, pipeline-core, migration, or infra files.