@crossplatformai/skills/skills/post-build-ship/build/SKILL.md

Reusable Agent Skills for CrossPlatform.ai projects.

---
name: post-build-ship/build
description: Implement Authorizing User-approved outcomes adaptively and prove them with proportionate QA.
---

# Build

Use `build` for an Authorizing User-approved Post objective. Build owns implementation, adaptive test
work, logical diff review, and proportionate QA. Narrative commits and the Ship handoff apply only
when the invoked route contains Ship.

Package publication, registry replacement, deployment, temporary-link unlinking, migration command
execution, and generated migration artifacts remain user-owned unless a separate repository rule
explicitly assigns a safer in-scope action. Those exclusions are never broadened by general Build
authority.

Load `temporary-pnpm-package-links` whenever linked-source validation is in scope. Report
`implementation: complete against validated linked source` separately from `manual release
finalization: pending | complete`; pending publication or unlinking is not partial implementation.
For React Native Web-to-DOM ownership, read
`post-build-ship/references/react-native-web-to-dom.md`.

## Admission

Before mutation:

1. inspect repository instructions and `git status --short`;
2. classify pre-existing changes by hunk and preserve their ownership;
3. verify Authorizing User authority for the approved objective;
4. run `pbs-admit` against the handoff when available, or apply its direct checks when it is not;
5. confirm acceptance outcomes, material boundaries, risk/rules, and current prerequisites; and
6. confirm command execution required for this objective is available and no required QA is already
   failed.

Do not request, fabricate, or validate plan-review receipts, implementation approvals, commit
validation, reviewer availability, capability proofs, attestations, or review digests. Existing
review content is supplemental context. Resolve a material issue it identifies because the issue
affects the objective, not because a reviewer marked a gate blocking.

If admission fails, return concise diagnostics naming the safety-, authority-, or
implementation-relevant deficiency. Presentation-only deficiencies belong in Post and must not be
deferred to Build.

## Adaptive Implementation

Preserve the approved objective, observable acceptance, public contracts, material boundaries, and
risk envelope. Within that envelope, Build may adapt:

- implementation approach and touched files
- focused tests and fixtures
- commands and feedback-loop checks
- recovery tactics that preserve fail-fast behavior
- coherent narrative commit partitions

Adding or correcting tests is adaptive. Weakening acceptance coverage, adding silent error-swallowing
fallbacks, or introducing suppressions is material drift unless the approved objective explicitly
requires and justifies it.

Return to Post for Authorizing User direction only when implementation would materially change intent,
observable acceptance, a public API/schema/protocol, security/privacy/data/migration/release
behavior, repository or runtime-dependency boundaries, or the risk tier. File-list, test, command,
tactic, and commit-boundary changes alone are not drift.

For routes containing Ship., create any number of coherent narrative commits when they improve the
implementation story. A commit is metadata: it does not invalidate passing QA, require peer review,
or force a new QA run. If work stops early, retain safe local commits but report the objective as not
shipped. Resume under the same approved packet unless its outcome or risk changed.

## QA

Apply `references/quality-assurance.md`.

- Run preflight only for real dependency, environment, or known-baseline uncertainty.
- Use focused checks while implementing when they shorten feedback.
- Reuse passing evidence until a relevant source, dependency, configuration, toolchain, fixture,
  generated output, or runtime state changes.
- Before selecting the authoritative final QA manifest, confirm that every owned path already
  contains the form the commit will produce.
- Select one authoritative final QA manifest from the completed diff and risk surface.
- Run the full repository baseline only when breadth or external risk warrants it.

When delegated QA is useful, use one command-capable process, keep raw output there, and exchange
compact receipts. Delegation is optional; reviewer or QA-process availability is not itself
admission evidence.

## Diff, Ownership, And Ship Handoff

For routes containing Ship., inspect fresh status and the relevant staged and unstaged diffs. Confirm
hunk ownership, scope containment, acceptance coverage, fallback status, temporary-link policy,
migration policy, and the authoritative QA manifest. Stage only owned work when staging is useful; do
not treat staging as a workflow receipt.

For routes containing Ship., include the selected PBS mode in the Build-to-Ship handoff. When portable mode was selected despite
provider availability, include the concise capability or compatibility reason. Do not require an
additional receipt or reviewer field for this context.

Hand `ship`:

- target repository and approved objective
- Authorizing User authority source and risk tier
- changed files and ownership classifications
- implementation and narrative-commit summary
- material adaptations and confirmation that none changed the outcome envelope
- commands run and reusable QA receipts
- authoritative final QA manifest and results
- optional review findings actually used
- known risks, user-owned follow-ups, and prohibited release-like actions

Then load `ship` only when the invoked route contains Ship. For Build. and Post.Build., stop after
implementation and required QA without staging or committing. No extra Authorizing User confirmation
is required for a Ship. handoff that remains within the approved objective.