ln-62-repository-publisher
starsforks
How to install ln-62-repository-publisher?
levnikolaevich/claude-code-skills/ln-62-repository-publisher
$npx -y skills add levnikolaevich/claude-code-skills --skill ln-62-repository-publisherValidates, commits, pushes, and remotely verifies approved repository changes. Use when publication is requested; not for releases, package publishing, or announcements.
SKILL.md
| 1 | # Repository Publisher |
| 2 | |
| 3 | **Goal:** Publish only changes the user has authorized, then verify the result from the remote source. |
| 4 | |
| 5 | **Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete. |
| 6 | Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: None | section/item — reason; outcome impact; exact next action**; list every incomplete item. |
| 7 | |
| 8 | ## Tool Routing |
| 9 | |
| 10 | | Need | Preferred capability | Fallback | |
| 11 | |---|---|---| |
| 12 | | Scope, staging, history, and synchronization | Native Git CLI | Stop if equivalent Git evidence is unavailable | |
| 13 | | Repository validation | Project-native commands and installed validators | Documented manual checks | |
| 14 | | Remote branch and CI state | Authenticated hosting CLI or connector | Git remote evidence plus direct workflow URLs | |
| 15 | | Clean-source verification | Temporary clone and isolated host configuration when distribution surfaces changed | Remote raw files plus `BLOCKED` for required install evidence | |
| 16 | | Static-site verification | Deployment workflow plus direct HTTP request | Hosting API deployment state | |
| 17 | | Current marketplace behavior | Official host documentation | Mark assumptions and avoid destructive retries | |
| 18 | |
| 19 | Prefer compact Git output first, then open the full diff for files that will be staged. Never pipe commands in a way that hides the failing exit code. |
| 20 | |
| 21 | Use hosting APIs for remote facts and Git for repository facts. A local marketplace directory cannot prove that a Git-backed user update works. |
| 22 | |
| 23 | ## Checklist |
| 24 | |
| 25 | - [ ] Confirm the user explicitly requested a commit and push and identify the intended branch. |
| 26 | - [ ] Read repository instructions, release rules, and the current branch policy before mutation. |
| 27 | - [ ] Check `git status -sb`, staged and unstaged diffs, untracked files, remotes, and recent commit style. |
| 28 | - [ ] Identify unrelated user changes; do not stage them without explicit whole-worktree authorization. |
| 29 | - [ ] Inspect deletions and generated files as carefully as edited text. |
| 30 | - [ ] Check whether behavior, installation commands, catalogs, layout, or the public site require matching documentation updates. |
| 31 | - [ ] Do not create a changelog merely because one is absent; follow the repository's documented release policy. |
| 32 | - [ ] Do not change versions, tags, or release metadata during an ordinary publication unless the request or repository policy explicitly includes them. |
| 33 | - [ ] For marketplace edits, confirm every stable identifier is unchanged unless an intentional migration was approved. |
| 34 | - [ ] When multiple host catalogs exist and repository policy requires parity, confirm they contain the same distribution units in the required order. |
| 35 | - [ ] When metadata is duplicated across manifests or catalogs, confirm descriptions and source paths agree with the canonical source. |
| 36 | |
| 37 | ## Validation Routing |
| 38 | |
| 39 | - [ ] Discover and run repository-native validation commands before generic checks. |
| 40 | - [ ] For changed skills, run repository-required or host-native skill validators, or perform their documented manual fallback. |
| 41 | - [ ] For changed plugins or packages, run repository-required validators, or perform their documented manual fallback. |
| 42 | - [ ] Run every host-native strict validator whose distribution surface exists and changed or is required by repository policy. |
| 43 | - [ ] Run only the catalog parity, manifest parsing, stale-reference, local-link, and whitespace checks required by the repository and affected surfaces. |
| 44 | - [ ] Run only relevant product tests; do not invent a heavyweight release gate absent from repository policy. |
| 45 | - [ ] Stop before commit on a confirmed failing required check unless the user explicitly accepts the failure. |
| 46 | - [ ] Record skipped checks with the exact missing dependency or environment. |
| 47 | |
| 48 | ## Synchronization and Commit |
| 49 | |
| 50 | - [ ] Fetch the target remote and compare local HEAD with the remote branch before committing. |
| 51 | - [ ] If histories diverge, stop and report the commits on both sides; do not force-push or rewrite history implicitly. |
| 52 | - [ ] Stage explicit paths when the worktree is mixed; use whole-worktree staging only when the user approved all changes. |
| 53 | - [ ] Review the cached diff and diffstat after staging. |
| 54 | - [ ] Remove secrets, local caches, temporary artifacts, and unintended credentials from the staged set. |
| 55 | - [ ] Match the repository's commit-message convention and summarize the entire staged change. |
| 56 | - [ ] Do not add an automated co-author or signature unless repository policy or the user requests it. |
| 57 | - [ ] Create the commit and capture its |
People who liked this also viewed
6 picksType
- caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026
- git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026
- finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026
