github · Un1quer23 · Jun 18, 2026
@@ -192,6 +192,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
 | [github-copilot-starter](../skills/github-copilot-starter/SKILL.md)<br />`gh skills install github/awesome-copilot github-copilot-starter` | Set up complete GitHub Copilot configuration for a new project based on technology stack | None |
 | [github-issues](../skills/github-issues/SKILL.md)<br />`gh skills install github/awesome-copilot github-issues` | Create, update, and manage GitHub issues using MCP tools. Use this skill when users want to create bug reports, feature requests, or task issues, update existing issues, add labels/assignees/milestones, set issue fields (dates, priority, custom fields), set issue types, manage issue workflows, link issues, add dependencies, or track blocked-by/blocking relationships. Triggers on requests like "create an issue", "file a bug", "request a feature", "update issue X", "set the priority", "set the start date", "link issues", "add dependency", "blocked by", "blocking", or any GitHub issue management task. | `references/dependencies.md`<br />`references/images.md`<br />`references/issue-fields.md`<br />`references/issue-types.md`<br />`references/projects.md`<br />`references/search.md`<br />`references/sub-issues.md`<br />`references/templates.md` |
 | [github-release](../skills/github-release/SKILL.md)<br />`gh skills install github/awesome-copilot github-release` | Guides IA through releasing a new version of a GitHub library end-to-end. Handles SemVer versioning and Keep a Changelog formatting automatically. | `references/commit-classification.md`<br />`references/semver-rules.md` |
+| [github-repo-publisher](../skills/github-repo-publisher/SKILL.md)<br />`gh skills install github/awesome-copilot github-repo-publisher` | Guide agents through GitHub repository publishing-surface preparation, audits, and safe publishing workflows. Use when preparing a repository for first public release, reviewing an already public GitHub repo, or updating README files, translated READMEs, About description, topics, homepage, social preview, badges, license and attribution notices, community health files, package metadata, changelog or release copy, issues, PR text, branch or security settings, and other public-facing GitHub copy; also use for git, gh, GitHub API, or connector operations that must preserve repo facts and user changes. | `references/github-operations.md`<br />`references/publishing-copy.md`<br />`references/readme-metadata.md`<br />`references/safety-quality.md`<br />`scripts/collect-repo-facts.mjs`<br />`scripts/collect-repo-facts.ps1` |
 | [go-mcp-server-generator](../skills/go-mcp-server-generator/SKILL.md)<br />`gh skills install github/awesome-copilot go-mcp-server-generator` | Generate a complete Go MCP server project with proper structure, dependencies, and implementation using the official github.com/modelcontextprotocol/go-sdk. | None |
 | [gsap-framer-scroll-animation](../skills/gsap-framer-scroll-animation/SKILL.md)<br />`gh skills install github/awesome-copilot gsap-framer-scroll-animation` | Use this skill whenever the user wants to build scroll animations, scroll effects, parallax, scroll-triggered reveals, pinned sections, horizontal scroll, text animations, or any motion tied to scroll position — in vanilla JS, React, or Next.js. Covers GSAP ScrollTrigger (pinning, scrubbing, snapping, timelines, horizontal scroll, ScrollSmoother, matchMedia) and Framer Motion / Motion v12 (useScroll, useTransform, useSpring, whileInView, variants). Use this skill even if the user just says "animate on scroll", "fade in as I scroll", "make it scroll like Apple", "parallax effect", "sticky section", "scroll progress bar", or "entrance animation". Also triggers for Copilot prompt patterns for GSAP or Framer Motion code generation. Pairs with the premium-frontend-ui skill for creative philosophy and design-level polish. | `references/framer.md`<br />`references/gsap.md` |
 | [gtm-0-to-1-launch](../skills/gtm-0-to-1-launch/SKILL.md)<br />`gh skills install github/awesome-copilot gtm-0-to-1-launch` | Launch new products from idea to first customers. Use when launching products, finding early adopters, building launch week playbooks, diagnosing why adoption stalls, or learning that press coverage does not equal growth. Includes the three-layer diagnosis, the 2-week experiment cycle, and the launch that got 50K impressions and 12 signups. | None |

@@ -0,0 +1,64 @@
+---
+name: github-repo-publisher
+description: 'Guide agents through GitHub repository publishing-surface preparation, audits, and safe publishing workflows. Use when preparing a repository for first public release, reviewing an already public GitHub repo, or updating README files, translated READMEs, About description, topics, homepage, social preview, badges, license and attribution notices, community health files, package metadata, changelog or release copy, issues, PR text, branch or security settings, and other public-facing GitHub copy; also use for git, gh, GitHub API, or connector operations that must preserve repo facts and user changes.'
+---
+
+# GitHub Repo Publisher
+
+Use this skill to make GitHub-facing work factual, consistent, and safe. Treat README, About metadata, topics, releases, PRs, issues, and discussions as one publishing surface, not separate scraps of copy.
+
+## Core Workflow
+
+1. Resolve context.
+   - Identify the local repository, target GitHub remote, default branch, current branch, and whether the task is read-only or write-capable.
+   - Read local `AGENTS.md` or equivalent repo instructions before using network commands, `gh`, git writes, or packaging/release commands.
+   - Review Git tracking state with `git status`, `git ls-files`, and ignored/untracked files before treating local-vs-remote differences as publishing problems.
+   - Prefer GitHub connector tools for structured repo, issue, and PR data when available. Use `gh` or git when local branch state, Actions logs, commits, pushes, or fields unsupported by the connector matter.
+
+2. Collect facts before writing.
+   - Inspect source files, package manifests, docs, CI config, license, examples, screenshots, releases, and existing GitHub metadata.
+   - For local repos, prefer `node scripts/collect-repo-facts.mjs --repo <path>` for a quick cross-platform fact map.
+   - If Node.js is unavailable, use `pwsh -NoProfile -File scripts/collect-repo-facts.ps1 -RepoPath <path>` when PowerShell 7 is available, or collect the same facts manually.
+   - Classify local files as tracked repository content, ignored local context, or untracked candidates. Do not call ignored/untracked local assistant instructions "missing from GitHub" unless the user explicitly intends to publish them.
+   - Report likely tracking mistakes: local assistant instructions that are tracked and need public-intent review, and public-facing docs/assets/manifests that are untracked and may have been forgotten.
+   - Before changing README, About, topics, or homepage, check package manifest metadata, README raw line structure, available screenshot/image assets, license files, and attribution clues.
+   - If the project has i18n config, `_locales`, locale directories, translation resources, or existing translated READMEs, evaluate whether README languages match the user-facing project-supported locales.
+   - Do not invent features, badges, benchmarks, compatibility claims, sponsorship claims, security posture, or installation commands.
+
+3. Classify project scale before making recommendations.
+   - Read `references/safety-quality.md` and classify the repository as `Tiny / Personal / Experiment`, `Small Public / Low-Risk`, `Usable / Public Utility`, or `Serious / Community / Product`.
+   - Then classify the right-sizing dimensions: `Collaboration posture`, `Security exposure`, `Distribution surface`, `User impact`, `Documentation complexity`, and `README language coverage`.
+   - Fit recommendations to the project scale, audience, and right-sizing dimensions. Do not prescribe community governance, security automation, release process, docs architecture, or multilingual documentation unless the context justifies it or the user asks.
+   - Treat Dependabot, code scanning, dependency review, secret scanning, push protection, branch protection, and vulnerability reporting as audit recommendations by default. Do not create configs, workflows, or change GitHub settings for them unless the user explicitly asks for that specific action.
+
+4. Choose the publishing track.
+   - README/About/Topics/Homepage/Social preview/multilingual docs: read `references/readme-metadata.md`.
+   - PR, issue, discussion, release, and changelog copy: read `references/publishing-copy.md`.
+   - GitHub operations, commits, pushes, PR creation, or API writes: read `references/github-operations.md`.
+   - Risk checks, write confirmations, and quality gates: read `references/safety-quality.md`.
+
+5. Draft or edit with traceability.
+   - Tie each public claim to observed repository facts.
+   - Keep copy audience-aware: first-time evaluator, potential contributor, package user, maintainer, or reviewer.
+   - If facts are missing, add a clear placeholder note, ask a focused question, or omit the claim.
+
+6. Validate before delivery.
+   - Re-read changed files for broken headings, links, image paths, tables, fenced code blocks, and stale badges.
+   - For README audits, report whether raw Markdown line structure was checked. Prefer `lineCount` and `maxLineLength` from `scripts/collect-repo-facts.mjs` when available.
+   - Run relevant tests or lint/docs checks when the repo provides them.
+   - For GitHub writes, summarize target repo, branch, files/metadata, and exact action before applying unless the user already explicitly requested that write.
+
+## Operating Rules
+
+- Preserve user work. Do not reset, checkout away, delete, or overwrite unrelated changes.
+- Keep local edits and remote writes separate. A polished README draft is not permission to push it.
+- Use explicit paths when staging mixed worktrees. Avoid broad `git add -A` unless every change belongs to the task.
+- Treat ignored or untracked local assistant instructions such as `AGENTS.md`, `CLAUDE.md`, or editor/agent rule folders as operational context, not GitHub publishing-surface gaps. If they are tracked, review whether they are intentional public repo content before recommending changes.
+- For security automation, report `Required for this context` or `Optional for this context` recommendations first. Do not add `.github/dependabot.yml`, security workflows, branch rules, or repository security settings unless the user explicitly authorizes that exact change.
+- Prefer draft PRs unless the user asks for ready review.
+- For `gh` or HTTPS failures, check auth first, then repo instructions for proxy requirements. If a local instruction requires proxy environment variables, apply them to the command invocation.
+- If a requested GitHub field is not available through the current tool, state the limitation and provide an exact fallback command or manual update text.
+
+## Output Shape
+
+For audits, include `Scale classification`, `Right-sizing dimensions`, concrete findings, and right-sized proposed edits. Mark every recommendation as `Required for this context` or `Optional for this context`, and name the dimension that triggers it. For creation/update tasks, provide the changed files plus concise notes on what GitHub metadata should be set to. For write operations, include what succeeded, what was verified, and anything still requiring the user's GitHub permissions.
@@ -0,0 +1,104 @@
+# GitHub Operations
+
+Use this reference when a task touches git state, GitHub APIs, `gh`, PRs, issues, releases, or repository metadata writes.
+
+## Tool Preference
+
+- Use GitHub connector tools for structured repo, issue, PR, comment, label, and reaction operations when available.
+- Use local `git` for branch, diff, status, staging, commit, and push.
+- Use `gh` for current-branch PR discovery, GitHub Actions checks/logs, repository metadata fields not exposed elsewhere, releases, and API fallbacks.
+- Use the browser only when an action depends on the user's existing logged-in web session or when the user explicitly asks for browser operation.
+
+## Before Write Operations
+
+Check:
+
+- `git status --short --branch`
+- `git ls-files`
+- Ignored and untracked files, for example with `git ls-files --others --exclude-standard` and `git ls-files --others --ignored --exclude-standard`
+- `git remote -v`
+- Current branch and upstream.
+- Whether the worktree contains unrelated user changes.
+- Local instructions such as `AGENTS.md`, especially proxy, packaging, release, branch, or commit conventions.
+- Auth with `gh auth status` when using `gh`.
+- Branch protection, rulesets, required reviews, required status checks, signed commit rules, and release permissions when a write targets GitHub.
+- For security automation writes, confirm the target repository, exact file or setting, schedule or trigger, affected branches/ecosystems, and expected notification or permission impact. This includes `.github/dependabot.yml`, `.github/workflows/*security*`, code scanning, dependency review, branch protection, Dependabot settings, secret scanning, push protection, and private vulnerability reporting.
+
+If GitHub HTTPS access requires a proxy, apply repo-local instructions. Example for shells that support environment variables:
+
+```bash
+HTTPS_PROXY=<proxy-url> HTTP_PROXY=<proxy-url> gh repo view
+```
+
+In PowerShell:
+
+```powershell
+$env:HTTPS_PROXY='<proxy-url>'; $env:HTTP_PROXY='<proxy-url>'; gh repo view
+```
+
+## Git Tracking Review
+
+Before reporting that a local file is missing from GitHub, classify it by Git tracking state.
+
+Common local assistant instruction files include `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `CODEX.md`, `.cursor/rules`, `.cursorrules`, `.windsurfrules`, `.clinerules`, `.claude`, and `.codex`.
+
+- Treat ignored or untracked files in this family as local operational context, not GitHub publishing-surface gaps.
+- Treat tracked files in this family as valid repository content, but review whether publishing them is intentional, useful, and free of sensitive local instructions.
+- Flag untracked files that look public-facing as possible forgotten tracking, especially README assets, docs, license files, manifests, examples, screenshots, social previews, and CI/config files meant for the repository.
+- Do not stage, untrack, delete, or push tracking-review findings unless the user explicitly asks for that action.
+
+## Safe Git Flow
+
+1. Inspect current state.
+2. Create or switch to a task branch when appropriate. Use the repo's preferred agent branch prefix, or `agent/` when no convention exists.
+3. Edit only relevant files.
+4. Run focused validation.
+5. Stage explicit paths in mixed worktrees.
+6. Commit with a concise message.
+7. Push the branch.
+8. Open a draft PR unless the user requests ready review.
+
+Do not use destructive commands such as hard resets or checkout-based reverts unless the user clearly asks for them.
+
+Do not bypass branch protection, rulesets, required review, signed commit, or required status check policies. For regular collaborators, prefer a branch PR workflow. Use fork PRs primarily for external contributors or when repository permissions require them.
+
+Do not add Dependabot, code scanning, dependency review, secret scanning, or other security automation as a side effect of a repository audit. Draft or report the recommendation first, then apply only the exact security change the user explicitly requested.
+
+## Release Operations
+
+- Confirm the release tag, target commit, version, changelog source, generated notes source, and release assets before creating or updating a release.
+- Treat draft releases as the default when the user has not explicitly asked to publish immediately.
+- Do not upload binaries, installers, archives, screenshots, or GIFs unless the user requested release assets and the files are verified.
+
+## Metadata Updates
+
+Repository About metadata commonly includes:
+
+- `description`
+- `homepage`
+- `topics`
+
+Prefer drafting exact values first. Apply through connector/API/`gh repo edit` only after the target repo and values are confirmed or the user explicitly requested the update.
+
+Example fallback:
+
+```bash
+gh repo edit OWNER/REPO --description "..." --homepage "https://..."
+gh repo edit OWNER/REPO --add-topic agents --add-topic github
+```
+
+## Actions and CI
+
+For failing GitHub Actions:
+
+- Use `gh pr checks <pr> --json name,state,bucket,link,workflow`.
+- Fetch logs with `gh run view <run-id> --log-failed` when available.
+- Report external checks as external unless the user asks for a separate provider investigation.
+
+Never claim a check passed unless the command or connector result shows it.
+
+## Large Files and Assets
+
+- Avoid adding large screenshots, GIFs, videos, archives, installers, datasets, or generated binaries directly to the repository.
+- Prefer optimized images for README assets, GitHub release assets for downloadable artifacts, and Git LFS for large files that truly must live in the repository.
+- Before adding binary assets, check existing repo conventions and whether the project already uses Git LFS or release artifacts.