@llblab/pi-actors 0.46.0 → 0.47.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +7 -5
- package/CHANGELOG.md +20 -0
- package/README.md +2 -1
- package/dist/lib/async-runs.d.ts +1 -0
- package/dist/lib/async-runs.js +4 -1
- package/dist/lib/execution.d.ts +1 -0
- package/dist/lib/execution.js +1 -0
- package/dist/lib/extension-runtime.js +25 -9
- package/dist/lib/inspector.js +1 -0
- package/dist/lib/prompts.d.ts +6 -5
- package/dist/lib/prompts.js +22 -23
- package/dist/lib/recipes-context.d.ts +12 -3
- package/dist/lib/recipes-context.js +28 -4
- package/dist/lib/recipes-discovery.d.ts +22 -0
- package/dist/lib/recipes-discovery.js +108 -23
- package/dist/lib/recipes-references.d.ts +18 -0
- package/dist/lib/recipes-references.js +129 -38
- package/dist/lib/registry.d.ts +23 -6
- package/dist/lib/registry.js +294 -101
- package/dist/lib/runtime.d.ts +30 -3
- package/dist/lib/runtime.js +108 -9
- package/dist/lib/tools-inspect.d.ts +3 -0
- package/dist/lib/tools-inspect.js +190 -26
- package/dist/lib/tools-local.d.ts +2 -2
- package/dist/lib/tools-local.js +5 -2
- package/dist/lib/tools-register.js +2 -1
- package/dist/lib/tools-response.js +7 -1
- package/dist/lib/tools-spawn.d.ts +2 -2
- package/dist/lib/tools-spawn.js +1 -1
- package/dist/lib/tools.d.ts +4 -1
- package/dist/lib/tools.js +2 -0
- package/dist/scripts/conformance.mjs +1 -0
- package/dist/skills/actors/SKILL.md +76 -65
- package/dist/skills/actors/references/diagnostics.md +44 -0
- package/dist/skills/actors/references/persistent-tools.md +74 -0
- package/dist/skills/actors/references/recipes.md +51 -0
- package/dist/skills/actors/references/runs.md +39 -0
- package/dist/skills/artifacts/SKILL.md +24 -7
- package/dist/skills/media/SKILL.md +35 -7
- package/dist/skills/project-work/SKILL.md +28 -7
- package/dist/skills/recipe-memory/SKILL.md +27 -7
- package/dist/skills/swarm/SKILL.md +41 -445
- package/dist/skills/swarm/references/development-swarm.md +87 -539
- package/dist/skills/swarm/references/review-swarms.md +115 -0
- package/docs/README.md +5 -5
- package/docs/recipe-library.md +15 -10
- package/docs/template-recipes.md +3 -1
- package/docs/tool-registry.md +18 -6
- package/lib/async-runs.ts +5 -1
- package/lib/execution.ts +2 -0
- package/lib/extension-runtime.ts +33 -14
- package/lib/inspector.ts +1 -0
- package/lib/prompts.ts +24 -24
- package/lib/recipes-context.ts +49 -4
- package/lib/recipes-discovery.ts +186 -25
- package/lib/recipes-references.ts +176 -44
- package/lib/registry.ts +441 -113
- package/lib/runtime.ts +147 -12
- package/lib/tools-inspect.ts +254 -28
- package/lib/tools-local.ts +9 -3
- package/lib/tools-register.ts +4 -3
- package/lib/tools-response.ts +7 -1
- package/lib/tools-spawn.ts +3 -2
- package/lib/tools.ts +4 -1
- package/package.json +1 -1
- package/scripts/conformance.mjs +1 -0
- package/skills/actors/SKILL.md +76 -65
- package/skills/actors/references/diagnostics.md +44 -0
- package/skills/actors/references/persistent-tools.md +74 -0
- package/skills/actors/references/recipes.md +51 -0
- package/skills/actors/references/runs.md +39 -0
- package/skills/artifacts/SKILL.md +24 -7
- package/skills/media/SKILL.md +35 -7
- package/skills/project-work/SKILL.md +28 -7
- package/skills/recipe-memory/SKILL.md +27 -7
- package/skills/swarm/SKILL.md +41 -445
- package/skills/swarm/references/development-swarm.md +87 -539
- package/skills/swarm/references/review-swarms.md +115 -0
|
@@ -1,104 +1,115 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: actors
|
|
3
|
-
description:
|
|
3
|
+
description: Use for any non-trivial pi-actors operation, diagnosis, or development involving Recipes, persistent tools, Runs, spawn, message, inspect, Trace, Control, capability specialization, or activation.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# Actors
|
|
6
|
+
# Actors
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
## Choose the operation
|
|
9
|
+
|
|
10
|
+
Start from the intended outcome:
|
|
9
11
|
|
|
10
12
|
```text
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
```
|
|
13
|
+
Run a maintained capability once
|
|
14
|
+
→ use spawn recipe=<skill>/<recipe>
|
|
14
15
|
|
|
15
|
-
|
|
16
|
+
Make a maintained capability a persistent agent-callable tool
|
|
17
|
+
→ use register_tool from=<skill>/<recipe>
|
|
16
18
|
|
|
17
|
-
|
|
19
|
+
Keep the same capability but narrow caller defaults
|
|
20
|
+
→ use register_tool from=<skill>/<recipe> defaults={...}
|
|
18
21
|
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
- `inspect`: inspect `run:<id>`, `runtime`, `recipes`, or `tool:<name>`.
|
|
22
|
-
- `register_tool`: persist a trusted capability; it does not address a running actor.
|
|
22
|
+
Register a trusted command directly
|
|
23
|
+
→ use register_tool template="..."
|
|
23
24
|
|
|
24
|
-
|
|
25
|
+
Build a reusable multi-node execution graph
|
|
26
|
+
→ author a Recipe with named imports
|
|
25
27
|
|
|
26
|
-
|
|
28
|
+
Run a long-lived controlled process
|
|
29
|
+
→ spawn its async Recipe, then use message and inspect
|
|
27
30
|
|
|
28
|
-
|
|
31
|
+
Coordinate several independent actors or subagents
|
|
32
|
+
→ also read the swarm Skill
|
|
29
33
|
|
|
30
|
-
|
|
34
|
+
Choose capability-specific behavior
|
|
35
|
+
→ read the owning capability Skill
|
|
31
36
|
|
|
32
|
-
|
|
37
|
+
Diagnose resolution, registration, or activation
|
|
38
|
+
→ use Inspect status/doctor flows and stop on contradictory evidence
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
Use [persistent tools](./references/persistent-tools.md), [Recipes](./references/recipes.md), [Runs](./references/runs.md), or [diagnostics](./references/diagnostics.md) only when the selected operation needs that detail.
|
|
33
42
|
|
|
34
|
-
##
|
|
43
|
+
## Core distinctions
|
|
35
44
|
|
|
36
|
-
|
|
45
|
+
Keep these boundaries explicit:
|
|
37
46
|
|
|
38
|
-
```
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
"data": {},
|
|
45
|
-
"level": "info",
|
|
46
|
-
"attention": "notify"
|
|
47
|
-
}
|
|
47
|
+
```text
|
|
48
|
+
Skill Recipe ≠ registered tool
|
|
49
|
+
spawn ≠ registered-tool invocation
|
|
50
|
+
persisted ≠ callable
|
|
51
|
+
direct delegation ≠ named import composition
|
|
52
|
+
Run Control ≠ actor chat
|
|
48
53
|
```
|
|
49
54
|
|
|
50
|
-
|
|
55
|
+
A Skill Recipe is a maintained component addressed by `<skill>/<recipe>`. `spawn` creates a Run from a Recipe. `register_tool` creates or updates a persistent user tool. A tool is callable in the current session only when activation evidence says `callable_now: true`.
|
|
51
56
|
|
|
52
|
-
|
|
57
|
+
`actors` owns generic Recipe/tool/Run mechanics. The owning capability Skill owns capability-specific selection and constraints. `swarm` owns multi-actor decomposition and integration methodology.
|
|
53
58
|
|
|
54
|
-
|
|
59
|
+
## Persistent capability workflow
|
|
55
60
|
|
|
56
|
-
|
|
57
|
-
|
|
61
|
+
To make `media/player` callable as `music_player` with a default source:
|
|
62
|
+
|
|
63
|
+
```text
|
|
64
|
+
register_tool
|
|
65
|
+
name=music_player
|
|
66
|
+
from=media/player
|
|
67
|
+
defaults={"source":"~/Music/1MIX"}
|
|
58
68
|
```
|
|
59
69
|
|
|
60
|
-
|
|
70
|
+
Then:
|
|
61
71
|
|
|
62
|
-
|
|
72
|
+
1. Require registration to report successful resolution, validation, persistence, registry admission, host registration, activation, and `callable_now: true`.
|
|
73
|
+
2. Call the actual `music_player` tool. Do not call `spawn` and describe that as tool invocation.
|
|
74
|
+
3. Verify agent-facing evidence reports `launch_kind: "tool"`; use `inspect target=tool:music_player view=status` when usage or activation needs confirmation.
|
|
75
|
+
4. If callability is false, stop at the reported activation boundary. Preserve the logical source and diagnose it; do not substitute a Recipe spawn as proof.
|
|
63
76
|
|
|
64
|
-
|
|
77
|
+
Use direct delegation for the same maintained capability under a persistent name or narrower defaults. Use named imports only when one Recipe graph contains reusable child nodes. See [persistent tools](./references/persistent-tools.md) and [Recipes](./references/recipes.md).
|
|
65
78
|
|
|
66
|
-
Run
|
|
79
|
+
## Run workflow
|
|
67
80
|
|
|
68
|
-
|
|
69
|
-
- `trace.jsonl`: structured observations.
|
|
70
|
-
- `controls.jsonl`: durable actor-local inputs and outcomes.
|
|
71
|
-
- `control-endpoint.json`: generation-fenced service readiness.
|
|
72
|
-
- `execution.json`: command/session provenance and bounded complete-capture references.
|
|
73
|
-
- `result.json`, logs, and declared artifacts.
|
|
81
|
+
A Run is one concrete execution of a Recipe:
|
|
74
82
|
|
|
75
|
-
|
|
83
|
+
```text
|
|
84
|
+
Recipe --spawn--> Run
|
|
85
|
+
Run = Recipe + Trace + Control
|
|
86
|
+
```
|
|
76
87
|
|
|
77
|
-
|
|
88
|
+
1. Spawn with the exact logical Recipe identity and caller-owned values.
|
|
89
|
+
2. Retain the returned `run:<id>` and normally wait for terminal follow-up instead of polling.
|
|
90
|
+
3. Inspect `view=trace` when retained observations or attention matter.
|
|
91
|
+
4. Inspect `view=control` before diagnosing service readiness, stale work, or saturation.
|
|
92
|
+
5. Send `message` only for an action declared and consumed by that controlled Recipe.
|
|
93
|
+
6. Use terminal state, result, declared artifacts, and execution evidence to prove completion.
|
|
78
94
|
|
|
79
|
-
|
|
95
|
+
A Run exposes only `recipe`, `trace`, and `control` views. Control is bounded actor-local input, not peer messaging or chat. See [Runs](./references/runs.md).
|
|
80
96
|
|
|
81
|
-
|
|
82
|
-
2. Spawn with explicit values and retain the returned `run:<id>`.
|
|
83
|
-
3. Let short Runs finish; avoid polling.
|
|
84
|
-
4. Inspect Trace when evidence or attention requires it; its summary states whether retained history is complete.
|
|
85
|
-
5. Inspect Control capacity before diagnosing stale work or saturation, then send only declared actor-local Controls.
|
|
86
|
-
6. Use runtime kill/cancel behavior for lifecycle termination.
|
|
87
|
-
7. Inspect artifacts and execution evidence for final validation.
|
|
97
|
+
## Diagnosis and stop rules
|
|
88
98
|
|
|
89
|
-
|
|
99
|
+
When a pi-actors operation fails:
|
|
90
100
|
|
|
91
|
-
|
|
101
|
+
1. Keep the intended logical Recipe or tool identity.
|
|
102
|
+
2. Inspect the existing `recipes`, `tool:<name>`, `runtime`, or `run:<id>` surface that owns the failure.
|
|
103
|
+
3. Report resolver, registry, activation, Run, Trace, or Control truth exactly.
|
|
104
|
+
4. Retry only after the owning state is healthy.
|
|
92
105
|
|
|
93
|
-
|
|
94
|
-
- [Quorum review](../swarm/recipes/quorum-review.json)
|
|
95
|
-
- [Artifact bundle](../artifacts/recipes/bundle.json)
|
|
96
|
-
- [Music player service](../media/recipes/player.json)
|
|
97
|
-
- [Resource locker service](./recipes/resource-locker.json)
|
|
106
|
+
Stop if spawn and registry resolve the same Recipe differently. Stop if registration persists but is not callable. Stop if an operation cannot be proven through pi-actors surfaces.
|
|
98
107
|
|
|
99
|
-
|
|
108
|
+
Never recover by copying maintained Recipe args, defaults, Control, artifacts, or helper commands. Never hard-code a `{skill_dir}` replacement path. Never introduce `bash -lc`, `eval`, direct bundled-helper execution, or shell backgrounding to bypass resolution. Never call `spawn` and claim a tool call. Use [diagnostics](./references/diagnostics.md) for the safe next action.
|
|
100
109
|
|
|
101
|
-
|
|
102
|
-
- [Async Runs](../../docs/async-runs.md)
|
|
110
|
+
## When to read another Skill
|
|
103
111
|
|
|
104
|
-
Read
|
|
112
|
+
- Read the owning capability Skill when choosing or operating that capability pack.
|
|
113
|
+
- Read `swarm` in addition to `actors` for multiple actors/subagents, parallel scopes, reviewer lenses, quorum, conflict handling, or integration.
|
|
114
|
+
- For generic mechanics, this Skill outranks capability Skills and `swarm`. Report a stale Skill if it contradicts Recipe identity, registration, activation, spawn, Inspect, Trace, or Control semantics here.
|
|
115
|
+
- When changing the extension implementation itself, apply project implementation instructions after this operating protocol.
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
# Diagnostics
|
|
2
|
+
|
|
3
|
+
Preserve the intended logical identity and diagnose through public pi-actors surfaces. Do not inspect raw registry files or implementation source as the normal first response.
|
|
4
|
+
|
|
5
|
+
## Recipe resolution or catalog failure
|
|
6
|
+
|
|
7
|
+
```text
|
|
8
|
+
inspect target=recipes view=status
|
|
9
|
+
inspect target=recipes view=doctor identity=<skill>/<recipe>
|
|
10
|
+
```
|
|
11
|
+
|
|
12
|
+
Use the focused doctor form for one intended identity. It reports active-Skill ownership, exact resolvability, partial-catalog state, component status, portable source location, resolution generation, any rejection, and bounded next actions. Use the unfiltered doctor only for catalog-wide diagnosis. A partial catalog does not imply every exact component is unavailable. If the owning Skill is inactive, report that blocker rather than locating and running its helper manually.
|
|
13
|
+
|
|
14
|
+
## Persistent tool failure
|
|
15
|
+
|
|
16
|
+
```text
|
|
17
|
+
inspect target=tool:<name> view=status
|
|
18
|
+
inspect target=tool:<name> view=schema
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
Distinguish persistence, registry admission, host registration, active-tool membership, and `callable_now`. Confirm the source identity, effective caller schema, separate tool/spawn usage, and last launch kind when exposed.
|
|
22
|
+
|
|
23
|
+
If persistence succeeded but callability is false, do not use `spawn` and claim the tool worked. Follow the reported activation boundary or stop.
|
|
24
|
+
|
|
25
|
+
## Run failure
|
|
26
|
+
|
|
27
|
+
```text
|
|
28
|
+
inspect target=run:<id> view=recipe
|
|
29
|
+
inspect target=run:<id> view=trace
|
|
30
|
+
inspect target=run:<id> view=control
|
|
31
|
+
inspect target=runtime view=status
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Use Recipe view for captured identity/launch evidence, Trace for bounded observations, Control for readiness/capacity/stale work, and runtime status for kernel-level health. Treat retained-history completeness honestly.
|
|
35
|
+
|
|
36
|
+
## Safe failure protocol
|
|
37
|
+
|
|
38
|
+
1. Keep the exact intended Recipe/tool/Run identity.
|
|
39
|
+
2. Identify the owning public surface.
|
|
40
|
+
3. Record exact resolver, registry, activation, or Run truth.
|
|
41
|
+
4. Apply only the bounded next action returned by that owner.
|
|
42
|
+
5. Retry only after the owning state is healthy.
|
|
43
|
+
|
|
44
|
+
Stop if evidence remains contradictory or the requested operation cannot be proven. Never recover by copying maintained contracts, hard-coding installation paths, directly executing bundled helpers, adding `bash -lc` or `eval`, shell-backgrounding work, editing unrelated Skills, or relabeling a Recipe spawn as a tool call.
|
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
# Persistent Tools
|
|
2
|
+
|
|
3
|
+
Use a persistent tool when the agent should call a trusted capability by name across turns or sessions. Use `spawn` instead for one-off Recipe execution.
|
|
4
|
+
|
|
5
|
+
## Choose one source mode
|
|
6
|
+
|
|
7
|
+
```text
|
|
8
|
+
Maintained or explicit-file Recipe
|
|
9
|
+
→ register_tool from=<skill>/<recipe|path.json|path.md>
|
|
10
|
+
|
|
11
|
+
Trusted command template
|
|
12
|
+
→ register_tool template="..."
|
|
13
|
+
|
|
14
|
+
Reviewed captured draft
|
|
15
|
+
→ register_tool draft=<draft-path>
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
Do not mix source modes.
|
|
19
|
+
|
|
20
|
+
## Specialize a maintained Recipe
|
|
21
|
+
|
|
22
|
+
```text
|
|
23
|
+
register_tool
|
|
24
|
+
name=music_player
|
|
25
|
+
from=media/player
|
|
26
|
+
defaults={"source":"~/Music/1MIX"}
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
`from` means logical direct delegation. The source remains authoritative for async behavior, caller args and types, source defaults, artifacts, Control, and runtime-owned origins. The persistent user Recipe stores only the compact specialization; do not copy inherited fields.
|
|
30
|
+
|
|
31
|
+
Use `description` to narrow agent-facing intent when useful. Every supplied default must name a caller-owned source arg and satisfy its type or enum. Never default runtime-owned origins.
|
|
32
|
+
|
|
33
|
+
## Prove registration
|
|
34
|
+
|
|
35
|
+
Read registration as a state transition, not one success word:
|
|
36
|
+
|
|
37
|
+
```text
|
|
38
|
+
resolved
|
|
39
|
+
→ validated
|
|
40
|
+
→ persisted
|
|
41
|
+
→ registry_active
|
|
42
|
+
→ host_registered
|
|
43
|
+
→ active_tool
|
|
44
|
+
→ callable_now
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
When `callable_now` is true, call the actual generated tool and verify `launch_kind: "tool"` when provenance matters. When false, stop at the reported activation boundary and use tool/Recipe diagnosis. A Recipe spawn is not an activation test or tool invocation substitute.
|
|
48
|
+
|
|
49
|
+
Use:
|
|
50
|
+
|
|
51
|
+
```text
|
|
52
|
+
inspect target=tool:<name> view=status
|
|
53
|
+
inspect target=tool:<name> view=schema
|
|
54
|
+
inspect target=recipes view=doctor
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
## Command templates
|
|
58
|
+
|
|
59
|
+
Use `template` only for a trusted command definition, not to make the agent guess whether a string is command text or Recipe delegation. Give raw command tools an agent-facing description and declare or infer only caller-owned args. Use a Recipe file when reusable composition or lifecycle policy is needed.
|
|
60
|
+
|
|
61
|
+
## Updates and deletion
|
|
62
|
+
|
|
63
|
+
Use `update=true` only for an intentional replacement. Preserve the existing capability when candidate resolution, validation, persistence, or activation fails. Use the compact deletion form documented by the live `register_tool` schema; do not create a second deletion mechanism.
|
|
64
|
+
|
|
65
|
+
## Stop rules
|
|
66
|
+
|
|
67
|
+
Stop rather than:
|
|
68
|
+
|
|
69
|
+
- copying source Recipe args, defaults, artifacts, Control, or helper command;
|
|
70
|
+
- invoking a Skill helper by installation path;
|
|
71
|
+
- using `spawn` and claiming the tool was called;
|
|
72
|
+
- treating persistence as callability;
|
|
73
|
+
- adding shell evaluation or backgrounding to bypass registration;
|
|
74
|
+
- editing an unrelated rejected Skill component unless that repair is explicitly requested.
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# Recipes
|
|
2
|
+
|
|
3
|
+
A Recipe is a reusable executable definition. Address a maintained component as `<active-skill>/<direct-filename-stem>` or use an explicit `.json` / `.md` path. Recipe files do not declare their own top-level `name`.
|
|
4
|
+
|
|
5
|
+
## Direct delegation
|
|
6
|
+
|
|
7
|
+
Use direct delegation when the root remains fundamentally the same capability under a different persistent name, description, or caller default:
|
|
8
|
+
|
|
9
|
+
```text
|
|
10
|
+
media/player
|
|
11
|
+
→ music_player with a default source
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
For agent-facing persistent specialization, use:
|
|
15
|
+
|
|
16
|
+
```text
|
|
17
|
+
register_tool from=media/player defaults={"source":"~/Music/1MIX"}
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
The delegated root inherits async behavior, args and types, defaults, artifacts, Control, and runtime-owned origins. Do not copy those fields into the wrapper.
|
|
21
|
+
|
|
22
|
+
## Named import composition
|
|
23
|
+
|
|
24
|
+
Use imports when authoring a graph with reusable named nodes:
|
|
25
|
+
|
|
26
|
+
```json
|
|
27
|
+
{
|
|
28
|
+
"imports": {
|
|
29
|
+
"review": "swarm/quorum-review",
|
|
30
|
+
"report": "artifacts/report"
|
|
31
|
+
},
|
|
32
|
+
"template": [
|
|
33
|
+
{ "name": "review" },
|
|
34
|
+
{ "name": "report" }
|
|
35
|
+
]
|
|
36
|
+
}
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
Imports are local definitions inside one execution graph. An imported child does not automatically make its Control contract the root Run's Control contract. Do not use imports merely to wrap one Recipe with defaults.
|
|
40
|
+
|
|
41
|
+
## Caller and runtime ownership
|
|
42
|
+
|
|
43
|
+
Callers provide only the effective public args. The runtime owns Recipe/Skill location, Run state, Trace, generation, owner/session, and related execution origins. Never declare, default, or override runtime-owned inputs.
|
|
44
|
+
|
|
45
|
+
Keep selected model, thinking, mission, concurrency, quorum, and timeout caller-owned unless the capability Skill documents stable policy.
|
|
46
|
+
|
|
47
|
+
## Resolution behavior
|
|
48
|
+
|
|
49
|
+
Exact resolution uses the current immutable session Skill context. An invalid unrelated component may make catalog inventory partial, but it must not block an unrelated exact valid identity. A disabled, missing, ambiguous, or changed target fails closed without ambient fallback.
|
|
50
|
+
|
|
51
|
+
If direct spawn and persistent admission disagree for the same identity, stop and diagnose. Do not switch to an absolute helper path, copy the source contract, or execute the helper directly.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Runs
|
|
2
|
+
|
|
3
|
+
Use a Run when execution may outlive the current turn, needs declared Control, produces retained artifacts/evidence, fans out, or must remain inspectable.
|
|
4
|
+
|
|
5
|
+
## Launch
|
|
6
|
+
|
|
7
|
+
```text
|
|
8
|
+
spawn recipe=<skill>/<recipe> values={...} as=run:<id>
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
Use the owning capability Skill to choose the Recipe and capability-specific values. Retain the returned Run id. A spawn result reports `launch_kind: "spawn"`; it is never evidence of registered-tool invocation.
|
|
12
|
+
|
|
13
|
+
## Observe
|
|
14
|
+
|
|
15
|
+
Normally wait for terminal follow-up. Inspect only when requested, when meaningful attention arrives, or when the Run is overdue or blocked:
|
|
16
|
+
|
|
17
|
+
```text
|
|
18
|
+
inspect target=run:<id> view=recipe
|
|
19
|
+
inspect target=run:<id> view=trace
|
|
20
|
+
inspect target=run:<id> view=control
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Trace is bounded retained observation, so read its completeness summary. Prove final outcomes with terminal status, result, declared artifacts, and execution evidence rather than assuming retained Trace is exhaustive.
|
|
24
|
+
|
|
25
|
+
## Control
|
|
26
|
+
|
|
27
|
+
Send an actor-local action only when the root Recipe declares and implements it:
|
|
28
|
+
|
|
29
|
+
```text
|
|
30
|
+
message target=run:<id> action=<declared-action> input={...}
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Inspect Control when readiness, capacity, stale work, or saturation matters. Put large data in an artifact and send only a bounded reference or instruction. Use runtime-owned termination for a stuck Run rather than inventing undeclared service actions.
|
|
34
|
+
|
|
35
|
+
Control is not actor chat, peer routing, or a task inbox. A Recipe import does not create a peer actor. Several actors/subagents require the `swarm` methodology in addition to these Run mechanics.
|
|
36
|
+
|
|
37
|
+
## Safety
|
|
38
|
+
|
|
39
|
+
Operate only on owned Runs and their active generation. Never edit Run state to force an outcome, bypass process identity checks, or signal processes directly from UI/instruction code. Restart creates new generation-local evidence; inspect the exact generation before destructive lifecycle action.
|
|
@@ -1,16 +1,33 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: artifacts
|
|
3
|
-
description:
|
|
3
|
+
description: Use when an actor workflow must write reusable files, reports, manifests, or bundles with deterministic paths and declared outputs.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Artifacts
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Use this Skill after the desired durable-output outcome is known. For generic Recipe execution, Runs, persistence, or diagnosis, follow `actors`; this Skill only selects artifact behavior.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Choose the outcome
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
-
|
|
12
|
+
| Desired outcome | Recipe | Result |
|
|
13
|
+
| --- | --- | --- |
|
|
14
|
+
| Write one generated artifact and a machine-readable manifest, with optional validation first | `artifacts/bundle` | Primary artifact plus manifest |
|
|
15
|
+
| Generate bounded normalized report content without committing a filesystem write | `artifacts/report` | Report content for review or later composition |
|
|
16
|
+
| Generate and write one artifact | `artifacts/write` | Declared artifact path written with explicit mode |
|
|
17
|
+
| Describe one existing or intended artifact | `artifacts/manifest` | Manifest JSON on stdout; no write |
|
|
18
|
+
| Write prior pipeline output exactly | `artifacts/file-write` | Supporting stdin-to-file write; normally use inside composition |
|
|
15
19
|
|
|
16
|
-
|
|
20
|
+
Prefer `bundle` when both durable content and inventory evidence are required. Prefer `write` for one accepted file. Use `report` while content still needs review. Do not use `file-write` as a content generator. If one selected outcome should become a recurring named tool, use the persistent-capability workflow in `actors`; do not copy its graph.
|
|
21
|
+
|
|
22
|
+
## Inputs and boundaries
|
|
23
|
+
|
|
24
|
+
- Keep `input` bounded and evidence-based; choose the current model explicitly where the Recipe requires `model`.
|
|
25
|
+
- Supply caller-owned `artifact_path` and, for `bundle`, a distinct `manifest_path`.
|
|
26
|
+
- `write_mode=create` is the safe default and stops if the target exists. Use `overwrite` or `append` only when the requested mutation is explicit.
|
|
27
|
+
- Parent directories are created by the writer. `~` is resolved for artifact paths.
|
|
28
|
+
- `manifest` reports existence, size, and modification evidence; it does not validate artifact meaning.
|
|
29
|
+
- Validation in `bundle` runs only when `run_validation=true` and uses the caller-supplied trusted command and scope.
|
|
30
|
+
|
|
31
|
+
## Stop rules
|
|
32
|
+
|
|
33
|
+
Stop rather than guessing when the target path, overwrite policy, accepted content, model, or validation command is unclear. Do not claim a durable artifact from `report` or `manifest` alone. After a Run starts, use the `actors` evidence and lifecycle protocol; this Skill does not redefine it.
|
|
@@ -1,16 +1,44 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: media
|
|
3
|
-
description:
|
|
3
|
+
description: Use for local media discovery, filtering, library summaries, playlist construction, or controllable playback.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Media
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Use this Skill for caller-selected local media. For generic Recipe execution, persistent-tool setup, Run lifecycle, or diagnosis, follow `actors`; this Skill only selects media behavior.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Choose the operation
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
12
|
+
| Intent | Recipe | Use when |
|
|
13
|
+
| --- | --- | --- |
|
|
14
|
+
| Start or control playback | `media/player` | A local file, directory, or playlist should become a controlled service |
|
|
15
|
+
| Build a library summary | `media/library` | A filtered playlist should feed bounded report content |
|
|
16
|
+
| Build a filtered playlist | `media/playlist-build` | Extension filtering and `paths`, `m3u`, or `inline` output are required |
|
|
17
|
+
| Scan a directory for raw file paths | `media/playlist-scan` | A shallow unfiltered inventory is intentionally sufficient |
|
|
15
18
|
|
|
16
|
-
|
|
19
|
+
Use `playlist-build` rather than `playlist-scan` for normal media selection. `library` composes playlist output into report content; its `artifact_path` identifies the intended report target but does not by itself prove a durable write.
|
|
20
|
+
|
|
21
|
+
## Controlled playback
|
|
22
|
+
|
|
23
|
+
`media/player` is an async controlled service. Start one owned Run, then use only its declared actions: `play`, `pause`, `resume`, `toggle`, `next`, `previous`, `stop`, and `status`.
|
|
24
|
+
|
|
25
|
+
```text
|
|
26
|
+
spawn recipe=media/player as=run:music values={"source":"~/Music","player":"auto"}
|
|
27
|
+
message target=run:music action=pause
|
|
28
|
+
inspect target=run:music view=control
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
For recurring playback as a persistent callable tool, use the persistent-capability workflow in `actors` with `from=media/player`; do not copy the player contract.
|
|
32
|
+
|
|
33
|
+
## Paths and selection
|
|
34
|
+
|
|
35
|
+
- `source` for playback must name caller-approved local media; do not broaden it to unrelated directories.
|
|
36
|
+
- `source_dir` must be an intended readable directory. `~` is accepted by maintained media helpers.
|
|
37
|
+
- Keep `max_depth` bounded. Use explicit comma-separated extensions for `playlist-build` and `library`.
|
|
38
|
+
- Choose `output_mode=m3u` only when playlist text is wanted; it does not create a playlist file.
|
|
39
|
+
- Choose an explicit `artifact_path` and model for `library` report generation.
|
|
40
|
+
- `player=auto` selects an available supported backend; do not install or substitute a player silently.
|
|
41
|
+
|
|
42
|
+
## Stop rules
|
|
43
|
+
|
|
44
|
+
Stop if the source is missing, unreadable, contains no selected media, or no supported player is available. Do not claim playback from process start alone; confirm through Run evidence or `status`. Prefer the declared `stop` action for a responsive player. If the service is unresponsive, return to `actors` for bounded Run recovery rather than shell process control.
|
|
@@ -1,16 +1,37 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: project-work
|
|
3
|
-
description:
|
|
3
|
+
description: Use for repository health inspection, project summaries, documentation maintenance, release-readiness evidence, or bounded run-operation reports.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Project Work
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Use this Skill to produce bounded project evidence and plans. For generic Recipe execution, Run lifecycle, persistence, or multi-actor methodology, follow `actors` and, when applicable, `swarm`; this Skill only selects project workflows.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Choose the primary workflow
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
12
|
+
| Intended result | Recipe | Boundary |
|
|
13
|
+
| --- | --- | --- |
|
|
14
|
+
| Repository status, recent history, docs surface, validation, and risks | `project-work/repo-health` | Runs the caller-supplied trusted validation command |
|
|
15
|
+
| Documentation consistency review and maintenance plan | `project-work/docs-maintenance` | Evidence and plan only; does not edit documentation |
|
|
16
|
+
| Multi-lens release verdict with blockers and degraded-confidence evidence | `project-work/release-readiness` | Readiness only; does not publish |
|
|
17
|
+
| Evidence-only release summary and PR-body draft | `project-work/release-summary` | No commit, PR, merge, tag, publish, or external release action |
|
|
18
|
+
| Bounded report over existing actor Run state | `project-work/run-ops` | Read-only report; does not send Control or mutate Runs |
|
|
15
19
|
|
|
16
|
-
|
|
20
|
+
Choose `release-readiness` when independent review and a release verdict are needed. Choose `release-summary` when the evidence is already sufficient and only a concise operator-gated summary is wanted. If one primary workflow should become a recurring named tool, use the persistent-capability workflow in `actors`; do not copy its composition.
|
|
21
|
+
|
|
22
|
+
## Inputs and evidence
|
|
23
|
+
|
|
24
|
+
- Scope every workflow to the caller-selected repository, docs directory, or Run state.
|
|
25
|
+
- Treat `validation_command` as trusted executable input. Do not invent or broaden it.
|
|
26
|
+
- Select current model policy explicitly for workflows that request a model; release-readiness reviewer roles inherit only the values supplied by the caller.
|
|
27
|
+
- Artifact paths identify intended report targets. Confirm actual declared artifact evidence before claiming a durable file.
|
|
28
|
+
- Preserve degraded or insufficient review status. Never turn partial reviewer output into consensus.
|
|
29
|
+
- Release outputs are evidence, not publication authority.
|
|
30
|
+
|
|
31
|
+
## Supporting Recipes
|
|
32
|
+
|
|
33
|
+
`git-status`, `git-log`, `changelog-head`, `changelog-section`, `markdown-index`, `package-summary`, and `skill-summary` support the primary workflows. Use one directly only when its narrow deterministic output is the requested result; otherwise start from a primary workflow and avoid rebuilding its composition manually.
|
|
34
|
+
|
|
35
|
+
## Stop rules
|
|
36
|
+
|
|
37
|
+
Stop when repository scope, version, validation command, model policy, or write target is ambiguous. Do not edit docs from a `docs-maintenance` plan, publish from release evidence, or send Run Controls from `run-ops`. Hand those operations to their owning protocol after explicit authorization.
|
|
@@ -1,16 +1,36 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: recipe-memory
|
|
3
|
-
description:
|
|
3
|
+
description: Use only for internal automatic Recipe-memory review, diagnosis, or recovery; do not use for normal Recipe creation, registration, or invocation.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Recipe Memory
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Use this Skill only when automatic draft-memory or active-tool review needs diagnosis or bounded recovery. Normal agents must not spawn, register, specialize, or invoke `recipe-memory/draft-review` or `recipe-memory/tool-review`; they are package-owned internal reviewer components.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Diagnose first
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
12
|
+
```text
|
|
13
|
+
inspect target=recipes view=reviews
|
|
14
|
+
inspect target=runtime view=triage
|
|
15
|
+
```
|
|
15
16
|
|
|
16
|
-
|
|
17
|
+
Use the review view to distinguish `draft` and `tool` scope, current phase, failed stage, bounded error, preserved transaction evidence, and the recorded next action. Use runtime triage only when the reviewer Run itself needs Run-level diagnosis. Follow `actors` for generic Inspect, Run, and Control semantics.
|
|
18
|
+
|
|
19
|
+
## Recovery Controls
|
|
20
|
+
|
|
21
|
+
Use runtime Controls only when the review evidence names the matching recovery action:
|
|
22
|
+
|
|
23
|
+
```text
|
|
24
|
+
message target=runtime action=review.retry input={"scope":"draft"}
|
|
25
|
+
message target=runtime action=review.retry input={"scope":"tool"}
|
|
26
|
+
message target=runtime action=review.reset input={"scope":"draft"}
|
|
27
|
+
message target=runtime action=review.reset input={"scope":"tool"}
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
- `review.retry` resumes the selected failed review scope while preserving authenticated transaction recovery.
|
|
31
|
+
- `review.reset` clears disposable failure state only. It must reject evidence that requires roll-forward recovery.
|
|
32
|
+
- Re-inspect `view=reviews` after one recovery Control; do not loop retries or resets without changed evidence.
|
|
33
|
+
|
|
34
|
+
## Stop rules
|
|
35
|
+
|
|
36
|
+
Stop when the phase is healthy or idle, the requested scope does not match the failure, recovery evidence requires deterministic roll-forward, or the reported next action is not retry/reset. Never edit review state, lineage, journals, quarantine, drafts, or persisted Recipes directly. Never bypass automatic review by running its internal Recipes as ordinary capabilities.
|