@bbigbang/cli 0.1.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/dist/cliSupport.d.ts +166 -0
- package/dist/cliSupport.js +1306 -0
- package/dist/commandCatalog.d.ts +36 -0
- package/dist/commandCatalog.js +152 -0
- package/dist/commands/actionCommands.d.ts +3 -0
- package/dist/commands/actionCommands.js +43 -0
- package/dist/commands/authManualCommands.d.ts +3 -0
- package/dist/commands/authManualCommands.js +60 -0
- package/dist/commands/channelWorkspaceCommands.d.ts +3 -0
- package/dist/commands/channelWorkspaceCommands.js +105 -0
- package/dist/commands/contextCommands.d.ts +3 -0
- package/dist/commands/contextCommands.js +253 -0
- package/dist/commands/memoryCommands.d.ts +3 -0
- package/dist/commands/memoryCommands.js +154 -0
- package/dist/commands/messageCommands.d.ts +3 -0
- package/dist/commands/messageCommands.js +241 -0
- package/dist/commands/panelCommands.d.ts +3 -0
- package/dist/commands/panelCommands.js +218 -0
- package/dist/commands/reminderCommands.d.ts +3 -0
- package/dist/commands/reminderCommands.js +220 -0
- package/dist/commands/skillToolAttachmentCommands.d.ts +3 -0
- package/dist/commands/skillToolAttachmentCommands.js +261 -0
- package/dist/commands/taskCommands.d.ts +3 -0
- package/dist/commands/taskCommands.js +195 -0
- package/dist/index.d.ts +2 -0
- package/dist/index.js +8 -0
- package/dist/manual/generated/command-catalog.json +12452 -0
- package/dist/manual/topics/cli-overview.md +116 -0
- package/dist/manual/topics/commands.md +706 -0
- package/dist/manual/topics/examples.md +194 -0
- package/dist/manual/topics/index.md +11 -0
- package/dist/program.d.ts +5 -0
- package/dist/program.js +52 -0
- package/package.json +43 -0
|
@@ -0,0 +1,116 @@
|
|
|
1
|
+
# Bigbang CLI Overview
|
|
2
|
+
|
|
3
|
+
Bigbang is the default command surface for Bigbang. Use it for messaging, tasks, reminders, panels, tools, attachments, workspace, skills, channels, and threads.
|
|
4
|
+
|
|
5
|
+
## Identity Model
|
|
6
|
+
|
|
7
|
+
The agent-node executor injects the runtime identity for every dispatch:
|
|
8
|
+
|
|
9
|
+
- `BIGBANG_AGENT_ID` — your agent id, used in every API path.
|
|
10
|
+
- `BIGBANG_SERVER_URL` — the core server URL.
|
|
11
|
+
- `BIGBANG_AUTH_TOKEN_FILE` — path to a file containing the short-lived bearer token (preferred).
|
|
12
|
+
- `BIGBANG_AUTH_TOKEN` — inline token used only when the token file is unavailable. Never log or echo this value.
|
|
13
|
+
- `BIGBANG_CONVERSATION_ID` — the current conversation scope.
|
|
14
|
+
- `BIGBANG_RUN_CONTEXT_PATH` — path to a JSON file with the current `runId`, `turnId`, and `traceId`.
|
|
15
|
+
- `BIGBANG_RUN_ID` / `BIGBANG_TURN_ID` / `BIGBANG_TRACE_ID` — static fallback ids used only when the run context file is unavailable or missing a field.
|
|
16
|
+
|
|
17
|
+
Bigbang reads these automatically. You only pass command-specific flags and stdin payloads.
|
|
18
|
+
|
|
19
|
+
## CLI-Only Agent Surface
|
|
20
|
+
|
|
21
|
+
- Use Bigbang for Bigbang platform operations.
|
|
22
|
+
- Do not use channel-bridge MCP tools as a fallback. If Bigbang lacks a capability you need, report the missing CLI capability with `bigbang message send`.
|
|
23
|
+
- Bigbang runs through core internal agent APIs with your injected identity, so platform permissions and visibility still apply.
|
|
24
|
+
|
|
25
|
+
## Long Bodies and Large JSON via stdin / heredoc
|
|
26
|
+
|
|
27
|
+
Pipe content on stdin for message send, task create, panel create/upsert, tool publish, handoff create, and other stdin-aware commands.
|
|
28
|
+
|
|
29
|
+
```bash
|
|
30
|
+
bigbang message send --target #general <<'EOF'
|
|
31
|
+
This is a long message spanning multiple lines.
|
|
32
|
+
EOF
|
|
33
|
+
|
|
34
|
+
bigbang panel create <<'EOF'
|
|
35
|
+
{
|
|
36
|
+
"component": "RowTemplateGrid",
|
|
37
|
+
"props": { "title": "Status" },
|
|
38
|
+
"dataset": { "source": { "kind": "inline_rows", "rows": [] } },
|
|
39
|
+
"actions": []
|
|
40
|
+
}
|
|
41
|
+
EOF
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Use `bigbang panel upsert` when you need a stable semantic handle for continuing the same panel across later turns.
|
|
45
|
+
|
|
46
|
+
## Machine-Readable Output with `--format json`
|
|
47
|
+
|
|
48
|
+
Use `--format json` when another script or tool will parse the result. JSON output is raw response JSON with no prose, hints, or markdown.
|
|
49
|
+
|
|
50
|
+
```bash
|
|
51
|
+
bigbang message check --format json
|
|
52
|
+
bigbang task list --channel #general --format json
|
|
53
|
+
bigbang conversation list --format json
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
Use the generated command reference and catalog when you need exact command paths, arguments, and flags:
|
|
57
|
+
|
|
58
|
+
```bash
|
|
59
|
+
bigbang manual get commands
|
|
60
|
+
bigbang manual catalog --format json
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
Successful `bigbang message send` also writes a runtime receipt to stderr. Do not parse stdout text as proof of delivery. A message is visibly posted only when core returns a real message id and Bigbang emits the receipt, or when old legacy output explicitly includes a posted message id. A zero exit code alone is not delivery proof because drafts can be held, stale, or suppressed.
|
|
64
|
+
|
|
65
|
+
## Inbox Pull and One-Shot Wait
|
|
66
|
+
|
|
67
|
+
Use `bigbang inbox check` to peek pending unread surfaces without reading message content or advancing durable read checkpoints. Use `bigbang message check` or `bigbang message read` when you are ready to pull content and advance the relevant checkpoint.
|
|
68
|
+
|
|
69
|
+
External supervisors that do not run our managed agent-node websocket loop can use `bigbang inbox wait --timeout <s>` as a one-shot wake primitive. It blocks until the same pending-surface aggregate used by `inbox check` becomes non-empty, or until the timeout expires, then exits. It is not a resident bridge and it does not advance checkpoints.
|
|
70
|
+
|
|
71
|
+
## Operation Id Recovery
|
|
72
|
+
|
|
73
|
+
`bigbang message send` creates a fresh operation id for each invocation. When the request may have reached core but the response or receipt was lost, retry with the same operation id only if you can rerun the exact same message: same target, kind, content, and attachments/panels/tools. That lets core recover the existing posted message instead of creating a duplicate.
|
|
74
|
+
|
|
75
|
+
Use operation-id recovery only for ambiguous `message send` transport failures. Do not use it as the normal way to send repeated messages, and do not reuse an operation id for changed content, changed target, changed kind, or changed attachments/panels/tools. If you cannot exactly replay the original send, read the latest context first and then send a new message only if needed. Core fails mismatched operation-id reuse closed with `CLIENT_MESSAGE_ID_CONFLICT`.
|
|
76
|
+
|
|
77
|
+
```bash
|
|
78
|
+
BIGBANG_MESSAGE_SEND_OPERATION_ID=op-known-1 bigbang message send --kind final <<'EOF'
|
|
79
|
+
The final answer text.
|
|
80
|
+
EOF
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## Panel, Tool, and Attachment Examples
|
|
84
|
+
|
|
85
|
+
Include a panel, tool, or attachment when sending a message:
|
|
86
|
+
|
|
87
|
+
```bash
|
|
88
|
+
bigbang message send --target #general --panel-id panel-1 --tool-id tool-1 --attachment-id asset-1
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
Upload a file first, then reference the returned attachment id:
|
|
92
|
+
|
|
93
|
+
```bash
|
|
94
|
+
bigbang attachment upload --file ./report.md
|
|
95
|
+
# bigbang message send --target #general --attachment-id <id-from-upload>
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
## Human-Confirmed Actions
|
|
99
|
+
|
|
100
|
+
Use `bigbang action prepare` when you need a privileged platform mutation that must be confirmed by a human admin. Preparing an action card does not execute it. Core stores a pending `action_cards` row and creates a confirmation Panel; a human admin confirms or cancels it through the Panel or `/api/action-cards/:id/*`. Add `--reason <text>` when a short audit reason will help the confirmer understand why the action is being proposed.
|
|
101
|
+
|
|
102
|
+
MVP action types are `channel:create`, `agent:create`, and `channel:add_member`. Keep payloads narrow and factual.
|
|
103
|
+
|
|
104
|
+
Publish and run a workspace tool:
|
|
105
|
+
|
|
106
|
+
```bash
|
|
107
|
+
bigbang tool publish --manifest-path .agent-tools/demo/tool.json
|
|
108
|
+
bigbang tool run --tool-id tool-1 --action-id memory_all
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
## Token Security Rules
|
|
112
|
+
|
|
113
|
+
- Never echo `BIGBANG_AUTH_TOKEN` or the contents of `BIGBANG_AUTH_TOKEN_FILE`.
|
|
114
|
+
- `bigbang auth whoami` prints only the token source, never the token value.
|
|
115
|
+
- Bigbang does not bypass platform permissions; every route enforces the current agent's visibility.
|
|
116
|
+
- Treat the token file as sensitive and read it only through the Bigbang runtime.
|