Good. The test infrastructure exists for static prompt-recipe validation. Now I'll produce the brainstorm. The key tension: the user is asking "can I create a shortcut... or what options do I have?" — this is a real question with several viable answers. I'll enumerate the genuine options without padding.

---

## 1. Problem restatement

You're invoking three chain recipes (`c-fix-commit`, `c-refactor-commit`, `c-security-loop`) via the verbose `/prompt-workflow <recipe> --bg "<args>"` syntax. The friction is **typing + remembering the exact recipe name and flag** every time, not capability — the adapter already works. Constraints that matter: (a) the shortcut must keep running through the existing `pi-subagents` `prompt-workflow` adapter, because that's what `Doc/chain-commands.md` documents and what `test/chain-workflow.test.ts` validates; (b) it must not silently break the static-validation tests that walk `c-*.md` files and assert their `chain:` frontmatter resolves to existing `p-*.md` steps with `subagent: true` + `fork: true`; (c) "done" = one short, memorable incantation per chain that the user actually types at the prompt, with a real-time-to-first-run under ~5 minutes of edits.

## 2. Alternatives

### Alternative A — Add a shell alias / shell function (no pi changes)

**Summary.** Define `fcc`, `rcc`, `scl` (or similar) as shell functions in your dotfiles that expand to `pi /prompt-workflow c-fix-commit --bg "$@"` etc.

**How it works.** Shell functions wrap the verbatim command. pi never sees a new surface; the prompt-workflow adapter and chain recipes are unchanged.

**Pros.**
- Zero changes to `.pi/agent/prompts/`, so zero risk to the static test suite.
- Reversible in one edit to your shell rc.
- Works outside pi (e.g., in a terminal multiplexer status line) if you ever want to fire-and-forget.
- Shortest possible keystroke.

**Cons.**
- Lives in shell config, not in pi — someone reading `Doc/chain-commands.md` won't see it.
- Doesn't work if you launch pi without a shell wrapper (e.g., from an editor's terminal-repl).
- You'll have three different mnemonics to remember; no discoverability.
- If the recipe name ever changes, the alias silently keeps the old name.

**Best when.** You control your shell env, don't need discoverability, and want this fixed in under two minutes.

### Alternative B — Add a `:c-fix`, `:c-refactor`, `:c-sec` slash-style prompt that delegates to the chain

**Summary.** Create `p-cfix.md`, `p-crefactor.md`, `p-csec.md` (or similar) that contain a single line of body text instructing the model to invoke `/prompt-workflow c-fix-commit --bg "$@"` and return.

**How it works.** pi already supports `:p-<verb>` invocation. The new `p-*.md` is just a thin wrapper; the model reads the body and dispatches to the chain.

**Pros.**
- Discoverable via `:prompts` TUI picker (per `Doc/prompts.md`).
- Lives alongside the existing prompt library, so it's version-controlled with the rest.
- One canonical name, one consistent signature.

**Cons.**
- Adds an **extra model turn** in the parent before the chain forks — every invocation pays a token + latency cost to "re-issue" the workflow.
- Indirect: the user types `:c-fix "..."`, the model has to *decide* to call `/prompt-workflow`, which is a behavior contract you now have to maintain.
- Doesn't actually save keystrokes if the model adds commentary.
- The shortcut name is a real prompt, so it gets `subagent: true` consideration (you almost certainly do **not** want `fork: true` here, since the wrapper must run in the parent).

**Best when.** Discoverability matters more than keystrokes, and you accept one extra LLM hop per invocation.

### Alternative C — Rename chains to one- or two-letter names (`c-x`, `c-r`, `c-s`) and document them

**Summary.** Shorten the recipe filenames to `c-x.md`, `c-r.md`, `c-s.md` (or `c-fc.md`, `c-rc.md`, `c-sl.md`) and update `Doc/chain-commands.md` accordingly.

**How it works.** `/prompt-workflow c-fc --bg "..."` is shorter than `/prompt-workflow c-fix-commit --bg "..."`. No new code, just renaming.

**Pros.**
- Zero new machinery, zero new abstractions.
- All three chains get the same treatment symmetrically.
- The `test/chain-workflow.test.ts` suite still passes unchanged — it walks every `c-*.md` file generically, so shorter names work for free.
- Most reversible option: rename back is a `git mv` + doc edit.

**Cons.**
- Loses self-documentation — `c-fix-commit` reads as English, `c-fc` doesn't.
- The test suite asserts chain names appear in `Doc/chain-commands.md` and `Doc/prompts.md`; you'd need to update those two docs.
- The mnemonics `fc / rc / sl` aren't obviously connected to "fix-commit / refactor-commit / security-loop" — you're trading the verbose-but-clear for terse-but-memorize-the-table.

**Best when.** You want the smallest possible diff and you're willing to keep a cheat sheet in your head or in the doc.

### Alternative D — Teach the `pi-subagents` prompt-workflow adapter to accept bare recipe names and a `--shortcut` mapping file

**Summary.** Add a config file (e.g., `~/.pi/agent/prompts/shortcuts.yaml`) that maps `fcc → c-fix-commit`, `rcc → c-refactor-commit`, `scl → c-security-loop`, so `/prompt-workflow fcc --bg "..."` Just Works.

**How it works.** A small lookup step at the start of the prompt-workflow adapter resolves the shortcut to a full recipe name, then proceeds exactly as today. The chain recipes and `p-*.md` files are unchanged.

**Pros.**
- Single point of customization — one file controls all shortcuts.
- Discoverable via `/prompt-workflow list --shortcuts` (a small doc/help add).
- Symmetric across all three chains; trivial to add a fourth later.
- Doesn't add an LLM hop (it's at the adapter layer, not the prompt layer).
- No new `p-*.md` files, so the existing test suite is unaffected.

**Cons.**
- Requires editing the `pi-subagents` adapter, which lives in a different package (`@earendil-works/pi-coding-agent` or a subagent extension) — outside the `.pi/agent/prompts/` tree.
- A new config file is a new thing to keep in sync if you ever rename a recipe.
- You now have two ways to spell the same command (full name and shortcut), which can confuse muscle memory.

**Best when.** You're already comfortable modifying the subagent adapter and want a long-term, documented shortcut surface that other recipes can opt into.

### Alternative E — A single dispatcher prompt `:chains` with subcommands

**Summary.** Add one `p-chains.md` prompt that reads subcommand syntax: `:chains fix "the checkout times out"`, `:chains refactor src/utils.ts`, `:chains sec auth endpoint`.

**How it works.** The body instructs the model to parse the first token as a subcommand and dispatch to the right `/prompt-workflow` invocation. Everything else routes through the existing adapter.

**Pros.**
- One entry point to remember (`p-chains`), three obvious subcommands.
- Easy to extend (add a new subcommand = one line in the body).
- Discoverable through `:prompts`.

**Cons.**
- Worst of both worlds: a wrapper prompt **plus** a parser inside it. The model is the parser, which is brittle for typos.
- Each call still adds one parent LLM turn before the chain forks.
- "Don't do that" energy — the static test suite doesn't have anything to validate against, and a model-driven subcommand parser is exactly the kind of indirection this codebase has been avoiding (see `Doc/prompts.md`: *"Prefer one prompt per turn. Chain them yourself … rather than asking one prompt to do everything."*).

**Best when.** Almost never. Enumerated for completeness.

## 3. Comparison table

| Alternative | Complexity | Time-to-ship | Reversibility | Performance | Fit with existing code |
|---|---|---|---|---|---|
| **A. Shell alias** | Trivial | ~2 min | Trivial (delete the alias) | Best — no LLM hop | Off-tree; orthogonal |
| **B. Wrapper `p-*.md`** | Low | ~10 min | Easy (delete the file) | Worst — +1 LLM turn every call | Strong (in-tree, follows existing prompt convention) |
| **C. Rename chains** | Low | ~5 min | Easy (`git mv` + doc edits) | Best — same dispatch path | Strongest — zero new abstractions |
| **D. Adapter shortcut map** | Medium | ~30–60 min, plus adapter access | Medium (config file + adapter code) | Best — adapter-layer, no LLM hop | Good if the adapter is local; awkward if it's a third-party package |
| **E. Dispatcher prompt** | Medium | ~15 min | Easy | Worst — model-parsed dispatch | Weak — fights the codebase's stated convention |

(Complexity = lines of code + new files. Time-to-ship measured against the existing on-disk tree in `~/.pi/agent/prompts/`. Performance assumes you invoke the chain often enough for the extra LLM turn to matter.)

## 4. Recommendation

**Pick Alternative A (shell alias) for today; promote to Alternative D (adapter shortcut map) when you have ≥5 chains.**

Reasoning grounded in the on-disk state:

1. The chain recipe files (`c-fix-commit.md`, `c-refactor-commit.md`, `c-security-loop.md`) are pure content — the `chain:` frontmatter, the body, and the example invocation in each file are *the entire user surface*. Touching them is unnecessary.
2. `test/chain-workflow.test.ts` walks `c-*.md` files generically and validates frontmatter + `chain:` resolution to `p-*.md` steps. Any approach that adds new `p-*.md` wrappers (B, E) creates new test surface and new `subagent: true` / `fork: true` decisions to make.
3. `Doc/chain-commands.md` already says chains run through `/prompt-workflow` and that `/c-...` "just pastes text" — this is documented behavior. The shortcut should sit at the *shell* layer (where you've already absorbed the verbose command into muscle memory) and not at the prompt layer, which would re-introduce the same "pastes text instead of running" pitfall.
4. The two keystroke-savers that *don't* add an LLM hop are A and D. A ships in two minutes; D ships in 30–60 and requires editing code you may not own. With only three chains, A is unambiguously the right now.

**Concrete proposal for A:**

```sh
# in ~/.bashrc or ~/.zshrc
fcc()  { pi /prompt-workflow c-fix-commit      --bg "$@"; }
rcc()  { pi /prompt-workflow c-refactor-commit --bg "$@"; }
scl()  { pi /prompt-workflow c-security-loop   --bg "$@"; }
```

Then your real invocation collapses from `/prompt-workflow c-fix-commit --bg "the checkout inter"` to `fcc "the checkout inter"`. Total on-disk changes: zero.

**Fallback (D):** if shell aliases feel like the wrong layer — e.g., you sometimes launch pi from a GUI launcher that bypasses your rc files — add a `shortcuts.json` (or equivalent) next to the recipes and have the adapter resolve it before dispatch. This is the only option that gives you both short names and in-tree discoverability without adding a parent LLM turn.

## 5. Unknowns

1. **Where does the `pi-subagents` `prompt-workflow` adapter actually live?** Is it a package you can edit, a vendored file, or a third-party dependency? That decides whether D is a 30-minute edit or a fork-and-PR. (Not visible in `~/.pi/agent/prompts/` — it's upstream of this tree.)
2. **How do you typically launch pi?** Inside a terminal where aliases resolve (favors A), from a launcher that doesn't source your rc (favors D), or both (favors C as the universal baseline)?
3. **Do you want shortcuts to be self-documenting in `Doc/chain-commands.md`?** If yes, A becomes invisible to future readers and you'd want a one-line "Shell shortcuts" section added; if no, A is a pure personal-quality-of-life win.
4. **Will more chains be added soon?** If yes, A scales linearly (one alias per chain, easy to forget) while D scales in one config file. If no (you'll have these three forever), A is strictly better.
5. **Is "the checkout inter" in your example a typo for "intermittently" inside the original quote, or a real argument you'd pass?** Doesn't change the recommendation, but it changes whether your real-world invocation is one word or a sentence — and shorter inputs make B's "wrapper prompt adds an LLM turn" cost more noticeable.

---