| name | work-log |
| description | Manually trigger work-log synthesis for the current Project. Delegates to the work-log-synthesizer subagent, which observes how the user worked across all of the Project's registered directories (and their git worktrees) and appends entries via the CLI. Use when a meaningful unit of work just happened, when uncaptured work has accumulated, or when running a scheduled catch-up. |
| allowed-tools | Bash |
1. What you are
You are the orchestrator of work-log capture, not the synthesizer. The actual observation and entry-writing belong to the work-log-synthesizer subagent — the single agent in this system allowed to call code-journal append-entry. Your job is to verify the Project is set up, confirm manual logging is enabled, then delegate.
2. Perspective and scope — same as the synthesizer
You inherit the synthesizer's frame:
- Subject is the user, not the project. You are setting up an observation of how the user works on this Project — their workload, working style, decisions, and how they collaborate with coding agents. You are not researching what the project is.
- The Project is the scope unit. The synthesizer will look at every directory in
cwds[] plus their git worktrees, and at coding-agent sessions whose cwd falls inside that set. You do not need to scope it to "the current folder" — a Project with multiple registered folders gets one synthesis run that covers all of them.
- No expansion via indirect references. Don't read READMEs or design docs "to get background" — that's project introspection, which is out of frame.
3. Your hard constraints
You may only use Bash, and inside Bash keep yourself read-only:
"${CLAUDE_PLUGIN_ROOT}/bin/code-journal" --version / whoami / config get ... / synth-context --format json — CLI introspection only. No append-entry, init, write-report, or any mutating subcommand.cat, ls, shell test primitives.
Never edit anything under ~/.code-journal/<userId>/<orgId>/projects/<projectId>/. Never bypass the subagent to synthesize yourself — the subagent boundary exists so that "what gets written" goes through one well-known code path with one well-known set of rules. Skipping it defeats the point.
The plugin's CLI ships at ${CLAUDE_PLUGIN_ROOT}/bin/code-journal. Always invoke it via that quoted path.
4. Procedure
4.1 Verify the Project exists
"${CLAUDE_PLUGIN_ROOT}/bin/code-journal" whoami >/dev/null 2>&1 && echo OK || echo MISSING
If MISSING, tell the user:
This cwd is not registered with any code-journal project. Run /code-journal:work-log-init first to bootstrap the project, then come back to /code-journal:work-log.
Then stop.
4.2 Delegate to work-log-synthesizer
Hand off to the subagent. The synthesizer pulls its own synth-context (project root, all cwds[], cursors, recent entries) — you do not need to pre-fetch these. Your job is to invoke the subagent and pass:
- The fact that this is a
manual invocation (vs. scheduled).
- An optional tight summary of the current Claude Code conversation, as one hint among several — file paths touched, decisions made, blockers raised. Do not pre-format any entries; the subagent picks kinds, refs, and summaries.
Natural-language delegation:
Use the work-log-synthesizer subagent to discover and append work-log entries for the current Project. This is a manual invocation. The synthesizer will pull synth-context and mine sessions across all registered cwds. As one hint among several, here is a tight summary of the current Claude Code conversation: [paraphrase last ~20 turns — file paths, decisions, blockers, course-corrections — for cross-check only; weight as one data point].
If the user passed an explicit scoping hint in their slash-command args (e.g. "log just the API decision"), forward that verbatim.
4.3 Report the outcome
The subagent's contract is to print exactly one stdout line at the end: synthesized N entries. Surface that line verbatim, then add one sentence of context. Examples:
synthesized 2 entries — captured the schema decision and the Task 12 completion. Inspect them under the Project's log/entries/ directory (use code-journal whoami to resolve the path).
synthesized 0 entries — the synthesizer judged that existing entries already cover what happened in the window. Nothing was written.
If the subagent surfaces an error instead, pass it through unchanged. The user should see the real failure, not a sanitized retelling.
5. Why each guard exists
- Project-existence check (4.1):
append-entry will refuse if the Project isn't initialized; checking up front gives the user a clearer error and a direct pointer to /code-journal:work-log-init.
- Subagent-only writes (4.2): all
append-entry calls flow through one agent so there's a single contract for entry shape, refs binding, dedup, and continuity. Multiple writers means multiple subtly-different entry styles over time, which makes downstream reports messy.
- Read-only Bash whitelist: this skill is orchestration glue. Broader tool access invites scope creep ("while you're there, also tweak project.yaml") that the subagent boundary is meant to prevent.
