Rewrite the Grill Me command output and read-only block reasons #295

Closed
opened 2026-10-09 21:20:06 +00:00 by david · 1 comment
Owner

Summary

Rewrite the grillme command output and the read-only refusal reasons to the STE rule categories: the /grill help text, every command notify / sendMessage string, statusMarkdown(), and the two refusal reasons in the tool_call handler.

Background

Depends on: #294

#294 rewrote the tool metadata and the prompt constants in the same files. Keeping this step after it avoids two writers in index.ts at once.

The rule categories are defined in extensions/grillme/ste-style.ts as STE_RULE_CATEGORIES and are the specification for this rewrite:

  1. Keep sentences short. Aim for about 20 words or fewer when you give an instruction. Aim for about 25 words or fewer when you describe something.
  2. Put one idea in each sentence.
  3. Use the active voice.
  4. Use simple tenses: past, present, future, and the imperative.
  5. Do not use an -ing verb form when a simple tense works.
  6. Use one word for one meaning. Do not trade between synonyms.
  7. Do not use a phrasal verb when one verb does the work.
  8. Keep a group of nouns to three words or fewer.
  9. Use short, common words.
  10. Keep the articles (a, an, the).

Exempt and byte-identical: code, file paths, identifiers, tool names, and commands. That covers every command form and option name in the help text, and the embedded command text in the bash refusal reason.

Implementation Details

Strings to rewrite in extensions/grillme/index.ts:

  • The /grill help content string (pi.registerCommand("grill", ...), command === "help"). Keep each command form byte-identical: /grill <topic>, /grill stop, /checkpoint [edit|chat], /grill checkpoint [edit|chat], /grill status, /grill intent auto|plan|learn|research|content|decide, /grill output <one or more outputs> (preference only; approval still required), /grill research off|ask|auto. The two closing sentences about the thorough style and the mandatory output-selection phase should be split into short sentences.
  • The description of pi.registerCommand("checkpoint", ...) and pi.registerCommand("grill", ...).
  • Every ctx.ui.notify(...) string, including the usage warnings and the info messages for /grill stop, /grill intent, /grill output, /grill research, and Cancelled grill start.. Keep any interpolated value (for example the intent or research-mode name) intact.
  • statusMarkdown(state) output — rewrite the prose, keep the field labels and any Markdown structure the overlay reads.
  • pi.sendMessage(...) content strings that carry prose, such as the help and status messages.
  • The two refusal reasons in the tool_call handler:
    • the edit / write block reason;
    • the bash block reason. Keep the trailing Command: ${command} line and its newline exactly, so the blocked command is still shown verbatim.

Also check extensions/grillme/widget.ts. Its status-line text is user-facing; rewrite any prose there too, but do not change its logic or its exported function behaviour (widget.test.ts asserts on the exact composed strings, so update that test only if a string it asserts on legitimately changes — prefer keeping the asserted strings stable where the rule categories allow it).

extensions/grillme/bash-filter.ts holds no user-facing reason text: the reasons live in index.ts. Do not change bash-filter.ts logic. If you do find a user-facing string there, rewrite that string only.

Do not change any logic, control flow, type, or exported name.

Acceptance Criteria

  • The /grill help output uses short sentences, and every command form is byte-identical to the list above.
  • Every ctx.ui.notify(...) and prose pi.sendMessage(...) string in index.ts follows the rule categories.
  • statusMarkdown() output follows the rule categories.
  • Both read-only refusal reasons follow the rule categories, and the bash reason still ends with the verbatim Command: ${command} line.
  • No logic or exported name changed in index.ts, bash-filter.ts, or widget.ts.
  • cd extensions/grillme && npm test passes, including bash-filter.test.ts and widget.test.ts.

Test Plan

cd extensions/grillme
npm test

Expected: all test files pass.

# the command forms must be unchanged
grep -n "grill stop\|grill checkpoint\|grill status\|grill intent\|grill output\|grill research" extensions/grillme/index.ts

Expected: every documented form is still present and unchanged.

git diff extensions/grillme/index.ts | grep -E "^[+-]" | grep -v "^[+-][+-]" | grep -vE '"|`' 

Expected: no changed line outside a string literal (adjust the pattern if a rewritten string is a template literal).

Manual, in a live session:

  1. Start pi in this repo, run /grill a small topic.
  2. Run /grill help, /grill status, /grill intent plan, /grill output design-doc, and /grill research ask; read each message.
  3. Ask the agent to run a mutating bash command (for example rm -rf /tmp/grill-ste-check) and read the refusal reason.
  4. Run /grill stop and read the notification.
## Summary Rewrite the `grillme` command output and the read-only refusal reasons to the STE rule categories: the `/grill help` text, every command `notify` / `sendMessage` string, `statusMarkdown()`, and the two refusal reasons in the `tool_call` handler. ## Background **Depends on:** #294 `#294` rewrote the tool metadata and the prompt constants in the same files. Keeping this step after it avoids two writers in `index.ts` at once. The rule categories are defined in `extensions/grillme/ste-style.ts` as `STE_RULE_CATEGORIES` and are the specification for this rewrite: 1. Keep sentences short. Aim for about 20 words or fewer when you give an instruction. Aim for about 25 words or fewer when you describe something. 2. Put one idea in each sentence. 3. Use the active voice. 4. Use simple tenses: past, present, future, and the imperative. 5. Do not use an `-ing` verb form when a simple tense works. 6. Use one word for one meaning. Do not trade between synonyms. 7. Do not use a phrasal verb when one verb does the work. 8. Keep a group of nouns to three words or fewer. 9. Use short, common words. 10. Keep the articles (`a`, `an`, `the`). Exempt and byte-identical: code, file paths, identifiers, tool names, and commands. That covers every command form and option name in the help text, and the embedded command text in the bash refusal reason. ## Implementation Details Strings to rewrite in `extensions/grillme/index.ts`: - The `/grill help` `content` string (`pi.registerCommand("grill", ...)`, `command === "help"`). Keep each command form byte-identical: `/grill <topic>`, `/grill stop`, `/checkpoint [edit|chat]`, `/grill checkpoint [edit|chat]`, `/grill status`, `/grill intent auto|plan|learn|research|content|decide`, `/grill output <one or more outputs> (preference only; approval still required)`, `/grill research off|ask|auto`. The two closing sentences about the thorough style and the mandatory output-selection phase should be split into short sentences. - The `description` of `pi.registerCommand("checkpoint", ...)` and `pi.registerCommand("grill", ...)`. - Every `ctx.ui.notify(...)` string, including the usage warnings and the info messages for `/grill stop`, `/grill intent`, `/grill output`, `/grill research`, and `Cancelled grill start.`. Keep any interpolated value (for example the intent or research-mode name) intact. - `statusMarkdown(state)` output — rewrite the prose, keep the field labels and any Markdown structure the overlay reads. - `pi.sendMessage(...)` content strings that carry prose, such as the help and status messages. - The two refusal reasons in the `tool_call` handler: - the `edit` / `write` block reason; - the `bash` block reason. Keep the trailing `Command: ${command}` line and its newline exactly, so the blocked command is still shown verbatim. Also check `extensions/grillme/widget.ts`. Its status-line text is user-facing; rewrite any prose there too, but do not change its logic or its exported function behaviour (`widget.test.ts` asserts on the exact composed strings, so update that test only if a string it asserts on legitimately changes — prefer keeping the asserted strings stable where the rule categories allow it). `extensions/grillme/bash-filter.ts` holds no user-facing reason text: the reasons live in `index.ts`. Do not change `bash-filter.ts` logic. If you do find a user-facing string there, rewrite that string only. Do not change any logic, control flow, type, or exported name. ## Acceptance Criteria - [ ] The `/grill help` output uses short sentences, and every command form is byte-identical to the list above. - [ ] Every `ctx.ui.notify(...)` and prose `pi.sendMessage(...)` string in `index.ts` follows the rule categories. - [ ] `statusMarkdown()` output follows the rule categories. - [ ] Both read-only refusal reasons follow the rule categories, and the `bash` reason still ends with the verbatim `Command: ${command}` line. - [ ] No logic or exported name changed in `index.ts`, `bash-filter.ts`, or `widget.ts`. - [ ] `cd extensions/grillme && npm test` passes, including `bash-filter.test.ts` and `widget.test.ts`. ## Test Plan ```bash cd extensions/grillme npm test ``` Expected: all test files pass. ```bash # the command forms must be unchanged grep -n "grill stop\|grill checkpoint\|grill status\|grill intent\|grill output\|grill research" extensions/grillme/index.ts ``` Expected: every documented form is still present and unchanged. ```bash git diff extensions/grillme/index.ts | grep -E "^[+-]" | grep -v "^[+-][+-]" | grep -vE '"|`' ``` Expected: no changed line outside a string literal (adjust the pattern if a rewritten string is a template literal). Manual, in a live session: 1. Start pi in this repo, run `/grill a small topic`. 2. Run `/grill help`, `/grill status`, `/grill intent plan`, `/grill output design-doc`, and `/grill research ask`; read each message. 3. Ask the agent to run a mutating bash command (for example `rm -rf /tmp/grill-ste-check`) and read the refusal reason. 4. Run `/grill stop` and read the notification.
david self-assigned this 2026-10-09 21:20:06 +00:00
david closed this issue 2026-10-09 22:10:37 +00:00
Author
Owner

pi-loop opened and merged a pull request for this issue: #305

pi-loop opened and merged a pull request for this issue: https://git.excelera.net/david/pi-extensions-and-skills/pulls/305
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
david/pi-extensions-and-skills#295
No description provided.