@crossplatformai/skills

Reusable Agent Skills for CrossPlatform.ai projects.

This package is intentionally no-build. It publishes TypeScript metadata from src/ and concrete Agent Skill directories from skills/.

Installation

After publication, install it like any other public package:

pnpm add -D @crossplatformai/skills

For local testing before publication, use a consumer-local link: dependency with a path relative to the consumer repository:

{
  "devDependencies": {
    "@crossplatformai/skills": "link:../framework/packages/skills"
  }
}

Then install from the consumer root:

pnpm --dir "/path/to/consumer" install

Commit approved unpublished-package validation state by default. Complete implementation, QA, and production-mode validation builds may continue against the link. AI agents never publish or unlink; the user may publish the validated framework package while the consumer remains linked, then owns replacement with and verification of the exact registry version before consumer production release. Load @crossplatformai/skills#temporary-pnpm-package-links for the complete contract.

Available Skills

Workflow skills — Post.Build.Ship.

A three-phase implementation workflow plus a direct-user commit path: post plans, build edits and stages, and ship commits. A direct Ship these changes request may inspect and selectively stage staged or unstaged changes, run non-mutating checks, self-validate the message, and commit without Post/Build artifacts. It is host-neutral and cross-agent: skills name gates (plan-review, implementation-assist, minimum-qa, implementation-approval, final-qa, commit-validation, and optional bounded-check) and visible runtime routes, so the same skill can run across visible agent surfaces. The complete system lives under skills/post-build-ship/.

Route resolution is separate from process creation. post records future Gate Launch Specifications, while build and ship create or select each visible gate process only when its complete prompt, command list, or review packet is ready to send. Gate processes are reused only for expected continuation of the same gate and closed after their terminal result; implementation approval remains in continuation through authoritative final QA. This keeps visible gates actionable without weakening QA receipts, review separation, fail-fast behavior, or commit validation.

plan-review also runs a read-only Build admission review and records the Plan-to-Build completeness verdict; this is a mode of the existing gate, not an additional gate, route, lifecycle, or public skill. references/plan-review-integrity.md is the single authority for the Build Admission Checklist shared by Post and Build, receipt semantics, launch authority, handoff states, draft quarantine, and material-drift handling.

Post reviews the complete substantive handoff, including every future Gate Launch Specification. After an unconditional receipt, Post immediately emits one atomic # Build Launch Prompt containing the complete candidate, receipt, Launch Approval Contract, and all gate specifications. Submitting that complete prompt as the initiating message in a fresh context approves the candidate as pasted for exact commit count 1. Build applies the same checklist, semantic-correspondence, count, gate, and consistency checks before mutation; harmless transport formatting is ignored, while omissions, truncation, and contradictions return structured diagnostics.

Every new Post candidate and Build Launch Prompt selects one dependency-ready active commit unit and uses exact commit count 1. Larger roadmaps remain visible only through a source pointer and an explicit exclusion of later units; those later details are not incorporated into the reviewed candidate. Activating the next unit requires a fresh Post candidate and accepted review receipt, and same-window execution requires explicit post-review approval and stops after the active unit ships. Build retains its multi-unit loop only as compatibility support for previously approved handoffs whose receipts, approval evidence, counts, and unit correspondence remain valid.

Build independently accepts that complete receipt and launch authority and rechecks each required gate's availability, capability proof, and sole allowed fallback before any repository mutation, including branch/worktree changes and QA commands that can write. Formal processes record requested and observed provider, harness, model, effort, and permission as audit data; a user-selected per-run retention override keeps terminal visible processes idle until separately approved for closure, never becomes the default lifecycle, and never permits gate reuse. Ship returns a completion audit manifest with receipt, candidate/tree, commit, post-commit, release-like-action, and process-closure evidence.

For Build handoffs, the workflow's authoritative order is: implement, stage the complete candidate, obtain implementation approval while keeping that reviewer open, run the complete final-QA baseline, prove candidate identity, then perform read-only commit validation and commit. Any content change after approval returns to Build for restaging, reapproval through the same reviewer, and a complete final baseline rerun. Pre-approval QA is always preliminary or inner-loop evidence. These formal approval and visible-gate requirements do not apply to standalone user Ship requests; standalone Ship retains staged-diff hashing, check/candidate correspondence, pre-commit tree capture, hook-mutation detection, post-commit tree comparison, and final status reporting.

• @crossplatformai/skills#post-build-ship: Dispatch reviewed Post.Build.Ship. and Build.Ship. handoffs plus direct standalone Ship. requests.
• @crossplatformai/skills#post-build-ship/post: Intake, investigate, review, and produce directly launchable single-unit Build Launch Prompts.
• @crossplatformai/skills#post-build-ship/build: Implement approved plans, contain scope, run QA, and hand staged work to ship.
• @crossplatformai/skills#post-build-ship/ship: Inspect staged or unstaged changes, validate, commit, and verify direct-user or Build-handoff work.

Guidance skills

Standalone, task-matched knowledge an agent loads on its own when a task matches:

• @crossplatformai/skills#temporary-pnpm-package-links: Temporary pnpm package-link guidance for consumer-local links, linked-source validation, committed development state, AI publication and unlink prohibitions, and registry verification before consumer production release.
• @crossplatformai/skills#react-native-web-styling: React Native Web and Uniwind styling guidance for class precedence, spacing, and compatibility fixes.
• @crossplatformai/skills#playwright-visual-verification: Local Playwright visual verification guidance for snapshots, screenshots, and computed-style checks.
• @crossplatformai/skills#desktop-electron-dev-attach: Desktop Electron dev attach guidance for DESKTOP_DEV_PORT, DESKTOP_CDP_PORT, Playwright Electron, and OpenCode MCP.
• @crossplatformai/skills#multi-agent-hunk-ownership: Multi-agent hunk-ownership guidance for preserving user and other-agent changes while editing, formatting, staging, and committing.
• @crossplatformai/skills#documentation-writing: Durable evergreen documentation guidance with change-oriented framing when change history is needed.
• @crossplatformai/skills#reconcile-setup: Idempotent run-once setup should be reconciled with an event-triggered, fail-loud QA drift-check.
• @crossplatformai/skills#rule-of-three: Structure complexity into about three memorable chunks with a rhythm - the phone-number principle.
• @crossplatformai/skills#see-something-say-something: See or smell something off, even outside your scope, and surface it - do not silently fix it or silently ignore it.
• @crossplatformai/skills#thinking-is-not-knowing: Before asserting a claim or recommendation, check whether you can say "I know" and name the failure mode it prevents - if not, it is a guess; verify before presenting it.
• @crossplatformai/skills#i-dont-know-is-the-answer: When you lack a grounded answer, say "I do not know" instead of hedging - and make it pull its weight with "I do not know yet, here is how I will find out, by when."
• @crossplatformai/skills#move-them-lose-them: Keep users in their current task context when they can satisfy a prerequisite or create missing data without leaving what they are trying to finish.

The package metadata exports the relative paths to these skill directories. It does not scan the filesystem or provide a runtime skill loader.

Artifact Kinds

Three kinds of artifact, distinguished by who decides to load them:

1. Workflow skills — orchestration entrypoints and phase owners (post-build-ship, post, build, ship). The user invokes these.
2. Guidance skills — standalone knowledge the agent loads on its own when a task matches. Peers to the workflow, not internals.
3. References — non-invokable supporting docs cited by a workflow skill, under skills/post-build-ship/references/. The workflow pulls them in; they are not addressable skills and are not exported in the metadata.

Workflow spines stay lean: invariants, gates, Post's single-unit boundary, Build's legacy multi-unit compatibility loop, QA receipt rules, and the gate contract stay inline; situational recipes, checklists, and feature-specific policies (framework release, PNPM audit, happy-path testing, fail-fast, and subagent delegation terms) live in references. Temporary pnpm package links are a standalone guidance skill because agents load that policy directly whenever linked-source testing or manual release-finalization ownership is in scope.

Publishing Model

The package publishes these files:

• src/: lightweight TypeScript metadata.
• skills/: concrete Agent Skill directories and SKILL.md payloads.
• README.md and LICENSE.

There is no build, prepack, bin, CommonJS export, or generated runtime artifact.

Pattern Inspiration

This package follows the same general package-distributed skill pattern used by TanStack Intent. It is not affiliated with TanStack Intent or TanStack.