Enforces mandatory DAR (Decision Analysis & Resolution) and RSKM (Risk Management) for architectural decisions without documentation or risk mitigation, based on CMMI SDLC levels.
npx claudepluginhub tachyon-beep/skillpacks --plugin axiom-sdlc-engineeringThis skill uses the workspace's default tool permissions.
This skill implements the **Decision Analysis & Resolution (DAR)** and **Risk Management (RSKM)** process areas from the CMMI-based SDLC prescription.
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 implements the Decision Analysis & Resolution (DAR) and Risk Management (RSKM) process areas from the CMMI-based SDLC prescription.
Core principle: Proactive governance prevents costly reactive firefighting. Documentation and risk management are investments that pay 3-10x returns by avoiding crisis mode.
Critical distinction:
Reference: See docs/sdlc-prescription-cmmi-levels-2-4.md Sections 3.4.1 (DAR) and 3.4.2 (RSKM) for complete policy.
Use this skill when:
Do NOT use for:
| Situation | Framework | Mandatory At | Key Action |
|---|---|---|---|
| "Obvious" architectural decision | DAR with ADR | Level 3+ | Document alternatives even if choice is clear |
| High-risk decision (vendor, framework) | DAR with decision matrix | Level 2+ for high-risk | Evaluate alternatives before committing |
| Authority wants specific option | DAR with independent analysis | Level 3+ | Analyze alternatives BEFORE authority input |
| External dependency (API, vendor) | RSKM with mitigation | Level 2+ | Risk register + mitigation plan mandatory |
| "Low-risk" project | RSKM with risk identification | Level 2+ | Optimism bias - identify risks proactively |
| Mid-project (risk monitoring) | RSKM review cadence | Level 3+ | Scheduled reviews, not set-and-forget |
Level 2 Baseline (All Projects):
Level 3 Organizational Standard:
Level 4 Quantitative:
Level 1 or Low-Risk Projects:
CRITICAL: "Low-risk" is often optimism bias. Verify with risk assessment before declaring optional.
Detection: "Everyone agrees", "clear choice", "no brainer"
Why it's tempting: Saves time, reduces documentation burden, team aligned
Why it fails: Today's "obvious" is tomorrow's mysterious. Future maintainers lack context, assumptions not validated, alternatives not considered
Counter:
Red flags: "We all know", "Obviously", "No need to write it down"
Detection: "Simple project", "Internal only", "We've done this before", "What could go wrong?"
Why it's tempting: Small scope, experienced team, reduces overhead
Why it fails: Scope creep, resource constraints, and timeline slips hit "simple" projects just as often. Optimism bias blinds to risks.
Counter:
Red flags: "What could go wrong?", "It's just...", "Low-risk"
Detection: "CTO met with vendor", "Tech lead suggested", "Management wants"
Why it's tempting: Reduces conflict, speeds decision, aligns with leadership
Why it fails: Authority bias prevents genuine alternatives analysis. Senior stakeholders have blind spots, vendor relationships create bias, title ≠ technical correctness
Counter:
Red flags: "CTO wants", "We should align with leadership", "Don't want to contradict"
Detection: "We've had 2 sales calls", "Demo account set up", "Already started integration"
Why it's tempting: Feels wasteful to "go backwards", momentum toward choice
Why it fails: Sunk cost fallacy - past investment doesn't validate future commitment. Small sunk cost vs large future cost (vendor lock-in, wrong tool).
Counter:
Red flags: "We've already", "Going backwards", "Wasted effort"
Detection: "Established company", "Good reputation", "SLA guarantees uptime"
Why it's tempting: Vendor reputation, SLA promises reduce perceived risk
Why it fails: SLAs are probabilistic, not guarantees. 99.9% = 43 minutes downtime per month. All vendors have outages. Trust ≠ technical mitigation.
Counter:
Red flags: "We can trust them", "SLA is good enough", "Reputable company"
Detection: "Handle issues as they come up", "React when needed", "Cross that bridge"
Why it's tempting: Defers work, avoids speculation, focuses on current tasks
Why it fails: Reactive firefighting costs 3-10x proactive mitigation. Incidents occur when you have least capacity to respond (deadlines, weekends, vacations).
Counter:
Red flags: "We'll handle it", "If it happens", "Cross that bridge when we come to it"
Detection: "4 months in, no issues", "Original risks didn't hit", "We're good"
Why it's tempting: Past success validates approach, monitoring feels wasteful
Why it fails: Risks evolve throughout project lifecycle. Absence of risks to-date ≠ absence of future risks. Complacency before late-stage crunch (integration, final testing, deployment).
Counter:
Red flags: "No problems yet", "We're on track", "Monitoring feels like overhead"
Detection: "Overhead", "Red tape", "Meetings for meetings' sake", "We want to code"
Why it's tempting: Team wants to deliver, documentation feels unproductive
Why it fails: Lightweight process prevents heavyweight problems. 30 min planning saves hours of firefighting. Process ≠ bureaucracy.
Counter:
Red flags: "Bureaucracy", "Overhead", "Red tape", "Slows us down"
Detection: "Just finished major release", "Deadline is tight", "Team exhausted"
Why it's tempting: Exhaustion and deadlines are real, shortcuts feel necessary
Why it fails: Shortcuts under pressure create more pressure later. Technical debt compounds into crisis. Skipping governance creates future exhaustion.
Counter:
Red flags: "We're exhausted", "Too busy", "Under pressure", "Just this once"
Detection: "After we ship", "When we have time", "In the next sprint"
Why it's tempting: Defers effort, focuses on delivery now
Why it fails: "Later" never comes. Context is lost immediately. Future maintainers suffer.
Counter:
Red flags: "Later", "After we ship", "When we have time", "Eventually"
Common exception requests:
Why it's tempting: Context appears legitimately exceptional, constraints feel unique, team confidence is high
Why it fails: Every team thinks they're special. Startups fail from poor decisions as often as slow delivery. "MVP" and "prototype" often become production. "After product-market fit" never arrives.
Response framework:
Acknowledge the constraint: "Startup time pressure IS real, I understand the urgency"
Reframe governance as enabler: "Governance prevents the costly mistakes that kill startups - bad vendor choices, unmitigated risks, undocumented decisions that create chaos during scaling"
Offer Level 2 as minimum: "Not suggesting heavyweight process. Level 2 = 30-min risk session, ADRs for high-risk decisions only. That's ~2% overhead, not 20%."
Make exception criteria explicit:
Show the math: "30 minutes planning vs 10+ hours crisis firefighting. Which timeline can your startup afford?"
Red flags indicating exception is rationalization, not legitimate:
Non-negotiable boundaries:
3 month timeline: Minimum Level 2
5 developers: Minimum Level 3
Example response:
User: "We're a startup MVP, can we skip the ADRs?"
Agent: "I understand the pressure to move fast. Let's find the right balance:
Your MVP is customer-facing with payment processing → Level 2 minimum, not negotiable.
Level 2 = lightweight, not heavyweight:
- ADRs for high-risk decisions only (database, payment gateway, auth provider)
- 30-min risk session (identify risks, plan mitigation for top 3)
- Total overhead: ~2% of project time
This prevents the mistakes that kill MVPs:
- Wrong payment provider → costly migration mid-growth
- No auth security planning → breach before Series A
- Undocumented decisions → chaos when scaling team
ROI: 2 hours planning saves 20+ hours crisis firefighting.
Can we start with risk identification? 30 minutes now."
The following reference sheets provide detailed methodologies for specific governance domains. Load them on-demand when needed.
When to use: Making architectural decisions, evaluating alternatives, documenting choices
→ See dar-methodology.md
Covers:
When to use: Identifying risks, assessing probability/impact, planning mitigation, monitoring risks
→ See rskm-methodology.md
Covers:
When to use: Need concrete templates for ADRs or risk registers
→ See templates.md
Covers:
When to use: Understanding appropriate governance rigor for project tier
→ See level-scaling.md
Covers:
| Mistake | Why It Fails | Better Approach |
|---|---|---|
| "Obvious" decisions undocumented | Context loss in 6 months, assumptions not validated | Level 3: Document all architectural decisions, even "obvious" ones |
| Alternatives analysis after commitment | Analysis becomes validation theater | Evaluate alternatives BEFORE authority/consensus input |
| Risk acceptance without mitigation | Reactive firefighting costs 3-10x | Mitigation plan required for high-probability or high-impact risks |
| Set-and-forget risk planning | Risks evolve, complacency before late-stage crunch | Scheduled reviews based on project length |
| Deferring to authority without analysis | Authority bias, vendor relationships create blind spots | Independent analysis first, authority input second |
| Sunk cost justifies decision | Small sunk cost vs large future cost | Name the fallacy, calculate future cost |
| "We'll document later" | "Later" never comes (5% success rate) | Documentation = part of "done" |
| When You're Doing | Also Use | For |
|---|---|---|
| Creating ADRs | design-and-build | Technical decision criteria |
| Risk identification for security | ordis-security-architect | Security-specific risk techniques |
| Decision analysis with data | quantitative-management | Quantitative decision criteria |
| Requirements with risks | requirements-lifecycle | Risk-driven requirements prioritization |
Without this skill: Teams experience:
With this skill: Teams achieve:
Remember: Proactive governance prevents costly reactive firefighting. Documentation and risk management are investments with 3-10x returns.