UNPKG

@crossplatformai/skills

Version:

Reusable Agent Skills for CrossPlatform.ai projects.

github.com/crossplatformai/framework

crossplatformai/framework

144 lines (108 loc) • 7.12 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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
# Admission And Plan Integrity This reference is the authority for Post-to-Build admission, Authorizing User launch authority, optional peer review, material drift, and the `pbs-admit` interface. Direct standalone Ship uses its current user instruction as authority and applies `direct-user-ship.md`. ## Authority And Review Authorizing User approval of the final objective is the sole authority to enter Build. A digest, agent recommendation, issue status, reviewer verdict, receipt, model identity, or process record is never approval authority. Peer review is optional. Do not routinely ask whether it is wanted; launch it only when the Product Owner explicitly requests it. Existing review material may be included as supplemental evidence. Its substantive findings matter, but review absence, reviewer metadata, capability proofs, attestations, receipts, digests, and unused review routes never block Build or Ship. A completed peer review remains applicable to the findings, corrections, recommendations, tradeoffs, and alternatives it substantively assessed. Incorporating the reviewer's own explicit finding, correction, or recommendation stays within that coverage and does not start another review. Rewording, reorganizing the packet, correcting facts identified by the reviewer, or applying the reviewer's prescribed remediation likewise does not create a new review obligation. This freshness rule never makes peer review mandatory and never makes reviewer agreement Build or Ship authority. Material drift always routes to Authorizing User direction under Adaptive Build And Material Drift. When the Authorizing User requested peer review and the final candidate introduces new, previously unassessed content within a material-drift category in Adaptive Build And Material Drift, material drift routes to Authorizing User direction first and any continued review covers only that delta. Otherwise the existing review remains applicable. Never send a reviewer's own recommendation back merely for endorsement; that adds no independent evidence. The primary agent independently verifies the evidence, adopts or rejects the recommendation, and surfaces any remaining disagreement to the Authorizing User. Retaining a user decision the reviewer already considered and opposed does not itself require another review. Preserve the user's decision and surface the unresolved objection; do not force reviewer agreement. Claude reviews an Expo migration plan and discovers that the destination Expo account is `racklessinc`, not `racklessit`. The primary agent independently verifies that fact and changes `EXPO_OWNER` to `racklessinc`. No delta review is needed because the correction originated in Claude's review and was already assessed there. A delta review would be appropriate only if the primary agent then introduced a new, unreviewed behavior—for example, changing credential ownership, environment-loading precedence, or release boundaries. ## Compact Post Contract A portable packet carries five compact sections, using these headings or natural equivalents: 1. **Objective / Evidence** 2. **Outcomes / Proof** 3. **Scope / Boundaries** 4. **Risks / Rules** 5. **Execution / QA** The sections record the objective and authority state, relevant facts, observable acceptance, material scope and non-goals, risk and repository constraints, current prerequisites, and enough QA intent to establish feasibility. Post repairs imperfect labels and presentation differences before Build. It does not require thirteen visible labels, thirteen repeated statuses, roadmap phrasing, future process data, exact files, exact commands, implementation tactics, or commit partitions. Managed Workspace PBS v1 retains its thirteen internal Business Brief identities only at the provider boundary. `workspace-pbs-enforcement.md` owns that mapping. Portable packets never expose those identities as a human checklist. ## Hard Blockers Admission blocks only for an implementation-, safety-, or authority-relevant deficiency: - missing Authorizing User authority for the objective - unresolved product decisions - absent observable acceptance outcomes - absent material scope or boundaries - contradictory scope, boundaries, or risk statements - unmet external prerequisites required now - unavailable command execution required to implement or prove the objective - failed required QA Missing roadmap wording, non-canonical section labels, optional review, reviewer/process metadata, future-stage process state, or explanations for unused optional gates are defaults or warnings. Presentation-only defects are repaired in Post and never deferred to Build. Every blocker diagnostic names the deficiency and the safety, authority, or implementation concern it creates. Do not convert uncertainty about an exact file, test command, tactic, or commit boundary into a blocker when Build can resolve it inside the outcome envelope. ## Public Admission Executable The package exposes: ```text pbs-admit [--file <path>] [--mode portable|managed] [--tier 1|2|3] [--json] ``` It reads packet text from `--file` or stdin and performs no filesystem writes, Git operations, or network calls. The default mode is `portable` and the default tier is `2`. JSON output is: ```json { "inputDigest": "sha256:<hex>", "mode": "portable", "tier": 2, "blockers": [], "warnings": [], "defaults": [] } ``` Exit `0` means no hard blocker, `1` means one or more blockers, and `2` means invalid invocation or unreadable input. The tool never diagnoses missing peer review, missing reviewer metadata, missing review receipts, or unused review gates. The digest normalizes only transport differences: a UTF-8 BOM, CRLF versus LF, trailing horizontal whitespace, and outer blank lines. It proves that participants received transport-equivalent packet text. It never proves approval, freshness, correctness, or launch authority. If `pbs-admit` is unavailable in an older consumer, Post and Build apply this reference directly. Executable absence is a compatibility condition, not a blocker. ## Adaptive Build And Material Drift The approved packet freezes the outcome envelope, not the implementation recipe. Build may change files, tactics, focused tests, commands, recovery mechanics, and narrative commit partitions while preserving the objective, observable acceptance, public contracts, material boundaries, and risk. Return to Post for Authorizing User direction only when a change materially affects: - intent or observable acceptance - a public API, schema, or protocol - security, privacy, data, migration, or release behavior - repository or runtime-dependency boundaries - risk tier Adding or correcting tests is adaptive. Weakening acceptance coverage, silently swallowing errors, or introducing suppressions is material unless already explicit in the approved outcome envelope. When work pauses, safe local narrative commits remain. The objective is `not shipped` until every accepted outcome and required QA result is complete. Resume under the same packet unless the outcome or risk changed.