UNPKG

@crossplatformai/skills

Version:

Reusable Agent Skills for CrossPlatform.ai projects.

github.com/crossplatformai/framework

crossplatformai/framework

123 lines (91 loc) • 6.66 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
# Quality Assurance This reference is the canonical QA selection, reuse, invalidation, and receipt policy for Post.Build.Ship. QA is proportionate to the completed diff and risk surface. Repository launchers are an inventory, not an unconditional instruction to run every command. ## Three QA Moments 1. **Minimum preflight** — run only for genuine dependency, environment, toolchain, or known-baseline uncertainty that could waste implementation effort. 2. **Focused feedback** — run during implementation when a narrow check shortens the feedback loop. 3. **Authoritative final QA** — select one complete manifest from the final diff, acceptance proof, and risk surface before Ship. No step runs merely because a commit was created. No peer review is required before or after QA. ## Command Selection Inspect repository instructions and launchers first, then select commands deliberately. Load `@crossplatformai/skills#test-layer-fit` when the question is test placement, integration-suite reachability, or deterministic harness ownership. The authoritative QA command manifest must still reach every changed runnable surface, and specification gaming remains prohibited. - Tier 1 generally needs formatting or link/structure validation for the changed documentation plus `git diff --check`. - Tier 2 generally needs affected lint, typecheck, and focused tests, widening to package or workspace commands when dependency resolution or shared configuration is affected. - Tier 3 generally needs the complete relevant package baseline and broader workspace or consumer proof when publication, schema, distribution, security, or external behavior creates that reach. Include generated-skill validation, pack inspection, native builds, e2e, install verification, or consumer checks only when the changed surface or acceptance outcomes require them. A complete repository baseline is required only when breadth or external risk genuinely needs it. Failed selected commands are blocking. `unavailable` means a required script, tool, host capability, or external prerequisite cannot run now; it is not a synonym for inconvenient or slow. Skips and exclusions need a reason tied to the actual diff. A failed required command remains blocking. A passed receipt may be reused only under the invalidation rules below. Select one mandatory final QA sequence for the objective, not one per commit. Run scoped integration tests when an external adapter or real integration seam changes. ## Reuse And Invalidation A passing result stays reusable until something relevant to that result changes. Re-run the affected portion of QA after a change to: - source or test code covered by the check - dependencies or lockfiles - configuration or environment consumed by the check - toolchain versions or invocation semantics - fixtures, snapshots, or test data - generated output used by the check - runtime state that changes the behavior being proven A Git add, reset of staging metadata, commit, reword, tag, branch label, or other content-preserving Git operation does not invalidate QA. A source change invalidates only checks whose proof surface it can affect; it does not automatically erase unrelated evidence. When QA, a repository formatter, or a commit-time hook changes content—format fixes, snapshots, generated files, lockfiles, or other source artifacts—classify the mutation, review it, and rerun only the manifest portions it invalidates. ## Candidate Form Barrier Before recording the authoritative final QA manifest, settle the candidate form on every path the current task owns. Owned paths must already contain the form the commit will produce, including any repository-approved formatting that applies. Use explicit path-scoped arguments for the repository- approved formatter or formatter check. A formatter write is permitted only when every affected path is wholly owned by the current task. For a mixed-ownership path, use a non-mutating, path-scoped check only. Never format, stage, or run a staging/index-scoped hook for that path. If the check reports a mismatch, stop and report the path and required owner action rather than proceeding to the final manifest. This barrier is a property of the candidate, not a formatter receipt or timestamp; staging and index-scoped hook execution are not part of this step. ## Candidate Reopening After the Candidate Form Barrier, a later mutation covered by the existing invalidator set reopens settlement only for affected paths and the QA evidence covering those paths. Unaffected paths retain their settlement and evidence. Mixed-ownership paths re-enter the non-mutating, path-scoped check-only path; they never become formatter-write or index-hook proof. Reopening never automatically escalates to a complete manifest or repository baseline. Content-preserving Git operations do not reopen settlement. Post-commit hook mutations continue to follow the existing Ship mutation rule: classify the content change and rerun only the invalidated manifest portions before treating the tree as final. ## Delegated QA Delegation is useful when a command-capable process can own long raw logs or run independently. When used, prefer one process for the objective. Keep raw output in that process and exchange compact receipts. Do not require a delegated process when the current agent can safely and visibly execute the commands. A compact receipt records: - command and working directory - exit code or explicit unavailable/skipped state - result and short failure excerpt when applicable - content-mutation classification - raw log location when one exists The implementing agent selects the manifest and judges sufficiency. A QA process reports command facts; its identity or availability is not approval authority. ## Final QA Manifest Immediately before final QA, inspect the completed diff and record the authoritative command list and why it covers the acceptance and risk surface. Reuse still-valid earlier results and run only the missing or invalidated commands. Afterward, inspect fresh status and classify any mutation. Ship verifies that the manifest is sufficient, passing, current, and corresponds to the final tree. If a required command fails or cannot run, report the command, exit code or unavailable reason, useful excerpt, suspected cause when grounded, and next safe action. Do not label the objective shipped. Generated database migration commands and package publication remain user-owned even when broader QA would normally include them. Apply the dedicated migration and temporary-link policies instead of silently crossing those boundaries.