メニュー
Use when implementing CMMI processes in GitHub or Azure DevOps, migrating between platforms, or establishing traceability/compliance on GitHub/Azure - platform-specific process guidance
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | platform-integration |
| description | Use when implementing CMMI processes in GitHub or Azure DevOps, migrating between platforms, or establishing traceability/compliance on GitHub/Azure - platform-specific process guidance |
This skill provides concrete implementation guidance for mapping CMMI process areas to GitHub and Azure DevOps platform features.
Core principle: CMMI defines WHAT processes are required. This skill shows HOW to implement them in your platform with production-ready configurations.
Platforms covered:
Use this skill when:
Do NOT use for:
| CMMI Process Area | GitHub Feature | Azure DevOps Feature | Reference Sheet |
|---|---|---|---|
| REQM (Requirements Management) | Issues, Projects, Labels | Work Items, Queries, Backlogs | github-requirements.md, azdo-requirements.md |
| CM (Configuration Management) | Branch Protection, CODEOWNERS | Branch Policies, Required Reviewers | github-config-mgmt.md, azdo-config-mgmt.md |
| VER + VAL + PI (Quality) | Actions, Status Checks, PRs | Pipelines, Gates, Test Plans | github-quality-gates.md, azdo-quality-gates.md |
| MA (Measurement) | Insights, API, Actions | Analytics, Dashboards, OData | github-measurement.md, azdo-measurement.md |
| DAR + RSKM (Governance) | Discussions, Wiki, Issues | Wiki, Custom Work Items | github-audit-trail.md, azdo-audit-trail.md |
Best for:
Strengths:
Limitations:
CMMI Maturity:
Best for:
Strengths:
Limitations:
CMMI Maturity:
Common patterns:
Integration options:
The following reference sheets provide detailed, production-ready implementation guidance for each platform.
When to use: Implementing REQM (Requirements Management) in GitHub
→ See github-requirements.md
Covers:
Implements #123, Closes #456)When to use: Implementing CM (Configuration Management) in GitHub
→ See github-config-mgmt.md
Covers:
When to use: Implementing VER, VAL, PI (Verification, Validation, Integration) in GitHub
→ See github-quality-gates.md
Covers:
When to use: Implementing MA (Measurement & Analysis) in GitHub
→ See github-measurement.md
Covers:
When to use: Compliance and audit requirements in GitHub
→ See github-audit-trail.md
Covers:
When to use: Implementing REQM (Requirements Management) in Azure DevOps
→ See azdo-requirements.md
Covers:
When to use: Implementing CM (Configuration Management) in Azure DevOps
→ See azdo-config-mgmt.md
Covers:
When to use: Implementing VER, VAL, PI (Verification, Validation, Integration) in Azure DevOps
→ See azdo-quality-gates.md
Covers:
When to use: Implementing MA (Measurement & Analysis) in Azure DevOps
→ See azdo-measurement.md
Covers:
When to use: Compliance and audit requirements in Azure DevOps
→ See azdo-audit-trail.md
Covers:
| Mistake | Why It Fails | Better Approach |
|---|---|---|
| Treating platform as CMMI-aware | Platforms don't enforce CMMI; you configure enforcement | Map each CMMI practice to platform feature explicitly |
| Using platform defaults | Defaults are permissive (no quality gates, no reviews) | Configure branch protection, required checks, policies |
| Manual traceability | Spreadsheet traceability becomes stale immediately | Automate with issue/PR links, work item queries, API |
| Skipping audit trail setup | Compliance failures discovered during audit | Configure retention, access logs, history from project start |
| One-size-fits-all configuration | Level 2 project gets Level 4 overhead (or vice versa) | Scale configuration based on CMMI target level |
| Forgetting baselines | No way to freeze requirements or code for releases | Implement baseline tagging, release branches, milestone freezes |
| Ignoring platform limitations | GitHub weak at test management; Azure DevOps weak at code review | Use hybrid approach or third-party tools for gaps |
| No verification automation | Traceability breaks without detection | Scheduled checks for orphaned requirements, missing links |
| Generic metrics | Collecting data nobody uses | GQM approach: Goal → Question → Metric (actionable only) |
| Missing cross-process links | Requirements don't link to risks; tests don't link to design | Document integration patterns in configuration |
| When You're Doing | Also Use | For |
|---|---|---|
| Platform setup for requirements | requirements-lifecycle | REQM/RD process definitions |
| Platform setup for CI/CD | design-and-build | TS/PI process definitions |
| Platform setup for testing | quality-assurance | VER/VAL process definitions |
| Platform setup for metrics | quantitative-management | MA/QPM metrics definitions |
| Platform selection decision | governance-and-risk | Decision analysis for platform choice |
| Initial platform adoption | lifecycle-adoption | Incremental rollout strategy |
Remember: Platforms don't enforce CMMI compliance automatically. You must configure them to implement CMMI practices. This skill provides the configuration patterns to bridge CMMI policy to platform reality.
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.