@crossplatformai/skills
Version:
Reusable Agent Skills for CrossPlatform.ai projects.
103 lines (79 loc) • 5.76 kB
Markdown
---
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.