diff options
| -rw-r--r-- | .claude/commands/respond-to-cj-comments.md | 9 |
1 files changed, 5 insertions, 4 deletions
diff --git a/.claude/commands/respond-to-cj-comments.md b/.claude/commands/respond-to-cj-comments.md index 82c8baf..b92bf62 100644 --- a/.claude/commands/respond-to-cj-comments.md +++ b/.claude/commands/respond-to-cj-comments.md @@ -222,14 +222,15 @@ 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. -**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 `VERIFY` 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: +**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 `VERIFY` task in `todo.org` under the parent task it belongs to (the one whose subject it concerns). Name the heading so the question or ask is self-evident on scan: ``` -*** VERIFY <what you need from Craig> -cj: <Craig answers here> +*** VERIFY <self-evident question or ask — phrased so the heading alone tells Craig what's needed> ``` -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 `VERIFY` 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 `VERIFY` 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.) +Do **not** append a `cj: <placeholder>` line beneath the heading. A well-named VERIFY heading carries the question on its own, scans cleanly in the agenda, and Craig adds his own `cj:` annotation (inline `cj: ...` or `#+begin_src cj: ... #+end_src`) when he's ready to answer — that's the signal to come back and process the response. Leaving an empty `cj: <fill in>` placeholder is noise. + +Pair the VERIFY task 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 `VERIFY` 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 `VERIFY` task is the durable home for anything he must act on. (Craig's standing instruction, 2026-05-12; the no-placeholder rule added 2026-05-14.) **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. |