メニュー
Terminal human-acceptance phase of the /writing workflow — presents verified prose and returns the user's decision. Invoked by the workflow; not user-invocable.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/edwinhu/workflows --skill writing-acceptコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Use for feature development and engineering changes.
This skill should be used when the user asks to 'start data analysis', 'plan a data project', 'explore this dataset', 'what should I analyze', 'set up a new study', or needs the data-science workflow.
Use when the user asks to 'run a work workflow', 'do this properly', 'clarify, plan, and verify this', 'small structured task', or 'don't just wing it' for a bounded task too small for a specialized workflow.
SKILL.md を表示中
| name | writing-accept |
| description | Terminal human-acceptance phase of the /writing workflow — presents verified prose and returns the user's decision. Invoked by the workflow; not user-invocable. |
| user-invocable | false |
| disable-model-invocation | true |
This is the human acceptance beat. It does not perform prose, source-fidelity, or mechanical
review; those belong to writing-verify, which is independent MACHINE review of authenticated
PLAN-bound drafts. Passing writing-verify is evidence for this conversation, not acceptance by a
person — conflating the two is how a workflow ends up reporting "reviewed" for something no human
ever read.
Read ${CLAUDE_SKILL_DIR}/../beat-review/SKILL.md and follow it. It owns human-feedback capture, the
task queue, dispositions, and the meaning of REJECT:.
/writing was the only workflow with no beat-review path: its flow ended
→ /writing-revise → returned human review surface, a terminal surface hand-rolled inside the
revision loop. Everything the beat defines — dispositions, the queue, what REJECT: means — was
therefore reimplemented per workflow, or simply absent. The domain framing belongs somewhere, and
that somewhere is here rather than inside the beat or inside writing/SKILL.md.
{planFile, planHash}
identity. Read its Review Surfaces; they define what the user should read. Do not substitute a
fixed writing checklist — a plan that names its own surfaces is the authority on them.[CITE-NEEDED] markers that survived. Ask for acceptance, tactical feedback, or REJECT:.addressed, answered, or user-authorized waived),
and the resulting action through the review result and TaskList context. Do not create a planning
Markdown ledger for review material.beat-review, then send
unresolved changes to writing-revise with the concrete returned items. Its independent
writing-verify must re-run before this acceptance resumes. A reviser's claim that a finding is
fixed is not a new acceptance.REJECT: is not tactical feedback. The prose passed independent machine review and the user
still rejected it, so the receipt-selected plan's criteria were wrong. Mark the drafting and review
invalidated in TaskList and return to /writing to clarify and bind a replacement plan. Do not
patch the rejected plan, append criteria to it, or route this to writing-revise.REJECT:. Silence is neither.| About to | Why wrong | Do instead |
|---|---|---|
Report writing-verify PASS as human acceptance | Machine review is not a person; the whole point of this beat is the person | Present the surfaces and wait for a decision |
| Treat no response as acceptance | An unanswered question is not a yes | Ask again, or return that acceptance is outstanding |
Route a REJECT: to writing-revise | The criteria were wrong, not the prose | Return to /writing for a replacement plan |