Menü
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Use when you have a written implementation plan to execute
Spreadsheet toolkit. Reach for it whenever the artifact on either side of the conversation is a workbook file — .xlsx, .xlsm, .xltx, .csv, .tsv — and the user wants that artifact produced, changed, cleaned, or read. Typical triggers: 'build me a model', 'update this sheet', 'add a column', 'compute the totals as formulas', 'sanity-check this xlsx', 'export sheet 2 to CSV', 'render the workbook as PDF', 'the spreadsheet in ~/Downloads is a mess, fix it'. Applies equally to financial models, ops reports, data cleanups, and template fills. Skip it when the workbook is only source material and the real output is a Word doc, an HTML page, a Python script that runs standalone, a Google Sheets integration, or an ingestion pipeline into a database — in those cases the spreadsheet is a means, not the deliverable.
Perform a focused, evidence-based code review. Use when the user asks to review code, a diff, pull request, branch, commit, or implementation before merging.
Smart git commit message generator following Conventional Commits. Use when the user says 'commit', 'commit this', 'write a commit message', 'smart commit', or asks to create a git commit.
Use when the user asks what OpenZeroCode can do, how a feature works (memory, checkpoints, agents, subagents, tasks, compose, learn), how to configure it, where config/data lives, which config key controls a behavior, what CLI or slash commands exist, or how to enable/disable/tune something — the self-documenting reference for OpenZeroCode itself.
Use when executing implementation plans with independent tasks in the current session
Basierend auf der SOC-Berufsklassifikation
| name | compose:debug |
| description | Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes |
Systematic debugging: reproduce → isolate → root cause → fix → verify.
First, reproduce the issue reliably:
Narrow down the problem:
Find the actual cause:
Write the minimal fix:
After fixing:
| Symptom | Check |
|---|---|
| Test fails | Is the test correct? Is the implementation correct? |
| Build fails | Check error messages, types, imports |
| Runtime error | Check stack trace, variable values |
| Performance issue | Profile, check algorithms, check I/O |
After fixing a bug, consider:
