/report
Assemble a run report — the shareable postmortem of this John run (process scorecard + manifest + outcome summary + candidate lessons), privacy-scrubbed. Use when a run wraps or a milestone ships, when the user asks "how did this run go?", "make a run report", or wants evidence
$ npx -y skills add kitchen-engineer42/joharnessburg --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/report
Context preview
What this command does when you run it.
Assemble a run report — the shareable postmortem of this John run (process scorecard + manifest + outcome summary + candidate lessons), privacy-scrubbed. Use when a run wraps or a milestone ships, when the user asks "how did this run go?", "make a run report", or wants evidence
Command definition
report.mddescription: Assemble a run report — the shareable postmortem of this John run (process scorecard + manifest + outcome summary + candidate lessons), privacy-scrubbed. Use when a run wraps or a milestone ships, when the user asks "how did this run go?", "make a run report", or wants evidence to send a template owner. The report is the input format for template evolution; sharing is always manual.
When this command fires:
1. Run the process scorecard via Bash (add `--applied-metadata ${CLAUDE_PLUGIN_ROOT}/.applied-metadata.json` when running under an applied template — that file sits at the merged plugin's root):
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/process_scorecard.py"On `success: false` ("No .john/ directory"), tell the user there's no workspace to report on — `/john:init` first.
Then emit the auditor manifests (idempotent, zero-token; same `--applied-metadata` note as above):
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/emit_manifests.py" --applied-metadata "${CLAUDE_PLUGIN_ROOT}/.applied-metadata.json"This writes `<project>/.john/PROVENANCE.json` (run identity — John version, template name+version, corpus inputs, observed phases, run window) and `SELF_EVAL_MANIFEST.json` (how to re-run the scorecard, where reports live), so the finished run is legible to an external auditor and John's own evolution tooling without reading app code. A missing `.applied-metadata.json` is fine — a vanilla run emits both with template fields null. (Where a produced app wrote its *results* is template-defined; John core does not emit that manifest.)
2. Assemble the report at `<project>/.john/reports/<YYYY-MM-DD>-run-report.md`, following the format in the `skill-evolution` skill's `references/run-report-format.md` (1 page: manifest, scorecard highlights, outcome summary, candidate lessons, deviations). Create the `reports/` directory if missing. The scorecard JSON is the evidence backbone; your judgment supplies the outcome summary and the lesson selection — pick the few lessons whose `scope_guess` is `template` or `core` and whose evidence held up.
3. **Walk the scrub-and-generalize checklist** (bottom of the format reference) over the draft — the report is built to LEAVE this project, so it must carry no corpus content, client identifiers, or local filesystem paths. Restate any lesson that fails the check so it would hold for the next corpus of the domain.
4. Show the user the report path and the highlights. Remind them: sharing is manual and theirs — typically to the template's owner as evolution evidence. Nothing is ever transmitted automatically.
Read more
description: Assemble a run report — the shareable postmortem of this John run (process scorecard + manifest + outcome summary + candidate lessons), privacy-scrubbed. Use when a run wraps or a milestone ships, when the user asks "how did this run go?", "make a run report", or wants evidence to send a template owner. The report is the input format for template evolution; sharing is always manual.
When this command fires:
1. Run the process scorecard via Bash (add `--applied-metadata ${CLAUDE_PLUGIN_ROOT}/.applied-metadata.json` when running under an applied template — that file sits at the merged plugin's root):
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/process_scorecard.py"On `success: false` ("No .john/ directory"), tell the user there's no workspace to report on — `/john:init` first.
Then emit the auditor manifests (idempotent, zero-token; same `--applied-metadata` note as above):
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/emit_manifests.py" --applied-metadata "${CLAUDE_PLUGIN_ROOT}/.applied-metadata.json"This writes `<project>/.john/PROVENANCE.json` (run identity — John version, template name+version, corpus inputs, observed phases, run window) and `SELF_EVAL_MANIFEST.json` (how to re-run the scorecard, where reports live), so the finished run is legible to an external auditor and John's own evolution tooling without reading app code. A missing `.applied-metadata.json` is fine — a vanilla run emits both with template fields null. (Where a produced app wrote its *results* is template-defined; John core does not emit that manifest.)
2. Assemble the report at `<project>/.john/reports/<YYYY-MM-DD>-run-report.md`, following the format in the `skill-evolution` skill's `references/run-report-format.md` (1 page: manifest, scorecard highlights, outcome summary, candidate lessons, deviations). Create the `reports/` directory if missing. The scorecard JSON is the evidence backbone; your judgment supplies the outcome summary and the lesson selection — pick the few lessons whose `scope_guess` is `template` or `core` and whose evidence held up.
3. **Walk the scrub-and-generalize checklist** (bottom of the format reference) over the draft — the report is built to LEAVE this project, so it must carry no corpus content, client identifiers, or local filesystem paths. Restate any lesson that fails the check so it would hold for the next corpus of the domain.
4. Show the user the report path and the highlights. Remind them: sharing is manual and theirs — typically to the template's owner as evolution evidence. Nothing is ever transmitted automatically.
中文版: README_ZH.md John turns unstructured source material into a working knowledge-dense app. It keeps knowledge engineering and app building in one durable run, coordinates large per-entry fan-outs, and leaves auditable events and checkpoints on disk.
Other commands on joharnessburg.
- /archive
Bundle the finished John workspace (PLAN.md, CLAUDE.md, AGENTS.md, .john/, .claude/skills/, .agents/skills/) into a release zip. Use when the user says "archive this project", "package it up", "we're done", or you've completed an end-to-end run and want a portable bundle.
Open command - /endurance
Set or clear the long-running goal for this John session. Pinned into the system prompt by the SessionStart hook so it survives context compaction and stays visible across long ralph-loop runs. Use this command when the user says "let's run this in endurance mode", "set the
Open command - /init
Scaffold the John workspace in the current project. Creates .john/ working state, a starter PLAN.md, and (if missing) a starter CLAUDE.md. Optionally copies an input path into .john/input/. ALWAYS run this first when starting a new John project — every other John command depends
Open command - /status
Print John workspace status — active template, current phase, inventory of inputs/parsed/chunks/knowledge/events/checkpoints/produced-skills. Use whenever the user asks "where are we?", "what's done?", "what's next?", or you need to verify state before advancing a phase. Cheap;
Open command