@paradigma-inc/flywheel 0.1.15 → 0.1.19
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/flywheel/SKILL.md +7 -0
- package/skills/flywheel/compute/managed-compute.md +116 -2
- package/skills/flywheel/references/flywheel-mcp-tool-map.md +135 -142
- package/skills/flywheel-auto/SKILL.md +17 -7
- package/skills/flywheel-auto/evals/evals.json +6 -0
- package/skills/flywheel-auto/references/ARTIFACTS.md +47 -216
- package/skills/flywheel-auto/references/INTERFACES.md +192 -195
- package/skills/flywheel-auto/references/experiment-design-protocol-autonomous.md +62 -0
- package/skills/flywheel-auto/references/flywheel-mcp-tool-map.md +135 -142
- package/skills/flywheel-lookahead/SKILL.md +1 -0
- package/skills/flywheel-lookahead/references/ARTIFACTS.md +47 -216
- package/skills/flywheel-lookahead/references/INTERFACES.md +192 -195
- package/skills/flywheel-lookahead/references/flywheel-mcp-tool-map.md +135 -142
- package/skills/flywheel-reproduce/SKILL.md +7 -2
- package/skills/flywheel-reproduce/references/ARTIFACTS.md +47 -216
- package/skills/flywheel-reproduce/references/INTERFACES.md +192 -195
- package/skills/flywheel-reproduce/references/flywheel-mcp-tool-map.md +135 -142
- package/skills/flywheel-to-graph/SKILL.md +1 -0
- package/skills/flywheel-to-graph/references/ARTIFACTS.md +47 -216
- package/skills/flywheel-to-graph/references/INTERFACES.md +192 -195
- package/skills/flywheel-to-graph/references/flywheel-mcp-tool-map.md +135 -142
package/package.json
CHANGED
package/skills/flywheel/SKILL.md
CHANGED
|
@@ -50,3 +50,10 @@ Choose one primary file first, then add at most one supporting file only if need
|
|
|
50
50
|
- Prefer concrete steps and decision points over long narrative explanations.
|
|
51
51
|
- Do not run broad document reads; load only what is required by the current request.
|
|
52
52
|
- Do not start compute-heavy execution before design intent is clear.
|
|
53
|
+
- When another specialized Flywheel skill is explicitly invoked, this skill provides background guidance only and must not override that skill's workflow rules.
|
|
54
|
+
- For managed compute cleanup in autonomous runs, default to releasing only
|
|
55
|
+
known leases (leases acquired in the current run or explicitly selected by
|
|
56
|
+
the user).
|
|
57
|
+
- When unknown active leases are present, report and skip by default.
|
|
58
|
+
- Use account-wide release (`flywheel_compute_release_all`) only when the user
|
|
59
|
+
explicitly asks for account-wide cleanup.
|
|
@@ -14,8 +14,14 @@ Flywheel can provision managed GPU instances for you from providers like Lambda
|
|
|
14
14
|
```
|
|
15
15
|
|
|
16
16
|
2. **Approve a budget.** Flywheel opens an approval page in your browser where you set a spending cap for managed compute acquisition.
|
|
17
|
-
3. **
|
|
18
|
-
4. **
|
|
17
|
+
3. **Review and choose a GPU.** The agent lists current offers, recommends one option with rationale, presents alternatives, and waits for your explicit confirmation before acquiring.
|
|
18
|
+
4. **The agent acquires and connects.** After explicit confirmation, the agent acquires a machine, waits for it to become ready, and gets SSH access automatically. Provisioning typically takes a few minutes — the agent polls for readiness in the background.
|
|
19
|
+
5. **Release when done.** When you're finished, the agent releases the lease. You can also release leases from the WebUI at any time.
|
|
20
|
+
|
|
21
|
+
For autonomous runs, agents should default to releasing only known leases
|
|
22
|
+
(leases acquired in the current run or explicitly selected by the user). If
|
|
23
|
+
unknown active leases are detected, agents should report and skip those leases
|
|
24
|
+
by default. Use account-wide release only when the user explicitly requests it.
|
|
19
25
|
|
|
20
26
|
## [](https://flywheel.paradigma.inc//#managing-machines-in-the-webui)Managing machines in the WebUI
|
|
21
27
|
|
|
@@ -37,6 +43,114 @@ Compute is billed against your Flywheel credits balance, which is separate from
|
|
|
37
43
|
|
|
38
44
|
For a focused reference, see `compute/credits-and-billing.md`.
|
|
39
45
|
|
|
46
|
+
## Recommendation procedure
|
|
47
|
+
|
|
48
|
+
### Step 1 - Filter to allowed options
|
|
49
|
+
|
|
50
|
+
- Input: `options` from `flywheel_compute_list_options`.
|
|
51
|
+
- Keep only entries where `allowed == true`.
|
|
52
|
+
- If empty, return "empty option list" failure mode and stop.
|
|
53
|
+
|
|
54
|
+
### Step 2 - Extract task signals from node text
|
|
55
|
+
|
|
56
|
+
- Read `node.content`, `node.hypothesis`, `node.summary`.
|
|
57
|
+
- Extract:
|
|
58
|
+
- `weight_class` in `{light, medium, heavy, unknown}`
|
|
59
|
+
- `expected_runtime_hours`
|
|
60
|
+
- `min_vram_gb`
|
|
61
|
+
- Defaults:
|
|
62
|
+
- `expected_runtime_hours`: `1` for light, `3` for medium, `8` for heavy, `unknown` when weight is unknown.
|
|
63
|
+
- `min_vram_gb`: `0` for light, `24` for medium, `40` for heavy.
|
|
64
|
+
- If any signal is `unknown`, ask exactly one clarifying question:
|
|
65
|
+
- "Roughly what size model and how long do you expect to run?"
|
|
66
|
+
- LLM judgment is allowed only in this step.
|
|
67
|
+
|
|
68
|
+
### Step 3 - Apply affordability filter
|
|
69
|
+
|
|
70
|
+
- Compute `runway_hours = budget_remaining_cents / price_cents_per_hour` for each option.
|
|
71
|
+
- Drop options where `runway_hours < expected_runtime_hours * 1.25`.
|
|
72
|
+
- `1.25` is fixed in this issue; do not change it.
|
|
73
|
+
- If empty, return "all options over cap" failure mode and stop.
|
|
74
|
+
|
|
75
|
+
### Step 4 - Apply minimum VRAM filter
|
|
76
|
+
|
|
77
|
+
- Drop options where `gpu_memory_gb < min_vram_gb`.
|
|
78
|
+
- If this would empty the set, keep the Step 3 set and mark `VRAM-constrained fallback`.
|
|
79
|
+
- Use the Step 4-qualified set for subsequent ranking, alternatives, and retries.
|
|
80
|
+
- Use the Step 3 survivors for those later decisions only when `VRAM-constrained fallback` is active.
|
|
81
|
+
|
|
82
|
+
### Step 5 - Rank and pick recommendation
|
|
83
|
+
|
|
84
|
+
Evaluate buckets in this order and stop at the first non-empty bucket:
|
|
85
|
+
|
|
86
|
+
1. Preferred + affordable + VRAM-met (`offer_id` in `preferred_offer_ids`)
|
|
87
|
+
2. Affordable + VRAM-met
|
|
88
|
+
3. Affordable fallback (when `VRAM-constrained fallback` is active)
|
|
89
|
+
|
|
90
|
+
Sorting rules:
|
|
91
|
+
|
|
92
|
+
- Buckets 1 and 2 primary sort: cheapest `price_cents_per_hour`.
|
|
93
|
+
- Bucket 3 primary sort: largest `gpu_memory_gb`, then cheapest on tie.
|
|
94
|
+
|
|
95
|
+
Tie-breakers (only when primary sort values are exactly equal):
|
|
96
|
+
|
|
97
|
+
1. `availability_mode == live_capacity` before `allocation_time`
|
|
98
|
+
2. `price_kind == provider_reported` before `estimate`
|
|
99
|
+
3. more `regions` entries first
|
|
100
|
+
4. lexicographic `offer_id`
|
|
101
|
+
|
|
102
|
+
### Step 6 - Build recommendation rationale
|
|
103
|
+
|
|
104
|
+
Include:
|
|
105
|
+
|
|
106
|
+
- GPU identity: `{gpu_model} ({gpu_memory_gb}GB)`
|
|
107
|
+
- Hourly rate in dollars per hour
|
|
108
|
+
- Estimate suffix when `price_kind == estimate`
|
|
109
|
+
- Runway statement using `budget_remaining_cents`
|
|
110
|
+
- Weight-class match statement
|
|
111
|
+
- Availability note only when non-default
|
|
112
|
+
- Provenance tag for preferred-list pick or VRAM fallback
|
|
113
|
+
|
|
114
|
+
### Step 7 - Select up to two alternatives
|
|
115
|
+
|
|
116
|
+
From the active candidate set (Step 4-qualified set by default; Step 3 survivors only when `VRAM-constrained fallback` is active), fill at most two slots in this order:
|
|
117
|
+
|
|
118
|
+
1. Reliability alternative (only if recommendation is `allocation_time`): cheapest `live_capacity`
|
|
119
|
+
2. Cheaper alternative: strictly cheaper than recommendation
|
|
120
|
+
3. Headroom alternative: strictly higher `gpu_memory_gb` than recommendation
|
|
121
|
+
|
|
122
|
+
Display order:
|
|
123
|
+
|
|
124
|
+
1. recommendation first
|
|
125
|
+
2. filled alternatives in slot order
|
|
126
|
+
|
|
127
|
+
Never display more than three total options.
|
|
128
|
+
|
|
129
|
+
### Step 8 - Require confirmation and handle acquire failure
|
|
130
|
+
|
|
131
|
+
- Wait for explicit user confirmation (or explicit user override offer id) before `flywheel_compute_acquire`.
|
|
132
|
+
- On acquire failure due to capacity:
|
|
133
|
+
1. pick next-best candidate from the active candidate set (excluding failed offer),
|
|
134
|
+
2. same provider -> retry immediately without re-confirmation,
|
|
135
|
+
3. different provider -> ask user to re-confirm before retry,
|
|
136
|
+
4. cap retries at 3 total acquire attempts per user confirmation,
|
|
137
|
+
5. for `flywheel-auto` with `k > 1`, apply retry cap and confirmation boundary per worker.
|
|
138
|
+
|
|
139
|
+
Fixed numeric defaults for this flow:
|
|
140
|
+
|
|
141
|
+
- `1`, `3`, `8` runtime defaults
|
|
142
|
+
- affordability multiplier `1.25`
|
|
143
|
+
- acquire retry cap `3`
|
|
144
|
+
|
|
145
|
+
## Presenting the options
|
|
146
|
+
|
|
147
|
+
- Always show the recommended offer first with rationale.
|
|
148
|
+
- Then show up to two alternatives.
|
|
149
|
+
- Always wait for explicit user confirmation before calling `flywheel_compute_acquire`.
|
|
150
|
+
- If the user provides an explicit offer-id override, Treat as first-class and proceed with that selected offer after confirmation.
|
|
151
|
+
|
|
152
|
+
For persistent preference, set `preferred_offer_ids` in the node compute policy.
|
|
153
|
+
|
|
40
154
|
## [](https://flywheel.paradigma.inc//#tips)Tips
|
|
41
155
|
|
|
42
156
|
- Provisioning takes a few minutes — the agent polls automatically, so you don't need to babysit it.
|
|
@@ -1,160 +1,153 @@
|
|
|
1
1
|
# Flywheel MCP Tool Map
|
|
2
2
|
|
|
3
|
-
|
|
4
|
-
contract expected by the public Flywheel skill.
|
|
3
|
+
Contract-aligned routing guide for Flywheel MCP tool usage.
|
|
5
4
|
|
|
6
|
-
|
|
7
|
-
tool surface exposed by your current MCP host before executing critical flows.
|
|
5
|
+
Flywheel is a graph-based system for tracking research work, decisions, and evidence over time. Flywheel MCP is the tool interface for reading and updating that graph. You can discover, create, and manage nodes. You can collaborate with other users and use managed compute.
|
|
8
6
|
|
|
9
7
|
## Core Contract Expectations
|
|
10
8
|
|
|
11
|
-
-
|
|
12
|
-
|
|
13
|
-
- Node
|
|
14
|
-
- `
|
|
15
|
-
-
|
|
16
|
-
-
|
|
17
|
-
|
|
18
|
-
-
|
|
19
|
-
|
|
20
|
-
|
|
9
|
+
- Use `flywheel_get_contract` + `flywheel_get_contract_section` as canonical contract references.
|
|
10
|
+
- Node state is canonical durable state; avoid relying on ephemeral transcript state.
|
|
11
|
+
- Node kind (`untyped`, `empirical`, `insight`) is an explicit durable field.
|
|
12
|
+
- Node references include immutable `node_id` and optional immutable `slug_name`; prefer communicating both together for human clarity and disambiguation.
|
|
13
|
+
- Insight nodes should represent conceptual observations (theoretical insights, intuitions, motivations, decision-relevant framing); empirical nodes should represent experiments with explicit hypotheses and measured outcomes.
|
|
14
|
+
- Graph topology should encode logical/causal relations between concepts and experiments. Avoid defaulting to shallow root-only branching unless work items are truly independent.
|
|
15
|
+
- Node lifecycle semantics are interface-agnostic (`stage_node_create`, `stage_node_update`, `commit_node`); MCP tools are one projection of this shared contract.
|
|
16
|
+
- Mutating node writes are optimistic-locking operations: read latest state, pass `expected_revision`, and handle `409 conflict` with explicit reconciliation.
|
|
17
|
+
- Mutating operations are idempotent; MCP tool transport auto-manages `Idempotency-Key` on mutating tool calls.
|
|
18
|
+
- Commit is finalize-only: commit requests require `expected_revision` and may optionally override `summary`; committed node state must still satisfy strict contract (`summary`/`outcome`, `empirical+completed` requires artifacts or `no_artifacts_reason`, `insight` requires non-empty insights).
|
|
19
|
+
- When code is involved, pass `repo_url`/`branch_name`/`head_commit_sha` and align git structure with graph topology where practical (without forcing one-to-one mapping).
|
|
20
|
+
- Summaries, hypotheses, and artifacts should be reproduction-grade: enough setup, method, evidence, and interpretation for another reader to reproduce or audit results.
|
|
21
|
+
- Empirical workflow is hypothesis-driven: launch execution, inspect outcomes, publish evidence artifacts, and commit only after terminal status.
|
|
22
|
+
- For empirical work, publish evidence with `flywheel_prepare_artifact_uploads`, upload raw file bytes, then `flywheel_finalize_artifact_uploads` before commit.
|
|
23
|
+
- Artifact metadata records expose a non-empty `title` suitable for display labels; title normalization must never derive from `storage_url`.
|
|
21
24
|
|
|
22
25
|
## Tool Families
|
|
23
26
|
|
|
24
|
-
###
|
|
25
|
-
|
|
26
|
-
- `
|
|
27
|
-
- `
|
|
28
|
-
- `
|
|
29
|
-
- `
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
- `
|
|
34
|
-
- `
|
|
35
|
-
- `
|
|
36
|
-
- `
|
|
37
|
-
- `
|
|
38
|
-
- `
|
|
39
|
-
- `
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
- `
|
|
44
|
-
- `
|
|
45
|
-
- `
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
- `
|
|
50
|
-
- `
|
|
51
|
-
- `
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
- `
|
|
56
|
-
- `
|
|
57
|
-
- `
|
|
58
|
-
|
|
59
|
-
### Tags and Graph Annotation
|
|
60
|
-
|
|
61
|
-
- `mcp__flywheel__flywheel_create_node_tag`
|
|
62
|
-
- `mcp__flywheel__flywheel_update_node_tag`
|
|
63
|
-
- `mcp__flywheel__flywheel_delete_node_tag`
|
|
64
|
-
- `mcp__flywheel__flywheel_set_node_tag_assignments`
|
|
27
|
+
### Discovery and sharing
|
|
28
|
+
|
|
29
|
+
- `flywheel_auth_status` (read; scopes: `read`; HTTP: `GET /auth/status`; core surface): Return Flywheel auth status for the current access token.
|
|
30
|
+
- `flywheel_get_credits_balance` (read; scopes: `read`; HTTP: `GET /credits`; core surface): Return current user credits balance and lifetime counters.
|
|
31
|
+
- `flywheel_updates_list` (read; scopes: `read`; HTTP: `GET /mcp/updates`; core surface): List in-app updates/announcements for the signed-in user.
|
|
32
|
+
- `flywheel_updates_hide` (mutating; scopes: `write`; HTTP: `POST /mcp/updates/{announcement_id}/hide`; core surface): Mark one update as hidden for the current user (Don't show again).
|
|
33
|
+
- `flywheel_updates_hide_all_active` (mutating; scopes: `write`; HTTP: `POST /mcp/updates/hide-all-active`; core surface): Hide all active updates for the current user (Don't show all active again).
|
|
34
|
+
- `flywheel_updates_unhide` (mutating; scopes: `write`; HTTP: `DELETE /mcp/updates/{announcement_id}/hide`; core surface): Restore one hidden update for the current user.
|
|
35
|
+
- `flywheel_list_nodes` (read; scopes: `read`; HTTP: `GET /mcp/nodes`; full-surface only): List nodes with optional owners/writers/visibility filters and projection control (`core`, `topology`, `full`).
|
|
36
|
+
- `flywheel_resolve_node_slug` (read; scopes: `read`; HTTP: `GET /mcp/nodes/resolve-by-slug`; core surface): Resolve a node by slug_name with explicit conflict handling (`unique`, `context_resolved`, `ambiguous`, `not_found`).
|
|
37
|
+
- `flywheel_get_node_sharing` (read; scopes: `read`; HTTP: `GET /mcp/nodes/{node_id}/sharing`; full-surface only): Get node sharing for one node (owner/collaborators/visibility).
|
|
38
|
+
- `flywheel_set_sharing_for_node` (mutating; scopes: `write`; HTTP: `PUT /mcp/nodes/{node_id}/sharing`; full-surface only): Set sharing for one owned node (collaborators/private-unlisted-public visibility).
|
|
39
|
+
- `flywheel_set_sharing_for_nodes` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/sharing/bulk`; full-surface only): Apply one sharing configuration across multiple owned nodes in bulk.
|
|
40
|
+
- `flywheel_get_node` (read; scopes: `read`; HTTP: `GET /mcp/nodes/{node_id}`; core surface): Get one node by node_id.
|
|
41
|
+
- `flywheel_create_node_tag` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/{root_node_id}/tags`; full-surface only): Create one graph tag from a root node.
|
|
42
|
+
- `flywheel_update_node_tag` (mutating; scopes: `write`; HTTP: `PATCH /mcp/nodes/{root_node_id}/tags/{tag_id}`; full-surface only): Update one graph tag from a root node.
|
|
43
|
+
- `flywheel_delete_node_tag` (mutating; scopes: `write`; HTTP: `DELETE /mcp/nodes/{root_node_id}/tags/{tag_id}`; full-surface only): Delete one graph tag from a root node.
|
|
44
|
+
- `flywheel_set_node_tag_assignments` (mutating; scopes: `write`; HTTP: `PUT /mcp/nodes/{node_id}/tags`; full-surface only): Set graph tag assignments for one node.
|
|
45
|
+
- `flywheel_get_node_tree` (read; scopes: `read`; HTTP: `GET /mcp/nodes/{node_id}/tree`; full-surface only): Get a root-aware bounded tree/DAG projection for an anchor node.
|
|
46
|
+
- `flywheel_get_node_ancestry` (read; scopes: `read`; HTTP: `GET /mcp/nodes/{node_id}/ancestry`; full-surface only): Get ordered ancestry metadata from an anchor node to root boundaries.
|
|
47
|
+
- `flywheel_get_campaign_snapshot` (read; scopes: `read`; HTTP: `GET /mcp/nodes/{node_id}/campaign/snapshot`; core surface): Read the current campaign snapshot for a node's root campaign, including configured views and derived records.
|
|
48
|
+
- `flywheel_list_audit` (read; scopes: `read`; HTTP: `GET /mcp/nodes/{node_id}/audit`; full-surface only): List node MCP audit events.
|
|
49
|
+
|
|
50
|
+
### Node lifecycle
|
|
51
|
+
|
|
52
|
+
- `flywheel_stage_node_create` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/stage/create`; full-surface only): Stage creation of a new Flywheel node.
|
|
53
|
+
- `flywheel_stage_node_update` (mutating; scopes: `write`; HTTP: `PATCH /mcp/nodes/{node_id}/stage/update`; core surface): Stage mutable node fields, including content/readme text, with optimistic locking; use `no_artifacts_reason` when empirical completed nodes intentionally have no artifacts.
|
|
54
|
+
- `flywheel_commit_node` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/{node_id}/commit`; core surface): Commit a node with contract validation.
|
|
55
|
+
- `flywheel_branch_node` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/{node_id}/branch`; full-surface only): Create a child branch node.
|
|
56
|
+
- `flywheel_merge_nodes` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/merge`; full-surface only): Merge nodes with caller-resolved node payload.
|
|
57
|
+
- `flywheel_add_parent` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/{node_id}/parents/add`; full-surface only): Attach an additional parent edge to an existing node (keeps node identity, validates against cycles).
|
|
58
|
+
- `flywheel_remove_parent` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/{node_id}/parents/remove`; full-surface only): Detach one parent edge from a node without deleting the node.
|
|
59
|
+
- `flywheel_delete_node` (mutating; scopes: `write`; HTTP: `DELETE /mcp/nodes/{node_id}`; full-surface only): Delete a node subtree.
|
|
60
|
+
- `flywheel_bulk_delete_nodes` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/bulk-delete`; full-surface only): Delete multiple node subtrees in one operation.
|
|
65
61
|
|
|
66
62
|
### Artifacts
|
|
67
63
|
|
|
68
|
-
- `
|
|
69
|
-
- `
|
|
70
|
-
- `
|
|
71
|
-
- `
|
|
72
|
-
- `
|
|
73
|
-
- `
|
|
74
|
-
- `mcp__flywheel__flywheel_delete_artifact`
|
|
75
|
-
|
|
76
|
-
Common artifact types include:
|
|
77
|
-
`text`, `table`, `json`, `image`, `banner`, `html`, `plotly_html`, `vega`,
|
|
78
|
-
`checkpoint`, and `diff_carousel`.
|
|
79
|
-
|
|
80
|
-
### Export and Import
|
|
81
|
-
|
|
82
|
-
- `mcp__flywheel__flywheel_export_subgraph`
|
|
83
|
-
- `mcp__flywheel__flywheel_import_subgraph`
|
|
84
|
-
- `mcp__flywheel__flywheel_export_summary`
|
|
85
|
-
- `mcp__flywheel__flywheel_export_summary_stream`
|
|
86
|
-
- `mcp__flywheel__flywheel_export_summary_pdf`
|
|
87
|
-
- `mcp__flywheel__flywheel_export_summary_render_pdf`
|
|
64
|
+
- `flywheel_prepare_artifact_uploads` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/{node_id}/artifacts/uploads/prepare`; core surface): Prepare one or more raw-file artifact uploads (returns batch token + signed upload URLs). Upload must send raw file bytes to the returned URLs (do not upload JSON metadata wrappers).
|
|
65
|
+
- `flywheel_finalize_artifact_uploads` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/{node_id}/artifacts/uploads/finalize`; core surface): Finalize a prepared artifact upload batch and append all staged artifacts to the node in one revision bump.
|
|
66
|
+
- `flywheel_list_artifacts` (read; scopes: `read`; HTTP: `GET /mcp/nodes/{node_id}/artifacts`; core surface): List node artifacts.
|
|
67
|
+
- `flywheel_get_artifact` (read; scopes: `read`; HTTP: `GET /mcp/nodes/{node_id}/artifacts/{artifact_id}`; core surface): Get one artifact by id.
|
|
68
|
+
- `flywheel_delete_artifact` (mutating; scopes: `write`; HTTP: `DELETE /mcp/nodes/{node_id}/artifacts/{artifact_id}`; core surface): Delete one artifact by id with optimistic locking.
|
|
69
|
+
- `flywheel_set_artifact_note` (mutating; scopes: `write`; HTTP: `PATCH /mcp/nodes/{node_id}/artifacts/{artifact_id}/note`; core surface): Set or clear one artifact note with optimistic locking.
|
|
88
70
|
|
|
89
71
|
### Executions
|
|
90
72
|
|
|
91
|
-
- `
|
|
92
|
-
- `
|
|
93
|
-
- `
|
|
94
|
-
|
|
95
|
-
###
|
|
96
|
-
|
|
97
|
-
- `
|
|
98
|
-
- `
|
|
99
|
-
- `
|
|
100
|
-
- `
|
|
101
|
-
- `
|
|
102
|
-
- `
|
|
103
|
-
- `
|
|
104
|
-
- `
|
|
105
|
-
- `
|
|
106
|
-
- `
|
|
107
|
-
- `
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
- `
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
73
|
+
- `flywheel_launch_execution` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/{node_id}/executions`; core surface): Launch node execution.
|
|
74
|
+
- `flywheel_list_executions` (read; scopes: `read`; HTTP: `GET /mcp/nodes/{node_id}/executions`; core surface): List node executions.
|
|
75
|
+
- `flywheel_terminate_execution` (mutating; scopes: `write`; HTTP: `POST /mcp/nodes/{node_id}/executions/{execution_id}/terminate`; core surface): Terminate a node execution.
|
|
76
|
+
|
|
77
|
+
### Compute and budgets
|
|
78
|
+
|
|
79
|
+
- `flywheel_compute_list_options` (read; scopes: `compute`; HTTP: `GET /mcp/nodes/{node_id}/compute/options`; core surface): List managed compute options allowed for a node. When using grant-backed compute, pass the same compute_grant_id you will use for acquire.
|
|
80
|
+
- `flywheel_compute_status` (read; scopes: `compute`; HTTP: `GET /mcp/compute/status`; core surface): Read managed compute lease status for the current user. Lease rows include ownership flags so hosts can distinguish user-owned leases from sponsor-visible campaign leases. When checking a grant-backed lease, reuse the same compute_grant_id passed to acquire.
|
|
81
|
+
- `flywheel_compute_connection` (read; scopes: `compute`; HTTP: `GET /mcp/compute/connection`; core surface): Read SSH connection material for an active managed compute lease once flywheel_compute_status indicates the lease is usable. Only leases owned by the current user are connectable. Pass lease_id or node_id to disambiguate when needed.
|
|
82
|
+
- `flywheel_approval_session_heartbeat` (read; scopes: `compute`; HTTP: `POST /mcp/approval-sessions/heartbeat`; core surface): Create or refresh a compute-grant approval session for the current MCP host session.
|
|
83
|
+
- `flywheel_list_approval_sessions` (read; scopes: `compute`; HTTP: `GET /mcp/approval-sessions`; core surface): List approval sessions visible to the current user. Optionally include grant approval bindings for each session.
|
|
84
|
+
- `flywheel_expire_approval_session` (mutating; scopes: `compute`; HTTP: `POST /mcp/approval-sessions/expire`; core surface): Expire the current compute-grant approval session and release its active leases.
|
|
85
|
+
- `flywheel_request_compute_grant_approval` (mutating; scopes: `compute`; HTTP: `tool-mediated`; core surface): Request budget approval and return approval_url + request_id for user confirmation before managed compute acquisition.
|
|
86
|
+
- `flywheel_list_compute_grants` (read; scopes: `compute`; HTTP: `GET /mcp/compute/grants`; core surface): List active/exhausted compute grants available to the current user.
|
|
87
|
+
- `flywheel_list_campaign_budgets` (read; scopes: `compute`; HTTP: `GET /mcp/nodes/{root_node_id}/campaign-budgets`; full-surface only): List campaign compute budgets for a campaign root. Organizer-only management view.
|
|
88
|
+
- `flywheel_create_campaign_budget` (mutating; scopes: `compute`; HTTP: `POST /mcp/nodes/{root_node_id}/campaign-budgets`; full-surface only): Create an organizer-funded campaign compute budget shared with participants.
|
|
89
|
+
- `flywheel_update_campaign_budget` (mutating; scopes: `compute`; HTTP: `PATCH /mcp/nodes/{root_node_id}/campaign-budgets/{compute_budget_id}`; full-surface only): Update hard caps or metadata for an organizer-funded campaign compute budget.
|
|
90
|
+
- `flywheel_revoke_campaign_budget` (mutating; scopes: `compute`; HTTP: `DELETE /mcp/nodes/{root_node_id}/campaign-budgets/{compute_budget_id}`; full-surface only): Revoke an organizer-funded campaign compute budget.
|
|
91
|
+
- `flywheel_compute_acquire` (mutating; scopes: `compute`; HTTP: `POST /mcp/nodes/{node_id}/compute/acquire`; core surface): Acquire managed compute for a node with explicit SKU + region and required compute_grant_id (returns accepted/completed lease state only; poll flywheel_compute_status for readiness, not SSH key material). This tool heartbeats and forwards approval_session_id.
|
|
92
|
+
- `flywheel_compute_release` (mutating; scopes: `compute`; HTTP: `POST /mcp/compute/release`; core surface): Asynchronously release one managed compute lease by lease_id.
|
|
93
|
+
- `flywheel_compute_release_all` (mutating; scopes: `compute`; HTTP: `POST /mcp/compute/release-all`; core surface): Asynchronously release all active managed compute leases for the current user.
|
|
94
|
+
|
|
95
|
+
### Contract, audit, and export
|
|
96
|
+
|
|
97
|
+
- `flywheel_get_contract` (read; scopes: `read`; HTTP: `GET /mcp/contract`; core surface): Return Flywheel MCP contract overview (scopes, write safety, operation catalog, and section index).
|
|
98
|
+
- `flywheel_get_contract_section` (read; scopes: `read`; HTTP: `GET /mcp/contract/sections/{section_id}`; core surface): Return one contract section by section_id (for example `graph` or `campaign/template_v1`).
|
|
99
|
+
- `flywheel_export_subgraph` (read; scopes: `read`; HTTP: `POST /mcp/export`; full-surface only): Export selected graph/subgraph nodes as JSON.
|
|
100
|
+
- `flywheel_import_subgraph` (mutating; scopes: `write`; HTTP: `POST /mcp/import`; full-surface only): Import graph/subgraph JSON payload into new node IDs. Set normalize_cycles=true to drop cycle/self-loop edges; default rejects cyclic payloads.
|
|
101
|
+
- `flywheel_summarize_node_tree` (read; scopes: `read`; HTTP: `GET /mcp/nodes/{node_id}/summary`; full-surface only): Summarize a node tree using node fields only.
|
|
102
|
+
- `flywheel_export_summary` (read; scopes: `read`; HTTP: `POST /mcp/export-summary`; full-surface only): Generate markdown summary for selected nodes.
|
|
103
|
+
- `flywheel_export_summary_stream` (read; scopes: `read`; HTTP: `POST /mcp/export-summary-stream`; full-surface only): Generate summary stream events for selected nodes.
|
|
104
|
+
- `flywheel_export_summary_pdf` (read; scopes: `read`; HTTP: `POST /mcp/export-summary-pdf`; full-surface only): Generate PDF summary for selected nodes.
|
|
105
|
+
- `flywheel_export_summary_render_pdf` (read; scopes: `read`; HTTP: `POST /mcp/export-summary-render-pdf`; full-surface only): Render provided markdown to PDF and embed export metadata.
|
|
121
106
|
|
|
122
107
|
## Practical Tool Sequences
|
|
123
108
|
|
|
124
|
-
###
|
|
125
|
-
|
|
126
|
-
1. `
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
-
|
|
159
|
-
-
|
|
160
|
-
-
|
|
109
|
+
### List Owned Nodes
|
|
110
|
+
|
|
111
|
+
1. `flywheel_list_nodes` with `{'owners': ['me'], 'projection': 'core'}`.
|
|
112
|
+
|
|
113
|
+
### Safe Node Update
|
|
114
|
+
|
|
115
|
+
1. `flywheel_get_node`: Read latest node state before mutating fields.
|
|
116
|
+
2. `flywheel_stage_node_update`: Stage changes with fresh expected_revision and resolve 409 conflicts explicitly.
|
|
117
|
+
3. `flywheel_commit_node`: Commit once terminal and contract-complete.
|
|
118
|
+
|
|
119
|
+
### Empirical Workflow
|
|
120
|
+
|
|
121
|
+
1. `flywheel_stage_node_create`: Create a staged node, then set empirical fields before execution.
|
|
122
|
+
2. `flywheel_stage_node_update`: Set `kind=empirical`, `hypothesis`, and summary fields with fresh `expected_revision`.
|
|
123
|
+
3. `flywheel_request_compute_grant_approval`: If compute is needed, request budget approval first. Response status is `approval_required`.
|
|
124
|
+
4. Branch on `flywheel_request_compute_grant_approval.status`: Branch by response status. `approval_required` is a response state, not a request parameter.. if `approval_required` then `present_approval_url_to_user`: Present `approval_url` to the user; the user opens it and confirms budget approval.; `flywheel_list_approval_sessions`: After approval, list approval sessions with include_approvals=true and use the active `compute_grant_id` for the current approval_session_id.
|
|
125
|
+
5. `flywheel_compute_acquire`: Acquire lease with `compute_grant_id`; include `approval_session_id` from approval response.
|
|
126
|
+
6. `flywheel_compute_status`: Poll until the active lease is ready; follow `recommended_next_action`.
|
|
127
|
+
7. `flywheel_launch_execution`: Launch execution once compute and inputs are ready.
|
|
128
|
+
8. `flywheel_list_executions`: Poll until execution reaches terminal status.
|
|
129
|
+
9. `flywheel_prepare_artifact_uploads`: Prepare signed upload URLs for empirical evidence.
|
|
130
|
+
10. `raw_file_upload`: Upload raw bytes to each signed URL with required headers.
|
|
131
|
+
11. `flywheel_finalize_artifact_uploads`: Finalize prepared uploads before commit, or set `no_artifacts_reason` when intentionally artifact-free.
|
|
132
|
+
12. `flywheel_commit_node`: Commit terminal empirical node once contract requirements are satisfied.
|
|
133
|
+
|
|
134
|
+
## Runtime Guidance
|
|
135
|
+
|
|
136
|
+
- `flywheel_resolve_node_slug`: resolve human-facing slug references. If response status is `ambiguous`, ask the user to confirm the intended node_id before mutating anything.
|
|
137
|
+
- `flywheel_get_node`: read the current node state before writes.
|
|
138
|
+
- `flywheel_stage_node_update`: update in-progress node fields (title/content/summary, kind/outcome/hypothesis/insights/no_artifacts_reason), always with fresh `expected_revision`.
|
|
139
|
+
- `flywheel_get_campaign_snapshot`: read the current derived campaign state for this node's root campaign instead of inferring standings from freeform text.
|
|
140
|
+
- `flywheel_get_node_sharing`: after sharing writes, verify with flywheel_get_node_sharing before reporting private/shared/public state.
|
|
141
|
+
- `flywheel_compute_status`: check first when work may need managed compute (GPU), to detect any active user lease state.
|
|
142
|
+
- `flywheel_list_compute_grants`: list active compute grants (funded by user/root budgets) and select one `compute_grant_id` for acquisition.
|
|
143
|
+
- `flywheel_request_compute_grant_approval`: request/confirm budget before acquire and choose a budget source (`user` or `root`); this returns `approval_url` + `request_id` when interactive approval is needed.
|
|
144
|
+
- `flywheel_compute_connection`: read SSH connection material for the active user lease once status indicates the lease is usable.
|
|
145
|
+
- `flywheel_compute_list_options`: use when a lease is needed and no suitable active lease exists, then select explicit provider-qualified `offer_id` (`provider::offer_id`) and `region`. Consider each option's `availability_mode`: `live_capacity` means provider-reported capacity, `allocation_time` means capacity is confirmed only when `flywheel_compute_acquire` attempts provisioning.
|
|
146
|
+
- `flywheel_compute_acquire`: provision compute once requirements are clear. This requires a valid `compute_grant_id` and returns lease/provisioning state only (not SSH key material).
|
|
147
|
+
- `flywheel_compute_release`: release compute when no longer needed.
|
|
148
|
+
- `flywheel_launch_execution`, `flywheel_list_executions`, `flywheel_terminate_execution`: manage execution lifecycle.
|
|
149
|
+
- `flywheel_prepare_artifact_uploads`: prepare one or more signed raw-file upload requests for concrete deliverables/evidence produced by the work.
|
|
150
|
+
- `flywheel_finalize_artifact_uploads`: finalize a staged artifact batch and append all uploaded artifacts in one revision bump.
|
|
151
|
+
- `flywheel_delete_artifact`: remove an accidental/obsolete node artifact.
|
|
152
|
+
- `flywheel_list_artifacts`, `flywheel_get_artifact`: inspect node artifact metadata (`title` is the display label) and consume `storage_url` for raw artifact bytes only.
|
|
153
|
+
- `flywheel_commit_node`: finalize staged node state once terminal and contract-complete (optional summary override only).
|
|
@@ -21,7 +21,8 @@ Before execution, recover or establish these inputs:
|
|
|
21
21
|
- Ask only when a required execution input cannot be recovered from explicit user instructions, current conversational context, or recent graph state.
|
|
22
22
|
- If start nodes cannot be recovered from explicit ids/slugs, named current context, or recent graph context, ask once.
|
|
23
23
|
- If the objective is missing, ask once; if the user refuses, infer it from graph context and persist it before execution.
|
|
24
|
-
- If budget ceiling
|
|
24
|
+
- If budget ceiling or budget unit is missing, ask once before execution.
|
|
25
|
+
- If budget ceiling and budget unit are present but terminal condition is missing, set `terminal_condition: "budget ceiling reached"` and persist that derivation in the control node `content` before compute request or acquisition.
|
|
25
26
|
- If the user gives a non-credit budget unit, persist that exact user-facing unit and derive the operational compute approval cap before acquisition.
|
|
26
27
|
|
|
27
28
|
## Working Terms
|
|
@@ -37,6 +38,7 @@ Before execution, recover or establish these inputs:
|
|
|
37
38
|
- Use artifacts for supporting files and evidence, not as a substitute for the node's main narrative.
|
|
38
39
|
- Only create graph edges for durable semantic relationships, because graphifying every wiki link floods the graph with noise that hides decision-relevant structure.
|
|
39
40
|
- Treat the flywheel-auto skill as graph-local autonomous research: persist the run contract in the graph, keep the plan `n` hops ahead, and spend only within an explicit measured budget.
|
|
41
|
+
- When guidance from flywheel, flywheel-lookahead, flywheel-reproduce, or flywheel-to-graph conflicts during an active $flywheel-auto run, flywheel-auto rules take precedence for compute, questioning, and stop decisions.
|
|
40
42
|
- Ask only the minimum clarification questions needed to establish a coherent control contract, and ask none when the required answers are already recoverable from user instructions, conversational context, or graph state.
|
|
41
43
|
- Planned nodes that are expected to produce evidence or artifacts should be typed `empirical`; planned nodes that only encode synthesis, decomposition, or decision structure should be typed `insight`.
|
|
42
44
|
- Keep the control node typed `insight` and keep its `insights` non-empty so the insight commit contract stays valid.
|
|
@@ -49,12 +51,12 @@ Before execution, recover or establish these inputs:
|
|
|
49
51
|
2. Resolve the objective and budget contract.
|
|
50
52
|
- Recover required execution inputs from the current conversation and graph first. Ask only for inputs that remain genuinely missing after that recovery pass.
|
|
51
53
|
- The flywheel-auto skill requires a measurable objective and an explicit terminal condition. Ask once for missing prerequisites; if the user refuses to specify an objective, infer it from the available graph context and state it explicitly before continuing.
|
|
52
|
-
- The budget contract must be explicit before execution starts. Ask once for
|
|
54
|
+
- The budget contract must be explicit before execution starts. Ask once for missing budget ceiling or budget unit. When budget ceiling and budget unit are present but terminal condition is missing, derive `terminal_condition: "budget ceiling reached"` and persist that derivation into the control node `content` before any compute request or acquisition.
|
|
53
55
|
- Managed compute spend is billed in Flywheel credits. If the user gives dollars, hours, or another measurable budget semantic, persist that user-facing cap explicitly and derive the operational compute approval cap before acquisition.
|
|
54
56
|
- Persist the run contract in a dedicated `insight` control node for this frontier. Put the canonical contract in node `content`, keep a one-line synopsis in `summary`, and keep brief run rationale in `insights` so the commit contract stays valid.
|
|
55
57
|
- The control contract must name: objective, decision criterion, start nodes, budget ceiling and unit, lookahead depth `n`, frontier width `k`, and an explicit terminal condition.
|
|
56
58
|
- Later flywheel-auto replans must read the control node `content` first and continue from that persisted contract rather than from chat memory.
|
|
57
|
-
- Run the design gate from [references/experiment-design-protocol.md](references/experiment-design-protocol.md) before the first compute request: confirm objective, decision criterion, evidence plan,
|
|
59
|
+
- Run the design gate from [references/experiment-design-protocol-autonomous.md](references/experiment-design-protocol-autonomous.md) before the first compute request: confirm objective, decision criterion, evidence plan, budget readiness, and stop-reason recording requirements, even though later continuation decisions become graph-local.
|
|
58
60
|
3. Map each stable page, claim, or concept to a node.
|
|
59
61
|
- For exact node-mutation shapes, load [references/flywheel-mcp-tool-map.md](references/flywheel-mcp-tool-map.md).
|
|
60
62
|
- Create a new node with `flywheel_stage_node_create` when needed.
|
|
@@ -78,14 +80,20 @@ Before execution, recover or establish these inputs:
|
|
|
78
80
|
- In the flywheel-auto skill, the same `k` also caps concurrent workers pursuing executable frontier nodes.
|
|
79
81
|
- Keep unresolved plan nodes staged until the corresponding work is resolved.
|
|
80
82
|
8. Execute and replan continuously.
|
|
81
|
-
- For exact execution and compute request shapes, load [references/flywheel-mcp-tool-map.md](references/flywheel-mcp-tool-map.md) and [references/experiment-design-protocol.md](references/experiment-design-protocol.md).
|
|
83
|
+
- For exact execution and compute request shapes, load [references/flywheel-mcp-tool-map.md](references/flywheel-mcp-tool-map.md) and [references/experiment-design-protocol-autonomous.md](references/experiment-design-protocol-autonomous.md).
|
|
82
84
|
- Use `flywheel_launch_execution` when the branch can run as a Flywheel node execution without a separate leased machine, and inspect terminal status before commit.
|
|
83
|
-
- Use managed compute when the branch needs provider or SKU choice, SSH access, a custom runtime, or longer-lived hardware. In that case use `flywheel_request_compute_grant_approval`, resolve the approved `compute_grant_id` with `flywheel_list_compute_grants` or `flywheel_list_approval_sessions`, then `flywheel_compute_acquire`, poll `flywheel_compute_status`, and use `flywheel_compute_connection` when the lease is ready.
|
|
85
|
+
- Use managed compute when the branch needs provider or SKU choice, SSH access, a custom runtime, or longer-lived hardware. In that case use `flywheel_request_compute_grant_approval`, resolve the approved `compute_grant_id` with `flywheel_list_compute_grants` or `flywheel_list_approval_sessions`, call `flywheel_compute_list_options`, recommend one offer deterministically and present up to two alternatives, wait for explicit user confirmation (or explicit user override offer id), then `flywheel_compute_acquire`, poll `flywheel_compute_status`, and use `flywheel_compute_connection` when the lease is ready.
|
|
84
86
|
- Spawn up to `k` workers for distinct executable frontier nodes.
|
|
87
|
+
- For `k > 1`, apply the list-options -> recommendation -> explicit confirmation boundary per worker before each worker-specific acquire call.
|
|
85
88
|
- Route additional viable branches sequentially when there are more than `k` worthwhile directions.
|
|
86
89
|
- After each resolved node, refresh the lookahead so the graph remains `n` hops ahead.
|
|
87
|
-
- Release managed compute
|
|
90
|
+
- Release managed compute when a branch is done. Default to releasing only
|
|
91
|
+
known leases. Use `flywheel_compute_release_all` only when the user
|
|
92
|
+
explicitly requests account-wide cleanup.
|
|
88
93
|
- Stop only when the graph-local terminal condition says to stop, such as: objective met, budget exhausted, or no non-redundant frontier branch is likely to produce enough decision-relevant information to justify the remaining budget and duplication risk.
|
|
94
|
+
- If stopping because no non-redundant frontier branch is worth pursuing, record a per-candidate rejection rationale in control node `content` before termination.
|
|
95
|
+
- Before every termination path, persist `stop_reason` in control node `content` as one of: `budget_exhausted`, `objective_met`, `no_viable_branch`, `user_cancelled`, `runtime_error`.
|
|
96
|
+
|
|
89
97
|
9. Commit after the node snapshot is coherent with `flywheel_commit_node`.
|
|
90
98
|
- Commit resolved insight nodes only when they have non-empty `insights`.
|
|
91
99
|
- Commit resolved empirical nodes only when outcome and artifact rules are satisfied.
|
|
@@ -100,7 +108,8 @@ When the skill completes a pass, it should leave behind:
|
|
|
100
108
|
- Zero or more committed resolved nodes, but only when their commit contracts are satisfied.
|
|
101
109
|
- Uploaded artifacts for completed empirical work, or an explicit `no_artifacts_reason` when artifacts are absent by design.
|
|
102
110
|
- Released managed compute if any lease was acquired during the pass.
|
|
103
|
-
- An explicit
|
|
111
|
+
- An explicit `stop_reason` recorded in node state so a later pass can resume graph-locally.
|
|
112
|
+
- If the no-branch stop clause is used, a per-candidate rejection log recorded in control node `content`.
|
|
104
113
|
|
|
105
114
|
## Persisted Control Contract
|
|
106
115
|
|
|
@@ -138,6 +147,7 @@ Canonical contract shape:
|
|
|
138
147
|
- Lookahead depth:
|
|
139
148
|
- Frontier width:
|
|
140
149
|
- Terminal condition:
|
|
150
|
+
- Stop reason:
|
|
141
151
|
```
|
|
142
152
|
|
|
143
153
|
Use `Compute approval cap` for the operational cap that will govern managed
|
|
@@ -11,6 +11,12 @@
|
|
|
11
11
|
"expected_output": "Persist the dollar-denominated budget ceiling and unit verbatim in the control node, derive an operational compute approval cap before acquisition, record both values before any compute request is made, and leave a coherent run contract behind for later continuation.",
|
|
12
12
|
"files": []
|
|
13
13
|
},
|
|
14
|
+
{
|
|
15
|
+
"id": "cold-start-budget-only-auto-exhaustion",
|
|
16
|
+
"prompt": "Use $flywheel-auto to continue autonomously under a budget ceiling when only the budget contract is explicit at cold start.",
|
|
17
|
+
"expected_output": "When terminal condition is missing but budget ceiling and budget unit are explicit, derive terminal condition as budget ceiling reached, continue autonomously without premature user handoff, and persist stop_reason in the committed control contract before termination.",
|
|
18
|
+
"files": []
|
|
19
|
+
},
|
|
14
20
|
{
|
|
15
21
|
"id": "cold-start-with-no-objective",
|
|
16
22
|
"prompt": "Use $flywheel-auto to go autonomous on this Flywheel graph until you find something interesting. If I refuse to specify an objective, infer one from the graph context and make it explicit before you execute.",
|