New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Fix Issues

by yvanvds in yvanvds/yse-soundengine

A skill your agent uses when fixing compiler warnings, static analyzer findings (clang-tidy, etc.), or runtime errors/crashes in the libYSE codebase.

MITAuto-check passedSecurity

Install Fix Issues

skills CLI
$ npx skills add yvanvds/yse-soundengine --skill fix-issues -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install yvanvds/yse-soundengine fix-issues --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/yvanvds/yse-soundengine.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/fix-issues .claude/skills/fix-issues && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
fix-issues
GitHub stars
238
Token cost
~3k tokens
SKILL.md length
1,630 words
Files
1
Skills in repo
4
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when fixing compiler warnings, static analyzer findings (clang-tidy, etc.), or runtime errors/crashes in the libYSE codebase.

  • Works in 4 steps: Correctness bugs first, cosmetic… → Performance is non-negotiable on the… → Stay in scope. Fix only what was… → …
  • Fixing compiler warnings
  • SKILL.md covers Issue tracking — GitHub Issues…, Core principles, Triage: classify every… and Performance rules, plus 6 more sections
  • Calls python and gh

What it does

Fix Issues is an agent skill from yvanvds/yse-soundengine. Use when fixing compiler warnings, static analyzer findings (clang-tidy, etc.), or runtime errors/crashes in the libYSE codebase. Enforces the project's performance-first stance: never trade audio-thread speed for stylistic cleanliness, never modify vendored dependencies, never broaden scope beyond the reported issues.

Its SKILL.md is about 3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Security, covering Static analysis and SAST. It works with GitHub. The repository describes itself as: advanced 3D sound engine. The licence is MIT.

When your agent uses it

  • Fixing compiler warnings
  • Static analyzer findings (clang-tidy
  • Runtime errors/crashes in the libYSE codebase

Example prompts

  • “/fix-issues”

Requirements

  • Python 3

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Correctness bugs first, cosmetic warnings second, never both in one pass.
  2. Performance is non-negotiable on the audio thread. Anything inside or
  3. Stay in scope. Fix only what was reported. Do not refactor, modernize,
  4. Never modify vendored dependencies. Anything under dependencies/

What it can do on your machine

Read from SKILL.md and the folder at commit 911ea2d. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • python
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Fix Issues loads about 3k tokens when it runs. Until then it costs about 83 tokens; SKILL.md has 1,630 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~83
When it runs · the whole SKILL.md, loaded when a task matches
~3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from yvanvds/yse-soundengine at commit 911ea2d, republished under its MIT licence (© yvanvds). 1,630 words, ~2,979 tokens.

Download SKILL.mdSave it as .claude/skills/fix-issues/SKILL.md (or your agent's skills folder).
name
fix-issues
description
Use when fixing compiler warnings, static analyzer findings (clang-tidy, etc.), or runtime errors/crashes in the libYSE codebase. Enforces the project's performance-first stance: never trade audio-thread speed for stylistic cleanliness, never modify vendored dependencies, never broaden scope beyond the reported issues.

Fixing warnings, analyzer findings, and runtime errors in libYSE

libYSE is a real-time C++ sound engine. Audio-callback code runs at buffer rate on a dedicated thread and must remain lock-free and allocation-free. "Cleaning up" code here is not free: a well-meaning fix can introduce a glitch, a click, or a crash that is far worse than the original warning.

This skill governs how to triage and fix reported issues. Read it fully before making any change.

Issue tracking — GitHub Issues only

All bugs, follow-ups, and known-issue notes live in GitHub Issues on yvanvds/yse-soundengine. Do not add new entries to a local KNOWN_ISSUES.md or any other in-repo issue list — that file has been retired and removed.

  • Read context: before starting a fix, check the relevant issue with gh issue view <n>. Look for prior repro steps, fix sketches, and workarounds-in-tests already documented.
  • File new findings: if a fix surfaces a separate bug, file it with gh issue create --title "..." --label bug --body-file ... rather than inlining a TODO comment that no one will find later. Workarounds in test code should reference the issue number (e.g. // see #29) instead of a file path.
  • Close on landing — always. Every fixed issue must end up closed on GitHub. Two paths:
    • Preferred: write Closes #<n> (or Fixes #<n>) in the PR body so GitHub auto-closes the issue when the PR merges into the default branch. Verify after merge — auto-close does not fire for PRs targeting non-default branches (e.g. this repo's dev integration branch), so a dev PR still needs the manual close below once the merge to master lands.
    • Manual: gh issue close <n> --reason completed after merge, with a short comment if context is non-obvious (gh issue comment <n> -b "fixed in <sha>"). Use --reason not planned when closing as wontfix or duplicate.
    • Partial fix: leave the issue open and edit the body to describe what is still outstanding, rather than closing and filing a follow-up.
  • Search before filing: gh issue list --search "<keyword>" — duplicates are easy to make when descriptions live across multiple subsystems.

The gh CLI is authenticated in the project environment; no MCP server or extra setup is required.

Core principles

  1. Correctness bugs first, cosmetic warnings second, never both in one pass. A dangling pointer and an unused-parameter warning are not the same problem. Fix the bug properly. Silence the cosmetic warning with the smallest possible change.

  2. Performance is non-negotiable on the audio thread. Anything inside or reachable from process() methods on dspObject / dspSourceObject, the PortAudio/OpenSL ES callback path, or the lock-free message queue consumer must not get slower. If a "fix" adds branches, allocations, virtual dispatch, atomic ops, or mutex acquisitions on this path, it is the wrong fix.

  3. Stay in scope. Fix only what was reported. Do not refactor, modernize, reformat, rename, add [[nodiscard]] everywhere, swap containers, sprinkle noexcept, or "improve" anything adjacent. Each of those is a separate decision the user has not made.

  4. Never modify vendored dependencies. Anything under dependencies/ (doctest, portaudio headers, rtmidi, libsndfile) is off-limits. Suppress warnings from these at the CMake target level or with a localized pragma around the include site, not by editing the header.

Triage: classify every reported issue before touching code

For each warning, analyzer finding, or error, decide which bucket it falls into:

A. Real bug

Examples: returning a pointer into a destroyed temporary, use-after-free, uninitialized read, missing override that hides a base method, data race, mismatched new/delete, signed/unsigned comparison that actually overflows.

These get fixed properly, even if the fix is bigger than a one-liner. A real bug in audio-thread code is the highest priority issue in this codebase because it manifests as glitches/clicks/crashes that are very hard to debug.

B. Cosmetic / pedantic warning

Examples: __COUNTER__ is a C2y extension, const qualifier on a return value type, unused parameters in virtual base methods with empty default implementations, unused-but-set variables in debug-only paths.

These get silenced with the minimum-impact mechanism (see below). Do not restructure code to satisfy a stylistic warning.

C. Maybe-bug-maybe-not

Examples: an overloaded virtual that hides the base, a signed/unsigned comparison in a loop bound, a "may be uninitialized" the compiler isn't sure about.

Investigate. If it is a bug → bucket A. If the compiler is being conservative and the code is correct → silence with [[maybe_unused]], static_cast, explicit initialization, using Base::method;, etc. Do not silence by disabling the warning globally.

D. Vendored / third-party

The reported file lives under dependencies/. Never edit. Suppress at the build-system level (target-scoped -Wno-...) or with a #pragma clang diagnostic push/ignored/pop block around the #include of the vendored header in our own code.

Performance rules

Before applying any fix, identify whether the affected code is on the audio thread. The audio thread is reached through:

  • Any process() override on a dspObject or dspSourceObject subclass
  • The PortAudio callback (device/portaudioDeviceManager.cpp) and OpenSL ES equivalent
  • The consumer side of the lock-free message queue (utils/lfQueue.hpp)
  • Anything called from the above transitively

On the audio thread, these are forbidden as part of a warning fix:

  • Adding heap allocation (new, malloc, std::vector::push_back on a vector that wasn't pre-sized, std::string construction, etc.)
  • Adding mutex/lock acquisition of any kind
  • Adding try/catch or anything that could throw
  • Replacing a plain field access with a std::atomic operation that wasn't already atomic (the project has aBool/aInt/aFlt wrappers — use those if atomicity is genuinely needed, but warning fixes rarely require it)
  • Adding virtual dispatch where there was none
  • Adding work inside hot loops (per-sample, per-frame) — even a single extra branch matters at 48000 × N-channel rates

Off the audio thread (application thread, manager singletons running in update(), file loading, demo code, tests), normal C++ rules apply, but still: minimum change to silence the warning.

Show full SKILL.md (688 more words)Show less

Preferred silencing mechanisms (when the issue is genuinely cosmetic)

Ranked from least invasive to most:

  1. Local annotation in our own code: [[maybe_unused]], (void)param;, /*paramName*/ comment, using Base::method;, explicit initialization, static_cast to the right type.
  2. Localized pragma around a vendored #include: #pragma clang diagnostic push / ignored "-Wfoo" / pop in the file that includes the third-party header.
  3. Target-scoped CMake suppression: target_compile_options(yse_tests PRIVATE -Wno-foo) for warnings that only matter in one target (tests are the typical case). Never apply globally to the engine target.
  4. Disabling the warning globally: essentially never. Reserve for warnings that have no signal value at all in this codebase.

Platform coordination

If the warning is platform-specific (e.g. only appears on MSVC, only on MSYS2/Clang64, only on Android NDK), check that the fix doesn't break the other platforms. The CMake build covers Windows and Linux; Android is built separately. Suppression flags must be guarded by compiler/platform conditions when the warning only exists on one toolchain.

Workflow

  1. Inventory. List every distinct warning/error from the build log. Group identical ones (a doctest __COUNTER__ warning hitting 38 times is one issue, not 38). Note the file path of each.
  2. Classify. Assign each group to bucket A/B/C/D above.
  3. Audio-thread check. For each bucket-A and bucket-C item, determine whether the affected code is on the audio thread.
  4. Plan. Write down the intended fix per group before editing. If a fix would change anything on the audio thread other than removing a real bug, stop and surface it for review rather than applying it.
  5. Apply. Make the smallest change that resolves each issue. Do not touch unrelated code in the same file.
  6. Verify. Rebuild on the platforms in scope. Run ctest --preset tests-debug. Confirm warning count drops as expected and no new warnings appear. Spot-check at least one demo runs (audio-thread regressions typically show up at runtime, not at compile time).
  7. Report. Summarize: groups fixed, mechanism used per group, any items deferred and why, any audio-thread-adjacent code touched.
  8. Close. Once the fix merges, ensure every referenced GitHub issue is closed (PR keyword auto-close or gh issue close <n> --reason completed — see "Close on landing" above). Partial fixes stay open with an updated body.

Running clang-tidy locally

A baseline check set lives at .clang-tidy. Invoke analysis through the project wrapper rather than calling clang-tidy directly — the wrapper picks the right compile_commands.json and avoids the "doctest/doctest.h not found" failure mode on test files:

powershell
python yse.py analyze YseEngine/dsp/lfo.cpp        # one file
python yse.py analyze YseEngine/device/            # one directory
python yse.py analyze                              # whole project (slow)

Per CLAUDE.md item 6, run python yse.py analyze <changed-files> before committing and clear any new findings on the modified code. The baseline is 43 distinct pre-existing findings across YseEngine/ and Tests/ (measured 2026-09-28, 2 in headers; the ~280 header findings #426 surfaced were cleared by #573) — don't fix in passing during unrelated work.

Note that a header finding is reported once per include spelling, not once per header: clang-tidy dedupes on the literal path, so the same warning shows up again as YseEngine/channel/../classes.hpp after YseEngine/classes.hpp. Judge "did I add a finding?" by the file:line, not by the line count.

Things that are out of scope for this skill

  • Adding new compiler warnings to the build (enabling -Wfoo that wasn't on before) without an accompanying issue
  • Migrating to a newer C++ standard
  • Replacing project utilities (aFlt, MULTICHANNELBUFFER, the message queue, dspObject::link()) with standard-library equivalents
  • Reformatting code that happens to be near a warning

If any of those would actually help, raise them as a separate proposal, not as part of a warning-fix pass.

Runtime errors and crashes

For runtime errors (assertions, segfaults, audio glitches, hangs) the same priorities apply but with different emphasis:

  • Reproduce first. A crash you can't reproduce is not a crash you can fix safely.
  • Distinguish audio-thread crashes from application-thread crashes. The former are usually races, lock-free queue misuse, allocations on the audio path, or DSP buffers being read past their length.
  • Do not "fix" by adding locks on the audio thread. The lock-free contract is structural; a mutex on the callback is a regression even if it eliminates the immediate symptom.
  • Audio glitches/clicks without a hard crash are real bugs, not cosmetic issues. Treat them as bucket A.

© yvanvds, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/fix-issues of yvanvds/yse-soundengine.

Open the folder on GitHubat commit 911ea2d

Compare with similar skills

Fix Issues next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Fix Issues compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Fix Issues this skillyvanvds/yse-soundengine238—~3kAutomated safety check: PassMIT
Triage Codeqlnetdata/netdata81k—~1.8kAutomated safety check: NotesGPL-3.0
Agentic GitHub Actions Auditortrailofbits/skills7.4k6 repos~5.4kAutomated safety check: NotesCC-BY-SA-4.0
Openclaw CI Limitsopenclaw/openclaw392k—~13kAutomated safety check: PassMIT
Implementing GitHub Advanced Security For Code Scanningmukul975/Anthropic-Cybersecurity-Skills34k—~2.3kAutomated safety check: PassApache-2.0
Pipeline Security Gatesrevfactory/harness-1001.3k—~1.5kAutomated safety check: PassApache-2.0

Similar skills

  • Triage Codeql

    netdata/netdata

    Inspect, review or triage GitHub Code Scanning alerts, including CodeQL findings; apply verified dismissals when authorized.

    81k GitHub stars~1.8k tokensUpdated today
    SecurityAuto-check: notes

  • Agentic GitHub Actions Auditor

    trailofbits/skills

    Official

    Statically audits GitHub Actions workflows that run AI coding agents, tracing attacker-controlled input to agent prompts and flagging unsafe sandbox, trigger and allowlist settings.

    7.4k GitHub starsUsed in 6 repos~5.4k tokens
    SecurityAuto-check: notes

  • Openclaw CI Limits

    openclaw/openclaw

    Manage OpenClaw GitHub Actions and Blacksmith CI capacity, runner-registration budgets, fanout caps, main-push single-flight, shard sizing, hosted-runner offload, queue health, and safe…

    392k GitHub stars~13k tokensUpdated today
    SecurityAuto-check passed

  • Implementing GitHub Advanced Security For Code Scanning

    mukul975/Anthropic-Cybersecurity-Skills

    Configures GitHub Advanced Security (code scanning with CodeQL, secret scanning, dependency review, and Dependabot alerts) to perform automated static analysis and vulnerability detection across…

    34k GitHub stars~2.3k tokensUpdated 1 mo ago
    SecurityAuto-check passed

  • Pipeline Security Gates

    revfactory/harness-100

    CI/CD pipeline security gate design guide. An agent skill from revfactory/harness-100.

    1.3k GitHub stars~1.5k tokensUpdated 6 mo ago
    SecurityAuto-check passed

  • Triaging Security Findings

    bitwarden/ai-plugins

    Official

    This skill should be used when the user asks to "triage security findings", "fix an Aikido finding", "review Aikido issues", "dismiss a false positive", "check SAST/IaC alerts", or needs to work…

    154 GitHub stars~2.2k tokensUpdated today
    SecurityAuto-check passed

More from yvanvds/yse-soundengine

  • C API Extend

    yvanvds/yse-soundengine

    A skill your agent uses when extending the C API at YseEngine/capi/ — wrapping a new engine class, method, enum, or callback — or when auditing the C API for drift from the engine's public surface.

    238 GitHub stars~4.4k tokensUpdated 8 days ago
    Auto-check passed

  • Cleanup

    yvanvds/yse-soundengine

    Use after an issue's PR has been merged to wrap up the issue branch — close the issue, switch back to dev, fast-forward, and delete the local and remote feature branches.

    238 GitHub stars~2k tokensUpdated 8 days ago
    Auto-check passed

  • Release

    yvanvds/yse-soundengine

    A skill your agent uses when the user asks to cut a new release of libYSE — phrases like "release a new version", "cut a patch/minor/major release", "publish a new release", "ship X.Y.Z".

    238 GitHub stars~3.8k tokensUpdated 8 days ago
    Auto-check passed

Works with

Categories

Questions about Fix Issues

What does Fix Issues do?

A skill your agent uses when fixing compiler warnings, static analyzer findings (clang-tidy, etc.), or runtime errors/crashes in the libYSE codebase. Fix Issues is an agent skill from yvanvds/yse-soundengine.), or runtime errors/crashes in the libYSE codebase.

When should I use Fix Issues?

Fix Issues fits situations like: fixing compiler warnings; static analyzer findings (clang-tidy; runtime errors/crashes in the libYSE codebase.

How do I install Fix Issues in Claude Code?

Run `npx skills add yvanvds/yse-soundengine --skill fix-issues -a claude-code`. Or copy the skill folder (.claude/skills/fix-issues in yvanvds/yse-soundengine) into .claude/skills/fix-issues in your project. Claude Code loads it when a task matches its description.

How do I install Fix Issues in Codex?

Run `npx skills add yvanvds/yse-soundengine --skill fix-issues -a codex`. Or copy the skill folder (.claude/skills/fix-issues in yvanvds/yse-soundengine) into .agents/skills/fix-issues in your project. Codex loads it when a task matches its description.

Can I use Fix Issues in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add yvanvds/yse-soundengine --skill fix-issues -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/fix-issues, .gemini/skills/fix-issues, .github/skills/fix-issues and .opencode/skills/fix-issues in your project.

What does Fix Issues need to run?

Going by SKILL.md and its folder, Fix Issues needs the command-line tools its instructions call (python and gh). Our summary lists: Python 3.

Does Fix Issues access the network?

SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Fix Issues safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Fix Issues use?

Fix Issues is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Fix Issues use?

About 3k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Fix Issues?

Skills that share tags, products or a category with Fix Issues: Triage Codeql (netdata/netdata, 81k stars), Agentic GitHub Actions Auditor (trailofbits/skills, 7.4k stars), Openclaw CI Limits (openclaw/openclaw, 392k stars) and Implementing GitHub Advanced Security For Code Scanning (mukul975/Anthropic-Cybersecurity-Skills, 34k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Fix Issues?

yvanvds (a GitHub user) maintains it in yvanvds/yse-soundengine, which has 238 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on September 29, 2026.

Source: yvanvds/yse-soundengine on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.