Music as Code

View saved version →

---
name: lilypond
description: Create, edit, explain, and repair LilyPond scores in local `.ly` files. Hand off a local file and a hacklily.org/wasm link after writing the source. Never open a browser to validate. Use for sheet music, classical scores, parts, lead sheets, engraving, SATB, chamber music, or LilyPond debugging. Do not use for Strudel, live-coding, DAW projects, or rendered audio unless the user also wants LilyPond source.
---

# Text to LilyPond

Create readable LilyPond source that the user can keep editing, engraving, and
playing. The local `.ly` file is the primary artifact. A chat response or a
rendered preview is not a substitute for the source.

## Speed

The user is waiting to see the score. Once the `.ly` file exists and the
Hacklily link is in the reply, **stop**.

Do not open Playwright, a browser, Hacklily, LilyBin, a PDF viewer, or a MIDI
player to validate, preview, or debug. Those tools being available is not
permission to use them. The user will see problems when they open the link.

Write the file, build the link, reply. That is the whole job unless the user
later reports a Hacklily or compile error.

If `lilypond` is on `PATH`, also compile once for PDF and MIDI next to the
source. A missing compiler is not a reason to delay the link.

## Working defaults

- Preserve the user's requested tempo, meter, key, instrumentation, length, and
  output path.
- If no path is given, write a short descriptive filename under `music/`, such
  as `music/sarabande-in-d.ly`.
- Start every file with `\version "2.24.0"` and `\language "english"`. English
  names are `cs` and `bf`, never `c#`, `cis`, or `bes` unless the user asks for
  another language.
- Every `\score` must contain both `\layout { }` and `\midi { }`. Missing
  `\layout` yields MIDI only. Missing `\midi` yields PDF only.
- Set `\tempo` so MIDI plays at the requested speed. LilyPond's MIDI default is
  quarter = 60.
- Prefer a short complete score over a large generated work. Add movements or
  parts only when the request calls for them.
- Put each part in a named variable (`rightHand`, `violinI`, `melody`) so later
  edits stay local.
- Use `|` bar checks at the end of every bar.
- Use only documented LilyPond syntax and General MIDI instrument names. Never
  invent a command, `\include`, or `midiInstrument` string to satisfy a prompt.
- Do not write Scheme (`#` functions, `#(define ...)`) unless the user asks for
  a feature that requires it.
- Do not autoplay MIDI.

Read [references/lilypond-code-guide.md](references/lilypond-code-guide.md) when
writing or debugging LilyPond. Search it for the specific construct instead of
loading unrelated material.

## Workflow

1. Inspect an existing target before editing it. Preserve its musical identity
   unless the user asks for a rewrite.
2. Translate the request into a short musical brief: tempo, meter, key,
   forces, length, and whether the user wants concert score, parts, or a lead
   sheet. State only assumptions that affect the result.
3. Write or edit the `.ly` source. The file must compile as a complete LilyPond
   input, not a fragment pasted in chat.
4. Build a viewer link with
   `node skills/lilypond/scripts/lilypond-url.mjs <file>` or equivalent URL
   encoding: `https://www.hacklily.org/wasm#src=` + `encodeURIComponent(source)`.
5. If `lilypond` is on `PATH`, compile with
   `node skills/lilypond/scripts/lilypond-compile.mjs <file>` when that path
   exists, otherwise `lilypond -dno-point-and-click -o <stem> <file>`. The
   script prints `pdf:` and `midi:` paths on success. If lilypond is missing
   (script exit 2), skip this step.
6. Reply with the handoff choices, compile status if attempted, and the tempo
   assumption. Then stop.
7. If the user reports a Hacklily or lilypond error, repair the smallest
   responsible part from the error text and repeat steps 4 to 6. Do not open a
   browser to find the error.

## Editing rules

- Change only the requested musical dimension when asked to preserve rhythm,
  harmony, voicing, or structure.
- For explanations, connect each LilyPond expression to what appears on the
  page or in the MIDI.
- For repairs, do not replace the whole score when a local syntax, octave, or
  duration correction is enough.
- Duration persists until changed. If a passage is rhythmically wrong, look at
  the last explicit duration before rewriting bars.
- `\relative` octaves are computed from the previous pitch. If one note is in
  the wrong octave, every following note may be wrong too. Fix the first bad
  leap, then recompile.
- Do not claim that a score sounds good or looks publication-ready based on a
  clean compile. Report compile status separately from the user's judgment.

## Handoff

Always include:

- **View source:** the exact `.ly` path as a clickable Markdown link
- **Open score and player:** a `hacklily.org/wasm` link built from that file's
  source
- The tempo assumption (for example `quarter = 96`)

When local compile ran, also include:

- Whether it passed or failed
- **View score:** the `.pdf` path as a clickable Markdown link
- **Play locally:** the `.midi` path as a clickable Markdown link. Do not
  autoplay or claim the host has a MIDI player.

Never claim the score was read or the MIDI was heard unless the user actually
did that.

Referenced files: 3

View saved version →

---
name: strudel
description: Create, edit, explain, and repair playable Strudel live-coding music in local `.strudel.js` files. Hand off a local file and a strudel.cc link after a local syntax check. Never open a browser or REPL to validate. Use for natural-language music requests, Strudel patterns, algorithmic composition, remixes, arrangement changes, or Strudel debugging. Do not use for rendered audio production, notation engraving, or DAW projects unless the user also wants Strudel source.
---

# Text to Strudel

Create readable Strudel source that the user can keep editing and performing.
The local `.strudel.js` file is the primary artifact. A chat response or audio
preview is not a substitute for the source.

## Speed

The user is waiting to press play. Once the `.strudel.js` file exists, syntax
check has run, and the `strudel.cc` link is in the reply, **stop**.

Do not open Playwright, a browser, strudel.cc, a headless runtime, or any REPL
to validate, preview, query cycles, screenshot, or debug. Those tools being
available is not permission to use them. A missing sample is cheaper than
making the user wait. They will hear problems when they press play.

Write the file, check syntax, build the link, reply. That is the whole job
unless `node --check` failed or the user later reports a REPL error.

## Working defaults

- Preserve the user's requested tempo, meter, harmony, instruments, structure,
  and output path.
- If no path is given, write a short descriptive filename under `music/`, such
  as `music/dub-at-dawn.strudel.js`.
- Treat one cycle as one bar in ordinary 4/4 requests. Convert BPM to cycles per
  minute with `bpm / 4`, for example 120 BPM becomes `.cpm(30)`.
- Prefer a small playable idea over a long generated arrangement. Add sections
  only when the request calls for them.
- Keep rhythm, harmony, bass, melody, and texture legible as separate patterns
  when that makes later live editing easier.
- Use only documented Strudel functions and known sound names. Never invent an
  API or sample name to satisfy a prompt.
- Do not autoplay audio. Playback requires a user action.
- Keep gain conservative. Avoid dense unbounded patterns that can produce a
  burst of simultaneous events.

Read [references/strudel-code-guide.md](references/strudel-code-guide.md) when
writing or debugging Strudel. Read
[references/strudel-sounds.md](references/strudel-sounds.md) when choosing
samples, synths, drum machines, or wavetables. Search these references for the
specific function or sound instead of loading unrelated material. Read
[references/official-docs.md](references/official-docs.md) when a bundled
reference is incomplete, ambiguous, or likely stale. Prefer current official
documentation when it disagrees with a bundled reference. If documentation
lookup is unavailable, do not invent an API or sound name.

## Workflow

1. Inspect an existing target before editing it. Preserve its musical identity
   unless the user asks for a rewrite.
2. Translate the request into a short musical brief: tempo, cycle convention,
   meter, sound palette, harmonic material, rhythmic character, structure, and
   requested performance controls. State only assumptions that affect the
   result.
3. Write or edit the `.strudel.js` source. The file must evaluate to a pattern,
   or use Strudel's `$:` syntax for concurrent patterns.
4. Check ordinary JavaScript syntax with `node --check <file>` when the source
   does not rely on REPL-only `$:` labels. A syntax check does not prove that
   Strudel functions or sounds exist.
5. Build a playable REPL link with
   `node skills/strudel/scripts/strudel-url.mjs <file>` or equivalent URL
   encoding: `https://strudel.cc/#` + `encodeURIComponent(source)`.
6. Reply with the handoff choices, whether `node --check` passed, and the tempo
   assumption. Then stop.
7. If the user reports a REPL error, repair the smallest responsible part from
   the error text and repeat steps 4–6. Do not open a browser to find the error.

## Editing rules

- Keep intentional repetition. Randomness is a musical choice, not a default
  way to make a loop seem sophisticated.
- Change only the requested musical dimension when asked to preserve rhythm,
  harmony, sound design, or structure.
- For explanations, connect each code expression to what a listener hears.
- For repairs, do not replace the whole composition when a local syntax or API
  correction is enough.
- Do not claim that a composition sounds good based on parsing or event checks.
  Report deterministic checks separately from the user's listening judgment.

## Handoff

Always include:

- **View source:** the exact `.strudel.js` path as a clickable Markdown link
- **Open and play:** a `strudel.cc` link built from that file's source; playback
  starts only after the user presses Play
- Whether `node --check` passed
- The tempo assumption (BPM and `.cpm()` value)

Optional:

- If the agent environment supports inline audio playback, the agent may attach
  a short preview. Treat that as a convenience, not the deliverable.

Strudel requires its browser audio engine, so do not offer fake terminal
playback. Never claim playback or listening occurred unless the user actually
heard it or the agent truly rendered audio in a supported environment.

Referenced files: 4

View saved version →

---
name: supercollider
description: Create, edit, explain, check, open, and locally play SuperCollider music in `.scd` files. Use for synthesis, algorithmic composition, generative music, live coding, effects, SynthDefs, Patterns, Routines, or SuperCollider debugging. Hand off clickable source plus choices to open the IDE or play through the local terminal. Do not use for engraved notation or Strudel patterns unless the user also wants SuperCollider source.
---

# Text to SuperCollider

Create readable `.scd` source. Treat the local file as the primary artifact.

## Working defaults

- Preserve requested tempo, form, synthesis method, and output path.
- Write a descriptive filename under `music/` when the user gives no path.
- Make each new file self-contained and safe to evaluate as a whole.
- Set `s.options.numInputBusChannels = 0` before boot for synthesis-only files.
  Preserve input channels when the composition actually uses audio input.
- Use only core classes and UGens unless the user requests a Quark or plugin.
- Keep amplitude conservative. Add `Limiter` or `tanh` when feedback, resonance,
  or summed voices can spike.
- Free temporary synths, buffers, buses, MIDI handlers, OSC handlers, and
  routines when the piece stops.
- Prefer named `SynthDef` and `Pdef` objects for music the user may edit live.
- Do not claim that code sounds good because it compiles or runs.

Read [references/supercollider-code-guide.md](references/supercollider-code-guide.md)
before writing or repairing source. Search it for the relevant construct instead
of loading unrelated sections.

## Workflow

1. Inspect an existing target before editing it. Preserve its musical identity
   unless the user asks for a rewrite.
2. Translate the request into tempo, duration or form, sound sources, processing,
   and performance controls. State only assumptions that affect the result.
3. Write or edit a complete `.scd` file. Put server-dependent setup inside
   `s.waitForBoot { ... }`.
4. Check syntax without running the composition:
   `node skills/supercollider/scripts/supercollider-check.mjs <file>`.
   The script locates `sclang` on `PATH` or in the standard macOS app location.
5. Hand off three choices. Do not launch or play automatically:
   - **View source:** render the exact local path as a clickable Markdown link.
   - **Open in SuperCollider:** after the user chooses it, run
     `node skills/supercollider/scripts/supercollider-open.mjs <file>`.
   - **Play locally:** after the user chooses it, run
     `node skills/supercollider/scripts/supercollider-play.mjs <file>` in an
     interactive terminal. Tell them that Ctrl-C stops playback.
6. GUI and audio actions may require user approval. If either helper exits 2,
   say that SuperCollider is not installed and link to
   `https://supercollider.github.io/downloads`.
7. Use terminal output to repair interpreter or server errors. Do not claim
   that opening the file evaluated it or that syntax checking proved playback.

## Editing and repair

- Change only the requested musical dimension when asked to preserve rhythm,
  harmony, synthesis, or form.
- Repair the smallest responsible expression from interpreter output.
- Use `Pdef` names consistently so reevaluation replaces the intended pattern.
- Avoid `s.freeAll` inside reusable source unless the file owns the whole server
  session. The terminal player stops with Ctrl-C.
- Treat missing third-party UGens and Quarks as dependencies. Do not replace
  them silently with invented names.
- For finite pieces, provide a clear stop or cleanup path. For live pieces,
  expose named patterns or routines the user can stop and reevaluate.

## Handoff

Always include the clickable `.scd` path, syntax-check result, the open and play
choices, and the tempo assumption. Report interpreter status if local playback
ran. Never claim playback or listening occurred unless audio actually ran.

Referenced files: 5