To Coder
Generate a concise Chinese HTML report for the developer who owns this change: how efficient the run was, and what to look at before shipping. This skill is Task-backed only — there is no Standalone mode.
Resolve the Source
Take task-id from the invocation argument, or from superharness:finishing-a-development-branch when it dispatches this skill. Stop and ask for the exact task-id when no argument is supplied and no finishing context provides one.
Confirm .superharness/tasks/{task-id}/ exists and contains task.json. When the directory or task.json is missing, report the missing path and stop — do not create the report.
Collect Evidence
Run the metrics script from wherever it was installed alongside this SKILL.md (the file lives at <skill-dir>/scripts/collect-metrics.mjs, relative to this document):
node <skill-dir>/scripts/collect-metrics.mjs .superharness/tasks/{task-id}
This is the only source for every number in the report (durations, phase minutes, line counts, commit counts, clarifications, rework). Never compute or estimate a number yourself. When the script exits non-zero, report its stderr line and stop — do not produce a report from partial data.
Read task evidence in this priority, same as to-tester: task.json → prd.md and contract.md → plan.md → verification.md → Git commits/diff for the task's commit range → trace.jsonl.
task.json for identity, task items, and each item's commit.prd.md/contract.md for what the change is meant to do.plan.md for the intended module boundaries, useful for grouping the "重点修改" write-up.verification.md for Known Risks, unverified items, and any review findings left open — these feed 高风险模块 and 推荐自测清单.git show --numstat <commit> per item (already computed by the script, but read git show <commit> / git diff <base>..<head> directly when you need to understand what changed, not just how much) to write the file-level "改了什么" sentences.trace.jsonl for anything not covered by the metrics JSON (e.g. understanding which task item a review loop touched).
Synthesize
The report is a five-minute skim, not a design doc. Keep this red line:
- The two things that matter are efficiency (总览) and what to watch (重点关注 + 高风险模块 + 自测清单). Everything else — especially 修改范围 — stays short.
- In 修改范围, only give a diagram to genuinely important changes: a sequence diagram for call-chain/interaction changes, an architecture diagram for module/dependency changes, a flowchart for branching/logic changes. Mechanical changes (adding a field, renaming, wiring boilerplate) get no diagram, just one sentence saying why.
- Every diagrammed change must list its involved files: path, per-file +/- line counts (from the commit's numstat), and one short sentence of what that file does in the change. Task-table rows whose changes are not individually diagrammed are still summarized by file count in that row — do not silently drop files from the record.
- Do not write a per-task implementation essay or a tech-spec-style long-form section. No content outside the two reasons above gets expanded.
- High-risk determination: touches a public seam or is depended on by multiple callers, has no test coverage, has an open review finding, or is an unverified item from
verification.md.
- Rate every high-risk item on two axes: 发生可能性 and 影响范围, each 低/中/高. Place one dot per risk on the quadrant matrix (coordinate mapping 低=17% / 中=50% / 高=83%; X = 影响范围, Y = 发生可能性). Dot ids
R1..Rn anchor-link to their risk cards (#risk-r{n}); the dot count must equal the card count. A risk with either axis rated 高 uses the default red dot; all-其余 combinations use the mid (orange) dot class. Show both ratings as badges on the card title line.
- 推荐自测清单 is exhaustive (not just high-risk items) and high-risk rows are pinned to the top and marked
risk-row. Each row carries a checkbox with a stable data-id (tc1..tcN, top-to-bottom); a high-risk row's 自测点 references its risk anchor (对应 R{n}). The template's progress script persists checked state in localStorage under a key containing the task-id — keep the {{TASK_ID}} substitution inside the script's KEY constant.
- Every number placed in the report must come verbatim from the metrics JSON. A
null metric renders as "不可用" with the card kept in place (do not omit the card, do not substitute a guess). Non-empty warnings from the JSON must surface somewhere near the metric they qualify (e.g. as the phase-legend caption or a muted note) so the reader knows a number is a degraded estimate.
Write the Document
Copy <skill-dir>/templates/report-template.html, replace every {{SLOT}} placeholder and repeat the repeating blocks (task rows, focus-change blocks, file-list items, focus-table rows, risk blocks, self-test rows) as needed for this task's actual content, then overwrite .superharness/tasks/{task-id}/to-coder.html with the full file. Every run replaces the file wholesale; there is no incremental diff.
After writing, try to open it automatically and never fail the skill if opening doesn't work:
open .superharness/tasks/{task-id}/to-coder.html 2>/dev/null \
|| xdg-open .superharness/tasks/{task-id}/to-coder.html 2>/dev/null \
|| start "" .superharness/tasks/{task-id}/to-coder.html 2>/dev/null \
|| true
Completion Gate
Re-read the generated file and confirm:
- Exactly five
<section> blocks exist, in order: #overview, #scope, #focus, #risks, #selftest; the sticky topbar nav carries exactly these five anchors and its compact title matches the report title.
- The sticky topbar is the page's only header: it carries task title, badge, task-id, profile, branch,
base_sha..head_sha, generation time, and the five section anchors — no separate in-page header block.
- Every number in
#overview matches the metrics JSON field-for-field; any null renders as "不可用"; the phase bar segments sum to the active total and a qa segment appears only when phase_minutes.qa > 0.
- Insertions render green, deletions render red, in both the overview card and every task/file row.
- Every diagrammed change in
#scope has a syntactically paired mermaid block (opening/closing node and arrow syntax match) and a .file-list covering its files; every task-table row accounts for its files even when not individually diagrammed.
#risks blocks each carry exactly 风险点/影响面/验证方式 plus 可能性/影响 badges; the quadrant matrix has one dot per risk card, every dot's href resolves to an existing card id, and dot coordinates match the rated axes.#selftest is exhaustive and every high-risk row is pinned above the rest and tagged; every row has a checkbox with a unique sequential data-id; the progress script is present and its localStorage KEY contains this task-id.- No placeholder text (
{{...}}) remains anywhere in the file.
Report the output path. When invoked from superharness:finishing-a-development-branch, return control to its option menu after generation.
1---2name: to-coder3description: Generate a developer-facing efficiency and focus-area report for a completed Superharness task. Use when the user asks to "生成开发者报告", "开发交接报告", "to-coder", "developer report", or when /superharness:to-coder is invoked.4---56# To Coder78Generate a concise Chinese HTML report for the developer who owns this change: how efficient the run was, and what to look at before shipping. This skill is Task-backed only — there is no Standalone mode.910## Resolve the Source1112Take `task-id` from the invocation argument, or from `superharness:finishing-a-development-branch` when it dispatches this skill. Stop and ask for the exact task-id when no argument is supplied and no finishing context provides one.1314Confirm `.superharness/tasks/{task-id}/` exists and contains `task.json`. When the directory or `task.json` is missing, report the missing path and stop — do not create the report.1516## Collect Evidence17181. Run the metrics script from wherever it was installed alongside this SKILL.md (the file lives at `<skill-dir>/scripts/collect-metrics.mjs`, relative to this document):1920 ```bash21 node <skill-dir>/scripts/collect-metrics.mjs .superharness/tasks/{task-id}22 ```2324 This is the **only** source for every number in the report (durations, phase minutes, line counts, commit counts, clarifications, rework). Never compute or estimate a number yourself. When the script exits non-zero, report its stderr line and stop — do not produce a report from partial data.252. Read task evidence in this priority, same as `to-tester`: `task.json` → `prd.md` and `contract.md` → `plan.md` → `verification.md` → Git commits/diff for the task's commit range → `trace.jsonl`.26 - `task.json` for identity, task items, and each item's commit.27 - `prd.md`/`contract.md` for what the change is meant to do.28 - `plan.md` for the intended module boundaries, useful for grouping the "重点修改" write-up.29 - `verification.md` for Known Risks, unverified items, and any review findings left open — these feed 高风险模块 and 推荐自测清单.30 - `git show --numstat <commit>` per item (already computed by the script, but read `git show <commit>` / `git diff <base>..<head>` directly when you need to understand *what* changed, not just how much) to write the file-level "改了什么" sentences.31 - `trace.jsonl` for anything not covered by the metrics JSON (e.g. understanding which task item a review loop touched).3233## Synthesize3435The report is a five-minute skim, not a design doc. Keep this red line:3637- The two things that matter are **efficiency** (总览) and **what to watch** (重点关注 + 高风险模块 + 自测清单). Everything else — especially 修改范围 — stays short.38- In 修改范围, only give a diagram to genuinely important changes: a sequence diagram for call-chain/interaction changes, an architecture diagram for module/dependency changes, a flowchart for branching/logic changes. Mechanical changes (adding a field, renaming, wiring boilerplate) get **no diagram**, just one sentence saying why.39- Every diagrammed change must list its involved files: path, per-file +/- line counts (from the commit's numstat), and one short sentence of what that file does in the change. Task-table rows whose changes are not individually diagrammed are still summarized by file count in that row — do not silently drop files from the record.40- Do not write a per-task implementation essay or a tech-spec-style long-form section. No content outside the two reasons above gets expanded.41- High-risk determination: touches a public seam or is depended on by multiple callers, has no test coverage, has an open review finding, or is an unverified item from `verification.md`.42- Rate every high-risk item on two axes: 发生可能性 and 影响范围, each 低/中/高. Place one dot per risk on the quadrant matrix (coordinate mapping 低=17% / 中=50% / 高=83%; X = 影响范围, Y = 发生可能性). Dot ids `R1..Rn` anchor-link to their risk cards (`#risk-r{n}`); the dot count must equal the card count. A risk with either axis rated 高 uses the default red dot; all-其余 combinations use the `mid` (orange) dot class. Show both ratings as badges on the card title line.43- 推荐自测清单 is exhaustive (not just high-risk items) and high-risk rows are pinned to the top and marked `risk-row`. Each row carries a checkbox with a stable `data-id` (`tc1..tcN`, top-to-bottom); a high-risk row's 自测点 references its risk anchor (对应 R{n}). The template's progress script persists checked state in localStorage under a key containing the task-id — keep the `{{TASK_ID}}` substitution inside the script's KEY constant.44- Every number placed in the report must come verbatim from the metrics JSON. A `null` metric renders as "不可用" with the card kept in place (do not omit the card, do not substitute a guess). Non-empty `warnings` from the JSON must surface somewhere near the metric they qualify (e.g. as the phase-legend caption or a muted note) so the reader knows a number is a degraded estimate.4546## Write the Document4748Copy `<skill-dir>/templates/report-template.html`, replace every `{{SLOT}}` placeholder and repeat the repeating blocks (task rows, focus-change blocks, file-list items, focus-table rows, risk blocks, self-test rows) as needed for this task's actual content, then overwrite `.superharness/tasks/{task-id}/to-coder.html` with the full file. Every run replaces the file wholesale; there is no incremental diff.4950After writing, try to open it automatically and never fail the skill if opening doesn't work:5152```bash53open .superharness/tasks/{task-id}/to-coder.html 2>/dev/null \54 || xdg-open .superharness/tasks/{task-id}/to-coder.html 2>/dev/null \55 || start "" .superharness/tasks/{task-id}/to-coder.html 2>/dev/null \56 || true57```5859## Completion Gate6061Re-read the generated file and confirm:6263- Exactly five `<section>` blocks exist, in order: `#overview`, `#scope`, `#focus`, `#risks`, `#selftest`; the sticky topbar nav carries exactly these five anchors and its compact title matches the report title.64- The sticky topbar is the page's only header: it carries task title, badge, task-id, profile, branch, `base_sha..head_sha`, generation time, and the five section anchors — no separate in-page header block.65- Every number in `#overview` matches the metrics JSON field-for-field; any `null` renders as "不可用"; the phase bar segments sum to the active total and a `qa` segment appears only when `phase_minutes.qa > 0`.66- Insertions render green, deletions render red, in both the overview card and every task/file row.67- Every diagrammed change in `#scope` has a syntactically paired mermaid block (opening/closing node and arrow syntax match) and a `.file-list` covering its files; every task-table row accounts for its files even when not individually diagrammed.68- `#risks` blocks each carry exactly 风险点/影响面/验证方式 plus 可能性/影响 badges; the quadrant matrix has one dot per risk card, every dot's href resolves to an existing card id, and dot coordinates match the rated axes.69- `#selftest` is exhaustive and every high-risk row is pinned above the rest and tagged; every row has a checkbox with a unique sequential `data-id`; the progress script is present and its localStorage KEY contains this task-id.70- No placeholder text (`{{...}}`) remains anywhere in the file.7172Report the output path. When invoked from `superharness:finishing-a-development-branch`, return control to its option menu after generation.
mrlyk