How do I install the Github Pages Visual System skill?

Run npx skillmds@latest add valentinnikolaev/github-pages-visual-system in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Github Pages Visual System safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Github Pages Visual System?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Github Pages Visual System free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Github Pages Visual System?

ValentinNikolaev (@valentinnikolaev) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Github Pages Visual System by valentinnikolaev

Name: Github Pages Visual System
Author: ValentinNikolaev

Github Pages Visual System

Design or refine the visual system of a GitHub Pages documentation site, repository website, wiki, or project landing page. Use for Pages-specific CSS tokens, color and dark themes, typography, reading measure, spacing, grids, hierarchy, responsive behavior, and repository branding. Do not use for generic product design systems, native mobile UI, or non-Pages websites.

ValentinNikolaev 83913c1 4 files · 8.1 KB Updated Sep 17, 2026

File contents

Generated Codex skill — do not edit manually

This complete skill and its bundled resources are generated from agent-plugins/skills/github-pages-visual-system/SKILL.md. Manual changes in this directory will be overwritten the next time the generator runs. Edit the canonical skill instead.

GitHub Pages Visual System

Create a coherent, lightweight visual layer that supports repository content and survives static hosting constraints.

Stay inside the Pages boundary

Inspect the existing site stack, theme, CSS, assets, screenshots, logos, and documented branding before changing visual direction.
Preserve a healthy framework-native theme and its accessible behavior. Prefer small token and component overrides over a replacement design system.
Design for documentation, project explanation, code, tables, and navigation—not for an imaginary application dashboard.
Keep remote fonts, trackers, scripts, and asset hosts out unless explicitly authorized and reviewed for privacy, reliability, and integrity.
Treat exact colors, typefaces, and breakpoints as repository decisions. Do not copy illustrative values as universal requirements.
Leave route generation, base-path configuration, framework migration, and deployment ownership with create-github-pages. If visual work exposes a defect in one of those areas, report and hand it off instead of silently changing it.

Read the contract

Read references/pages-visual-contract.md before creating or materially changing the Pages visual system.

Produce an implementable system

Define only the tokens and rules the site actually uses:

semantic colors for background, surface, text, border, action, focus, code, and status;
type roles for body, headings, labels, and code;
spacing, content width, grid, and radius scales;
light, dark, and high-contrast behavior when supported;
responsive rules driven by real content failure points;
hierarchy for home, documentation, navigation, cards, callouts, and CTAs;
asset and branding reuse decisions.

Implement these through the selected framework's supported theme layer or maintainable CSS variables. Avoid unused token catalogs.

Verify the result

Render representative home, documentation, reference, and not-found pages at desktop and narrow mobile widths.
Run the production build and preview it under the expected Pages base path; confirm representative routes still resolve after theme changes.
Check contrast, visible focus, keyboard states, zoom, reduced motion, overflow, code, tables, images, and navigation.
Test real repository content rather than placeholder copy.
Verify that light and dark variants preserve semantic roles instead of merely inverting colors.
Report browser or accessibility checks that could not be performed; source inspection is not rendered verification.

---name: github-pages-visual-systemdescription: Design or refine the visual system of a GitHub Pages documentation site, repository website, wiki, or project landing page. Use for Pages-specific CSS tokens, color and dark themes, typography, reading measure, spacing, grids, hierarchy, responsive behavior, and repository branding. Do not use for generic product design systems, native mobile UI, or non-Pages websites.---## Generated Codex skill — do not edit manuallyThis complete skill and its bundled resources are generated from `agent-plugins/skills/github-pages-visual-system/SKILL.md`. Manual changes in this directory will be overwritten the next time the generator runs. Edit the canonical skill instead.# GitHub Pages Visual SystemCreate a coherent, lightweight visual layer that supports repository content and survives static hosting constraints.## Stay inside the Pages boundary- Inspect the existing site stack, theme, CSS, assets, screenshots, logos, and documented branding before changing visual direction.- Preserve a healthy framework-native theme and its accessible behavior. Prefer small token and component overrides over a replacement design system.- Design for documentation, project explanation, code, tables, and navigation—not for an imaginary application dashboard.- Keep remote fonts, trackers, scripts, and asset hosts out unless explicitly authorized and reviewed for privacy, reliability, and integrity.- Treat exact colors, typefaces, and breakpoints as repository decisions. Do not copy illustrative values as universal requirements.- Leave route generation, base-path configuration, framework migration, and deployment ownership with `create-github-pages`. If visual work exposes a defect in one of those areas, report and hand it off instead of silently changing it.## Read the contractRead [references/pages-visual-contract.md](references/pages-visual-contract.md) before creating or materially changing the Pages visual system.## Produce an implementable systemDefine only the tokens and rules the site actually uses:1. semantic colors for background, surface, text, border, action, focus, code, and status;2. type roles for body, headings, labels, and code;3. spacing, content width, grid, and radius scales;4. light, dark, and high-contrast behavior when supported;5. responsive rules driven by real content failure points;6. hierarchy for home, documentation, navigation, cards, callouts, and CTAs;7. asset and branding reuse decisions.Implement these through the selected framework's supported theme layer or maintainable CSS variables. Avoid unused token catalogs.## Verify the result- Render representative home, documentation, reference, and not-found pages at desktop and narrow mobile widths.- Run the production build and preview it under the expected Pages base path; confirm representative routes still resolve after theme changes.- Check contrast, visible focus, keyboard states, zoom, reduced motion, overflow, code, tables, images, and navigation.- Test real repository content rather than placeholder copy.- Verify that light and dark variants preserve semantic roles instead of merely inverting colors.- Report browser or accessibility checks that could not be performed; source inspection is not rendered verification.

Frequently asked questions