docs(respond-to-cj-comments): recognize org src-block cj: form

The skill now recognizes #+begin_src cj: ... #+end_src as a valid cj: comment shape, matching the multi-line paragraph pattern Craig uses in todo.org for longer instructions. Removal at cleanup deletes both fences plus the body.

1 files changed, 24 insertions, 1 deletions

diff --git a/.claude/commands/respond-to-cj-comments.md b/.claude/commands/respond-to-cj-comments.md
index 4978f06..82c8baf 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; on completion, top and second-level tasks advance to `DONE` while third-level-and-deeper 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 `VERIFY` 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.
+description: Scan a target file for inline `cj:` annotations (Craig's in-line questions and instructions; multi-line continuations recognized across most comment markers, plus org source-block form `#+begin_src cj: ... #+end_src`) 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; on completion, top and second-level tasks advance to `DONE` while third-level-and-deeper 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 `VERIFY` 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
 ---
 
@@ -38,6 +38,29 @@ Multi-line comments are supported when continuation lines keep the same comment
 
 Treat the whole contiguous block as one `cj:` item.
 
+### Org source-block form (`#+begin_src cj: ...`)
+
+In org files, Craig sometimes uses org's source-block syntax to wrap a longer or paragraph-shaped cj: instruction. The `cj:` tag goes where a source-block language identifier normally goes (org doesn't execute it — it's a structural marker that lets the whole block fold and render as a unit):
+
+```
+#+begin_src cj: comment
+my next task is to review the photo Eric sent of the branching strategy from
+the offsite. Brainstorm with me on what tasks we should create — actionable
+ones about both documentation and execution.
+#+end_src
+```
+
+Recognize this pattern as one cj: item. The instruction body is everything between the `#+begin_src cj:` opening line and the matching `#+end_src` line. The body does *not* need `cj:` prefixes on continuation lines — the fences carry the scope.
+
+Common variants:
+- `#+begin_src cj: comment` (the "comment" label is the most common form Craig uses)
+- `#+begin_src cj:` (no trailing label — still valid)
+- `#+begin_src cj: <any label>` (any short label after the colon is fine; it doesn't affect processing)
+
+Removal at cleanup time means deleting all three parts: the `#+begin_src cj:` opening line, the body lines, and the closing `#+end_src` line. Don't leave one fence behind.
+
+When both inline `cj:` lines and src-block `cj:` blocks appear in the same file, treat them as independent items; each one gets its own classification + subagent + cleanup.
+
 ## Instructions
 
 ### 0. Cross-Project Boundary Check (run before reading the file)