# To Coder > 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. - Skill: `mrlyk/to-coder` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add mrlyk/to-coder` - Raw SKILL.md: https://api.skillmd.com/api/skills/mrlyk/to-coder/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: mrlyk (https://skillmd.com/u/mrlyk) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/mrlyk/to-coder --- # 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 1. Run the metrics script from wherever it was installed alongside this SKILL.md (the file lives at `/scripts/collect-metrics.mjs`, relative to this document): ```bash node /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. 2. 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 ` per item (already computed by the script, but read `git show ` / `git diff ..` 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 `/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: ```bash 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 `
` 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.