GitHub repository access in containerized environments using REST API and credential detection. Use when git clone fails, or when accessing private repos/writing files via API.
日本語の概要は準備中です。原文の説明を表示しています。
Listen to generated music by measuring it and by reading it as sheet music: render Strudel code or record a Web Audio page through the real engine in headless Chromium, then read spectrograms, pYIN pitch lines, chroma, roughness and semitone-rub meters; engrave notes as a score with beat-by-beat harmony; transcribe a melody from audio; read MusicXML/MIDI/ABC or a score image into notes and into Strudel code. Use to check whether generated music sounds right or better (before/after a change), to match a reference track, spectrogram image or score, or to find discordant chords, a buried melody, clipping or muddy mixes. Triggers on 'does it sound better', 'listen to', 'render and check', 'spectrogram', 'sfft/stft', 'discordant', 'clashing chords', 'sounds off', 'compare to the original', 'reproduce this track in Strudel', 'sheet music', 'score', 'notation', 'MusicXML', 'MIDI', 'ABC', 'transcribe', 'OMR'. Pairs with strudeling (writing Strudel); for format conversion use processing-video.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Claude hears nothing, but it can render audio in the real engine and measure it. Set up the loop render → look → measure → change one thing → re-render, and keep a table of the numbers per version. A version is better when a number you chose beforehand moves by more than the take-to-take noise, and the spectrogram shows the same thing.
Requirements: Node with playwright and Chromium (preinstalled in Claude Code on the web),
Python with librosa soundfile scipy matplotlib pillow, and for sheet music
music21 verovio mir_eval cairosvg
(pip install --break-system-packages librosa music21 verovio mir_eval cairosvg). The first render installs @strudel/web into
~/.cache/listening-to-music/. All scripts live in scripts/; run them with --help or read the
docstring for options.
S=/path/to/listening-to-music/scripts
node $S/render_strudel.mjs loop.js --out v1.wav --seconds 40 --warmup 4 # Strudel code
node $S/record_page.mjs page.html --click "#power" --out v1.wav --seconds 40 --warmup 8 \
--query "station=house" --eval "window.__fm.setSeed(7)" # any Web Audio page
Both print peak level and flag clipping. A peak above 1.0 means the listener hears hard clipping; fix levels before judging anything else.
For a before/after comparison, fix the randomness (a seed hook via --eval) so both versions
play the same material, and record each version twice.
python3 $S/spectrogram.py v1.wav --out v1.png --from-onset --pyin-floor G3 --label v1
Then open v1.png with the image viewer. The top panel is a note-axis CQT spectrogram with the
pYIN lead line, and the bottom panel is chroma. Compare it with the reference picture or the
previous version side by side. The .npz next to it holds the numbers for step 3.
| Question | Tool | Reads |
|---|---|---|
| Do simultaneous notes rub? (discordant chords) | render_strudel.mjs --events → clashes.py | minor 2nd/9th overlap per cycle, by layer pair; worst moments |
| Do they rub in the recording? | rubs.py, --pair for replicated takes | share of tonal peak energy in semitone/minor-9th pairs |
| Is it rougher or smoother overall? | roughness.py, --pair for replicated takes | Sethares roughness median/p90 |
| Does it match a reference image? | reference.py ticks/decode/compare | per-semitone profile, melody agreement, overtone offsets, chroma agreement |
| Is the melody audible over the mix? | spectrogram.py pYIN voiced %, reference.py compare melody % |
The clash scan is exact for the notes as written. rubs.py confirms them in the audio, where
release tails and reverb add overlaps the note data does not show. Record harmony checks with
percussion and noise textures muted in both versions: drum partials form their own peaks and hold
a full mix at a rub share near 0.28 whatever the chords do. Use --warmup, 40 s or more, and two
takes per version; --pair prints the take-to-take spread and says when a change is inside it.
Summed roughness (roughness.py) is a coarse overall measure. On Strudel FM (2026-09-24) it
could not tell the harmony fix apart from take-to-take noise in sleep and house. On the same
takes, the rub meter measured sleep −51%, ambient −33%, lofi −20% and house −13%, with spreads of
0.006–0.015. A loud bass drone dominates the roughness normalisation and hides a pad's rubs.
Don't treat an unmoved roughness figure as proof that nothing changed.
Notation is the other way to hear. A score shows voicings, clusters (noteheads pushed sideways are seconds), register and rhythm at a glance, and Claude reads clean engraving accurately. All these scripts share one events JSON (layer, t0, t1, midi; times in bars).
node $S/render_strudel.mjs loop.js --events ev.json --cycles 8 # notes as written
python3 $S/score.py ev.json --out score.png --layers LEAD,KEYS,BASS --harmony # engrave + analyse
python3 $S/transcribe.py take.wav --out mel.json --bpm 115 # notes as heard (melody)
python3 $S/compare_notes.py ev.json mel.json --ref-layer LEAD --cand-layer melody --align 1
python3 $S/read_score.py tune.musicxml --out ref.json # .mxl .mid .abc .krn, corpus:
python3 $S/to_strudel.py ref.json --out tune.js # score -> Strudel code
score.py --harmony prints each chord change with its pitches, music21's chord name, a Roman
numeral in the detected key, and a rub flag. On Strudel FM the same four lofi bars went from 15
of 28 chord changes with a rub to 0 of 28 after the voicing fix, and the engraving showed why:
the old Fmaj7 had its E and F side by side.
Measured on 2026-09-25 (compare_notes.py, onset within 0.05 bar and pitch within 50 cents):
| Path | Test | F1 |
|---|---|---|
| read_score → to_strudel → render events | Bach BWV 66.6, 4 parts, 163 notes | 100% every part |
| transcribe.py, one line | same chorale, soprano alone, piano, not used for tuning | 87% |
transcribe.py --no-split | synth lead with delay echoes | 82% (65% with splitting) |
| transcribe.py | full four-part chorale | 0%: monophonic only |
| OMR (oemer 0.1.8) | clean engraved soprano line | 6%; key read as flats, quarters as whole notes |
| Claude reading the image → ABC | unseen chorale, soprano + bass, 38 notes | 100% (one clean engraving) |
So:
K:, M:, L:, one V: per staff), convert it with
read_score.py, re-engrave with score.py, and compare the two pictures bar by bar before
using the notes. Use oemer only as a rough first pass, and never trust it unchecked.--no-split for leads with delay or echo.compare_notes.py --align N. It
searches shifts up to N bars and prints the one used.Change one parameter or rule at a time, and after each change render and rerun the same measurements. A metric can reward the wrong thing, so check it against the spectrogram each round.
.delaytime("3/8") means "3, over 8
cycles", so the delay was 3 s (clamped to 1 s). Pass a number: .delaytime(0.39).
.gain("0.9, 0.3") on a stacked pattern is itself a stack, so every hit fired twice and the
drums peaked at 2.9× full scale. Give each layer its own scalar gain.supersaw, …) need a secure context. Pages served from
http:// get no audioWorklet, and those synths are silent while everything else plays. The
scripts serve local pages from https://local.test/ for this reason. initStrudel also loads
the worklets only on the first document click, so the scripts click.reference.py compare (the overtone rows against the control rows) before voicing a pad
from them. A misread gave a Gmaj7 that the source never played.chordify() discards pitch spelling, and a Key's inferred tonic
transposes to the wrong letter (a leading tone of F instead of E♯ in F♯ minor). notes.spell
re-spells after every chordify from the key's own scale plus the raised 6th and 7th. Without
that, the score reads as wrong notes.reference.py ticks rather than by eye; a half-bin error splits every note across two
semitones.まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
GitHub repository access in containerized environments using REST API and credential detection. Use when git clone fails, or when accessing private repos/writing files via API.
日本語の概要は準備中です。原文の説明を表示しています。
Decide which model, effort level, and cascade shape each subagent gets, and how to keep improvement loops safe (evaluator-as-selector, stop on regression). Routes on measured cost-per-completed-task rather than per-token price, because a tier's token count varies more by task shape than price varies across tiers. Covers per-model effort semantics, the concision lever, cascade preconditions, context handoff, and watching a subagent fan-out live. Use when choosing a subagent's model or effort, when choosing how to escalate a failed attempt, or when asked which model or effort a task should get. Grounded in a 2026-07 calibration, a 2026-08 coding-cost study, a 2026-09 seeded-bug repair battery, a 2026-10 Haiku 5.5 ladder priced per spawn, and a 2026-10 retry-versus-escalation ladder on 295 SWE-bench Verified tasks; Managed Agents API specifics are operational, not calibrated.
日本語の概要は準備中です。原文の説明を表示しています。
Securely manages API credentials for multiple providers (Anthropic Claude, Google Gemini, GitHub). Use when skills need to access stored API keys for external service invocations.
日本語の概要は準備中です。原文の説明を表示しています。
Guidance for asking clarifying questions when user requests are ambiguous, have multiple valid approaches, or require critical decisions. Use when implementation choices exist that could significantly affect outcomes.
日本語の概要は準備中です。原文の説明を表示しています。
Pre-change blast-radius report for a symbol or file. Walks tree-sitting references, augments with a plain-text scan over non-parsed files (configs, plain docs), and clusters affected sites by feature (`_FEATURES.md`) or top-level package. Use when about to refactor, rename, or delete something in a repo you don't own — "what breaks if I change `validateUser`", "who calls this", "is this safe to remove", "where is this used", "blast radius", "impact analysis". This is the CONVERGENT pre-change risk skill — for "what is this repo?" use exploring-codebases; for "where is X?" use searching-codebases.
日本語の概要は準備中です。原文の説明を表示しています。
Read Bluesky/ATProto without depending on Bluesky's AppView — interactions on a user's posts, thread replies, any repo's records, network-wide backlinks across every lexicon, an account's handle and PDS history, which collections are active network-wide, and layer-by-layer outage diagnosis. Use when bsky.app or the AppView is down or slow, when a Bluesky read returns timeouts or 5xx, when asked who liked/replied/quoted/reposted something, when pulling live Bluesky context cheaply, when reading records straight from a PDS, when asked who references a record or account anywhere on the network, whether an account has changed handle or migrated servers, or which lexicons and non-Bluesky apps are active on atproto. Complements browsing-bluesky, which routes everything through the AppView and fails when it does.
日本語の概要は準備中です。原文の説明を表示しています。