+
+| Compatibility |
+
+I considered supporting YAML for local snippets (`.wt.json`), instead of JSON.
+JSON is not super friendly to command-lines - since everything's gotta be
+encapsulated as a string. Embedding tabs `\t`, newlines `\r`, escape characters,
+is fairly straightforward. However, quotes can get complicated fast in JSON,
+since they've got to be escaped too, and with many CLI utilities also having
+separate quote-parsing rules, JSON can get unwieldy quickly.
+
+However, supporting YAML directly would require us to spec out a YAML syntax for
+these files, and also find an OSS YAML parser and implement support for it. That
+would be quite a bit more expensive than JSON.
+
+ |
+
+| Accessibility |
+
+Nothing particular to call out here. The Snippets pane will need to be a11y
+tested, like most of our other UI surfaces.
+
+ |
+
+| Sustainability |
+
+No substantial climate impacts expected here. We're not using expensive compute
+resources for this feature, so the impact should be comparable to any other
+Terminal feature.
+
+ |
+
+| Localization |
+
+I'm mildly worried here about the potential for community-driven tasks to have
+non-localized descriptions. We may need to accept a `description:{ en-us:"",
+pt-br:"", ...}`-style map of language->string descriptions. That may just need
+to be a future consideration for now.
+
+ |
+
+| Security |
+
+Another reason we shouldn't support keys being able to be lazy-bound to local
+snippets: It's entirely too easy for `malicious.exe` to create a file in
+`%HomePath%` that creates a snippet for `\u003pwn-your-machine.exe\r` (or
+similar). Any app can read your settings file, and it is again too easy for that
+malicious app to set it's own action `id` to the same as some other well-meaning
+local snippet's ID which you DO have bound to a key.
+
+When we first load the snippets from the `.wt.json` file, we'll want to also ask
+them if they trust that folder. This is similar to the way that VsCode et. al.
+If they accept, then we'll add that folder to a list of trusted folders (and
+store permanently in `state.json`). If they don't, then we'll just ignore that
+file. To make things easier for the user, we can also add a checkbox to "trust
+the parent folder" in the dialog (again, similar to VsCode).
+
+We'll also want to engage our security partners to see if there's anything extra
+we'll need to do to ensure we're securely parsing random JSON files that we
+don't own.
+
+ |
+
+
+
+### Other potential issues
+
+Something like `wt save ping 8.8.8.8 > foo.txt` isn't going to work the way
+users want. The shell is gonna get the first crack at parsing that commandline,
+and is going to try and redirect the _output of `wt`_ to `foo.txt`.
+
+Predictably, local snippets won't work over ssh or other remote connections.
+Terminal is only able to read files off the local filesystem. We'll at best be
+able to read snippets from the directory they `ssh`'d _from_ locally.
+
+## Implementation Plan
+
+### 🐣 Crawl
+* [ ] The Command Palette and Suggestions UI need to be able to display both the
+ command name and a tooltip for the comment
+ - This will need to be reconciled with [#7039], which tracks displaying
+ non-localized names in the command palette
+ - It won't be a TeachingTip, since those are an unmitigated disaster. But we
+ can just fake it with another text box.
+ - A prototype can be found in [#17376]
+* [X] [#1595] Add the Suggestions UI, with support for `tasks`
+* [x] Fragments can add **actions** to a user's settings
+
+### 🚶 Walk
+* [ ] The terminal can look for a settings file of tasks in a profile's
+ `startingDirectory` (regardless of shell integration being enabled)
+* [ ] [#5790] - profile specific actions
+* [ ] [#12857] Ability to save selected text as a `sendInput` action
+* [x] [#12861] Re-evaluate showing some sort of "ghost text" or other preview for snippets
+
+### 🏃♂️ Run
+* [ ] When the user `cd`s to a directory (with shell integration enabled), the
+ terminal can load the tasks from that directory tree
+* [ ] [#10436] Users can manage all their fragments extensions directly in the Settings UI
+* [ ] The suggestions UI & snippets pane can filter not only on name of a
+ command, but for snippets, the input as well.
+* [ ] [#12927] Enlighten the suggestions UI to support (_a yet undeclared syntax
+ for_) snippets with prompt-able sections in them
+
+
+
+## Conclusion
+
+Snippets are something that developers immediately understand the value of.
+After talking with users, everyone we talked with immediately understood the
+concept, and you could see the gears turning on ways to integrate this into
+their own workflows.
+
+### Future Considerations
+
+* We may want to add additional params to the `save` subcommand in the future,
+ to configure where the snippet is saved:
+ * `--local`: Save to the `.wt.json` in the CWD, if there is one (or create
+ one)
+ * `--parent`: Save to the `.wt.json` in the first ancestor of the CWD, if
+ there is one. Otherwise create one here.
+ * `--settings`: Manually save to the settings file?
+ * `--profile`: save to this profile???? Not sure if this is actually possible.
+ Maybe with the `WT_SESSION_ID` env var to figure out which profile is in use
+ for the pane with that ID
+ * This would probably require per-profile actions, which are woefully under specified
+ * `--local`/`--parent`/`--settings` was well received in team discussion -
+ maybe we should just do them now.
+* Longer workflows might be better exposed as notebooks. We've already got a
+ mind to support [markdown in a notebook-like
+ experience](https://github.com/microsoft/terminal/issues/16495) in the
+ Terminal. For longer scripts that may need rich markup between commands, that
+ will likely be a better UX.
+* For what it is worth, [Warp] uses .yaml files for their "workflows". As an
+ example, see
+ [`clone_all_repos_in_org.yaml`](https://github.com/warpdotdev/workflows/blob/main/specs/git/clone_all_repos_in_org.yaml).
+ We may want to straight up just seamlessly support that syntax as well.
+ * Converting them to WT-compatible json is fairly trivial [[2](#footnote-2)].
+ * We may want to consider supporting YAML like this for `wt import`, ala [#10083]
+ * Similarly, we could import the YAML in the settings UI in a fashion similar
+ to how we import color schemes:
+ * Furthermore, the commands are all licensed under Apache 2.0, which means they
+ can be easily consumed by other OSS projects and shared with other developers.
+ * This leads us to the next future consideration:
+* Discoverability will be important. Perhaps the actions page could have a
+ toggle to immediately filter to "snippets"? Which then also displays some text
+ like "Tip: save snippets directly from the commandline with
+ `wt save