Agent Skills
› daeuniverse/honk
› honk-change
honk-change
GitHub用于规划、审查和验证 honk 代码变更,涵盖影响分析、双脑评审及PR准备。
Trigger Scenarios
需要修改 honk 相关代码或配置时
准备涉及 honk 的 PR 时
Install
npx skills add daeuniverse/honk --skill honk-change -g -y
SKILL.md
Frontmatter
{
"name": "honk-change",
"description": "Use for any honk change to plan, review, verify and prepare the PR."
}
Read first: AGENTS.md and the rules files its Task routing table names for the contracts touched.
Steps
- Plan first, in a file or draft PR text. Name the failing input and the line producing it at
origin/main, with its SHA. Write one imperative sentence per commit and say what is deliberately left alone. Tests:AGENTS.md, "Testing instructions". For a non-behavioural change (docs, workflow, extraction), say why reproduction and hunk ablation do not apply. Name the substitute check: byte comparison, link check or workflow stub. - Inventory the impact of each contract touched: users in other crates, tests and benches that construct it directly, CI workflows that run them, pages in
doc/en/anddoc/zh/, and any second implementation. Mark each changed, checked unaffected or left as a finding. If the change reaches another module, change that module rather than leaving a shim. - Have a second mind review the plan before code.
- One commit per step:
AGENTS.md, "Code style guidelines". - Verification and reporting:
AGENTS.md, "Testing instructions" and "Current validation guidance". For input-to-structure code, also compare a fixed input set before and after. List every changed output and its reason. - Have a reader who has not seen the plan read the diff and write what a user would experience differently.
- PR text:
AGENTS.md, "Code style guidelines" (PR bodies). - Batch same-theme few-line fixes in one PR with one commit each. Put edge findings in the rolling tracker issue and serious reproducible defects in their own issues.
Checklist
- Plan records the input, source revision, commits, exclusions and applicable check.
- Impact inventory gives every consumer a disposition.
- A second mind reviewed the plan before code.
- Commit steps follow "Code style guidelines".
- Verification follows the named root sections; input-to-structure comparisons account for changed outputs.
- A reader without the plan described the diff's user-visible effects.
- PR text follows "Code style guidelines".
- Fixes and findings are batched by step 8.
Version History
- 73b1077 Current 2026-11-07 08:53


