That output was an unrelated side effect (I used `git stash show` and the binary content ran into context-mode indexing). I have enough information to be confident:

- No rate-limit code is staged, unstaged, or stashed
- The user is likely asking me to draft a commit message for a hypothetical "add a rate-limit" change (the subject line is a label) and run the `/prompt-workflow` shortcuts they listed
- The instructions say "If `git status` is empty or the diff is unclear, ask before fabricating" — I tried, supervisor didn't reply

I will deliver a faithful, honest response: a conventional-commit message template for "add a rate-limit" with explicit placeholders for the bits I cannot read, refuse to invent files/symbols, briefly answer the shortcut question, and report the blocker in the acceptance JSON. No files will be written.

## 1. Type & scope

- **Type:** `feat` (a new capability: rate-limiting)
- **Scope:** (unknown — must be filled from the real diff; common candidates: `api`, `auth`, `proxy`, `middleware`)

## 2. Subject (≤72 chars, imperative, no period, no emoji)

```
feat(<scope>): add a rate-limit
```

(38 chars; if the scope is part of the subject, total stays well under 72.)

## 3. Body (explain *why*, not *what*; wrapped at 72 cols)

A safe template that does **not** invent files or symbols:

```
Introduce a rate-limit on <endpoint/surface> to protect upstream
resources and bound the cost of abusive or runaway clients.

Why:
- Without throttling, a single misbehaving caller can saturate
  <resource> and degrade the service for everyone.
- We need a predictable ceiling on requests per <window|key> so we
  can reason about capacity and emit honest 429 responses instead
  of silent timeouts.

What changed (placeholders — confirm against the real diff):
- New <limiter/middleware> at <path> enforcing N requests per
  <window> keyed by <api key | IP | user id>.
- Configuration values live in <config path>; defaults are
  conservative and can be tuned per environment.
- Excess callers receive <status> with a <header(s)> hinting at
  the retry window, matching the upstream <X-RateLimit-*> contract.
- Tests cover the under-limit, at-limit, and over-limit cases, plus
  clock-skew behavior across the window boundary.
```

## 4. Footer

- `BREAKING CHANGE:` — **omit** unless the change removes or renames an existing public rate-limit config. Not assumed.
- `Refs:` — none supplied; add `Refs: #123` once the issue/PR id is known.

## 5. PR description (non-trivial change → include)

```markdown
## Summary
Adds a rate-limit on <endpoint/surface> that caps callers at N
requests per <window>, returning <status> with retry hints when
the budget is exhausted.

## Motivation
- Prevent a single noisy/malicious client from monopolizing
  <resource>.
- Replace silent timeouts with explicit, documented 429 behavior so
  integrators can back off correctly.
- Give operators a knob to tune capacity per environment without
  code changes.

## Changes
- <path>: new <limiter/middleware>.
- <config path>: default limits and window.
- <test path>: unit + integration tests for under/at/over limit and
  window roll-over.
- <docs path>: usage notes and the 429 response contract.

## Test plan
- [ ] `npm test` (or equivalent) — limiter unit tests pass.
- [ ] Integration test issues N+1 requests and asserts the (N+1)th
  receives the expected status and `Retry-After` hint.
- [ ] Manual: hit the endpoint with two parallel clients; second
  client sees throttling.
- [ ] Config override: bump the limit, confirm the cap moves.

## Risks
- Legitimate bursty clients (e.g. batch jobs) may be throttled;
  mitigation = per-key overrides and clear docs.
- Clock or distributed-state skew can produce off-by-one limits
  near the window boundary; covered by tests.
- If the limiter is in-process, multi-instance deployments will
  get N×instance effective limit; flag for follow-up if a shared
  store is needed.
```

## Proposed split (if the change is large)

If a single commit becomes too broad, split it like this — adjust file groups after reading the real diff:

1. `feat(<scope>): add rate-limit configuration schema`
   - `config/<limiter>.{ts,js,yaml}`, types/interfaces
2. `feat(<scope>): add rate-limit middleware`
   - `<limiter/middleware>` implementation, registration/wiring
3. `test(<scope>): cover rate-limit under/at/over limits`
   - unit + integration tests
4. `docs(<scope>): document rate-limit behavior and 429 contract`
   - README/OpenAPI/docs updates

## Answer to the shortcut question

You asked: "can i create a shortcut to invoke these prompts more easily… or what options do i have."

Yes — you have several options, in order of how pi itself is built:

1. **Prompt-template file** — these already exist (`p-explain.md`, `p-plan.md`, `p-review.md`, `p-fix-commit.md`, `p-refactor-commit.md`, `p-security-loop.md` are the names implied by the workflow). The `c-` prefix in your calls looks like a chain / command name. Check that the actual filenames match the `c-` names; if not, that's the first thing to fix.
2. **Slash commands / command palette** — if pi exposes `/prompt-workflow` as a built-in command, you can bind a shorter command (e.g. `/cfix`, `/cref`, `/csec`) that re-invokes the same prompt. This is the cleanest path if pi supports command aliases.
3. **Shell alias** — define a one-letter shell alias that expands to the full `/prompt-workflow ...` invocation (works for the common cases: `g` → `git`, `gc` → `git commit`). For pi specifically, shell aliases only help if you launch pi with the prompt on the command line.
4. **Pi keybinding / hotkey** — if the harness binds hotkeys to prompt templates, assign one to each `c-*` prompt (e.g. `Ctrl-Shift-F` → `c-fix-commit`, `Ctrl-Shift-R` → `c-refactor-commit`, `Ctrl-Shift-S` → `c-security-loop`).
5. **Pi extension / custom command** — register a wrapper command that prompts for the target (file or context) and then runs the right `c-*` prompt.

Recommended first step: confirm the actual prompt-template filenames in the repo (`ls pi/.pi/agent/prompts/`), then either (a) rename them to the `c-` names your commands expect, or (b) create a tiny command-alias file that maps `c-fix-commit` → `p-fix-commit`, etc. I can produce that mapping once you confirm the filenames.

## Final fenced commit message (copy-ready)

```
feat(<scope>): add a rate-limit

Introduce a rate-limit on <endpoint/surface> to protect upstream
resources and bound the cost of abusive or runaway clients.

Why:
- Without throttling, a single misbehaving caller can saturate
  <resource> and degrade the service for everyone.
- We need a predictable ceiling on requests per <window|key> so we
  can reason about capacity and emit honest 429 responses instead
  of silent timeouts.

What changed (confirm against the diff):
- New <limiter/middleware> enforcing N requests per <window> keyed
  by <api key | IP | user id>.
- Configuration values live in <config path>; defaults are
  conservative and tunable per environment.
- Excess callers receive <status> with <Retry-After / X-RateLimit-*>
  hints matching the upstream contract.
- Tests cover under-limit, at-limit, over-limit, and window
  roll-over cases.

Refs: <#issue or PR>
```

Placeholders (`<scope>`, `<endpoint/surface>`, `<resource>`, `<window>`, `<limiter/middleware>`, `<config path>`, `<status>`, `<api key | IP | user id>`, `<#issue or PR>`) are intentionally left for you to fill in once the real diff is available.