Routes SDLC requests to specialist skills by detecting CMMI maturity level. Covers requirements management, design documentation, quality assurance, governance, metrics, and process adoption on projects.
npx claudepluginhub tachyon-beep/skillpacks --plugin axiom-sdlc-engineeringThis skill uses the workspace's default tool permissions.
This skill routes SDLC-related requests to the appropriate specialist skill within the axiom-sdlc-engineering skillpack. It detects the project's CMMI maturity level and ensures users receive guidance tailored to their context.
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.
This skill routes SDLC-related requests to the appropriate specialist skill within the axiom-sdlc-engineering skillpack. It detects the project's CMMI maturity level and ensures users receive guidance tailored to their context.
Core Principle: Match the right process rigor to the project's needs. Not all projects need Level 3 or 4 formality.
Use this skill when requests involve:
When NOT to use: Implementation details for specific technologies (Python testing → axiom-python-engineering, security → ordis-security-architect).
Priority order (check in this sequence):
CMMI Target Level: X or CMMI Level: XLevel Summary:
User request received
│
├─ New project setup / comprehensive adoption?
│ └─ Route to: lifecycle-adoption
│ (Bootstrapping guidance, parallel tracks, incremental rollout)
│
├─ Requirements-related? (tracking, traceability, elicitation, changes)
│ └─ Route to: requirements-lifecycle
│ (RD + REQM practices at detected level)
│
├─ Design/architecture? (ADRs, design docs, code standards, branching)
│ └─ Route to: design-and-build
│ (TS + CM + PI practices at detected level)
│
├─ Quality/testing? (code review, testing strategy, peer review, UAT)
│ └─ Route to: quality-assurance
│ (VER + VAL practices at detected level)
│
├─ Decisions/risk? (ADRs, formal decisions, risk management)
│ └─ Route to: governance-and-risk
│ (DAR + RSKM practices at detected level)
│
├─ Metrics/measurement? ("what to measure", dashboards, SPC)
│ └─ Route to: quantitative-management
│ (MA + QPM + OPP practices at detected level)
│
├─ Platform-specific? (GitHub setup, Azure DevOps setup)
│ └─ Route to: platform-integration
│ (GitHub vs Azure DevOps implementation patterns)
│
└─ Ambiguous / multiple concerns?
└─ Ask clarifying question OR provide overview of relevant skills
| User Intent | Route To | Key Indicators |
|---|---|---|
| New project, comprehensive setup | lifecycle-adoption | "starting new", "from day one", "bootstrapping", "where to start" |
| Existing project adoption | lifecycle-adoption | "existing project", "retrofit", "adopt CMMI", "parallel tracks" |
| Requirements tracking | requirements-lifecycle | "requirements", "user stories", "traceability", "RTM", "change requests" |
| Architecture decisions | design-and-build | "design", "architecture", "ADR", "technical decision", "coding standards" |
| Version control setup | design-and-build | "Git", "branching", "GitFlow", "releases", "configuration management" |
| Testing strategy | quality-assurance | "testing", "test coverage", "code review", "peer review", "UAT", "validation" |
| Formal decisions | governance-and-risk | "ADR", "decision documentation", "alternatives analysis" |
| Risk management | governance-and-risk | "risk", "risk register", "mitigation", "probability×impact" |
| Metrics planning | quantitative-management | "metrics", "what to measure", "dashboards", "DORA", "KPIs" |
| Statistical analysis | quantitative-management | "Level 4", "SPC", "control charts", "Cp/Cpk", "process capability" |
| GitHub implementation | platform-integration | "GitHub", "GitHub Actions", "issue tracking" |
| Azure DevOps implementation | platform-integration | "Azure DevOps", "Azure Pipelines", "Azure Boards" |
| General quality improvement | quality-assurance (first), then others | "better quality", "fewer bugs", "improve" (ambiguous) |
Separation of Concerns: axiom-sdlc-engineering defines WHAT to do (process), other skillpacks define HOW (implementation).
| Scenario | SDLC Skill | Implementation Skill | Handoff |
|---|---|---|---|
| Python testing | quality-assurance (test strategy) | axiom-python-engineering (pytest implementation) | "Use axiom-python-engineering for writing pytest tests" |
| Python code quality | design-and-build (coding standards) | axiom-python-engineering (ruff, mypy, black) | "Use axiom-python-engineering for Python-specific tooling" |
| UX design reviews | quality-assurance (review process) | lyra-ux-designer (design critique) | "Use lyra-ux-designer for UX-specific review criteria" |
| Security testing | quality-assurance (test strategy) | ordis-security-architect (security testing) | "Use ordis-security-architect for security test cases" |
| Documentation writing | governance-and-risk (ADR process) | muna-technical-writer (technical writing) | "Use muna-technical-writer for documentation structure" |
| E2E testing | quality-assurance (test pyramid) | ordis-quality-engineering (E2E automation) | "Use ordis-quality-engineering for E2E test frameworks" |
Key Rule: If the request is about process/policy → SDLC skill. If it's about tool/technology implementation → domain-specific skillpack.
When multiple skills could apply:
Option 1: Ask Clarifying Question
"I can help with quality improvement in several ways:
1. Testing strategy and code reviews (quality-assurance skill)
2. Design practices and architecture (design-and-build skill)
3. Metrics to track quality (quantitative-management skill)
Which aspect of quality are you most concerned about?"
Option 2: Provide Overview
"Quality improvement involves multiple CMMI process areas:
- Requirements quality (requirements-lifecycle): Clear, testable requirements
- Design quality (design-and-build): Architecture reviews, coding standards
- Test quality (quality-assurance): Test coverage, peer reviews, UAT
I recommend starting with quality-assurance skill for immediate impact on defect rates."
| Objection | Counter-Response | Route To |
|---|---|---|
| "We're too small for CMMI" | "Level 2 works for 1-2 person teams. It's ~5% overhead: basic Git branching, lightweight code review, simple issue tracking." | lifecycle-adoption |
| "Process slows us down" | "Process prevents rework. Level 2 saves time: no re-litigating decisions, no integration hell, no forgotten requirements." | lifecycle-adoption |
| "We need to ship fast" | "Level 2 speeds delivery: clear requirements (no misunderstandings), CI/CD (no manual deploys), peer review (catch bugs early)." | lifecycle-adoption |
| "CMMI is waterfall" | "CMMI is methodology-agnostic. GitHub Flow + CI/CD + user stories = Level 3 compliance. Agile and CMMI coexist." | lifecycle-adoption |
| "Too much documentation" | "Level 2 minimizes docs: ADRs in markdown (15 min), requirements in GitHub Issues, traceability via commit messages." | design-and-build |
| "We don't have time to measure" | "Level 3 automates metrics via GitHub API. 1-hour setup, then free data forever. No manual spreadsheets." | quantitative-management |
Symptoms of wrong routing:
Correct routing examples:
quality-assurance (process question)axiom-python-engineering (implementation)quantitative-management (process question)platform-integration (implementation detail)For comprehensive requests, provide sequenced guidance:
Example: "Starting new Level 3 project"
lifecycle-adoption → Assess current state, plan rolloutplatform-integration → Choose and configure GitHub/Azure DevOpsrequirements-lifecycle → Set up requirements trackingdesign-and-build → Establish branching, ADR process, coding standardsquality-assurance → Define test strategy, code review policygovernance-and-risk → Set up risk register, decision documentationquantitative-management → Define metrics, establish baselinesExample: "Adopting on existing 6-month-old project"
lifecycle-adoption → Parallel tracks strategy (new work = new process)design-and-build → Git branching cleanup, start ADRs for new decisionsrequirements-lifecycle → Capture current requirements, traceability for new workquality-assurance → Add tests for new code, code review for new PRsquantitative-management → Metrics after 2-3 months of dataDefault Routing (when in doubt):
lifecycle-adoptionrequirements-lifecycledesign-and-buildquality-assurancegovernance-and-riskquantitative-managementplatform-integrationDefault Level: Level 3 (unless otherwise specified)
Cross-Skillpack Default: If request is about technology implementation (not process), route to appropriate domain skillpack (axiom-python-engineering, ordis-quality-engineering, etc.)
Router is effective when:
❌ Don't: Guess at CMMI level if not specified → Default to Level 3 ❌ Don't: Route technology questions here → Send to domain skillpacks ❌ Don't: Provide process guidance directly → Load appropriate skill ❌ Don't: Skip level detection → Always check CLAUDE.md first ❌ Don't: Overwhelm with all 7 skills → Route to most relevant one
✅ Do: Detect level systematically (CLAUDE.md → message → default) ✅ Do: Announce routing decision ("Routing to X skill because...") ✅ Do: Load the skill and follow it exactly ✅ Do: Provide multi-skill roadmap for complex requests ✅ Do: Counter "process = overhead" rationalizations with Level 2 examples