メニュー
Use when starting new projects with CMMI, adding CMMI to active development, preparing for audits, migrating tools, or facing team resistance to process adoption
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when working on a Python task and unsure which specialist to load - routes to type-system, mypy-resolution, project-tooling, delinting, testing, async, scientific-computing, ML-workflows, debugging-and-profiling, or Textual-TUI specialists based on symptoms
Use when starting any UX/UI design task — visual design, IA, interaction, accessibility (WCAG 2.2), user research across mobile, web, desktop, game, and AI surfaces, plus first-principles audience-derived needs analysis. Routes to 11 specialist sheets.
Use when a Claude is taking **standing ownership** of a software product across many sessions — discovery, strategy, specs, and value validation — deciding *what to build, why, for whom,* and *whether it worked*, with continuity, decision provenance, and an authority boundary that escalates irreversible or outward-facing actions to the human owner. Owns the product disciplines: opportunity assessment (JTBD, problem validation, business case), vision/strategy/positioning and intent-roadmapping, PRDs with falsifiable acceptance criteria, delivery orchestration and acceptance, product-value metrics and experimentation, and the product anti-pattern catalog. Orchestrates rather than reimplements: routes sequencing/flow/WSJF to `/axiom-program-management`, plans to `/axiom-planning`, solution/architecture to `/axiom-solution-architect`, research method to `/lyra-ux-designer`. Do **not** load to build one feature, choose an architecture, or manage delivery flow for already-decided work.
This skill should be used when the user asks to "track work", "create an issue", "find something to work on", "what should I work on next", "triage bugs", "close an issue", "check what's blocked", "plan a milestone", "review sprint progress", "coordinate agents", or when working in a project that uses filigree for issue tracking. Provides workflow patterns, team coordination protocols, and operational guidance for the filigree issue tracker.
Use when designing a system that spans more than one process, machine, or failure domain and a partition, crash, or duplicate must not silently corrupt state. Use when you see split-brain, lost writes under partition, duplicate processing, stuck or half-applied sagas, retry storms, dual writes drifting apart, or "works in staging, melts under load." Architecture-level — how to design correctness under partial failure, not how to deploy it. Single-service API internals → `axiom-web-backend`; CI/CD and ops → `axiom-devops-engineering`; replay/seed determinism → `axiom-determinism-and-replay`; broker/event-sourcing mechanics → the event-driven pack.
Use when designing a system whose past behaviour must be recoverable as a fact — RL training substrates, multi-agent simulations, deterministic game engines, replay-debuggable services, multiplayer lockstep, or any pipeline where "I cannot reproduce that bug" is unacceptable. Use when teams disagree about what "snapshot", "seed", or "replay" mean across modules. Use when cross-machine or cross-process determinism is required, or a regulator will ask "what was the input at tick T?". Architecture-level — how to design a deterministic system. For verifying an existing simulation against known patterns, use `/check-determinism` from yzmir-simulation-foundations instead.
| name | lifecycle-adoption |
| description | Use when starting new projects with CMMI, adding CMMI to active development, preparing for audits, migrating tools, or facing team resistance to process adoption |
This skill guides incremental CMMI adoption on existing projects without halting development. Whether you're starting a new project with CMMI from day one or retrofitting practices onto a 5-year-old codebase, this skill provides strategies for:
Use this skill when:
High-Level Guidance:
Reference Sheets (On-Demand):
The Core Principle: You don't need to stop development to adopt CMMI. Use parallel tracks:
┌─────────────────────────────────────────────────────────┐
│ NEW FEATURES (Follow New Process) │
│ - Requirements tracked in issues │
│ - ADRs for design decisions │
│ - PR reviews required │
│ - Test coverage enforced │
│ - Full CMMI compliance │
└─────────────────────────────────────────────────────────┘
│
│ Parallel Development
│
┌─────────────────────────────────────────────────────────┐
│ EXISTING CODE (Exempt from Retrofit) │
│ - Legacy code untouched unless modified │
│ - Bug fixes follow minimal process │
│ - Critical paths retrofitted selectively │
│ - No "rewrite everything" required │
└─────────────────────────────────────────────────────────┘
Timeline: 2-3 months to full adoption for typical team (5-10 developers)
Benefits:
Anti-Pattern: "Big Bang Adoption" - Trying to go from Level 1 to Level 3 overnight. Result: Development freeze, team revolt, incomplete implementation.
| Aspect | Big Bang (❌ Anti-Pattern) | Incremental (✅ Recommended) |
|---|---|---|
| Timeline | "We're Level 3 starting Monday!" | 2-3 month phased rollout |
| Development | Freeze while implementing | Parallel tracks, continuous shipping |
| Team reaction | Overwhelm, resistance | Gradual learning, buy-in |
| Risk | High (all-or-nothing) | Low (course corrections possible) |
| First milestone | Full compliance | Quick wins (branch protection, PR reviews) |
Why Big Bang Fails:
Incremental Approach:
Quick Wins (implement first - immediate value):
| Practice | Time to Implement | Value |
|---|---|---|
| Branch protection rules | 30 minutes | Prevents force pushes, lost work |
| PR review requirement | 1 hour | Catches bugs before merge |
| Issue templates | 2 hours | Structured requirement capture |
| CI/CD basic pipeline | 1 day | Automated testing, faster feedback |
| ADR template | 1 hour | Decision documentation starts |
Foundational Practices (implement second - enables maturity):
| Practice | Time to Implement | Enables |
|---|---|---|
| Requirements traceability | 1-2 weeks | Audit trail, impact analysis |
| Branching workflow (GitFlow/Trunk) | 1 week + training | Release management, parallel dev |
| Test coverage baseline | 2-3 weeks | Quality metrics, regression prevention |
| Metrics collection | 2-4 weeks | Baselines, trend analysis, process improvement |
| Risk register | 1 week | Proactive risk management |
Strategy: Lead with quick wins to demonstrate value, then invest in foundations while team is bought in.
2-3 Person Team (Minimal Viable CMMI):
4-10 Person Team (Sweet Spot):
11-30 Person Team (Organizational Standard):
30+ Person Team (Full CMMI):
Problem: Small teams lack independent oversight (no tech lead, no manager, no external review). Under deadline pressure, teams can exploit this to appear compliant while avoiding actual work.
Solution: See Enforcement Mechanisms #16-20 (Small Team Enforcement section) for detailed enforcement strategies including:
These mechanisms require external verification (advisor, consultant, or automation) since small teams cannot self-police.
Selective Retrofitting Principle: Not all legacy code needs full CMMI compliance.
DO retrofit:
DON'T retrofit:
Risk-Based Decision Matrix:
High Change Frequency │ RETROFIT │ RETROFIT │
│ (Full) │ (Selective) │
─────────────────────┼─────────────┼─────────────┤
Low Change Frequency │ RETROFIT │ EXEMPT │
│ (Critical) │ │
└─────────────┴─────────────┘
High Risk Low Risk
Example: 100 features shipped over 2 years
Time savings: Retrofitting 40 features instead of 100 = 60% effort reduction
CRITICAL: Exemption List Approval Gate
Enforcement: CTO or security officer MUST approve exemption list before Week 4. This prevents managers from classifying everything as "low risk" to avoid retrofit work.
Approval requirements:
Red flags requiring escalation to executive sponsor:
80% of features labeled "exempt" → Gaming detected
Accountability:
Example compliant exemption:
Feature: Legacy report generator (reports.py)
- Last changed: 18 months ago
- Risk: Low (read-only, no PII, no auth)
- Change frequency: Zero changes in 12+ months
- Status: EXEMPT (approved by CTO 2026-01-24)
Example non-compliant exemption:
Feature: User login endpoint (auth.py)
- Risk claimed: "Low"
- Reality: HIGH (authentication is always high risk)
- Status: CANNOT EXEMPT (handles auth → must retrofit)
Objection 1: "CMMI will slow us down"
Response:
Objection 2: "We're too small for CMMI"
Response:
Objection 3: "We're agile, CMMI is waterfall"
Response:
Objection 4: "It's too late to change mid-project"
Response:
Objection 5: "We don't have time for this"
Response:
If you or the user are thinking these thoughts, STOP and reconsider:
| Thought | Reality | What to Do Instead |
|---|---|---|
| "Let's do a big bang rollout" | 95% failure rate for big bang CMMI adoption | Use parallel tracks: new work follows new process, old code exempt |
| "We'll retrofit everything before starting new work" | Analysis paralysis, development freeze | Selective retrofit (30% critical features), parallel new development |
| "We're too small for CMMI" | 2-person teams can do Level 2 in 1 week | Show team size adaptation table (Level 2 = minimal viable) |
| "CMMI = waterfall, we're agile" | CMMI is methodology-agnostic | Map CMMI to sprint ceremonies (RD in planning, VER in review) |
| "Let's wait until the project is done" | Post-hoc compliance is 10x harder | Start now with parallel tracks, minimal disruption |
| "We need perfect compliance from day one" | Perfectionism kills adoption | Incremental: 30% → 50% → 70% compliance over 3 months |
| "Process first, then demonstrate value" | Team will revolt before seeing benefits | Quick wins first (branch protection Day 1), then deeper practices |
| "Everyone must follow the same process" | One-size-fits-all fails | Tailoring by team size, risk, and domain |
| "We'll add tests after the feature is done" | "Later" = never | Require tests for all new code NOW, retrofit selectively |
| "Management just needs to mandate it" | Top-down mandates create cargo cult compliance | Involve team in process design, demonstrate value, then enforce |
Common rationalizations that undermine adoption (and how to counter them):
| Rationalization | Pattern | Counter |
|---|---|---|
| "Just this once we'll skip [practice]" | Slippery slope | "Just this once" becomes "every time". Enforce consistently from Day 1. |
| "We're in a hurry, no time for [practice]" | Time pressure override | "Hurry is why we NEED process. Skipping reviews = 5x more debugging time later." |
| "This feature is too small for [practice]" | Scope minimization | "Small changes cause big bugs. All features follow process, no exceptions." |
| "The process is slowing us down" | Productivity panic | "Initial 10% slowdown, long-term 30% speedup. Measure before/after." |
| "We already do code review informally" | Informal = good enough | "Informal = inconsistent. 8 of last 10 PRs had no review (check GitHub)." |
| "Our team is experienced, we don't make mistakes" | Overconfidence | "Last month: 12 production bugs. Experience ≠ infallibility." |
| "We'll fix the process later" | Procrastination | "Process debt compounds like technical debt. Fix now or pay 10x later." |
| "The audit is months away" | Distant deadline | "Process takes 2-3 months to stabilize. Start now or fail audit." |
| "Let's use our own process, not CMMI" | Not invented here | "Your process likely duplicates CMMI. Map it, fill gaps, save time." |
| "We need to finish this sprint first" | Perpetual deferral | "Every sprint will have 'just one more thing'. Parallel tracks start TODAY." |
| "This is too bureaucratic" | Fear of overhead | "Level 2 = branch protection + PR template. That's not bureaucracy." |
| "Our old process worked fine" | Status quo bias | "13 bugs last quarter, 45% of time on rework. That's not 'fine'." |
How to use this table:
Purpose: Prevent common loophole exploits discovered through TDD adversarial testing. These 19 mechanisms close rationalizations teams use under pressure.
Organization:
Prevents: "Just this once" excuse for skipping process
Enforcement:
emergency-bypassRed flag: >2 emergencies/month
Prevents: Eternal quick-wins loop, permanent plateau
Enforcement:
Red flag: Still at quick wins in Month 3 → escalate
Prevents: Workshop theater (checkbox attendance without engagement)
Enforcement:
Red flag: <50% felt they could influence → repeat workshop
Prevents: Indefinite legacy exemption
Enforcement:
Red flag: Work started Week 7 claimed as "legacy"
Prevents: Junior dev pilot theater
Enforcement:
1 year tenure required
Red flag: Pilot confined to 1-2 people Week 8
Prevents: Shallow requirements speed run
Enforcement:
Red flag: 5+ feature retrofits per day
Prevents: "Pending validation" indefinite deferral
Enforcement:
Red flag: >10% "pending" at Week 4
Prevents: 30% escape hatch abuse
Enforcement:
Red flag: PM unilaterally claims "Level 2"
Prevents: Spreadsheet escape hatch at Level 3
Enforcement:
Red flag: Spreadsheet still used Month 2 for Level 3
Prevents: Hiding undocumented features from audit
Enforcement:
Red flag: Feature count suspiciously low for LOC
Prevents: Risk-labeling game (self-declaring "low risk")
Enforcement:
Red flag: >80% features labeled "low risk"
Prevents: Rubber-stamp theater
Enforcement:
20% rubber stamps → lose approval privileges 1 month
Red flag: 100% compliance, 0 bugs caught for 4+ weeks
Prevents: Rubber-stamp between friends
Enforcement:
Accountability: External reviewer reports to executive
Prevents: Verbal-only work
Enforcement:
Red flag: >20% Issues created within 1 hour of PR
Prevents: Backdating architectural decisions
Enforcement:
Verification: git log --format=%ai -- docs/adr/ vs implementation commits
Prevents: Skipping review when partner unavailable
Enforcement:
emergency-solo tag, external review within 48 hoursRed flag: >4 solo emergencies/year
Prevents: GitHub admin bypass enabled
Enforcement:
Verification: gh api repos/{owner}/{repo}/branches/main/protection | jq '.enforce_admins.enabled'
Prevents: Fork-based bypass attack
Enforcement:
Red flag: Multiple failed force-push attempts
Prevents: Disabling branch protection
Enforcement:
Red flag: Protection disabled >1 hour
The following reference sheets provide detailed, step-by-step guidance for specific adoption scenarios. Each reference is a separate file - load on-demand when needed.
maturity-assessment.md)When to load: Starting adoption, gap analysis, determining Level 2/3/4 fit, audit preparation
Assess current CMMI maturity level, identify gaps, prioritize improvements using:
Provides: Scoring method, assessment templates, prioritization framework, tool integration patterns
Load reference: See maturity-assessment.md for complete assessment process.
adoption-roadmap.md)When to load: Planning phased rollout, pilot project strategy, scaling practices organization-wide
12-week incremental adoption roadmap with:
Provides: Weekly implementation plans, pilot selection criteria, scaling strategies, rollout timelines
Load reference: See adoption-roadmap.md for complete phased rollout guidance.
retrofitting-requirements.md)When to load: Adding requirements traceability to existing features, documenting undocumented code
Add RD + REQM practices to existing codebase without rewriting:
Provides: Retrofitting workflow, traceability templates, GitHub/Azure DevOps implementation patterns
Load reference: See retrofitting-requirements.md for complete retrofitting process.
retrofitting-cm.md)When to load: Adopting branching strategies mid-project, adding version control discipline, migrating platforms
Add CM practices to existing project without disrupting active development:
Provides: Migration playbooks, branch protection rules, release process templates, rollback procedures
Load reference: See retrofitting-cm.md for complete CM retrofitting guidance.
retrofitting-quality.md)When to load: Adding tests and code reviews to legacy code, implementing VER + VAL practices
Add testing and review practices without "test everything first":
Provides: Test retrofitting strategies, review policy templates, coverage targeting, validation workflows
Load reference: See retrofitting-quality.md for complete quality retrofitting process.
retrofitting-measurement.md)When to load: Establishing metrics without historical data, adding MA + QPM + OPP practices
Create baselines and measurement programs when starting from zero:
Provides: Metric definitions, baseline establishment methods, dashboard templates, SPC implementation
Load reference: See retrofitting-measurement.md for complete measurement retrofitting guidance.
managing-transition.md)When to load: Tool migrations, platform changes, maintaining compliance during parallel operations
Maintain CMMI compliance while changing tools/platforms:
Provides: Migration playbooks, parallel operation procedures, traceability preservation, rollback plans
Load reference: See managing-transition.md for complete transition management guidance.
change-management.md)When to load: Team resistance, executive skepticism, demonstrating ROI, building buy-in
Overcome organizational resistance and build support for CMMI adoption:
Provides: Objection handling scripts, ROI calculations, stakeholder communication templates, success metrics
Load reference: See change-management.md for complete change management guidance.
How to access:
"I need detailed guidance on [topic]"
→ Load the appropriate reference sheet from the list above
When you need a reference:
Cross-references: Reference sheets link to each other when practices overlap (e.g., retrofitting requirements references maturity assessment for prioritization).