@adelie/agent-development 0.0.0-stage → 0.4.2
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/LICENSE +201 -0
- package/icon.svg +6 -0
- package/package.json +18 -3
- package/plugin.json +8 -0
- package/skills/penguin-config/SKILL.md +72 -0
- package/skills/penguin-orchestration/SKILL.md +162 -0
- package/skills/penguin-sdk/SKILL.md +536 -0
- package/skills/penguin-sdk/reference/agent-api.md +159 -0
- package/skills/unified-llm-api/SKILL.md +198 -0
- package/README.md +0 -3
package/LICENSE
ADDED
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work
|
|
38
|
+
(an example is provided in the Appendix below).
|
|
39
|
+
|
|
40
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
41
|
+
form, that is based on (or derived from) the Work and for which the
|
|
42
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
43
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
44
|
+
of this License, Derivative Works shall not include works that remain
|
|
45
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
46
|
+
the Work and Derivative Works thereof.
|
|
47
|
+
|
|
48
|
+
"Contribution" shall mean any work of authorship, including
|
|
49
|
+
the original version of the Work and any modifications or additions
|
|
50
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
51
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
52
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
53
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
54
|
+
means any form of electronic, verbal, or written communication sent
|
|
55
|
+
to the Licensor or its representatives, including but not limited to
|
|
56
|
+
communication on electronic mailing lists, source code control systems,
|
|
57
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
58
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
59
|
+
excluding communication that is conspicuously marked or otherwise
|
|
60
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
61
|
+
|
|
62
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
63
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
64
|
+
subsequently incorporated within the Work.
|
|
65
|
+
|
|
66
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
67
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
68
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
69
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
70
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
71
|
+
Work and such Derivative Works in Source or Object form.
|
|
72
|
+
|
|
73
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
74
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
75
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
76
|
+
(except as stated in this section) patent license to make, have made,
|
|
77
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
78
|
+
where such license applies only to those patent claims licensable
|
|
79
|
+
by such Contributor that are necessarily infringed by their
|
|
80
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
81
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
82
|
+
institute patent litigation against any entity (including a
|
|
83
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
84
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
85
|
+
or contributory patent infringement, then any patent licenses
|
|
86
|
+
granted to You under this License for that Work shall terminate
|
|
87
|
+
as of the date such litigation is filed.
|
|
88
|
+
|
|
89
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
90
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
91
|
+
modifications, and in Source or Object form, provided that You
|
|
92
|
+
meet the following conditions:
|
|
93
|
+
|
|
94
|
+
(a) You must give any other recipients of the Work or
|
|
95
|
+
Derivative Works a copy of this License; and
|
|
96
|
+
|
|
97
|
+
(b) You must cause any modified files to carry prominent notices
|
|
98
|
+
stating that You changed the files; and
|
|
99
|
+
|
|
100
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
101
|
+
that You distribute, all copyright, patent, trademark, and
|
|
102
|
+
attribution notices from the Source form of the Work,
|
|
103
|
+
excluding those notices that do not pertain to any part of
|
|
104
|
+
the Derivative Works; and
|
|
105
|
+
|
|
106
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
107
|
+
distribution, then any Derivative Works that You distribute must
|
|
108
|
+
include a readable copy of the attribution notices contained
|
|
109
|
+
within such NOTICE file, excluding those notices that do not
|
|
110
|
+
pertain to any part of the Derivative Works, in at least one
|
|
111
|
+
of the following places: within a NOTICE text file distributed
|
|
112
|
+
as part of the Derivative Works; within the Source form or
|
|
113
|
+
documentation, if provided along with the Derivative Works; or,
|
|
114
|
+
within a display generated by the Derivative Works, if and
|
|
115
|
+
wherever such third-party notices normally appear. The contents
|
|
116
|
+
of the NOTICE file are for informational purposes only and
|
|
117
|
+
do not modify the License. You may add Your own attribution
|
|
118
|
+
notices within Derivative Works that You distribute, alongside
|
|
119
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
120
|
+
that such additional attribution notices cannot be construed
|
|
121
|
+
as modifying the License.
|
|
122
|
+
|
|
123
|
+
You may add Your own copyright statement to Your modifications and
|
|
124
|
+
may provide additional or different license terms and conditions
|
|
125
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
126
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
127
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
128
|
+
the conditions stated in this License.
|
|
129
|
+
|
|
130
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
131
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
132
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
133
|
+
this License, without any additional terms or conditions.
|
|
134
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
135
|
+
the terms of any separate license agreement you may have executed
|
|
136
|
+
with Licensor regarding such Contributions.
|
|
137
|
+
|
|
138
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
139
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
140
|
+
except as required for reasonable and customary use in describing the
|
|
141
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
142
|
+
|
|
143
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
144
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
145
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
146
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
147
|
+
implied, including, without limitation, any warranties or conditions
|
|
148
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
149
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
150
|
+
appropriateness of using or redistributing the Work and assume any
|
|
151
|
+
risks associated with Your exercise of permissions under this License.
|
|
152
|
+
|
|
153
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
154
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
155
|
+
unless required by applicable law (such as deliberate and grossly
|
|
156
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
157
|
+
liable to You for damages, including any direct, indirect, special,
|
|
158
|
+
incidental, or consequential damages of any character arising as a
|
|
159
|
+
result of this License or out of the use or inability to use the
|
|
160
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
161
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
162
|
+
other commercial damages or losses), even if such Contributor
|
|
163
|
+
has been advised of the possibility of such damages.
|
|
164
|
+
|
|
165
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
166
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
167
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
168
|
+
or other liability obligations and/or rights consistent with this
|
|
169
|
+
License. However, in accepting such obligations, You may act only
|
|
170
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
171
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
172
|
+
defend, and hold each Contributor harmless for any liability
|
|
173
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
174
|
+
of your accepting any such warranty or additional liability.
|
|
175
|
+
|
|
176
|
+
END OF TERMS AND CONDITIONS
|
|
177
|
+
|
|
178
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
179
|
+
|
|
180
|
+
To apply the Apache License to your work, attach the following
|
|
181
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
182
|
+
replaced with your own identifying information. (Don't include
|
|
183
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
184
|
+
comment syntax for the file format. We also recommend that a
|
|
185
|
+
file or class name and description of purpose be included on the
|
|
186
|
+
same "printed page" as the copyright notice for easier
|
|
187
|
+
identification within third-party archives.
|
|
188
|
+
|
|
189
|
+
Copyright [yyyy] [name of copyright owner]
|
|
190
|
+
|
|
191
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
192
|
+
you may not use this file except in compliance with the License.
|
|
193
|
+
You may obtain a copy of the License at
|
|
194
|
+
|
|
195
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
196
|
+
|
|
197
|
+
Unless required by applicable law or agreed to in writing, software
|
|
198
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
199
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
200
|
+
See the License for the specific language governing permissions and
|
|
201
|
+
limitations under the License.
|
package/icon.svg
ADDED
|
@@ -0,0 +1,6 @@
|
|
|
1
|
+
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.7" stroke-linecap="round" stroke-linejoin="round">
|
|
2
|
+
<path d="m12 3 8 4.5v9L12 21l-8-4.5v-9z" />
|
|
3
|
+
<path d="m4 7.5 8 4.5 8-4.5" />
|
|
4
|
+
<path d="M12 12v9" />
|
|
5
|
+
<path d="m8 5.25 8 4.5" />
|
|
6
|
+
</svg>
|
package/package.json
CHANGED
|
@@ -1,6 +1,21 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@adelie/agent-development",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"
|
|
5
|
-
"
|
|
3
|
+
"version": "0.4.2",
|
|
4
|
+
"description": "Agent development on Adelie: build agent apps on the SDK or connect them to an agent over the Agent API, call any model through one unified LLM API, manage models and secrets, and orchestrate agents, sessions, costs and schedules.",
|
|
5
|
+
"license": "Apache-2.0",
|
|
6
|
+
"repository": {
|
|
7
|
+
"type": "git",
|
|
8
|
+
"url": "git+https://github.com/lmliheng/Adelie.git",
|
|
9
|
+
"directory": "plugins/agent-development"
|
|
10
|
+
},
|
|
11
|
+
"files": [
|
|
12
|
+
"plugin.json",
|
|
13
|
+
"icon.svg",
|
|
14
|
+
"skills",
|
|
15
|
+
"hooks",
|
|
16
|
+
"LICENSE"
|
|
17
|
+
],
|
|
18
|
+
"publishConfig": {
|
|
19
|
+
"access": "public"
|
|
20
|
+
}
|
|
6
21
|
}
|
package/plugin.json
ADDED
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
{
|
|
2
|
+
"description": "Agent development on Adelie: build agent apps on the SDK or connect them to an agent over the Agent API, call any model through one unified LLM API, manage models and secrets, and orchestrate agents, sessions, costs and schedules.",
|
|
3
|
+
"description_zh": "基于 Adelie 的智能体开发:用 SDK 构建应用或经 Agent API 接入智能体、经统一的 LLM API 调用任意模型、管理模型与密钥、编排智能体/会话/成本/定时任务。",
|
|
4
|
+
"short_description": "SDK, Agent API, unified LLM API, config and orchestration.",
|
|
5
|
+
"short_description_zh": "SDK、Agent API、统一 LLM API、配置与编排。",
|
|
6
|
+
"version": "2026.10.17.1",
|
|
7
|
+
"category": "ai-app-development"
|
|
8
|
+
}
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: penguin-config
|
|
3
|
+
description: Manage model API keys, default models and per-agent vault secrets with the penguin CLI.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Penguin Config (CLI)
|
|
7
|
+
|
|
8
|
+
The `penguin` CLI manages model credentials, default models and per-agent vault secrets. Its primary job is model configuration: `penguin config model add` registers a model and `penguin config model list` shows the models currently available. Configuration goes through the CLI only — never read or hand-edit the underlying hidden files.
|
|
9
|
+
|
|
10
|
+
## Before you start
|
|
11
|
+
|
|
12
|
+
If the user's message only invokes this skill (e.g. "use penguin-cli skill") without a concrete request, ask the user what they want to configure. Do not run any command until the goal is clear.
|
|
13
|
+
|
|
14
|
+
## Models
|
|
15
|
+
|
|
16
|
+
Add or update a model (upsert by the `(provider, model_id)` pair; re-run with more options to amend an entry):
|
|
17
|
+
|
|
18
|
+
```bash
|
|
19
|
+
penguin config model add --provider <group> --model-id <upstream_id> [--api-key <key>] [--base-url <url>] \
|
|
20
|
+
[--client-type <type>] [--context-window <n>] [--max-tokens <n>] [--vision | --no-vision] \
|
|
21
|
+
[--price-cache-read <n>] [--price-cache-write <n>] [--price-output <n>] \
|
|
22
|
+
[--project-id <id>] [--root <dir>] [--set-default]
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
- A model is identified by the `(provider, model_id)` pair, so `--provider` and `--model-id` are **both required** — the group is never inferred from the model id, because gateways resell vendor models under their upstream ids and a wrong guess would send the key to another vendor's endpoint. `--model-id` takes the provider's upstream model id (what the API expects) and is persisted as the entry's request id, so it reaches the API unchanged; `--provider` names the group (`deepseek`, `openai`, `anthropic`, `google`, `openrouter`, `siliconflow`, … — `custom` for any other endpoint).
|
|
26
|
+
- Only `custom`, `vllm` and groups of your own take models added by hand. Every other built-in group carries its catalog models only: `model add` there accepts one of that group's catalog model ids (to set its key, limits or prices, or to bring it back) and refuses any other id with "cannot be added". Add such a model under `custom` with `--base-url`, or under a group of your own.
|
|
27
|
+
- For any OpenAI chat-completion compatible endpoint use `--client-type openai --base-url <endpoint>`; omit `--client-type` to auto-route by model id.
|
|
28
|
+
- Prices are USD per million tokens (cache read / cache write / output).
|
|
29
|
+
- `--vision` / `--no-vision` mark whether the model accepts images; omitting both keeps the current value (default is vision-capable).
|
|
30
|
+
- `--max-tokens <n>` pins a per-model output cap (positive integer), overriding the Agent's `model.max_tokens`; omit to inherit. Lower it for small-context models — the per-Agent default (32000) cannot fit into e.g. a 32k context window together with any prompt.
|
|
31
|
+
- All `penguin config model ...` and `penguin config vault ...` commands accept `--root <dir>` to target another data root (default `ADELIE_HOME`, then the pre-rename `PENGUIN_HOME`, then `~/.adelie/data`). Two configuration targets — treat the difference as a hard rule:
|
|
32
|
+
- **Penguin's own model** (self-configuration: the model Penguin itself runs on): pass `--root <data root>` as well — the parent directory of the App Data Dir named in your Environment section. An agent running inside Adelie never sees `ADELIE_HOME` or `PENGUIN_HOME`: the harness strips every `ADELIE_*` and `PENGUIN_*` variable from a command's environment, so a command without `--root` falls back to `~/.adelie/data` and configures a root the running server does not read.
|
|
33
|
+
- **An AI app you are building**: `--root` **must** point at the app's own data directory inside the project (e.g. `--root ./penguin_data`, the same path the app gives `createAgent({ root })`) unless the user explicitly chose another location — never write an app's models or keys into the global `~/.adelie/data`, which belongs to the person running Penguin, not to the app.
|
|
34
|
+
- While developing an app, review regularly: `penguin config model list --root <app root>` should show the app's entries, and the global list (no `--root`) should stay clean.
|
|
35
|
+
|
|
36
|
+
Other model commands:
|
|
37
|
+
|
|
38
|
+
```bash
|
|
39
|
+
penguin config model default --model-id <upstream_id> --provider <group> [--root <dir>] # set the project default model
|
|
40
|
+
penguin config model vision --model-id <upstream_id> --provider <group> [--root <dir>] # set the project vision model (reads images for text-only sessions)
|
|
41
|
+
penguin config model list [--root <dir>] # list models; api_key is shown masked
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## Vault (per-agent secrets)
|
|
45
|
+
|
|
46
|
+
The vault holds an agent's environment-variable secrets (third-party API keys etc.); values are injected into that agent's shell subprocesses:
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
penguin config vault set --key <NAME> --value <value> [--project-id <id>] [--agent-id <id>] [--root <dir>]
|
|
50
|
+
penguin config vault list [--project-id <id>] [--agent-id <id>] [--root <dir>] # values are shown masked
|
|
51
|
+
penguin config vault remove --key <NAME> [--project-id <id>] [--agent-id <id>] [--root <dir>]
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
- `--project-id` defaults to `default_project`, `--agent-id` to `default_agent`.
|
|
55
|
+
- Key names follow shell variable rules (letter or underscore first, then letters, digits and underscores); values are limited to 8192 characters.
|
|
56
|
+
|
|
57
|
+
## Language
|
|
58
|
+
|
|
59
|
+
```bash
|
|
60
|
+
penguin config lang <en|zh> # persist the CLI language via ADELIE_LANG in your shell rc
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
## Running agents
|
|
64
|
+
|
|
65
|
+
`penguin run -m "<task>" [--provider <group> --model-id <id>] [--agent-id <id>] [--workspace <path>] [--approve <mode>]` runs one task; `penguin chat [--resume [session_id]]` starts or resumes an interactive chat with the same options. The model reference stays a pair here too: pass `--provider` and `--model-id` together, or neither to run on the project's default model — one without the other is rejected.
|
|
66
|
+
|
|
67
|
+
## Storage
|
|
68
|
+
|
|
69
|
+
Paths use `<app_data_dir>`, the App Data Dir value from your Environment section.
|
|
70
|
+
|
|
71
|
+
- `<app_data_dir>/.project_config.toml` — the project's single hidden config file: model list, settings and per-model credentials (`api_key` etc. inlined in each model entry). Configuration is CLI-only — never read, print or hand-edit this file.
|
|
72
|
+
- `<app_data_dir>/agents/<agent_id>/agent_state/.vault.toml` — that agent's vault entries, hidden file; same rule, manage it with `penguin config vault`.
|
|
@@ -0,0 +1,162 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: penguin-orchestration
|
|
3
|
+
description: Drive Adelie itself from a shell — list and create agents and sessions, send and steer messages mid-flight, and query costs and scheduled tasks via the penguin CLI over the local server.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Penguin Orchestration
|
|
7
|
+
|
|
8
|
+
The `penguin` CLI is a thin client of the Adelie server. Inside a harness agent session it reaches the same server that is running you, so you can orchestrate the platform yourself: list and create agents, start conversations with them, steer those conversations while they run, and query costs and scheduled tasks.
|
|
9
|
+
|
|
10
|
+
## Before you start
|
|
11
|
+
|
|
12
|
+
If the user's message only invokes this skill (e.g. "use penguin-orchestration skill") without a concrete request, ask the user what they want to orchestrate. Read-only commands (`project ls`, `agent ls`, `ls`, `logs`, `cost`, `schedule ls`) are always safe; do not create agents, start sessions or send messages until the goal is clear.
|
|
13
|
+
|
|
14
|
+
## How the connection works
|
|
15
|
+
|
|
16
|
+
- **Inside a harness agent session** (you, now): every command subprocess has `ADELIE_API_URL`, `ADELIE_API_TOKEN`, `ADELIE_PROJECT_ID`, `ADELIE_AGENT_ID` and `ADELIE_SESSION_ID` injected, so `penguin` commands automatically reach your own server with your project and agent as the defaults — no login step.
|
|
17
|
+
- **Outside an agent** (a human shell): the CLI attaches to the running local server via its lock file, or auto-starts one; the local `<data-root>/api-token` file (0600) authenticates it.
|
|
18
|
+
- You are operating the same server that runs you: sessions and agents you create appear live in the web UI, where the user sees and owns everything you spawn.
|
|
19
|
+
- The injected token is admin-equivalent. Act accordingly: stick to what the task requires, and prefer read-only commands until a mutation is clearly needed.
|
|
20
|
+
|
|
21
|
+
## Orient first
|
|
22
|
+
|
|
23
|
+
Before mutating anything, see what exists:
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
penguin project ls # projects on this server
|
|
27
|
+
penguin agent ls # agents in the current project
|
|
28
|
+
penguin ls --json # the project's sessions, with running state
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
`--json` on any listing gives machine-parseable output.
|
|
32
|
+
|
|
33
|
+
## Command surface
|
|
34
|
+
|
|
35
|
+
```
|
|
36
|
+
penguin run -m <msg> [--project-id <id>] [--agent-id <id>] [--workspace <path>]
|
|
37
|
+
[--model-id <id> --provider <p>] [--approve <mode>] [--thinking <level>]
|
|
38
|
+
[--session <session_id>] [--background] [--timeout <duration>]
|
|
39
|
+
[--goal [budget]] [--json]
|
|
40
|
+
penguin ls [--project-id <id>] [--agent-id <id>] [--days <n>] [-a|--all] [--json]
|
|
41
|
+
penguin input [session_id] [-m <text>] [--timeout <duration>]
|
|
42
|
+
[--project-id <id>] [--agent-id <id>] [--json] [--server <url>]
|
|
43
|
+
penguin logs [session_id] [--project-id <id>] [--agent-id <id>] [--tail <n>]
|
|
44
|
+
[-f|--follow] [--timeout <duration>] [--json]
|
|
45
|
+
penguin agent ls [--project-id <id>] [--json]
|
|
46
|
+
penguin agent create --agent-id <id> [--name <s>] [--description <s>] [--skills <a,b>]
|
|
47
|
+
[--project-id <id>] [--json]
|
|
48
|
+
penguin project ls [--json]
|
|
49
|
+
penguin cost [--days <n>] [--from <d> --to <d>] [--by date|agent|model|session]
|
|
50
|
+
[--project-id <id>] [--agent-id <id>] [--json]
|
|
51
|
+
penguin schedule ls [--project-id <id>] [--agent-id <id>] [--json]
|
|
52
|
+
penguin schedule add <name> --prompt <s> --start-at <ISO|now> [--period <duration>]
|
|
53
|
+
[--end-at <ISO>] [--session-id <id> | --workspace <path>
|
|
54
|
+
[--model-id <id> --provider <p>]] [--disabled]
|
|
55
|
+
[--project-id <id>] [--agent-id <id>]
|
|
56
|
+
penguin schedule update <name> [<same field flags>] [--enable|--disable]
|
|
57
|
+
[--project-id <id>] [--agent-id <id>]
|
|
58
|
+
penguin schedule rm <name> [--project-id <id>] [--agent-id <id>]
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
- `run` starts a task and waits, rendering the conversation, unless `--background` — then it prints the new session id and exits while the server keeps running the task. `--session <session_id>` runs the task in an existing session instead of creating one; the model reference is the `--provider` + `--model-id` pair (both or neither); `--goal [budget]` runs in goal mode — the session loops until the agent declares the goal complete, with an optional spend budget.
|
|
62
|
+
- **Caller-context defaults.** Inside a harness agent, a session-creating `run` fills every field you leave unspecified from your own live session, per field independently: `--workspace`, the `--model-id`/`--provider` pair, `--approve` and `--thinking` inherit the caller's values — the same convention as `run_subagent` parent inheritance. Precedence: explicit flag > caller value > plain fallback (cwd, the Project default model, `allow-all`, none — used wholesale if the caller lookup fails, with a dim stderr note). So inside an agent, `penguin run -m "..."` alone typically does the right thing; pass flags only to diverge.
|
|
63
|
+
- `--timeout <duration>` (`30s`, `5m`, `2h`, or bare seconds) bounds the wait of a foreground `run`, an `input`, or a `logs -f`. Expiry is a soft yield, not an error: the command exits 0 while the task keeps running server-side, printing a still-running note that names the follow-up commands (`--json` prints `{sessionId, status: "running", text}` with the text so far). `--timeout 0` (also `0s`) returns immediately after delivery — the same note without collected text (`--json`: `{sessionId, status: "running"}`); on a bare poll it snapshots a running session instantly. `run --background` stays the idiomatic fire-and-forget for new tasks and rejects `--timeout`; `logs --timeout` requires `-f`.
|
|
64
|
+
- `input` with `-m` steers a **running** session mid-turn (the agent absorbs it as a course correction within the current task) or starts a new turn on an idle one; it waits for the reply unless a `--timeout` bounds the wait (`--timeout 0` = deliver and return at once). Bare `input [session_id]` (no `-m`) **polls**: it prints the session's most recent complete assistant text — an idempotent snapshot that skips user/thinking/tool output and never touches approvals, mirroring `input_subagent`'s empty-prompt semantics. A running session is waited on first (bounded by `--timeout`, else indefinitely); a session with no reply yet prints `(no assistant reply yet)`. `--json` reports `{sessionId, status, text}` — `idle`/`running` when polling, `completed`/`aborted`/`running` with `-m`.
|
|
65
|
+
- `ls` spans every agent of the project, newest first (by last active); archived sessions are left out unless `-a`/`--all` includes them, and `--days <n>` keeps only sessions last active since local midnight n−1 days ago — today counts as day 1, so `--days 2` is yesterday and today, `--days 7` this week. `logs` renders a session's transcript: `--tail <n>` for the last entries, `-f` to follow live.
|
|
66
|
+
- Session ids embed their creation timestamp — `session-YYYY-MM-DD-HH-mm-ss-<8hex>`. Every `<session_id>` argument takes any unique substring of an id; the 8-hex tail is the recommended short form, and an ambiguous fragment errors listing the candidates. On `input` and `logs`, `--project-id` scopes that fragment search (unnecessary with a full id).
|
|
67
|
+
- On `input` and `logs` the id is optional altogether: omitted, it is the agent's most recent session, off the same newest-first listing `chat --resume` uses, with `--agent-id` picking whose. The chosen id is announced as a dim `[latest]` line on stderr, so the target is never ambiguous and `--json` on stdout stays parseable. Bare `penguin logs` is therefore "what just happened" and bare `penguin input` is "what did my agent last say"; an agent with no session at all gets one line pointing at `penguin run` and a non-zero exit.
|
|
68
|
+
|
|
69
|
+
## Recipes
|
|
70
|
+
|
|
71
|
+
### Yesterday's or this week's sessions, with their latest replies
|
|
72
|
+
|
|
73
|
+
```bash
|
|
74
|
+
penguin ls --days 2 --json # yesterday + today (today counts as day 1)
|
|
75
|
+
penguin ls --days 7 --json # this week; add -a to include archived sessions
|
|
76
|
+
penguin input <session_id> # one session's latest complete assistant reply
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
- `--days <n>` keeps sessions last active since local midnight n−1 days ago. For strictly-yesterday, take `--days 2` and drop today's entries client-side — ids embed the creation date and the JSON carries last-active.
|
|
80
|
+
- Bare `input` prints the latest reply; add `--timeout 0` to snapshot a running session instantly instead of waiting for its turn to finish.
|
|
81
|
+
|
|
82
|
+
### Summarize this week's history in a new session
|
|
83
|
+
|
|
84
|
+
A fresh session gets a fresh context window for the summary; feed it through a file, not the prompt:
|
|
85
|
+
|
|
86
|
+
```bash
|
|
87
|
+
penguin ls --days 7 --json # pick the sessions
|
|
88
|
+
penguin logs <session_id> --tail 100 # gather each transcript (widen if cut short)
|
|
89
|
+
# write what you gathered into a workspace file with your file tools, then:
|
|
90
|
+
penguin run -m "Read ./weekly-material.md and write the weekly summary to ./weekly-summary.md"
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
- **Exchange big material through workspace files.** Caller-context defaults mean the new session shares your workspace — write the gathered transcripts to `./weekly-material.md` and have the new session read it there. Pages of transcript do not belong in `-m`.
|
|
94
|
+
- Read the result from `./weekly-summary.md` (the foreground run also renders the reply).
|
|
95
|
+
|
|
96
|
+
### Create an agent and say hello
|
|
97
|
+
|
|
98
|
+
```bash
|
|
99
|
+
penguin agent create --agent-id greeter --name "Greeter" --description "Welcomes people"
|
|
100
|
+
penguin run --agent-id greeter -m "Hello! Introduce yourself."
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
- Agent ids must match `^[a-z][a-z0-9_]{1,63}$`: a lowercase letter first, then lowercase letters, digits and underscores — no hyphens.
|
|
104
|
+
- A newly created agent starts with **no skills preinstalled**: seed it at creation with `--skills a,b` (library names) — include `penguin-orchestration` itself when the new agent must drive the harness too.
|
|
105
|
+
- `--agent-id` switches only the agent: workspace, model, approval and thinking still inherit from your own session (caller-context defaults) — add those flags to change them too. Each `run` without `--session` opens a fresh session; reuse a session id to continue a conversation.
|
|
106
|
+
|
|
107
|
+
### Summarize each agent's costs in a new session
|
|
108
|
+
|
|
109
|
+
```bash
|
|
110
|
+
penguin cost --days 7 --by agent --json # who spent what this week
|
|
111
|
+
penguin run -m "Summarize this per-agent cost report and flag anomalies: <the JSON>"
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
- The default `penguin cost` card already carries today / last 7 days / total; `--by date|model|session` and `--from <d> --to <d>` give the other cuts, `--project-id` / `--agent-id` narrow the scope.
|
|
115
|
+
- A `--by agent` report is small enough to inline in `-m`; for long breakdowns (`--by session` over a busy week), use the file-exchange pattern from the weekly-summary recipe.
|
|
116
|
+
|
|
117
|
+
### Set up a scheduled task for the current agent
|
|
118
|
+
|
|
119
|
+
```bash
|
|
120
|
+
penguin schedule add build-watch --prompt "Check the build results and report the failures" \
|
|
121
|
+
--start-at now --period 12h --session-id "$ADELIE_SESSION_ID" \
|
|
122
|
+
--end-at <ISO instant> # only when the request has a horizon
|
|
123
|
+
penguin schedule add daily-report --prompt "Summarize yesterday's conversations" \
|
|
124
|
+
--start-at now --period 1d # no target: a fresh session per firing
|
|
125
|
+
penguin schedule ls # verify
|
|
126
|
+
penguin schedule update daily-report --period 12h # adjust; --enable/--disable to toggle
|
|
127
|
+
penguin schedule rm daily-report # remove — no confirmation prompt
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
- `--agent-id` defaults to yourself from the caller env, so this schedules the current agent. `--start-at` takes ISO 8601 or `now`; `--period` is at least 5m (`30m`/`12h`/`1d`/`7d`), omit it for a one-shot; `--end-at` bounds recurrence. Target the session you are in — `--session-id "$ADELIE_SESSION_ID"` — unless the user asked for somewhere else: the prompt then arrives in this conversation, with its context. Leave the target off when the user wants a separate session, or when the task is better off starting clean (a nightly report that should not inherit this conversation); each firing then opens a new session, which `--workspace <path>` and the `--model-id` + `--provider` pair configure.
|
|
131
|
+
- `add` creates the schedule **enabled** (`--disabled` stages it off) — deliberately diverging from the raw file, where `enabled` defaults to false. `update` is read-modify-write: unspecified fields keep their stored values, and switching the target form clears the other one.
|
|
132
|
+
- In `schedule ls`, read: the AGENT column (without `--agent-id` the listing spans agents), `enabled` (a disabled entry never fires), `startAt` (first firing), `period` (absent means one-shot), the target — an existing session versus a new session per firing — and `lastFiredAt`.
|
|
133
|
+
- The CLI writes through the schedules API, so mistakes are rejected synchronously. The TOML file stays the single source of truth — `<app_data_dir>/agents/<agent_id>/agent_state/schedule/<name>.toml`, fields mirroring the flags (`prompt`, `enabled` — false by default in the file, `start_at`, `period`, `end_at`, `session_id` / `workspace`+`provider`+`model_id`) — and remains editable with file tools; your system prompt's schedule roster lists yours. A hand edit is only validated by the periodic reconcile (roughly every 30s), with errors landing in error records rather than your terminal — prefer the CLI.
|
|
134
|
+
|
|
135
|
+
### Run a conversation in the background and steer it mid-flight
|
|
136
|
+
|
|
137
|
+
Two patterns; both leave you free while the conversation runs.
|
|
138
|
+
|
|
139
|
+
**(a) Background CLI process — you get a completion report.** Run the CLI itself as a background command: `exec_command` with `run_in_background: true` and the command
|
|
140
|
+
|
|
141
|
+
```bash
|
|
142
|
+
penguin run --agent-id <agent_id> -m "<long task>"
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
- The harness delivers a `[background_task_done]` report when the CLI exits — no polling needed for completion.
|
|
146
|
+
- Meanwhile, find the session with `penguin ls --json` (it shows as running, with the newest id) and steer it: `penguin input <session_id> -m "Focus on X; skip Y" --timeout 0` (deliver and return at once).
|
|
147
|
+
- Poll the latest answer with bare `penguin input <session_id> --timeout 30s` — a bounded wait that exits 0 with a still-running note when the reply is not in yet — or read the raw transcript with `penguin logs <session_id> --tail 20`.
|
|
148
|
+
|
|
149
|
+
**(b) Server-side background — survives you.** `penguin run --background --agent-id <agent_id> -m "<long task>"` prints the session id and exits; the server keeps running the task with no local process.
|
|
150
|
+
|
|
151
|
+
- Poll the latest answer with bare `penguin input <session_id> --timeout 30s`, watch live with `penguin logs <session_id> -f`, and check running state with `penguin ls --json`; steer with `penguin input <session_id> -m ...` the same way.
|
|
152
|
+
|
|
153
|
+
Prefer (a) when you stay around for the result — the completion report comes to you. Prefer (b) when the work must survive your own session ending, or when fanning out many tasks without holding a process per task. A bounded foreground run is the middle ground: `penguin run --timeout 5m -m "..."` renders up to the bound, then soft-yields with the task still running — pick up the answer later with a bare `penguin input <session_id>`.
|
|
154
|
+
|
|
155
|
+
## Cautions
|
|
156
|
+
|
|
157
|
+
- **One active task per session.** `penguin input` at a busy session steers the running task rather than starting a second one; a new task sent at a busy session waits its turn. For parallel work, start parallel sessions.
|
|
158
|
+
- **Unattended sessions must not need a human.** A spawned session inherits your approval mode (`allow-all` when there is no caller to inherit from); if you yourself run under `always-ask`, pass `--approve allow-all` (trusted work) or `--approve read-only` explicitly — an unattended `always-ask` session hangs waiting for approval in the web UI.
|
|
159
|
+
- **No runaway loops.** An agent that messages itself — directly, through a chain of agents, or through a schedule aimed back at its own session — keeps spending until someone stops it. Make every automated conversation terminate: a recurring schedule pointed at your own session takes an `--end-at` whenever the request has a natural horizon (or no `--period` at all, for a one-time reminder), and a prompt whose per-firing work stays small — that session's context grows with every firing. When the user wants it open-ended, leave `--end-at` off and tell them it runs until they remove it.
|
|
160
|
+
- **Spawned work bills the project.** Everything you start lands in the same project's usage (`penguin cost` shows it); a fan-out of sessions multiplies spend.
|
|
161
|
+
- **Opening an agent to programs is the owner's call.** `penguin agent api` manages an agent's Agent API. Its `status` and `keys ls` only read. Never run `enable`, `disable`, `set`, `keys create`, `keys rm` or `server` yourself: the server refuses them to your token (`403 human_required`), and you must not sign in or mint a session to get past that. Ask the user to make the change on the agent's **API** tab, or in their own terminal after `penguin auth login`. To connect a program to an agent, use the penguin-sdk skill.
|
|
162
|
+
- **Configuration stays CLI-managed.** Never read or hand-edit `.project_config.toml` or `agent_state/.vault.toml` — models and secrets go through `penguin config` (see the penguin-cli skill).
|