/ln-61-repository-publisher

name: ln-61-repository-publisher
description: "Commits, pushes and remotely verifies authorized repository changes; does not create releases."

Repository Publisher

**Goal:** Publish only changes the user has authorized, then verify the result from the remote source.

**Execution contract:** The checklist defines completion. Track each item internally as `PENDING`, `PROVEN` with evidence, `CLEARED` with evidence its condition is absent, or `UNPROVEN` with a gap; reading, delegation, or tool failure is not proof. Reconcile after each section. Before returning, resolve all `PENDING`, count only `PROVEN` and `CLEARED`, and apply verdict and approval rules to every gap. Preserve intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without skipping checks. Preserve dependency and safety order; otherwise choose an appropriate verification method. Accept equivalent user or repository evidence; no other skill, named artifact, or complete lifecycle is required. Preserve source requirement and decision IDs. Bind reused evidence to relevant source versions, dirty changes, configuration, and environment; invalidate only affected claims. On continuation, reconcile task, authorization, current state, and unresolved evidence. For long work, return a compact continuation record or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority. Prepare authorized work before required approval. If blocked by an instruction, cite its exact source and unresolved boundary; do not invent approval gates from caution.

Tool Routing

| Need | Preferred capability | Fallback | |---|---|---| | Scope, staging, history, and synchronization | Native Git CLI | Stop if equivalent Git evidence is unavailable | | Repository validation | Project-native commands and installed validators | Documented manual checks | | Remote branch and CI state | Authenticated hosting CLI or connector | Git remote evidence plus direct workflow URLs | | Clean-source verification | Temporary clone and isolated host configuration when distribution surfaces changed | Remote raw files plus `BLOCKED` for required install evidence | | Static-site verification | Deployment workflow plus direct HTTP request | Hosting API deployment state | | Current marketplace behavior | Official host documentation | Mark assumptions and avoid destructive retries |

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.

Use hosting APIs for remote facts and Git for repository facts. Local distribution or deployment state cannot prove that a remote consumer update works.

Checklist

Establish scope and evidence

• [ ] Confirm the user explicitly requested a commit and push and identify the intended branch.
• [ ] Read repository instructions, release rules, and the current branch policy before mutation.
• [ ] Check `git status -sb`, staged and unstaged diffs, untracked files, remotes, and recent commit style.
• [ ] Identify unrelated user changes; do not stage them without explicit whole-worktree authorization.
• [ ] Inspect deletions and generated files as carefully as edited text.
• [ ] Check whether behavior, installation commands, catalogs, layout, or the public site require matching documentation updates.
• [ ] Do not change versions, tags, or release metadata during an ordinary publication unless the request or repository policy explicitly includes them.
• [ ] For marketplace edits, confirm every stable identifier is unchanged unless an intentional migration was approved.
• [ ] When multiple host catalogs exist and repository policy requires parity, confirm they contain the same distribution units in the required order.
• [ ] When metadata is duplicated across manifests or catalogs, confirm descriptions and source paths agree with the canonical source.

Validation Routing

• [ ] Discover and run repository-native validation commands before generic checks.
• [ ] For changed skills, run repository-required or host-native skill validators, or perform their documented manual fallback.
• [ ] For changed plugins or packages, run repository-required validators, or perform their documented manual fallback.
• [ ] Run every host-native strict validator whose distribution surface exists and changed or is required by repository policy.
• [ ] Run only the catalog parity, manifest parsing, stale-reference, local-link, and whitespace checks required by the repository and affected surfaces.
• [ ] Run only relevant product tests; do not invent a heavyweight release gate absent from repository policy.
• [ ] Stop before commit on a confirmed failing required check unless the user explicitly accepts the failure.
• [ ] Record skipped checks with the exact missing dependency or environment.

Synchronization and Commit

• [ ] Fetch the target remote and compare local HEAD with the remote branch before committing.
• [ ] If behind or diverged, inspect both sides and reconcile within the authorized branch workflow while preserving user changes; stop for unresolved semantic conflicts or a required history rewrite. Never force-push implicitly.
• [ ] Stage explicit paths when the worktree is mixed; use whole-worktree staging only when the user approved all changes.
• [ ] Review the cached diff and diffstat after staging; ensure required checks cover this exact tree, rerunning only checks invalidated by synchronization or subsequent edits.
• [ ] Exclude secrets, local caches, temporary artifacts, and unintended credentials from the staged set without deleting user-owned files; if an intended change contains a secret, block that publication and report redacted evidence.
• [ ] Match the repository's commit-message convention and summarize the entire staged