@floomhq/floom 5.1.5 → 5.1.7
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/assets/floom-skill.md +5 -1
- package/package.json +1 -1
package/assets/floom-skill.md
CHANGED
|
@@ -24,6 +24,7 @@ For a new Floom install, do NOT start from an open-ended worker idea. Drive the
|
|
|
24
24
|
Once the first read-only worker has a real completed run and you have shown the output:
|
|
25
25
|
1. **Offer to schedule that worker** — ask if the user wants this same worker to run on a cadence. Only call `workers_update` after the user says yes.
|
|
26
26
|
2. **Bridge to the second worker** — ask: "what repetitive task do YOU want automated?" Offer this short menu of high-success next workers: Slack Unread Digest, GitHub Stale-PR Notifier, Summarize-a-URL, Daily Gmail Follow-up Drafter.
|
|
27
|
+
- None of these? Ask the user what recurring task they want automated, then create the closest-matching worker from their own description. Pick the nearest template as a starting point, connect what it needs, keep it manual and read-only for the first proof run, and confirm before scheduling.
|
|
27
28
|
3. **Build and prove it the same way** — create the smallest manual worker for their pick, run it, verify a real completed run, show the output, then offer to schedule it.
|
|
28
29
|
|
|
29
30
|
## The loop
|
|
@@ -46,7 +47,8 @@ Never claim success for a failed run or a run whose final status is unknown.
|
|
|
46
47
|
- **workers_** list / get / create / update / run / write_file
|
|
47
48
|
- **runs_** list / get / watch / logs / approve / reject / cancel
|
|
48
49
|
- **secrets_** list / set — credentials workers reference by name (write-only, never printed)
|
|
49
|
-
- **connections_** list
|
|
50
|
+
- **connections_** list — inspect connected OAuth apps such as Gmail, Slack, and HubSpot
|
|
51
|
+
- **connections_** add_mcp — register a custom MCP server connection; do not use it for OAuth app connects
|
|
50
52
|
- **contexts_** list / read / write — brain-pack files workers draw on at run time
|
|
51
53
|
|
|
52
54
|
(Tool names may appear with a dot in some clients, e.g. `workers.list`.)
|
|
@@ -54,6 +56,8 @@ Never claim success for a failed run or a run whose final status is unknown.
|
|
|
54
56
|
## Rules of thumb
|
|
55
57
|
- A worker = **worker.yml** (config: trigger, schedule, inputs) + **run.py** or **SKILL.md** (what it does).
|
|
56
58
|
- Keep first-worker authoring small: one trigger, clear inputs, one observable success condition.
|
|
59
|
+
- Prefer read-only connection tools for the first proof run. Do not copy raw Gmail or customer data into worker logs unless the user explicitly asks for an audit trail.
|
|
60
|
+
- OAuth apps and MCP servers are different connection paths: use OAuth/app connect flows for Gmail, Slack, HubSpot, and similar apps; use `connections_add_mcp` only when the user is registering a custom MCP server URL/command.
|
|
57
61
|
- Prefer setting a **schedule** after the first useful manual run — that's the loop (set once, never run again).
|
|
58
62
|
- Never claim success until a run has completed successfully and you have checked details/logs.
|
|
59
63
|
- Reference secrets by name; never echo their values.
|