Update to Keel

{
  "description": "Change an existing strategy with one focused edit: the user's own strategy takes the change as its next version (earlier versions and their backtests stay in its history); a shared link or a Keel Library entry is forked first. Read the whole source, choose the smallest edit that meets the intent, dry-run, save once per user-visible step, explain the change view. Use when the user names a strategy and asks for a change, or says \"fork\", \"based on\", \"like that but ...\", \"import this share link\", \"start from the library\". Not for authoring from scratch (strategy-creation) or for merely reading a strategy (keel_strategy_get).\n",
  "included_files": [],
  "name": "strategy-fork-and-iterate",
  "skill_md_contents": "---\nname: strategy-fork-and-iterate\ndescription: |\n  Change an existing strategy with one focused edit: the user's own strategy takes the change as its next version (earlier versions and their backtests stay in its history); a shared link or a Keel Library entry is forked first. Read the whole source, choose the smallest edit that meets the intent, dry-run, save once per user-visible step, explain the change view. Use when the user names a strategy and asks for a change, or says \"fork\", \"based on\", \"like that but ...\", \"import this share link\", \"start from the library\". Not for authoring from scratch (strategy-creation) or for merely reading a strategy (keel_strategy_get).\nreferences:\n  - step: 3\n    topic: \"dsl_syntax\"\n    why: \"'Strategy Template & Iterative Changes' — which declarations never move without being asked; scope-to-request examples\"\n  - step: 3\n    topic: \"composition_mechanics\"\n    why: \"adding a branch: Parallel semantics, branch isolation, the two mask systems\"\n  - step: 3\n    topic: \"reasoning_principles\"\n    why: \"invariants a swap must preserve: terminal WeightSeries, one clock, each transform once\"\n  - step: 4\n    topic: \"rule:<CODE>\"\n    why: \"the lesson behind a validation issue code the dry run returns\"\n  - step: 4\n    topic: \"mistakes\"\n    why: \"structural mistakes to flag (not fix) when you meet them in the existing source\"\ntools:\n  - keel_strategy_search\n  - keel_strategy_get\n  - keel_strategy_fork\n  - keel_library_list\n  - keel_library_fork\n  - keel_strategy_compose\n  - keel_strategy_diff\n  - keel_strategy_history\n  - keel_strategy_restore\n  - keel_backtest_run\n---\n\n# References\n\nReference topics this workflow cites (keel_help topics):\n\n- Step 3 — `dsl_syntax` — 'Strategy Template & Iterative Changes' — which declarations never move without being asked; scope-to-request examples\n- Step 3 — `composition_mechanics` — adding a branch: Parallel semantics, branch isolation, the two mask systems\n- Step 3 — `reasoning_principles` — invariants a swap must preserve: terminal WeightSeries, one clock, each transform once\n- Step 4 — `rule:<CODE>` — the lesson behind a validation issue code the dry run returns\n- Step 4 — `mistakes` — structural mistakes to flag (not fix) when you meet them in the existing source\n\n# Method\n\n## Step 1 — Resolve the source\n\n- A strategy id the user owns → go to Step 2. Its variants (a 10D vs 30D\n  lookback, a buffer sweep) are VERSIONS of that strategy — one compose save\n  each, `message` naming the change — not forks, the same as the Keel app,\n  which saves every edit as a version; there are no unsaved variants. A sweep\n  is small (2–4 versions): one backtest each, `keel_backtest_compare` once,\n  then `keel_strategy_restore(ref=<n>)` makes the chosen version HEAD — HEAD\n  is the pick, not whichever version was saved last. Earlier versions and\n  their backtests stay in the strategy's history, so a before/after\n  comparison needs no fork, and the reply names the save by its version\n  (v2, v3 …), never as a fork. Fork only to copy someone else's, a share link or a\n  Library strategy, when the user asks for a separate copy, or when the work\n  heads in an entirely new direction (Step 3's structural rewrite).\n- A share link / share id → `keel_strategy_fork(source=<id>)` → a new owned\n  `strategy_id`.\n- A Keel Library entry → `keel_library_list` for the slug, then\n  `keel_library_fork(slug=...)` → a new owned `strategy_id`.\n- \"That strategy from last week\" → `keel_strategy_search(query=..., limit=5)`,\n  confirm which.\n\n## Step 2 — Read the whole source\n\n`keel_strategy_get(strategy_id=<id>, include_source=true)` and read it end to end\nbefore proposing anything — the request often presupposes structure that is\nor is not there. (Hosts that browse resources may read\n`keel://strategy/<id>/source` instead.)\n\n## Step 3 — Choose the smallest edit\n\nFor each requested change, classify it:\n\n- parameter tweak (lookback, threshold) → edit that one value;\n- component swap (`EqualWeightSizer` → `VolWeightSizer`) → one component,\n  then check the downstream type and any slot it now needs;\n- new branch (a filter, a confirmation) → a `Parallel` with the existing\n  computation as one branch, not a serial Store/Load chain;\n- structural rewrite → push back: \"this is a new strategy; want me to draft\n  it from scratch?\"\n\nNever change the architecture (discrete ↔ continuous, single ↔ multi-signal)\nwithout asking. Never remove or alter anything unrelated to the request; a bug\nyou notice is a separate question, not a silent fix. `Execution(...)` stays as\nit is unless the user asks to change it.\n\n## Step 4 — Dry run, then save once per user-visible step\n\n1. `keel_strategy_compose(strategy_id=<id>, source=<edited>, dry_run=True)` — fix\n   what it names (`keel_help(topic=\"rule:<CODE>\")` for the lesson).\n2. `keel_strategy_compose(strategy_id=<id>, source=<edited>, message=<the change>)`\n   — the next version, visible in `keel_strategy_history` and the web app under\n   that message (derived from the change when omitted). A dry run is the\n   agent's own check: the user sees one \"Draft check\" row, so while drafting\n   the reply says the draft is being revised rather than quoting parser or\n   validator text, unless the user asked for the detail. Save once per\n   user-visible step; the save's `view` — its card, which carries the name,\n   the change and the links — is what the reply explains, by name. When the\n   question is what differs between two strategies or two versions,\n   `keel_strategy_diff` answers it (two strategies: pass each one's source)\n   and draws the change as a card; the reply names the change in a line\n   rather than pasting either source.\n\n## Step 5 — Undo when the user changes their mind\n\n`keel_strategy_history` for the prior version; then\n`keel_strategy_restore(strategy_id=<id>, ref=<n>)` — a forward commit that makes\nthat version HEAD, history preserved (the same as reading it with\n`keel_strategy_get(version=<n>, include_source=true)` and saving it again).\n\n# Decision points\n\n- When the user asks for improvements: 1–2 that are useful and easy to\n  understand (parameter, buffering, smoothing, a second signal) — never a list\n  of ten.\n- \"Get more trades\" → thresholds / filters / hold periods, not a path change;\n  \"too much turnover\" → smooth the signal or `buffered`; \"this period was bad\"\n  → diagnose the mechanism, no rearchitecture.\n- A larger change is proposed and waits for the user's approval.\n\n# Output shape\n\n1. The save's `view`: where the host draws it the user already sees it —\n   explain it in your own words; elsewhere its markdown stands in.\n2. One sentence naming the change (\"Swapped equal-weight sizing for\n   vol-targeted sizing at 20% annualized\").\n3. The new `version` and `hero_url`.\n4. If the user wants the change tested: a backtest of the new version,\n   compared against the previous version's run.\n\n# When NOT to use\n\n- A brand-new strategy → `strategy-creation` (do not fork a nominal template\n  for a structurally different idea).\n- Just reading a strategy → `keel_strategy_get(include_source=true)`.\n- Running the backtest → `backtest-and-analyze`.\n\n# Test prompts\n\n1. \"Fork str_K9p2Lz and change the lookback from 20 to 30.\"\n2. \"Based on the shared strategy gDXjURKqWPs8CZ4eXdqAI, can you add a BTC\n   beta hedge?\"\n3. \"Take my funding-carry strategy and switch it to vol-targeted sizing.\"\n"
}