# Medicare Gov Design System

> Builds Medicare.gov interfaces with the official CMS Medicare.gov child design system layered on CMS Design System core. Use only for Medicare.gov products and explicitly governed related experiences.

- Skill: `blencorp/medicare-gov-design-system` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add blencorp/medicare-gov-design-system`
- Raw SKILL.md: https://api.skillmd.com/api/skills/blencorp/medicare-gov-design-system/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: blencorp (https://skillmd.com/u/blencorp)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/blencorp/medicare-gov-design-system

---


# Medicare.gov Design System

Build within the system's documented scope and delivery model.

## Before editing

1. Confirm the product owner and that this system is authorized for the target surface.
2. Read [references/implementation.md](references/implementation.md) before installing or changing dependencies.
3. Read [references/sources.md](references/sources.md) when checking versions, provenance, license, or release state.
4. Inspect the existing framework, package manager, asset pipeline, and accessibility tests. Preserve them unless the official integration requires a change.

## Workflow

1. Choose one documented delivery path; do not mix compiled, source, CDN, and framework-wrapper paths accidentally.
2. Pin the dependency or downloaded asset version and keep upstream notices.
3. Reuse official components, tokens, content guidance, and templates before adding custom UI.
4. Extend through documented tokens, properties, slots, Sass settings, or composition. Do not edit vendored package files.
5. Test semantic structure, keyboard operation, focus order and visibility, accessible names, error recovery, zoom/reflow, contrast, and target browsers.
6. Report custom patterns, unsupported requirements, and upstream gaps explicitly.

## Boundaries

- **Scope:** Medicare.gov product surfaces. Do not treat it as a general healthcare or CMS brand.
- **Release:** active package in the CMS Design System monorepo.
- **Delivery:** Branded child-system package consuming CMS Design System core.
- Do not invent component APIs, tokens, package names, or compliance claims.
- Do not import another jurisdiction's branding to fill a gap.
- A passing component example does not prove the completed service conforms to WCAG, Section 508, the ADA, or local policy.

## References

- [Implementation](references/implementation.md) — packages, setup, and integration decisions
- [Sources](references/sources.md) — authoritative URLs, snapshot versions, ownership, and license notes