Help us improve
Share bugs, ideas, or general feedback.
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-foundationsHow this skill is triggered — by the user, by Claude, or both
Slash command
/axiom-engineering-foundations:using-software-engineeringThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Universal methodology for professional software engineering practice. Language-agnostic foundations that apply regardless of tech stack.
Guides evidence-driven analysis for hard bugs, architecture decisions, root-cause investigation, and high-stakes implementation planning using repo fingerprints, hypothesis ladders, and evidence matrices.
Guides AI as a disciplined coding partner for features, bugs, systems, refactoring. Human provides vision/decisions; AI executes with transparency, understanding, craftsmanship.
Code review, debugging, and incident discipline. Confidence calibration, root-cause iron law, alert-on-changes rule, the pre-existing blame protocol.
Share bugs, ideas, or general feedback.
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.