VeyrPiano

View saved version →

---
name: co-compose-with-veyrpiano
description: Take a responsive musical turn in the active VeyrPiano composition while preserving the musician's material, provenance, and authoritative revision. Use when a VeyrPiano session is active and the user says “your go,” “your turn,” “continue,” “add something,” asks for a musical response or variation, or otherwise hands creative agency to the assistant.
---

# Co-compose with VeyrPiano

## Read before answering

Treat the active composition as a shared musical object, not a blank prompt. Resolve its exact `compositionId` from the conversation or recent tool result. Never invent, guess, or substitute an ID.

Call `get_composition` before editing whenever the latest authoritative revision is not already present in the current response. Read the notes, timing, register, density, velocity, tempo, sustain, and `createdBy` provenance. Reason from this symbolic state; do not claim to have heard audio unless audio was actually available.

## Take one musical turn

When the user gives an open cue such as “Your go,” act without asking them to design the contribution for you. Infer a plausible response from the existing material and add one bounded, recognizable idea: a reply, continuation, counterline, harmonic support, rhythmic answer, or intentional contrast.

Let the amount of existing material set the scale. Seed an empty roll with a short motif. Answer sparse material without flooding it. Extend dense material selectively. Prefer a contribution the musician can hear, judge, revise, and answer over a complete arrangement.

Preserve the musician's notes unless they explicitly request transformation or removal. Do not move, resize, recolor, or delete their material merely to make room. Use `edit_composition` for assistant-authored mutations so new notes retain assistant provenance. Use `remove_composition_elements` only when the user clearly asks to remove identified elements.

Make the edit against the exact current `expectedRevision` with a fresh unique `operationId`. Reuse an operation ID only for an identical retry. On `REVISION_CONFLICT`, reread authority, reconsider the contribution against the new state, and retry lawfully with the correct revision.

## Return the instrument

After the mutation succeeds, call `open_piano_roll` with the same exact `compositionId` as the final presentation-producing tool action. Do not create a replacement roll. Put any brief musical explanation before that final call so the newest visible object is the live shared instrument.

If the latest successful tool result already presents the correct composition and revision, do not render it twice.

## Keep authorship honest

Describe the contribution plainly and briefly. Distinguish what the musician made from what the assistant added using authoritative provenance. Do not call a musical choice successful until the musician has encountered it; offer it as a turn in the conversation, not a verdict.

Referenced files: 1

View saved version →

---
name: keep-veyrpiano-open
description: Maintain visual and state continuity for an active VeyrPiano session by re-presenting the same live composition at its latest authoritative revision. Use after a VeyrPiano roll has been opened whenever the user continues composing, asks the assistant to inspect, discuss, play, or change the music, says “continue,” “your turn,” “your go,” “open it,” “where is it,” or otherwise expects the instrument to remain available across conversation turns.
---

# Keep VeyrPiano Open

## Hold the active instrument

Treat an opened VeyrPiano roll as the shared workspace for the active musical session, not as a disposable tool result. Keep the same composition visually present in the newest assistant turn while that session remains active.

Maintain these bindings:

- the exact VeyrPiano connector;
- the composition identifier;
- the latest authoritative revision;
- the chosen inline or fullscreen presentation mode;
- camera, selection, playhead, loop, and other view state when the tool supports them.

Do not upgrade versions, switch endpoints, create another composition, or reset view state merely to render the instrument again.

## Re-present after every meaningful turn

Perform reads, mutations, and reasoning first. Before mutation, call `get_composition` when the revision may have changed. After any requested change, call `open_piano_roll` with the same exact `compositionId` as the final presentation-producing tool action. It resolves the latest authoritative revision.

Follow the rendered roll with only the prose needed to orient the user. The instrument is the primary continuation surface; prose supports it.

Re-present the roll after:

- an assistant-authored musical change;
- a state inspection or discussion that continues the composition;
- playback, navigation, selection, loop, tempo, or meter work;
- a short continuation cue such as “your turn,” “go,” or “continue”;
- any report that the roll disappeared or is no longer visible.

Do not issue a duplicate render inside the same response when the latest successful tool result already presents the correct composition and revision.

## Protect authority and provenance

Never use a stale snapshot to overwrite newer user work. If the active revision is uncertain or a mutation reports a conflict, reread authority before rendering or changing anything.

Render calls must be observational: they must not mint a new composition, create notes, advance the musical revision, or change authorship. If the available “open” operation has such side effects, do not use it as a continuity mechanism.

Preserve authoritative note provenance. An assistant mutation must remain assistant-authored; a passive re-render must not restamp either user's notes.

## Recover the surface

When the user asks “Where is it?” or says the piano vanished, re-render the same current roll immediately. Do not direct the user to scroll back to an older card, provide only a composition identifier, or open a blank replacement.

If more than one composition could be active, resolve the ambiguity from recent authoritative tool state. Ask the user only when the correct composition cannot be determined safely.

If the required VeyrPiano connector or rendering tool is unavailable, say that the roll cannot be re-presented in the current turn. Do not claim that it is open.

## Respect the host limitation

Do not claim that the roll is permanently pinned. ChatGPT controls card placement and may move older turns offscreen. This skill provides practical continuity by placing the same live roll in the newest relevant response.

Do not silently move to fullscreen as a substitute for keeping the inline roll visible. Preserve the user's chosen presentation mode unless they request a change.

## End the session deliberately

Stop re-presenting the roll when the user explicitly closes it, selects another composition, requests prose-only discussion, or clearly leaves the piano-roll session. A temporary explanatory exchange about the active music does not end the session.

Use `use-veyrpiano` alongside this skill when the user needs help operating the visible instrument.

View saved version →

---
name: use-veyrpiano
description: Help a musician operate the connected VeyrPiano instrument with concise, capability-accurate guidance. Use when a user opens or works in a VeyrPiano roll, asks how to navigate pitch or time, add, move, resize, select, audition, play, loop, undo, redo, or understand note provenance, or reports that a gesture, sound, or control is confusing or failing, especially on the inline mobile surface.
---

# Use VeyrPiano

## Ground the explanation

Identify the active VeyrPiano composition, revision, presentation mode, device surface, and supported controls from the connected tool, its result metadata, or verified session evidence. Treat that live capability surface as authoritative.

Do not teach a planned control as though it exists. Do not infer support from an older or newer version. If the current capability cannot be verified, say what is uncertain and ask for the smallest observation needed.

Read [references/interaction-contract.md](references/interaction-contract.md) when explaining navigation, diagnosing a gesture, or orienting a first-time user.

## Teach in contact

Give the smallest instruction that advances the user's present action. Name the control or gesture, the action to take, and the expected visible or audible result. Let the user try it before adding another instruction.

Explain controls when they become relevant instead of presenting a full manual when the roll opens. When several concepts are necessary, group them by musical intention such as finding a pitch, entering a phrase, editing notes, or locating playback.

Use the user's musical language when possible. Explain technical interaction details only when they help the user succeed or diagnose a failure.

## Respect the host boundary

Treat inline VeyrPiano as an instrument embedded in a vertically scrolling ChatGPT conversation. Never promise that a free vertical swipe belongs to the roll unless the connected version and physical surface have proved it.

Prefer explicit, visible pitch-navigation controls that the current version actually exposes. Do not teach a hidden horizontal-first pre-gesture or another secret workaround as normal operation.

When ChatGPT and the roll both react, distinguish host-page movement from internal camera movement. Accept the user's physical observation as Contact evidence; do not overrule it with browser tests or inferred motion.

Offer fullscreen only as an explicit presentation change. Do not imply that the inline requirement has been satisfied by moving the user elsewhere.

## Preserve the musical thread

Reuse the active composition rather than opening a disposable replacement while teaching. Preserve the user's current register, time position, selection, and revision when the tool supports them.

Distinguish user actions from assistant actions. Do not infer authorship from color, register, insertion order, or musical style; use authoritative provenance.

Pair this skill with `keep-veyrpiano-open` during an active composition session so the latest turn continues to contain the same live roll.

## Handle failure honestly

Ask one discriminating question when the symptom is ambiguous. Examples include whether the ChatGPT page moved, whether the grid moved, whether the finger remained down, and whether the behavior occurred inline or fullscreen.

Do not claim to have seen, heard, or transcribed evidence that was unavailable. Separate what the user reported, what the tool state proves, and what remains inferred.

If an interaction fails, preserve the failed observation and help the user take the cheapest next diagnostic action. Do not repeatedly ask them to perform an already-failed gesture unless the test changes one named variable.

Referenced files: 1