UNPKG

@crossplatformai/skills

Version:

Reusable Agent Skills for CrossPlatform.ai projects.

github.com/crossplatformai/framework

crossplatformai/framework

50 lines (34 loc) • 2.44 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
# Subagent Delegation Use this reference when `post`, `build`, or `ship` delegates bounded exploration, implementation, factual checking, optional peer review, or QA. ## Terms - A **same-runtime subagent** is a worker created inside the current runtime. - A **cross-runtime agent** runs in another visible provider or agent surface. - A **QA process** is a visible command-capable worker that retains raw command output. - A **peer reviewer** is an optional advisory collaborator requested by the Authorizing User. These terms describe execution, not authority. No delegated agent can manufacture Authorizing User approval. ## Bounded Brief Every delegation names the repository, concrete subtask, relevant evidence, ownership boundaries, allowed mutations, validation limits, prohibited release/migration/link actions, expected output, and stop condition. Implementation helpers do not stage or commit unless explicitly assigned a coherent owned partition. The primary agent verifies material findings and owns synthesis, scope, QA sufficiency, drift, and Ship readiness. A summary is not a substitute for evidence the primary needs to rely on. ## Parallel And Nested Work Use parallel workers only for independent tasks with clear hunk ownership. A delegated coordinator may absorb routine worker logs and report milestones, but nesting does not expand authority or mutation scope. Preserve user and other-agent work at hunk level. ## Optional Cross-Runtime Perspective Launch a peer reviewer only when the Authorizing User explicitly requests review. If the requested route is unavailable, report that fact and continue unless the Authorizing User made that exact route part of the objective. Do not silently substitute and call it the requested review. Record useful review findings that affected the work. Reviewer identity, model, process lifecycle, receipt, digest, availability proof, and verdict are never Build or Ship admission requirements. Never send a reviewer's own recommendation back merely for re-endorsement; if review continues after material drift routes to Authorizing User direction, it covers only new, previously unassessed substance. ## QA When delegated QA is useful, prefer one command-capable visible process for the objective. Keep raw logs there and return the compact receipts in `quality-assurance.md`. The primary agent still selects the manifest and decides what evidence remains reusable.