Explain engineering plainly
Skill HCW-AI2006/explain-engineering-plainly/skills/explain-engineering-plainly
Turn engineering-heavy updates into concise, accurate plain language.
npx -y skills add HCW-AI2006/explain-engineering-plainly --skill explain-engineering-plainlyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Translate engineering-heavy progress updates, completion reports, errors, code-review findings, implementation summaries, and technical explanations into concise, accurate plain language centered on what happened, what it means for the user, evidence, limitations, and next action. Use when the user asks for 大白话、说人话、通俗解释、没看懂、什么意思, when the audience is nontechnical, or when Codex is producing a stage or final engineering summary that would otherwise be jargon-heavy.
SKILL.md
3.6 KB, as published. Nobody here has run it
Explain Engineering Plainly
Translate the presentation, not the facts. Preserve what is true while replacing implementation-first wording with user-understandable cause, effect, status, and action.
Reverse map
Extract only decision-relevant facts from the engineering source:
Plain(source) = outcome → user-visible effect → reason when useful → evidence or limit → next action
Omit implementation details that do not change the user's understanding or decision. Keep an exact term, path, command, or error only when the user needs it to act; explain it plainly first.
Choose the shortest useful mode
- User says “大白话”, “说人话”, “没看懂”, or “什么意思”: start with
大白话就是：and answer directly. - Stage update: use at most three short sentences—what is done, what it means, and what happens next.
- Completion summary: lead with the result and user-visible change, then give verification and any remaining limitation.
- Failure or blocker: state what did not work, its practical impact, and the next safe action. Never disguise failure as progress.
- Direct explanation: answer first; use one analogy only if it materially improves understanding.
Translate accurately
- Replace architecture and algorithm names with observable cause and effect. Example: “weighted graph propagation found a four-hop dependency” becomes “系统顺着调用关系找到了四层之外的真正关联位置。”
- Explain necessary jargon once in parentheses after the plain meaning, not before it.
- Preserve uncertainty, risk, verification status, and required user decisions.
- Distinguish
implemented,tested, andproven in production; never merge them into “已经解决”. - Keep numbers when they carry evidence, but explain what they demonstrate.
- Match the user's language and level. Be respectful, not childish or patronizing.
- Do not add a tutorial, code walkthrough, speculative benefit, or new recommendation unless requested.
- Do not repeat the full engineering summary after translating it.
Compose with engineering skills
When another skill supplies a verified progress or completion result, translate that result without re-running the task or changing its claims. Preserve links only when they help the user inspect or act.
For complete-engineering-intent, apply this skill to stage and final summaries after implementation and verification. Keep the earlier intent-confirmation sentence unchanged.
Examples
Engineering: Added AST fingerprints and mechanism-weighted PPR; 23 regression tests pass.
Plain: 大白话就是：现在即使代码里的变量换了名字，系统也更容易找到真正相关的位置；而且已经用 23 项测试确认原有功能没有被破坏。
Engineering: Migration blocked by schema drift; no production write was attempted.
Plain: 这次更新还没有执行，因为现有数据库结构和预期不一致。生产数据没有被改动；下一步需要先确认结构差异，再重新验证更新。