From axiom-engineering-foundations
Provides language-agnostic methodologies for complex engineering tasks: debugging stubborn bugs, safe refactoring, code review, production incidents, technical debt triage, and understanding unfamiliar codebases.
npx claudepluginhub tachyon-beep/skillpacks --plugin axiom-engineering-foundationsThis skill uses the workspace's default tool permissions.
Universal methodology for professional software engineering practice. Language-agnostic foundations that apply regardless of tech stack.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Universal methodology for professional software engineering practice. Language-agnostic foundations that apply regardless of tech stack.
Engineering excellence is methodology, not heroics. Systematic approaches beat clever improvisation. These skills encode battle-tested processes for situations where "just figure it out" leads to wasted time and missed root causes.
Load this skill when:
Don't use for: Language-specific issues (use language packs), algorithm design (use CS fundamentals), infrastructure/deployment (use DevOps packs).
IMPORTANT: All reference sheets are in the SAME DIRECTORY as this SKILL.md.
When this skill is loaded from:
skills/using-software-engineering/SKILL.md
Reference sheets like complex-debugging.md are at:
skills/using-software-engineering/complex-debugging.md
NOT at:
skills/complex-debugging.md (WRONG PATH)
Symptoms:
Route to: complex-debugging.md
Why: Systematic debugging methodology using scientific method. Adapted for Claude's strengths (fast codebase reading, pattern recognition) and limitations (no interactive debuggers).
Integration: For domain-specific bugs, use this methodology THEN hand off to specialists:
yzmir-pytorch-engineering (debug-oom, debug-nan)yzmir-deep-rl (rl-debugging)bravos-simulation-tactics (debugging-simulation-chaos)yzmir-ml-production (production-debugging-techniques)Symptoms:
Route to: systematic-refactoring.md
Why: Safe, incremental transformation methodology. Preserves behavior while improving structure.
Pairs with: technical-debt-triage.md to decide WHAT to refactor, this skill for HOW.
Symptoms:
Route to: code-review-methodology.md
Why: Systematic review process - what to look for, in what order, how to give actionable feedback.
Pairs with: codebase-confidence-building.md when reviewing unfamiliar code areas.
Symptoms:
Route to: incident-response.md
Why: Fire-fighting methodology - contain, diagnose, fix, learn. Keeps you calm under pressure.
Note: Use DURING incidents for process. Use complex-debugging.md for the debugging portion.
Symptoms:
Route to: technical-debt-triage.md
Why: Systematic identification, categorization, and prioritization. When to pay down vs. live with debt.
Pairs with:
Symptoms:
Route to: codebase-confidence-building.md
Why: Systematic exploration to internalize a system you'll maintain. Different from archaeology (analysis) - this is about building working mental models.
Pairs with:
Related but different: axiom-system-archaeologist is for architecture ANALYSIS. This skill is for INTERNALIZATION of systems you'll maintain long-term.
When situation unclear, ASK ONE clarifying question:
"Help me with this code" → Ask: "What's the goal? Debug a bug? Review quality? Refactor safely? Understand it?"
"This is a mess" → Ask: "Do you need to debug something broken, or clean up working-but-ugly code?"
"Fix this" → Ask: "Is it broken (debugging) or just ugly (refactoring)?"
Never guess. Ask once, route accurately.
| Symptom | Wrong | Correct | Why |
|---|---|---|---|
| "Code needs cleanup" | complex-debugging | systematic-refactoring | Not broken, needs transformation |
| "Bug in code I don't know" | complex-debugging only | confidence-building THEN debugging | Understand before debugging |
| "Production down" | complex-debugging | incident-response THEN debugging | Contain first |
| "Should we fix this debt?" | systematic-refactoring | technical-debt-triage | Decide WHAT before HOW |
| "Review this PR" | complex-debugging | code-review-methodology | Review ≠ debugging |
| Sheet | Purpose |
|---|---|
| complex-debugging.md | Scientific method for horrible bugs |
| systematic-refactoring.md | Safe incremental code transformation |
| code-review-methodology.md | How to review systematically |
| incident-response.md | Production fire methodology |
| technical-debt-triage.md | Identify, prioritize, decide |
| codebase-confidence-building.md | Internalize systems you maintain |
This plugin provides methodology. Other plugins provide domain expertise. Use together:
| This Plugin | Pairs With | For |
|---|---|---|
| complex-debugging | yzmir-pytorch-engineering | ML debugging (OOM, NaN) |
| complex-debugging | yzmir-deep-rl:rl-debugging | RL training issues |
| complex-debugging | ordis-quality-engineering | Flaky tests, observability |
| complex-debugging | yzmir-systems-thinking | Systemic/feedback loop bugs |
| incident-response | ordis-quality-engineering | Chaos engineering, load testing |
| technical-debt-triage | axiom-system-architect | Architecture-level debt |
| technical-debt-triage | ordis-quality-engineering | Quality metrics, static analysis |
| codebase-confidence-building | axiom-system-archaeologist | Formal architecture analysis |
Pattern: Use this plugin's methodology to structure your approach, then hand off to domain specialists for specific technical guidance.
All reference sheets are adapted for Claude's unique position:
Claude's Strengths (lean into these):
Claude's Limitations (work around these):
When to ask the user: Sooner rather than later, but ONLY if you can't get the information yourself. Check logs, code, git history, tests first.