Using Sdlc Engineering

SDLC Engineering Router

Overview

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.

When to Use

Use this skill when requests involve:

• Requirements management (tracking, traceability, change control)
• Design and architecture (ADRs, design reviews, coding standards)
• Quality assurance (testing, code reviews, verification, validation)
• Governance and risk (decision documentation, risk management)
• Metrics and measurement (what to measure, how to analyze)
• Process adoption (implementing CMMI on existing projects)
• Platform integration (GitHub, Azure DevOps implementation patterns)
• General SDLC questions (where to start, what process to follow)

When NOT to use: Implementation details for specific technologies (Python testing → axiom-python-engineering, security → ordis-security-architect).

CMMI Level Detection

Priority order (check in this sequence):

1. CLAUDE.md configuration: Look for CMMI Target Level: X or CMMI Level: X
2. User message: Explicit mention ("Level 2", "Level 3", "Level 4", "CMMI L3")
3. Context clues:
   • "FDA", "medical device", "royal commission" → Level 3-4 (regulatory rigor)
   • "startup", "small team", "2-3 developers" → Level 2 (lightweight)
   • "audit", "compliance", "SOC 2" → Level 3 (organizational standards)
4. Default: Level 3 (good balance of rigor and agility)

Level Summary:

• Level 2 (Managed): Minimal viable practices, ~5% overhead, 1-5 person teams
• Level 3 (Defined): Organizational standards, ~10-15% overhead, 5+ person teams, audit-ready
• Level 4 (Quantitatively Managed): Statistical process control, ~20-25% overhead, regulated industries (FDA, medical devices)

Routing Decision Tree

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

Routing Table

Cross-Skillpack Coordination

Separation of Concerns: axiom-sdlc-engineering defines WHAT to do (process), other skillpacks define HOW (implementation).

Key Rule: If the request is about process/policy → SDLC skill. If it's about tool/technology implementation → domain-specific skillpack.

Handling Ambiguous Requests

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."

Countering Rationalizations

Red Flags - Stop and Reconsider

Symptoms of wrong routing:

• User asks about implementation (pytest setup, GitHub Actions YAML) → Wrong, should route to implementation skillpack
• User asks about domain-specific practices (ML experiment tracking, UX wireframes) → Wrong, should route to domain skillpack
• User asks how to write code → Wrong, SDLC is about process, not coding
• User needs technology tutorial → Wrong, SDLC assumes technical competence

Correct routing examples:

• "What testing strategy should I use?" → quality-assurance (process question)
• "How do I write pytest fixtures?" → axiom-python-engineering (implementation)
• "What metrics should we track?" → quantitative-management (process question)
• "How do I query GitHub API?" → platform-integration (implementation detail)

Multi-Skill Roadmaps

For comprehensive requests, provide sequenced guidance:

Example: "Starting new Level 3 project"

1. First: lifecycle-adoption → Assess current state, plan rollout
2. Then: platform-integration → Choose and configure GitHub/Azure DevOps
3. Then: requirements-lifecycle → Set up requirements tracking
4. Then: design-and-build → Establish branching, ADR process, coding standards
5. Then: quality-assurance → Define test strategy, code review policy
6. Then: governance-and-risk → Set up risk register, decision documentation
7. Then: quantitative-management → Define metrics, establish baselines

Example: "Adopting on existing 6-month-old project"

1. First: lifecycle-adoption → Parallel tracks strategy (new work = new process)
2. Then: design-and-build → Git branching cleanup, start ADRs for new decisions
3. Then: requirements-lifecycle → Capture current requirements, traceability for new work
4. Then: quality-assurance → Add tests for new code, code review for new PRs
5. Later: quantitative-management → Metrics after 2-3 months of data

Routing Workflow

1. Detect CMMI Level: Check CLAUDE.md → user message → default to Level 3
2. Analyze Request Intent: Match against routing table for keywords/symptoms
3. Check Routing Table: Find the skill(s) that best match the user's needs
4. Determine Single Skill OR Multi-Skill Sequence: Single concern vs. multi-skill roadmap
5. Announce Routing Decision: "I'm routing you to [skill-name] for [reason]. CMMI Level detected: [X]"
6. Invoke Appropriate Skill: Use Skill tool to load the skill
7. Follow Loaded Skill Exactly: Defer to the specialist skill's guidance

Quick Reference

Default Routing (when in doubt):

• Process adoption questions → lifecycle-adoption
• Requirements questions → requirements-lifecycle
• Design/architecture questions → design-and-build
• Testing/quality questions → quality-assurance
• Decision/risk questions → governance-and-risk
• Metrics questions → quantitative-management
• Tool setup questions → platform-integration

Default 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.)

Success Criteria

Router is effective when:

• CMMI level detected correctly from all sources
• Requests routed to correct skill 95%+ of time
• Ambiguous requests result in clarifying questions, not guesses
• Cross-skillpack boundaries respected (process vs. implementation)
• Multi-skill roadmaps provided when needed
• Rationalizations countered with evidence-based responses
• Users understand WHY they were routed to specific skill

Common Mistakes to Avoid

❌ 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