cofluxd 2.13.0 → 2.14.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/package.json +1 -1
- package/skills/coflux/SKILL.md +32 -55
- package/skills/coflux-secret/SKILL.md +104 -0
package/package.json
CHANGED
package/skills/coflux/SKILL.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: coflux
|
|
3
|
-
description: Use coflux to enter workspaces, open terminals the user can see and take over, run commands in them, wait for those commands, read their scrollback, type into them, run one-shot commands on another device in the account and get their output, report progress, notify the user, obtain preview URLs,
|
|
3
|
+
description: Use coflux to enter workspaces, open terminals the user can see and take over, run commands in them, wait for those commands, read their scrollback, type into them, run one-shot commands on another device in the account and get their output, report progress, notify the user, obtain preview URLs, pick up the elements the user annotated in Coflux's built-in browser and the comments they wrote on lines of the diff, and mark them done, and hand a bounded mechanical sub-task to the built-in executor instead of spending your own context on it. Prefer zero-credential local commands in the current workspace; use the account CLI across workspaces and devices. Coordinates arrive through coflux-session or COFLUX_* variables.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Working inside coflux
|
|
@@ -14,7 +14,7 @@ and a way to operate the other workspaces and devices under the account when you
|
|
|
14
14
|
|
|
15
15
|
| Track | Credentials | Reach | Use for |
|
|
16
16
|
|---|---|---|---|
|
|
17
|
-
| Local commands `coflux terminal/progress/notify/ports/executor/
|
|
17
|
+
| Local commands `coflux terminal/progress/notify/ports/executor/annotations` | none (the daemon identifies you by process tree) | **the workspace your cwd is in** | open, run, wait, read, send, close, report progress, call the user, preview URLs, implement the user's browser annotations and code comments, hand a bounded sub-task to the built-in executor: the default; some actions require a server connection |
|
|
18
18
|
| Account CLI | app login or `coflux login` | all devices and workspaces in the account | child workspaces and remote terminals; JSON output |
|
|
19
19
|
|
|
20
20
|
Of the local commands, `run`/`wait`/`read`/`send`/`close`/`progress`/`executor`/`annotations` complete
|
|
@@ -476,48 +476,11 @@ file channel: point at paths inside the workspace instead of trying to hand anyt
|
|
|
476
476
|
|
|
477
477
|
### Get a secret from the user
|
|
478
478
|
|
|
479
|
-
|
|
480
|
-
|
|
481
|
-
coflux
|
|
482
|
-
coflux secret inject DATABASE_URL --file .env.local
|
|
483
|
-
```
|
|
479
|
+
When you need a value from the user that must not enter the conversation (API key, token, password,
|
|
480
|
+
private key, connection string…), use the `coflux-secret` skill
|
|
481
|
+
([`../coflux-secret/SKILL.md`](../coflux-secret/SKILL.md)) — never ask the user to paste it into the chat.
|
|
484
482
|
|
|
485
|
-
|
|
486
|
-
goes to a **non-interactive** destination (a command that reads it from the environment, or a
|
|
487
|
-
dotenv/config file), ask for it with `coflux secret`. **Never ask the user to paste a secret into
|
|
488
|
-
the chat**: that puts it in the transcript, the model provider's logs and on screen. With
|
|
489
|
-
`coflux secret` you never see the value; you get a name and an outcome, and every use of the value
|
|
490
|
-
goes back through coflux.
|
|
491
|
-
|
|
492
|
-
- `ask NAME --reason "<why>"` shows a request card over this terminal on every Coflux desktop of
|
|
493
|
-
the account (plus one inbox notification). It blocks until the user answers, then prints exactly
|
|
494
|
-
one word: `provided`, `declined` or `cancelled` (closed card, timeout — default 10 minutes,
|
|
495
|
-
`--timeout <seconds>` — or the terminal ended). Exit status is 0 only for `provided`. Write the
|
|
496
|
-
reason for the user: say what the value is for and where it will go. NAME is an
|
|
497
|
-
environment-variable name. Asking again for a NAME replaces its value. On `declined`, do not ask
|
|
498
|
-
again unprompted; on `cancelled`, tell the user what you were waiting for before retrying. A
|
|
499
|
-
timeout with no card on the user's screen usually means their desktop app is too old — say so.
|
|
500
|
-
- `exec NAME [NAME…] -- <cmd> [args…]` runs the command with each value in a same-name environment
|
|
501
|
-
variable, passes its exit status through, and shows every occurrence of a value in its output
|
|
502
|
-
as `***`. A NAME that was not provided in this terminal fails with a sentence telling you to
|
|
503
|
-
`ask` first.
|
|
504
|
-
- `inject NAME --file <path> [--key KEY]` makes the daemon insert or update `KEY=value` (KEY
|
|
505
|
-
defaults to NAME) in a dotenv file inside the workspace your cwd is in. A new file is owner-only;
|
|
506
|
-
a path outside the workspace, including through a symlink, is refused. It prints only that the
|
|
507
|
-
file was written. Checking that the file is gitignored is yours.
|
|
508
|
-
|
|
509
|
-
Values belong to **this terminal**: only processes in it can use them, and they are dropped when it
|
|
510
|
-
ends (and when the user's device restarts its coflux runtime) — a new terminal must `ask` again.
|
|
511
|
-
They live only in the local daemon's memory, never on disk or on the center. `coflux terminal read`
|
|
512
|
-
and the center's copy of any terminal show a held value as `***`.
|
|
513
|
-
|
|
514
|
-
Not for interactive prompts: an `ssh` or `sudo` password prompt stays with the user — open a
|
|
515
|
-
terminal they can take over, `coflux notify` them, and `coflux terminal wait`. The built-in
|
|
516
|
-
executor cannot use `coflux secret` (it is not a terminal process). And it prevents accidents, not
|
|
517
|
-
a determined agent: once a value is in an environment variable or a file you can read, printing it
|
|
518
|
-
on purpose would leak it — never do that.
|
|
519
|
-
|
|
520
|
-
### Implement the user's browser annotations
|
|
483
|
+
### Implement the user's annotations: browser annotations and code comments
|
|
521
484
|
|
|
522
485
|
```sh
|
|
523
486
|
coflux annotations list
|
|
@@ -525,17 +488,32 @@ coflux annotations resolve 3 --note "Primary button now uses the brand token; sp
|
|
|
525
488
|
coflux annotations watch
|
|
526
489
|
```
|
|
527
490
|
|
|
528
|
-
|
|
529
|
-
|
|
530
|
-
|
|
491
|
+
Annotations come in two kinds that share one numbered list (#1, #2…):
|
|
492
|
+
|
|
493
|
+
- **Browser annotations**: the user points at elements of a page in Coflux's built-in browser tab
|
|
494
|
+
("this element — change it like so").
|
|
495
|
+
- **Code comments**: the user reviews this workspace's diff in Coflux's changes view and comments
|
|
496
|
+
on a line or a range of lines ("rename this", "this breaks when the list is empty").
|
|
497
|
+
|
|
498
|
+
The user hands them to you from the desktop, which types an instruction into your terminal, or
|
|
499
|
+
simply asks you to handle the annotations. They belong to the workspace your cwd is in and live on
|
|
531
500
|
this machine, so they are there whether or not a desktop is open.
|
|
532
501
|
|
|
533
|
-
- `list` prints the pending ones as markdown: the user's comment (and, for a reopened
|
|
534
|
-
earlier note and what the user answered),
|
|
535
|
-
|
|
536
|
-
|
|
537
|
-
|
|
538
|
-
|
|
502
|
+
- `list` prints the pending ones, both kinds, as markdown: the user's comment (and, for a reopened
|
|
503
|
+
one, your earlier note and what the user answered), then where it points. It always names the
|
|
504
|
+
workspace it resolved: an empty list in the wrong workspace means you moved (`coflux workspace`).
|
|
505
|
+
Add `--json` for structured output (`kind` is `page` or `code`).
|
|
506
|
+
- A **code comment** gives the file, the line range and the side of the diff, then the commented
|
|
507
|
+
lines in a fenced block. `in the working tree` means the current file; `on the base side` means
|
|
508
|
+
the version the changes are compared against (with its commit), typically lines the change
|
|
509
|
+
removed or replaced — read that version with `git show <commit>:<path>` if you need more context.
|
|
510
|
+
The line numbers are where the lines were when the comment was written: if the file has changed
|
|
511
|
+
since, find the commented lines by their text. The comment is about those lines, but the fix may
|
|
512
|
+
belong elsewhere (a caller, a test); make the change the comment asks for.
|
|
513
|
+
- A **browser annotation** gives the page, the component chain and source location when the page
|
|
514
|
+
exposed them, the element's selector, DOM path and key computed styles, and the paths of its
|
|
515
|
+
images.
|
|
516
|
+
- A browser annotation is not always one element. When the user selected several elements together, it
|
|
539
517
|
lists each one with its own component chain and context under "Element 1 of n": the comment
|
|
540
518
|
applies to all of them, so change them consistently and resolve the annotation once. When the user
|
|
541
519
|
dragged a **region**, it gives the region's size and offset, the *container* (the innermost
|
|
@@ -548,7 +526,8 @@ this machine, so they are there whether or not a desktop is open.
|
|
|
548
526
|
- The images are local files: read them. A *screenshot of the current state* shows the element as
|
|
549
527
|
the user saw it; a *reference image* is what the user wants or pointed at.
|
|
550
528
|
- After implementing each annotation, run `resolve <id or number> --note "<what you changed>"`.
|
|
551
|
-
The note is what the user reads to review the change; the pin on their page
|
|
529
|
+
The note is what the user reads to review the change; the pin on their page (or the comment card
|
|
530
|
+
under the diff line) turns into a check.
|
|
552
531
|
They confirm it (it disappears) or reopen it with a comment, and it comes back in `list`. Resolve
|
|
553
532
|
only what you actually changed; if you cannot or should not do one, resolve it with a note that
|
|
554
533
|
says why rather than leaving it pending silently.
|
|
@@ -685,8 +664,6 @@ There is no `--workspace`, and there is **no stdin**.
|
|
|
685
664
|
- A workspace has a cap on concurrently live terminals (default 8, including the user's own).
|
|
686
665
|
On hitting the cap, `list` first: usually some finished terminals were never collected. If the
|
|
687
666
|
user really filled it up, `notify` them instead of forcing it.
|
|
688
|
-
- `coflux secret ask` needs the daemon connected to the center (the request reaches the user's
|
|
689
|
-
desktops through it) and fails at once otherwise; `exec` and `inject` stay local.
|
|
690
667
|
- `new`/`list`/`ports`/`notify` and account commands need the daemon connected to the center; "letting the
|
|
691
668
|
user see" is their whole point. `run`/`wait`/`read`/`send`/`close`/`progress` do not
|
|
692
669
|
depend on the center. When disconnected they fail loudly rather than degrade silently.
|
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: coflux-secret
|
|
3
|
+
description: Use this whenever you need a value from the user that must not appear in the conversation, the model provider's logs or on screen — an API key, token, password, database connection string, private key or certificate, cookie, recovery code, or personal data such as an ID or card number. Use it before you go digging for such a value in shell history, the keychain or the user's config files yourself, and use it the moment the user offers to paste a secret into the chat — stop them and ask through `coflux secret` instead. The user types or pastes the value into a masked card on their Coflux desktop or iOS app; you only learn whether it was provided, and the value reaches commands and dotenv files without ever entering your context. Works only inside a Coflux terminal. Not for interactive prompts (an ssh or sudo password prompt, a one-time code typed into a login flow).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Get a secret from the user without seeing it
|
|
7
|
+
|
|
8
|
+
```sh
|
|
9
|
+
coflux secret ask OPENAI_API_KEY --reason "Run the integration tests against the real API"
|
|
10
|
+
coflux secret exec OPENAI_API_KEY -- pnpm test:integration
|
|
11
|
+
coflux secret inject DATABASE_URL --file .env.local
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
**Only inside a Coflux terminal.** `coflux secret` talks to the local Coflux daemon that runs this
|
|
15
|
+
terminal; you are in one when a `<coflux-session>` block is in your context or `COFLUX_SESSION_ID`
|
|
16
|
+
is set. Outside a Coflux terminal the command is unavailable: tell the user where the value needs to
|
|
17
|
+
go (an environment variable, a file) and let them put it there themselves — still never through the
|
|
18
|
+
chat.
|
|
19
|
+
|
|
20
|
+
## When to use it
|
|
21
|
+
|
|
22
|
+
Use `coflux secret` whenever a task needs a value only the user has and that the user would not
|
|
23
|
+
want in the transcript, in the model provider's logs or on screen:
|
|
24
|
+
|
|
25
|
+
- API keys, access tokens, passwords, database connection strings;
|
|
26
|
+
- private keys, certificates, cookies, recovery codes;
|
|
27
|
+
- personal data such as ID numbers or card numbers.
|
|
28
|
+
|
|
29
|
+
Three situations call for it:
|
|
30
|
+
|
|
31
|
+
1. **You need such a value.** Ask with `coflux secret ask`, never in the chat.
|
|
32
|
+
2. **You are about to dig it out yourself** — from shell history, the keychain, the user's dotfiles
|
|
33
|
+
or config files of other projects. Stop and ask through the card instead.
|
|
34
|
+
3. **The user offers to paste it into the chat** ("I'll paste the key", "here is the token…").
|
|
35
|
+
Intercept: tell them not to, and run `coflux secret ask` so they can enter it in the card. If a
|
|
36
|
+
secret was already pasted into the chat, do not repeat or reuse it; suggest they rotate it and
|
|
37
|
+
provide the new value through the card.
|
|
38
|
+
|
|
39
|
+
**Never ask the user to paste a secret into the chat**: that puts it in the transcript, the model
|
|
40
|
+
provider's logs and on screen. With `coflux secret` you never see the value; you get a name and an
|
|
41
|
+
outcome, and every use of the value goes back through coflux.
|
|
42
|
+
|
|
43
|
+
## Commands
|
|
44
|
+
|
|
45
|
+
- `ask NAME --reason "<why>"` shows a masked request card over this terminal in every Coflux desktop
|
|
46
|
+
and iOS app of the account (plus one inbox notification). It blocks until the user answers, then
|
|
47
|
+
prints exactly one word: `provided`, `declined` or `cancelled` (closed card, timeout — default
|
|
48
|
+
10 minutes, `--timeout <seconds>` — or the terminal ended). Exit status is 0 only for `provided`.
|
|
49
|
+
Write the reason for the user: say what the value is for and where it will go. NAME is an
|
|
50
|
+
environment-variable name. Asking again for a NAME replaces its value. On `declined`, do not ask
|
|
51
|
+
again unprompted; on `cancelled`, tell the user what you were waiting for before retrying. A
|
|
52
|
+
timeout with no card on the user's screen usually means their app is too old — say so.
|
|
53
|
+
- `exec NAME [NAME…] -- <cmd> [args…]` runs the command with each value in a same-name environment
|
|
54
|
+
variable, passes its exit status through, and shows every occurrence of a single-line value in
|
|
55
|
+
its output as `***` (see the limit for multi-line values below). A NAME that was not provided in
|
|
56
|
+
this terminal fails with a sentence telling you to `ask` first.
|
|
57
|
+
- `inject NAME --file <path> [--key KEY]` makes the daemon insert or update `KEY=value` (KEY
|
|
58
|
+
defaults to NAME) in a dotenv file inside the workspace your cwd is in. A new file is owner-only;
|
|
59
|
+
a path outside the workspace, including through a symlink, is refused. It prints only that the
|
|
60
|
+
file was written. Checking that the file is gitignored is yours.
|
|
61
|
+
|
|
62
|
+
Values belong to **this terminal**: only processes in it can use them, and they are dropped when it
|
|
63
|
+
ends (and when the user's device restarts its coflux runtime) — a new terminal must `ask` again.
|
|
64
|
+
They live only in the local daemon's memory, never on disk or on the center. `coflux terminal read`
|
|
65
|
+
and the center's copy of any terminal show a held single-line value as `***`.
|
|
66
|
+
|
|
67
|
+
`ask` needs the daemon connected to the center (the request reaches the user's apps through it) and
|
|
68
|
+
fails at once otherwise; `exec` and `inject` stay local.
|
|
69
|
+
|
|
70
|
+
## Multi-line values
|
|
71
|
+
|
|
72
|
+
Private keys, certificates and JSON credentials span several lines. The user pastes them into the
|
|
73
|
+
same card; the value arrives with every line break intact, as **LF** (`\n`) line endings — any CRLF
|
|
74
|
+
or lone CR in what they pasted becomes LF, and nothing else changes, including a trailing newline.
|
|
75
|
+
Land such a value in one of three ways:
|
|
76
|
+
|
|
77
|
+
- **An environment variable**: `coflux secret exec NAME -- <cmd>`, exactly as for a single-line
|
|
78
|
+
value.
|
|
79
|
+
- **A dotenv file**: `coflux secret inject NAME --file .env.local`. The daemon writes it
|
|
80
|
+
double-quoted with line breaks escaped as `\n`, which dotenv readers turn back into line breaks.
|
|
81
|
+
- **A standalone owner-only file** (for example `key.pem`):
|
|
82
|
+
|
|
83
|
+
```sh
|
|
84
|
+
coflux secret exec NAME -- sh -c '(umask 077; printf %s "$NAME" > <path>)'
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
`printf %s` writes the value byte for byte, trailing newline included; `umask 077` makes the file
|
|
88
|
+
owner-only from the moment it exists. Checking that the path is gitignored is yours.
|
|
89
|
+
|
|
90
|
+
**Multi-line values are not redacted in terminal output.** The `***` replacement matches only the
|
|
91
|
+
complete value as one piece. A terminal rewrites `\n` as `\r\n`, and a program may print a single
|
|
92
|
+
line of the value on its own, so a multi-line value — or any one line of it — printed to a terminal
|
|
93
|
+
shows in clear text in `exec` output, in `coflux terminal read` and in the center's copy of the
|
|
94
|
+
terminal. The only protection is never printing it: do not `cat` the file you wrote, do not echo
|
|
95
|
+
the variable, and do not run commands that dump their environment or config.
|
|
96
|
+
|
|
97
|
+
## Boundaries
|
|
98
|
+
|
|
99
|
+
- **Not for interactive prompts.** An `ssh` or `sudo` password prompt, or a one-time code typed into
|
|
100
|
+
a login flow, stays with the user: open a terminal they can take over, `coflux notify` them, and
|
|
101
|
+
`coflux terminal wait`.
|
|
102
|
+
- **The built-in executor cannot use `coflux secret`** (it is not a terminal process).
|
|
103
|
+
- **It prevents accidents, not a determined agent.** Once a value is in an environment variable or
|
|
104
|
+
a file you can read, printing it on purpose would leak it — never do that.
|