- Home
- /
- Categories
- /
- Debugging
Debugging
Find and fix bugs, error analysis
orchestration
by williamzujkowski
Orchestration standards for orchestration in Data Engineering environments.
story-consistency-monitor
by wordflowlab
"Use during chapter writing to automatically check character behavior, world rules, and timeline consistency - alerts when detecting potential contradictions before they become major issues"
l4
by smucclaw
Write legal and regulatory rules as executable, type-checked code in L4, a functional programming language for computational law. Use when formalizing contracts, legislation, regulations, policies, or compliance logic into computable form. Triggered when users need to encode legal rules, validate formalized law, generate web apps from legal logic, or translate natural language legal text into formal specifications. The skill covers L4 syntax, type system, pattern matching, validation with jl4-cli, and the complete workflow from analysis to deployment.
typescript-coder
by DmitriyYukhanov
Implements TypeScript/JavaScript code following established architecture and coding guidelines. Use when implementing features designed by typescript-architect.
Linter Autofix Patterns
by Ven0m0
Cross-language linter autofix commands and common fix patterns for biome, ruff, clippy, shellcheck, and more.
python-coder
by DmitriyYukhanov
Implements Python code following PEP 8, type hints, and project conventions. Use when implementing features designed by python-architect.
unity-coder
by DmitriyYukhanov
Use when implementing Unity C# code to follow proper coding guidelines, naming conventions, member ordering, and Unity-specific patterns
SwiftUI Engineer
by TrevorS
Build, review, debug, and modernize SwiftUI apps for macOS with modern patterns. Use when building SwiftUI UIs, reviewing code quality, debugging view issues, checking anti-patterns, migrating from AppKit, or designing app architecture.
fact-checking
by axiomantic
"Verify technical claims in code, docs, and comments via evidence-backed verdicts before merge."
debugging
by axiomantic
"Use when debugging bugs, test failures, or unexpected behavior. Triggers: 'why isn't this working', 'this doesn't work', 'X is broken', 'something's wrong', 'getting an error', 'exception in', 'stopped working', 'regression', 'crash', 'hang', 'flaky test', 'intermittent failure', or when user pastes a stack trace/error output. NOT for: test quality issues (use fixing-tests), adding new behavior (use implementing-features)."
async-await-patterns
by axiomantic
"Use when writing JavaScript or TypeScript code with asynchronous operations, fixing promise-related bugs, or converting callback/promise patterns to async/await. Triggers: 'promise chain', 'unhandled rejection', 'race condition in JS', 'callback hell', 'Promise.all', 'sequential vs parallel async', 'missing await'. Enforces async/await discipline over raw promises."
requesting-code-review
by axiomantic
"Use when implementation is done and you need a structured pre-PR review workflow. Triggers: 'ready for review', 'review my changes before PR', 'pre-merge check', 'is this ready', 'submit for review'. Orchestrates multi-phase review (planning, context assembly, dispatch, triage, fix, gate). Dispatches code-review internally. NOT the same as finishing-a-development-branch (which handles merge/PR decisions after review passes)."
brainstorming
by axiomantic
"Use when exploring design approaches, generating ideas, or making architectural decisions. Triggers: 'explore options', 'what are the tradeoffs', 'how should I approach', 'let's think through', 'sketch out an approach', 'I need ideas for', 'how would you structure', 'what are my options'. Also used in SYNTHESIS mode when implementing-features provides discovery context for autonomous design."
fixing-tests
by axiomantic
"Use when tests themselves are broken, test quality is poor, or user wants to fix/improve tests. Triggers: 'test is broken', 'test is wrong', 'test is flaky', 'make tests pass', 'tests need updating', 'green mirage', 'tests pass but shouldn't', 'audit report findings', 'run and fix tests'. Three modes: fix specific tests, process green-mirage audit findings, and run-then-fix. NOT for: bugs in production code caught by correct tests (use debugging)."
designing-workflows
by axiomantic
"Use when designing systems with explicit states, transitions, or multi-step flows. Triggers: \"design a workflow\", \"state machine\", \"approval flow\", \"pipeline stages\", \"what states does X have\", \"how does X transition\", or when implementing-features Phase 2.1 detects workflow patterns."
merging-worktrees
by axiomantic
"Use when merging parallel worktrees back together after parallel implementation, combining parallel development tracks, or unifying branches from dispatched parallel agents. Triggers: 'merge worktrees', 'combine parallel branches', 'integrate parallel work', 'all tracks complete', 'bring everything together'."
test-driven-development
by axiomantic
"Use when user explicitly requests test-driven development, says 'TDD', 'write tests first', 'red green refactor', 'test-first', or 'start with the test'. Also invoked as a sub-skill by implementing-features and executing-plans for each implementation task. NOT a replacement for implementing-features for full feature work."
enforcing-code-quality
by axiomantic
Use when writing or modifying code. Enforces production-quality standards, prohibits common shortcuts, and ensures pre-existing issues are addressed. Invoked automatically by implementing-features and test-driven-development.
auditing-green-mirage
by axiomantic
"Use when auditing whether tests genuinely catch failures, or when user expresses doubt about test quality. Triggers: 'are these tests real', 'do tests catch bugs', 'tests pass but I don't trust them', 'test quality audit', 'green mirage', 'shallow tests', 'tests always pass suspiciously', 'would this test fail if code was broken'. Forensic analysis of assertions, mock usage, and code path coverage."
isolated-testing
by axiomantic
Use when testing theories during debugging, or when chaos is detected. Triggers: "let me try", "maybe if I", "what about", "quick test", "see if", rapid context switching, multiple changes without isolation. Enforces one-theory-one-test discipline. Invoked automatically by debugging, scientific-debugging, systematic-debugging before any experiment execution.
fractal-thinking
by axiomantic
Adaptive recursive thought engine for deep exploration. Invoked by other skills (brainstorming, fact-checking, debugging, deep-research) when they need to deeply explore uncertainty, systematically decompose complex questions, or gain certainty about multi-faceted problems. Triggers: "think deeply about", "explore this recursively", "I need certainty about", "decompose this question", "what am I missing". Also invoked programmatically with a seed, intensity, and checkpoint mode. NOT for: simple questions with known answers, linear task execution, or file-by-file code review.
python-jax
by jkitchin
Expert guidance for JAX (Just After eXecution) - high-performance numerical computing with automatic differentiation, JIT compilation, vectorization, and GPU/TPU acceleration; includes transformations (grad, jit, vmap, pmap), sharp bits, gotchas, and differences from NumPy
test-driven-development
by brobertsaz
Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first
troubleshooting
by jkitchin
Systematic debugging and problem diagnosis using structured troubleshooting methodologies applicable to any domain - technical issues, process failures, system problems, or general obstacles. Use when users report errors, describe malfunctions, encounter unexpected behavior, or need help diagnosing root causes. Triggers include 'debug this,' 'troubleshoot,' 'why isn't this working,' 'getting an error,' 'something's wrong with,' 'how do I fix,' or any problem description.