UNPKG

@crossplatformai/skills

Version:

Reusable Agent Skills for CrossPlatform.ai projects.

github.com/crossplatformai/framework

crossplatformai/framework

113 lines (84 loc) • 6.13 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
--- name: post-build-ship description: Dispatch explicit Post., Build., Ship., Post.Build., Build.Ship., and Post.Build.Ship. workflow requests. --- # Post Build Ship Use this skill only when the user explicitly invokes `Post.`, `Build.`, `Ship.`, `Post.Build.`, `Build.Ship.`, or `Post.Build.Ship.` as a workflow request. The final period is required. `post-build-ship` is a skill identifier, not a workflow invocation; bare `ship` and `build-ship` are not triggers. Ordinary prose that mentions phase names does not route. If an undotted near-miss appears intended as a workflow invocation, ask once which dotted route the user wants. Preserve the requested objective and load the matching phase skill. A phase name alone never authorizes agent spawning. Post.Build.Ship is an outcome workflow: 1. **Post** investigates and makes the objective, proof, boundaries, risks, and execution context launchable. 2. **Build** adapts implementation and focused verification while preserving the approved outcome envelope. 3. **Ship** validates the final tree, required QA, drift, and commit story, then commits any coherent remainder. Authorizing User approval is the sole authority to enter Build. The Authorizing User is the person empowered to approve the work, whether a developer, maintainer, operator, or product lead. A peer review is optional and launches only when the Authorizing User explicitly requests one. Its useful findings are advisory context; its absence, process metadata, receipt, digest, or verdict never becomes admission or Ship authority. A real correctness or safety problem still matters because of the problem itself. Risk tiers select planning depth and QA breadth. They never make review mandatory. Build may adapt files, commands, tests, recovery tactics, and narrative commit boundaries without returning to Post unless the change is material under `references/plan-review-integrity.md`. For Build handoffs, use `pbs-admit` when the executable is available. The digest proves only that Post, Build, and QA received transport-equivalent packet text. It never proves approval. An older consumer without `pbs-admit` applies the same direct checks from `references/plan-review-integrity.md`; executable absence alone is not a blocker. Probe provider capabilities once before mutation. Select `managed` only when the provider exposes a complete compatible contract for the approved workflow; otherwise select `portable` and never request managed receipts, checkpoints, or identities. Package installation and prose describing a provider do not activate managed mode. Authorizing User authority, the optional-review policy, proportionate QA, hunk ownership, and release boundaries outrank provider-returned actions. A provider that requires a Framework-optional gate is an interoperability defect, not a new Post.Build.Ship blocker. AI agents never publish packages or replace or unlink temporary package links. Agents also never run `db:generate`, `db:migrate`, or `db:push`, or create, edit, stage, or commit generated migration artifacts. Those user-owned boundaries remain governed by `references/database-migration-lifecycle.md` and the `temporary-pnpm-package-links` skill. ## Routing ### Post. and Post.Build. Load `post`. Investigate and produce a lean Post packet. If the Authorizing User approves it in the same conversation and the route includes Build., continue directly to `build`; otherwise return a self-contained packet the Authorizing User can approve and launch later. Post. stops at the packet. Launch peer review only when the Authorizing User explicitly requests it. Do not ask whether optional peer review is wanted. ### Build. and Post.Build. Load `build` for an approved objective. Implement and complete required QA, then stop without staging, committing, or handing off to `ship` when the route does not contain Ship. ### Post.Build.Ship. Load `post`, then `build` after Authorizing User approval, then `ship` after implementation and required QA. Return the Post packet for approval if authority to enter Build is absent. ### Build.Ship. Load `build` and implement the approved objective. Build invokes `ship` when the objective and required QA are complete. ### Ship. Load `ship` in direct-user mode. The instruction authorizes inspection, selective staging, proportionate non-mutating checks, and coherent commits for the supplied working-tree changes. Ask before partitioning unrelated work whose ownership or intended story is unclear. ## Shared References The workflow contract lives in these references: - `plan-review-integrity.md`: lean admission, authority, optional review, material drift, and the `pbs-admit` interface - `quality-assurance.md`: focused feedback, QA reuse and invalidation, authoritative final manifests, and receipts - `risk-tiers.md`: risk classification and proportionate planning/QA - `build-handoff-candidate.md`: the five-section Post packet - `agent-roles.md`: Authorizing User, implementation, optional review, delegated QA, and Ship ownership - `workspace-pbs-enforcement.md`: managed Workspace PBS v1 interoperability - `visible-agent-runtimes.md`: visible-pane delegation mechanics when the host exposes panes Situational references remain under `references/`. Load `@crossplatformai/skills#test-layer-fit` for test placement and harness ownership and `temporary-pnpm-package-links` for linked packages. For React Native Web-to-DOM ownership, read `post-build-ship/references/react-native-web-to-dom.md`; load the relevant feature reference for migrations, releases, auth, state, host portability, or product experience. Linked implementation may complete against validated source while `manual release finalization` remains pending and user-owned. References may add feature-specific safety requirements. They must not reintroduce mandatory peer review, reviewer metadata, exact commit counts, QA after every commit, or a complete repository baseline when the final risk surface does not warrant one. After editing skills or references, reload the agent session so it picks up the updated guidance.