1仕組みと動作原理
スキル全体が単一の判断基準に集約されます:すべてのフィードバックは、まず「修正(revision)」、「新規要望(new request)」、「単なる曖昧な意見」のいずれかに分類し、分類が完了するまでプロジェクトファイルには手をつけません。
The whole skill is one judgment applied per note: *is this a revision, a new request, or just vague?* Run each note through this before opening the project.
核心となる線引きを、契約書にそのまま使える定義として明文化します(修正 = 承認済みブリーフ/ボード内の調整、新規要望 = それ以外のもの)。
- **A revision** = a change to something that was already in the approved brief/board (adjusting timing, colour from the palette, swapping an approved word, fixing a glitch).
そのままコピー&ペースト可能なSOW条項テキストを提供します:明確な回数指定、「1ラウンド=集約された1つのフィードバック」の定義、および対象内/対象外リストの明記。
This project includes [2] rounds of revisions. A "round" is one consolidated set of feedback, collected from all stakeholders and delivered in a single document, then addressed in full.
ワークフローの第一歩は「作業を止めること(Stop)」:意味が確定していないフィードバックに対して直ちに手を動かすことを避けるため、まずはプロジェクトファイルを開きません。
1. **Stop.** Do not open the project file yet.
フィードバックは必ず事前に一本化させます:クライアント社内であらかじめ意見の対立を解消させ、単一のドキュメント(タイムコード、必須対応フラグ、解決策ではなく課題の提示)として提出させます。
• Tell me the problem, not the fix — "the intro drags" is more useful than "make it faster," because it lets me solve it properly.
曖昧なフィードバックに対する翻訳表を用意:感覚的な形容詞を限定された選択肢へと変換し、該当するタイムコードの指定を求めます。
| "Make it pop" | "More saturated colour, faster pacing, bigger scale moves, or stronger sound? Point to a second that already pops." |
新規要望は変更オーダーとして処理:作業工数・費用・納期への影響を提示した上で、クライアントに「進めるか保留にするか」の選択肢を与え、拒絶ではなく協調的なトーンを保ちます。
Tone notes: collaborative, never accusatory. Offer the choice (proceed or park), give a number, and state the timeline impact. The goal is to make the trade-off visible, not to say "no."
ラウンドの可視化と承認ゲートのロックで締めくくります:ラウンド番号を毎回記録し、書面で確定したフェーズを再開する場合は新規作業としてカウントします。
| Reworking an approved scene | Approval gate not locked | Lock each stage in writing; reopening a locked stage = new request |
2コア機能
4推奨統制措置と判定根拠
- SKILL.md: プロンプト指示およびテキストルールのみで構成され、スクリプト実行や外部への副作用はありません
5二重目の独立検証
- [ok] 是否存在脚本、命令或联网动作 — 全目录仅 Markdown;代码块只有邮件与合同文本模板,无 shell/JS 可执行语句,无 npx/curl/fetch/URL(除署名页脚)。
- [ok] 「一轮 = 一份合并反馈」的定义前后是否一致 — SOW 条款块、合并反馈模板(subject 里的 Round [N])与常见错误表三处口径一致,无自相矛盾。
- [ok] 变更单模板是否真的给「继续或搁置」两个出口(基调是否与声明一致) — 邮件模板结尾明写 If you'd rather keep to the original scope and budget, no problem — we'll proceed as planned and can revisit this later.,与 Tone notes 的「不说不」一致。
- [unlocatable] 条款的法律效力/适用性是否可在源码内确认 — SOW 条款以英文通用表述给出,未标司法辖区、未附法律依据;文档自称可 drop into the contract,但效力取决于整体合同与当地法律,本次侦查无法也无意核验。
6結論
e26d799916086272…