メニュー
Produce a decision-ready brief after a repository change by reconciling actual scope, material requirement or architecture drift, review-driven rework, verification evidence, and acceptance gaps.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/HuanHuanHuanFFF/huan-dev --skill delivery-briefコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Orchestrate a scoped repository change through requirement calibration, goal-driven implementation, proportional verification, independent pressure review, ordinary rework, and an evidence-bounded handoff. Use when the user explicitly requests the complete Huan Dev workflow.
Independently pressure-test an implemented repository change, resolve substantiated in-scope findings, and expose remaining decisions or evidence gaps before acceptance.
Calibrate a repository change before implementation by separating discoverable facts from user-owned decisions and settling scope, ownership, acceptance, and review intensity.
SOC 職業分類に基づく
SKILL.md を表示中
| name | delivery-brief |
| description | Produce a decision-ready brief after a repository change by reconciling actual scope, material requirement or architecture drift, review-driven rework, verification evidence, and acceptance gaps. |
| license | MIT |
Give the user the shortest brief that supports a decision to accept, request rework, or run a remaining real-environment check. Optimize decision value per unit of reading attention, not raw brevity.
Reconstruct only acceptance-relevant facts from the request, confirmed decisions, implementation, review, and fresh checks:
When requirement or architecture alignment could change acceptance, compare against a discoverable baseline; report a missing baseline only when that absence prevents the decision. Mention a no-finding review only when proving the review occurred is itself an acceptance condition. Keep confirmed facts, inferences, and unknowns distinct.
Lead with the outcome and the fact most likely to change acceptance. Expand deviations, review-driven corrections, and evidence gaps; compress satisfied constraints and routine implementation detail. Keep each finding beside its consequence, response, and evidence.
Let the content choose the shape: use one compact paragraph for a linear result, bullets for independent facts, and headings only when they reduce scan cost. Use precise anchors for details the user can inspect cheaply.
Delete a sentence unless removing it could change the user's judgment about scope, requirement or architecture drift, review rework, verification, or the next action. Prefer direct language over dense phrasing that the user must decode. Give exceptions and uncertainty more space than routine success.
Finish when the user can decide in one pass whether to accept, request rework, or run another check; every acceptance-changing unknown is explicit; and each material claim is bounded by evidence.