mykg: Skill for Claude Code

mykg GitHub Pages

Publishes a purpose-built pages/ folder from the SenolIsci/mykg main branch as a website, via a GitHub Actions workflow that builds it with Jekyll and pushes the built _site/ output to a gh-pages branch, which is what GitHub Pages actually serves.

main branch                        gh-pages branch
├── src/       ← software          ├── index.html   ← built site
├── pages/     ← Pages source      ├── blog/...
│   ├── _config.yml                └── ...  (generated — never hand-edit)
│   ├── _posts/          (blog articles)
│   ├── index.md         (landing page, adapted from README.md)
│   └── diagrams/
└── .github/workflows/pages.yml

pages.yml: on push to main (pages/** changes) → jekyll build pages/ → _site/
           → peaceiris/actions-gh-pages pushes _site/ to gh-pages
Settings > Pages: source = gh-pages branch

Why a dedicated pages/ folder

A dedicated pages/ folder holds only content written for the public site, so there's never anything to accidentally publish. This skill's default and only source for initial content is README.md (see Step 1) — it never assumes any other folder in the repo is publishable. Any other repo artifact (a diagram, a logo, a screenshot, an existing doc) is fair game to feature on the site, but only when the user explicitly points at it — see "Sourcing artifacts from the repo" below. Don't scan the repo looking for content to publish; ask instead.

Check state before doing anything

gh api repos/SenolIsci/mykg/pages 2>&1
git ls-remote --heads origin gh-pages
cat .github/workflows/pages.yml 2>&1
ls pages/ 2>&1

• No pages/ folder, no gh-pages branch, no workflow file → first-time setup. Do the full flow: Step 1 through Step 5.
• pages/ and the workflow already exist → maintenance request (add a page, add a blog post, fix a failing build). Skip to the relevant section below.
• Workflow exists but the last run failed → go straight to Troubleshooting.
• Pages config exists but build_type is "workflow" while this repo deploys via a branch push (i.e. source.branch isn't reliably gh-pages, or the live URL 404s despite green Actions runs) → the misconfiguration described in Step 5/6 and Troubleshooting; fix with a PUT setting build_type=legacy before doing anything else.
• build_type/source look correct, Actions runs are green, gh-pages has real content, but the live URL still 404s and gh api .../pages --jq .status is null → check whether .github/workflows/pages.yml's deploy step uses secrets.GITHUB_TOKEN instead of a PAT secret. See Step 4a and the matching Troubleshooting entry — this is a different bug from the build_type one above and looks identical from the outside.
• The "Deploy to gh-pages" Actions step itself fails with remote: Permission ... denied / 403 on git push origin gh-pages → the PAT in the secret is fine-grained, not classic, or lacks the repo scope. See Step 4a — this repo's setup only worked with a classic PAT.
• The live URL returns 200 and loads real HTML, but the page has no styling at all (default browser serif font, no colors, no layout — looks like the theme never applied) → check pages/_config.yml for baseurl: "/mykg". See Step 3 — missing baseurl on a project Pages site makes the CSS <link> resolve to the domain root instead of /mykg/... and 404 silently; nothing in the Actions build or Pages config flags this.