diff options
| -rw-r--r-- | .claude/commands/respond-to-cj-comments.md | 15 |
1 files changed, 11 insertions, 4 deletions
diff --git a/.claude/commands/respond-to-cj-comments.md b/.claude/commands/respond-to-cj-comments.md index ba36f6c..54308e6 100644 --- a/.claude/commands/respond-to-cj-comments.md +++ b/.claude/commands/respond-to-cj-comments.md @@ -1,5 +1,5 @@ --- -description: Scan a target file for inline `cj:` annotations (Craig's in-line questions and instructions; multi-line continuations recognized across most comment markers) and process each via subagent-delegated accuracy. Each item is classified instruction / question / both, then dispatched to an instruction subagent (proposes a file:line patch) or a question subagent (researches with explicit scope, reports answer + evidence + confidence). Main thread reviews proposals before editing — subagents don't write to the source file. Org-mode TODO parents flip to DOING; new content lands under timestamped subheadings one level deeper. Public-facing writing (commits, PRs, Slack, email, public docs) gets `/voice personal`; private writing skips the voice pass. Summary lists handled instructions, answered questions with evidence + confidence, follow-ups, unresolved items, and an explicit clean / N-remain verdict. Long summaries (>6-8 items or >500 words) write to `/tmp/` and open in `emacsclient -n`. File paths render as clickable absolute org-mode links. Use when a file accumulates inline `cj:` comments. Do NOT use for general code review (`/review-code`), new work without inline comments, or trivial items. +description: Scan a target file for inline `cj:` annotations (Craig's in-line questions and instructions; multi-line continuations recognized across most comment markers) and process each via subagent-delegated accuracy. Each item is classified instruction / question / both, then dispatched to an instruction subagent (proposes a file:line patch) or a question subagent (researches with explicit scope, reports answer + evidence + confidence). Main thread reviews proposals before editing — subagents don't write to the source file. Org-mode TODO parents flip to DOING; new content lands under timestamped subheadings one level deeper; completed tasks get their heading rewritten to a dated action description (no DONE keyword) so they become an in-place event log. Public-facing writing (commits, PRs, Slack, email, public docs) gets `/voice personal`; private writing skips the voice pass. Summary lists handled instructions, answered questions with evidence + confidence, follow-ups, unresolved items, and an explicit clean / N-remain verdict. Anything needing Craig's input becomes a `STALLED` task in `todo.org` under the relevant parent (he answers inline with `cj:`) rather than a separate summary file. File/URL references render as clickable org-mode links. Use when a file accumulates inline `cj:` comments. Do NOT use for general code review (`/review-code`), new work without inline comments, or trivial items. disable-model-invocation: true --- @@ -101,7 +101,7 @@ For **instructions**: 4. **Surface URLs.** If the subagent's output includes URLs, file paths, or external references, list them under the updated task content. After applying the edit, offer to convert them into explicit org-mode links (`[[url][label]]` or `[[file:path][label]]`) at the location where the `cj:` comment originated, or elsewhere in the task if that fits better. -5. If the comment is inside an org-mode `TODO` heading, mark that `TODO` as `DOING` when work begins. Leave it `DOING` for the user to advance to `DONE` after review. +5. If the comment is inside an org-mode `TODO` heading, mark that `TODO` as `DOING` when work begins. **When the work is complete, do not advance it to `DONE`** — rewrite the heading itself into a timestamped action description and drop the keyword: `** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ <what was decided / done>` (generate the timestamp with `date "+%Y-%m-%d %a @ %H:%M:%S %z"`). The CLOSED line and the keyword go away; the task heading becomes a permanent event-log entry in place. Keep the task's body/sub-headers as the record of what it was. This is Craig's convention for all `todo.org` files (and his prep docs) — finished tasks turn into a dated log automatically. (Feedback memory: `feedback_done_tasks_become_dated_log_headings`.) Leave a still-in-progress task as `DOING` for the user; only the *completed* ones get the dated-heading rewrite. 6. Remove the `cj:` comment from the file (the entire contiguous block, including continuation lines). @@ -167,9 +167,16 @@ Never leave the reader guessing about whether the file is ready for follow-up wo Keep answers direct. If a question has a simple answer, one sentence. If it needs nuance, two or three. Do not pad. The user reads the summary, not the intermediate work. -**Long summaries go to a file.** If the summary runs beyond six to eight items, or beyond ~500 words of prose, write it to `/tmp/respond-to-cj-summary-YYYY-MM-DD.org` as an org file and open it in `emacsclient -n <path>`. The user may annotate the file, add new `cj:` comments in-line, or answer open questions in-line, then save. After the user saves, re-read the file for any additional instructions or answers and handle those before ending the run. A long summary dumped straight into chat is hard to comment on and hard to return to; the file form makes it reviewable and iterable. +**Items needing Craig's input go to `todo.org`, not a summary file.** When the run leaves something that needs Craig to decide, answer, or approve — a blocker, an open question, a draft awaiting sign-off, anything in the Follow-ups list above that requires his action — add a `STALLED` task in `todo.org` under the parent task it belongs to (the one whose subject it concerns), phrased so Craig can answer inline with a `cj:` comment: -**Every file path in the summary must be a clickable org-mode link.** Use absolute paths: `[[file:/absolute/path/to/file][display label]]`. Plain paths wrapped in `=verbatim=` markers aren't clickable in emacs. URLs in the summary should also use link form: `[[https://...][label]]`. This applies to every file reference in the summary file — source files read, artifacts created, archive destinations, anywhere the user might want to jump. If there's a path in the summary, it should open when clicked. +``` +*** STALLED <what you need from Craig> +cj: <Craig answers here> +``` + +Pair it with a dated child header for the work-log entry where one fits (`*** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ <desc>` — generate the timestamp with `date "+%Y-%m-%d %a @ %H:%M:%S %z"`). Do **not** default to writing a summary file in `/tmp/` and opening it in `emacsclient` — Craig prefers the in-place `STALLED` task: it lives next to the work, surfaces in his agenda, and he resolves it inline rather than having to go find a separate doc. The chat summary above still gets written (it's the FYI recap); the `STALLED` task is the durable home for anything he must act on. (Craig's standing instruction, 2026-05-12 — this replaces the older "long summary → /tmp file → emacsclient" step.) + +**Org-mode links where they help.** When you reference a file or URL — in the chat summary or in a `todo.org` entry — use clickable org-mode link form with absolute paths (`[[file:/absolute/path][label]]`, `[[https://...][label]]`), not `=verbatim=` paths, which aren't clickable in Emacs. ### 6. Cleanup pass |