UNPKG

@crossplatformai/skills

Version:

Reusable Agent Skills for CrossPlatform.ai projects.

103 lines (79 loc) • 5.76 kB
--- name: post-build-ship/ship description: Validate final ownership, QA, drift, and commit coherence, then ship authorized work. --- # Ship Use `ship` for either a Build handoff or a direct request to commit staged or unstaged work. Ship validates the final tree directly. It does not require downstream prose re-review, plan-review receipts, implementation approval, commit validation, reviewer metadata, exact commit counts, or QA after every commit. ## Authority For a Build handoff, verify Authorizing User authority for the approved objective and confirm the final work remains inside its observable outcomes, public contracts, material boundaries, and risk tier. For direct-user Ship, the current instruction authorizes inspection, selective staging, proportionate checks, and coherent commits for the changes placed in scope. Neither authority covers package publication, deployment, registry mutation, temporary-link replacement or unlinking, migration command execution, generated migration artifacts, or unrelated user-owned changes unless separately and explicitly authorized under repository policy. Load `temporary-pnpm-package-links` when the diff contains temporary package-link state. Report its user-owned `manual release finalization` separately. For React Native Web-to-DOM ownership, read `post-build-ship/references/react-native-web-to-dom.md`. ## Final Validation Inspect fresh `git status --short`, staged and unstaged diffs, and existing local commits relevant to the objective. Validate: 1. Authorizing User or direct-user authority; 2. final-tree hunk ownership and exclusion of unrelated work; 3. observable acceptance and no unresolved material drift; 4. required QA selected from the actual diff and risk surface; 5. freshness under the invalidators in `references/quality-assurance.md`; 6. temporary-link, migration, secret, generated-output, and release boundaries; and 7. a coherent narrative across existing and proposed commits. A commit operation alone never invalidates QA. Do not demand a full repository baseline merely because a launcher exists. Do not ask why optional review was not used. If optional peer-review findings exist, treat them as useful evidence and independently resolve any material correctness or safety issue they reveal. Any required QA failure, unavailable command required for final proof, ambiguous ownership, secret, material drift, unsafe hook mutation, or prohibited release-like action blocks Ship. Report the substantive reason and the next safe action. ## Commit Review the proposed commit story before staging. Preserve existing coherent local commits. Create one or more additional narrative commits only when the working tree contains separable owned work; there is no arbitrary cap. Use Conventional Commit subjects. Every normal authored commit must include one unwrapped explanatory body paragraph before any footer lines, even when the subject seems self-explanatory. Version-bump commits still require a body but may use multiple paragraphs. A valid temporary-link lifecycle commit may omit its body only when it uses the exact `--TEMP-- type(scope): subject` header. Generated merge, revert, `fixup!`, `squash!`, and `amend!` commits are exempt. Never add `Co-Authored-By` or agent/session attribution trailers, and never use `--no-verify` to bypass the policy. Validate the message before staging, validate the staged diff before committing, and confirm the hook result after the commit completes. ### Temporary pnpm-link commits Classify an agent-supported link commit as exactly `add` or `update`; refuse user-owned unlinking or replacement state. A temporary-link unit that fails any marker, classification, evidence, or isolation condition in `temporary-pnpm-package-links` blocks Ship. Use the first form for normal work and the second only for a temporary pnpm-link lifecycle commit: ```text type(scope): subject --TEMP-- type(scope): subject ``` The exact leading marker is required only for temporary link `add | update` work, and the marker is reserved exclusively for temporary pnpm package-link lifecycle commits. After recognizing exactly one valid leading prefix, validate the remaining `type(scope): subject` portion normally. Reject a missing, misplaced, duplicated, or wrong-case marker, including `type(scope): --TEMP-- subject`, `--temp-- type(scope): subject`, `--TEMP-- --TEMP-- type(scope): subject`, and `--TEMP-- Link Skills Package`. The complete header, including the nine-character `--TEMP-- ` prefix, is at most 50 characters. The prefix leaves temporary-link subjects nine fewer characters than normal headers. For every validation packet, include marker applicability and the staged-unit isolation evidence. For temporary pnpm-link work, also include the `add | update` lifecycle, old/new diff evidence, staged temporary-link files and hunks, and excluded permanent or unrelated hunks. For a normal commit, state why the marker is prohibited and confirm no temporary-link lifecycle state is staged. Immediately before each commit, verify the staged diff contains only its intended owned hunks. After the commit, compare the committed tree and fresh status to detect hook-generated or unexpected content. If a hook changes content, reclassify it, rerun invalidated QA, and commit only after the candidate is coherent again. ## Completion Report the commit hashes and subjects, changed files, authoritative QA results, optional advisory findings used, remaining dirty-tree classifications, material adaptations, and user-owned follow-up. Mark the objective shipped only when all accepted outcomes are complete. If implementation stopped early, retain safe local commits and report `not shipped` without inventing review or QA evidence.