Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
Enforces Architecture Decision Records (ADRs) for architecture decisions, CI/CD setup, technical debt management, and branching strategies per CMMI maturity levels.
npx claudepluginhub tachyon-beep/skillpacks --plugin axiom-sdlc-engineeringHow this skill is triggered — by the user, by Claude, or both
Slash command
/axiom-sdlc-engineering:design-and-buildThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill implements the **Technical Solution (TS)**, **Product Integration (PI)**, and **Configuration Management (CM)** process areas from the CMMI-based SDLC prescription.
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.
Orchestrates the full SDLC pipeline from CTO feature requests. Maps tasks to specialist agents (security, DB migration, compliance, performance) based on file patterns and topics.
Advises on architectural decisions by asking questions, surfacing trade-offs, and presenting options without executing. Use when designing features, choosing approaches, or refactoring.
Share bugs, ideas, or general feedback.
This skill implements the Technical Solution (TS), Product Integration (PI), and Configuration Management (CM) process areas from the CMMI-based SDLC prescription.
Core principle: Architecture decisions require documentation (ADRs). Emergency shortcuts require retrospective documentation. "Best practice" is never justification - requirements are.
Reference: See docs/sdlc-prescription-cmmi-levels-2-4.md Section 3.2 for complete policy and practice definitions.
Use this skill when:
Do NOT use for:
| Situation | Primary Reference Sheet | Key Decision |
|---|---|---|
| "Should we use microservices?" | Architecture & Design | Requires ADR. Use decision framework: team size, domain complexity, ops maturity. |
| "Git workflow is chaos" | Configuration Management | Diagnose root cause first. GitFlow (L3 releases) vs GitHub Flow (continuous) vs Trunk (high maturity). Requires ADR. |
| "70% of time on bugs" | Technical Debt Management | CODE RED. Feature freeze, architectural audit, classify debt (architectural/tactical/unpayable). |
| "Setting up CI/CD" | Build & Integration | Requirements gathering first. Platform choice requires ADR. Start simple, add stages incrementally. |
| "Quick fix vs proper solution" | Level 2→3→4 Scaling | Level 3 requires retrospective ADR within 48 hours. Document as HOTFIX with paydown commitment. |
CRITICAL: This skill enforces governance based on project maturity level.
Check for project level in:
CLAUDE.md: CMMI Target Level: 3| Level | ADR Required For | Exception Protocol |
|---|---|---|
| Level 2 | Major architecture decisions (platform choice, deployment strategy) | Informal discussion OK, document decision in wiki/README |
| Level 3 | ALL architectural decisions (tech stack, branching strategy, design patterns, CI/CD platform) | Emergency HOTFIX: Retrospective ADR within 48 hours mandatory |
| Level 4 | Everything in L3 + quantitative justification with metrics | No exceptions - statistical baselines required |
When: Production emergency, immediate fix needed, no time for full ADR process
Level 3 Requirements:
Violation: Skipping retrospective ADR = governance failure. See Enforcement section below.
HOTFIX Frequency Limit: >5 HOTFIXes per month = systemic problem requiring architectural audit, not process exception.
Architectural decisions (ADR required):
Implementation details (no ADR required, track in code/PR):
Borderline decisions (when in doubt, write ADR):
Level 3 Requirements:
For detailed enforcement mechanisms, escalation paths, and compliance metrics, see level-scaling.md.
Detection: User says "I've heard X is best practice" or "Everyone uses Y"
Red Flags:
Counter:
Forcing function: Require ADR with alternatives analysis. If they can't justify with measurable requirements, ADR review will reject it.
Detection: Over-engineered solution for simple problem
Red Flags:
Counter: "What's the SIMPLEST solution that meets requirements? Start there. Add complexity when demonstrated need exists, not hypothetically."
Detection: No reviews, no standards, "works on my machine"
Red Flags:
Counter: Enforce basic CM practices. Level 2 minimum: branch protection, required PR reviews, CI runs on PRs.
Detection: Increasing % of time on bugs, velocity declining
Red Flags:
50% time on bugs = WARNING
60% time on bugs = CODE RED
Counter: See Technical Debt Management reference sheet. CODE RED triggers feature freeze.
Load these on-demand for detailed guidance:
| Reference Sheet | When to Use | Link |
|---|---|---|
| Architecture & Design | Making technology choices, selecting patterns, designing system structure | architecture-and-design.md |
| Implementation Standards | Establishing coding standards, code review process, documentation requirements | implementation-standards.md |
| Configuration Management | Git chaos, branching strategy decisions, release management | configuration-management.md |
| Build & Integration | Setting up CI/CD, build optimization, deployment pipelines | build-and-integration.md |
| Technical Debt Management | Team spending >40% time on bugs, debt accumulating, velocity declining | technical-debt-management.md |
| Level 2→3→4 Scaling | Understanding what rigor is appropriate for your project tier | level-scaling.md |
| Mistake | Why It Fails | Better Approach |
|---|---|---|
| "Emergency exempts process" | Creates pattern where "urgent" = skip governance, accumulating undocumented debt | Use HOTFIX pattern: retrospective ADR within 48 hours, mandatory |
| "I'll document it later" | Later never comes, loses audit trail | Document NOW (ADR takes 15 min) or schedule retrospective (48 hours max) |
| "This is too simple for ADR" | Simple decisions have big impact, lose rationale for future | If it's truly simple, ADR takes 10 min. If it takes longer, it wasn't simple. |
| "Everyone uses X, so we should" | Resume-driven design, not requirements-driven | Require measurable justification. "Everyone" is not a requirement. |
| "20% debt allocation" when 70% bugs | Treats crisis as normal problem, ensures slow death | >60% bugs = CODE RED. Feature freeze, not incremental paydown. |
| "Pick branching strategy" without diagnosis | Treats symptom (conflicts) not cause (architecture? communication?) | Root cause analysis FIRST. Git strategy is symptom, not disease. |
| Generic CI/CD template without context | Wastes time on wrong solution | Requirements gathering FIRST: build characteristics, deployment context, risk profile |
| When You're Doing | Also Use | For |
|---|---|---|
| Designing Python architecture | axiom-python-engineering | Python-specific patterns and idioms |
| Designing web API | axiom-web-backend | REST/GraphQL best practices |
| Making architecture decision | governance-and-risk | Formal DAR process for critical choices |
| Setting up testing | quality-assurance | Test strategy and coverage |
| Choosing platforms | platform-integration | GitHub vs Azure DevOps specifics |
Without this skill: Teams experience:
With this skill: Teams achieve:
Remember: "Best practice" is never justification. Requirements are. If you can't articulate the requirement, you can't justify the architecture.