github-pageslisted

Arrange a project's README and GitHub Pages documentation into a consistent user-first layout: short README that links out, just-the-docs Jekyll site with a user-facing index, one page per user-facing feature (split into child pages when long), and a developer guide with technical sub-pages. TRIGGER when: setting up docs/ for a new project, adding a GitHub Pages site, writing or restructuring a README that will link to GH Pages, adding a new user-facing feature page, or asked to align docs with this project or bga-assistant. DO NOT TRIGGER when: editing unrelated docs outside docs/, working on a project that already has an incompatible docs framework (Docusaurus, MkDocs, VitePress, etc.).
AnotherSava/claude-code-common · ★ 0 · Code & Development · score 69

Install: claude install-skill AnotherSava/claude-code-common

# GitHub Pages Documentation Layout Use this skill when organizing project-level documentation into a README plus a GitHub Pages Jekyll site running the `just-the-docs` theme. The goal is a consistent shape across repos: the README sells the project in under a screen, every user-facing capability gets its own sidebar entry, and developers get a single Developer guide that may itself have technical child pages. Reference implementations: - **jsonl-logs-intellij-plugin** — modern just-the-docs reference. Single product with deep splitting (Usage parent + 6 children, Development parent + 2 children). - **chrome-assistant** — monorepo variant (one product per subfolder under `docs/pages/`). - **bga-assistant** — earlier flat variant. Read the target repo's `README.md`, `docs/index.md`, `docs/_config.yml`, and one or two child pages before writing new docs — copy their tone and shape. ## Core principles 1. **Single source of truth lives on GitHub Pages.** The README is an entry point, not a manual. If something takes more than a paragraph, it belongs on a page and the README links to it. 2. **User perspective by default.** Every page outside the Developer guide is written for someone using the thing, not building it. No build commands, no internal module names, no architecture diagrams — those live under `development`. 3. **One Developer guide.** The Developer guide may have child pages (Architecture, Extension points, etc.) — split when the parent page exceeds ~200 lines or