本文へ移動
cccskills
無料GitHub で公開

docsify

Comprehensive guide for building, configuring, customizing, and deploying Docsify documentation sites. Use when the user wants to (1) initialize a new Docsify site, (2) add or organize Markdown pages, sidebars, navbars, or cover pages, (3) configure `window.$docsify` options, (4) customize themes / CSS variables / fonts, (5) install built-in or third-party Docsify plugins (search, GA, emoji, zoom, copy-code, comments, pagination, tabs, etc.), (6) write a custom Docsify plugin using lifecycle hooks, (7) use Docsify Markdown helpers (callouts, link attributes, image attributes, heading IDs, task lists, embed files with `:include`), (8) deploy to GitHub Pages, GitLab Pages, Netlify, Vercel, Firebase, Docker, Nginx, etc., (9) enable PWA / offline mode, virtual routes, or Vue compatibility, or (10) upgrade a Docsify site from v4 to v5. Triggers on mentions of "docsify", "_sidebar.md", "_navbar.md", "_coverpage.md", "$docsify", or `docsify-cli`.

インストール方法を見る

含まれるファイル(11)

  • SKILL.md6.0 KB
  • assets/index.html2.3 KB
  • references/advanced.md6.4 KB
  • references/configuration.md8.3 KB
  • references/deployment.md3.7 KB
  • references/getting-started.md3.4 KB
  • references/markdown-helpers.md5.7 KB
  • references/pages-and-navigation.md4.9 KB
  • references/plugins.md6.0 KB
  • references/themes-and-styling.md4.3 KB
  • references/writing-plugins.md3.9 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Docsify

Docsify turns Markdown files into a documentation website at runtime — there is no static build step. A single index.html boots docsify.js, which fetches and renders .md files dynamically.

Targets Docsify v5 by default. v5 is currently published only as a release candidate (5.0.0-rc.4) — all CDN URLs in this skill pin to that exact version. Use docsify@rc (dist-tag) to track the latest 5.x RC, and switch to docsify@5 only after v5 stable is published. If the user needs the long-stable line, use docsify@4 (CDN path /lib/ instead of /dist/). For v4 migration guidance, load references/advanced.md.

When to load which reference

Load only the references needed for the current task — do not preload everything.

TaskLoad
Bootstrap a brand-new site / write index.html / docsify-cli usagereferences/getting-started.md (+ assets/index.html)
Add pages, build _sidebar.md / _navbar.md / _coverpage.md, multi-language layout, TOCreferences/pages-and-navigation.md
Set or look up any window.$docsify optionreferences/configuration.md
Docsify-specific Markdown syntax (callouts, link/image attrs, heading IDs, embed :include, code highlight)references/markdown-helpers.md
Theme switching, CSS variables, custom fonts, body classes, dark modereferences/themes-and-styling.md
Install / configure built-in or community pluginsreferences/plugins.md
Write a custom Docsify plugin (lifecycle hooks)references/writing-plugins.md
Deploy to GitHub Pages, GitLab, Netlify, Vercel, Firebase, Docker, Nginx, AWS Amplify, etc.references/deployment.md
PWA / offline, virtual routes, Vue components, v4 → v5 upgradereferences/advanced.md

Core mental model

A Docsify site needs only three things:

  1. index.html — single boot file that loads docsify.js, a theme CSS, optional plugins, and defines window.$docsify config.
  2. Markdown files — README.md is the homepage; any other *.md is a route (e.g. guide.md → /#/guide).
  3. Special underscore files (optional but common):
    • _sidebar.md — sidebar menu (requires loadSidebar: true)
    • _navbar.md — top navbar (requires loadNavbar: true)
    • _coverpage.md — landing cover (requires coverpage: true)
    • _404.md — custom 404 (requires notFoundPage: true)
    • _media/ — images and other assets
    • .nojekyll — required on GitHub Pages so underscore files are served

Subfolders define nested routes; nested _sidebar.md / _navbar.md override parent ones (used for multi-language sites).

Quick start workflow

For "set up a new Docsify site" requests:

  1. Read references/getting-started.md for the canonical index.html and CLI commands.
  2. Copy assets/index.html into the site folder and adjust the name, repo, theme add-ons, and plugin <script> tags.
  3. Create README.md (homepage) and .nojekyll (empty file).
  4. If the user wants a sidebar/navbar/cover, also load references/pages-and-navigation.md.
  5. Verify locally with docsify serve <folder> (or python3 -m http.server).

Key conventions to preserve

  • Always pin an exact CDN version. v5 is in RC: use docsify@5.0.0-rc.4 (or the @rc tag) until v5 stable releases — the shorthand docsify@5 does not resolve today. For the long-stable line, use docsify@4 with CDN path /lib/ instead of /dist/. See assets/index.html.
  • Theme CSS must come before Docsify JS; theme add-ons must come after the core theme; Prism language/theme files and plugin scripts must come after docsify.min.js.
  • .nojekyll is mandatory whenever the site is on GitHub Pages and uses any _*.md file.
  • Hash routing is the default (/#/page). Only switch to routerMode: 'history' if the host can rewrite URLs to index.html, and add alias entries for _sidebar.md / _navbar.md (see references/configuration.md).
  • Underscore files fall back up the directory tree — /guide/_sidebar.md is used if present, otherwise /_sidebar.md.
  • Docsify renders Markdown via marked and syntax-highlights via Prism (load extra Prism language components after docsify.min.js).

Common gotchas

  • Forgetting .nojekyll → GitHub Pages 404s on _sidebar.md.
  • Putting plugin <script> tags before docsify.min.js → plugin never registers.
  • Setting coverpage: true without creating _coverpage.md → blank landing.
  • Using routerMode: 'history' on a static host without rewrite rules → deep links 404 on refresh.
  • Mermaid: Docsify only supports synchronous Mermaid (≤ v9.3.0). See references/markdown-helpers.md.
  • The legacy !> / ?> callouts and the themeColor / topMargin options are deprecated in v5 — prefer GitHub-style > [!NOTE] callouts and CSS variables.

Assets

  • assets/index.html — production-ready index.html template with comments showing where to enable theme add-ons and plugins. Copy and edit; do not load into the conversation context unless modifying the template itself.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Add SLSA build-provenance attestations to existing GitHub Actions workflows. Use when the user wants to add artifact attestations, build provenance, or SLSA attestations to Docker container image builds in GitHub Actions CI/CD pipelines.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Guideline for designing, implementing, and verifying secure APIs following OWASP API Security Top 10 (2023) best practices. Use when the user wants to: (1) review API code or design for security vulnerabilities, (2) design a secure REST, GraphQL, or gRPC API architecture, (3) implement API authentication and authorization (OAuth2, JWT, API keys, mTLS), (4) configure rate limiting, input validation, or CORS, (5) audit API endpoints for BOLA, BFLA, or mass assignment vulnerabilities, (6) create API security checklists or verification plans, (7) fix API security bugs or harden existing APIs, (8) set up API security testing (OWASP ZAP, Schemathesis, Burp Suite), or (9) handle any API security concern including SSRF prevention, resource consumption limits, business flow protection, API inventory management, and secure third-party API consumption.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Write, review, and optionally test Bash and Zsh shell scripts following project coding standards. Use for ANY shell scripting task: (1) creating a new Bash or Zsh script, (2) editing, fixing, or reviewing an existing .sh, .bash, or .zsh file, (3) adding error handling, dependency checks, or cleanup traps to shell scripts, (4) implementing API integration or file processing in shell, (5) writing or fixing ShellSpec tests (spec/*_spec.sh), or (6) deciding whether a script should be written in Bash or Zsh. Defaults to Bash; Zsh-specific guidance lives in a reference file that is loaded only when writing Zsh.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Create, run, and maintain API test collections using Bruno (OpenCollection YAML format and legacy Bru format). Use when the user wants to: (1) create a Bruno API test collection from scratch or from OpenAPI/Swagger specs, (2) write API request files with tests and assertions, (3) run API tests using bru CLI, (4) generate test reports (HTML, JUnit, JSON), (5) set up CI/CD pipelines (GitHub Actions) for automated API testing, (6) debug or fix failing Bruno API tests, (7) add environment configurations for API testing, (8) chain API requests with data extraction, or (9) work with any .yml/.bru Bruno collection files. Triggers on mentions of 'Bruno', 'bru CLI', 'API testing collection', 'OpenCollection', or requests to automate API testing with file-based collections.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

jim60105 のスキルをすべて見る

このスキルの問題を報告する