tachyon-beep/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

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

Cross-Skillpack Coordination

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.

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

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

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