by-design

意図した設計

まずこのルールを読んでください。以下のすべてのステップはこのルールに従います。判断ごとに1行、返信ごとに質問は最大1つです。

このスキルは、Python 3.11以降とシェルが利用できる環境で動作します。標準ライブラリのみを使用し、ネットワークアクセスは不要です。

このスキルの名前は、作業内のあらゆる選択に対して問いかける質問です。それは意図した設計ですか。それとも、テンプレートとともに持ち込まれ、そのまま残ったものですか。

このスキルは、デザインをレビューするのではなく、判断を明らかにします。批評すること、方向性を選ぶこと、まだ存在しない作業の形を整えることは、それぞれ決定の後、最中、前に行う同じ行為です。つまり、役割はひとつの文にまとめられます。この作業に含まれる判断を見つけ、それぞれが何を犠牲にするかを明らかにし、実際には誰も決めていないものを示します。

最後の点にこそ価値があります。弱いデザインはたいてい、選択肢として認識されなかった選択から生まれます。たとえば、別のページから引き継がれたグリッドや、競合他社をまねたトーンです。

このスキルが受け付けるコマンドは何ですか？

コマンド	動作
help	この表と、各コマンドの説明を1行ずつ表示します。
watch	デフォルトです。判断を台帳に記録し、質問は最大1つにして返信します。
judge	既存の画面、コンポーネント、フロー、コピーのブロックを読み取り、その内容から台帳を埋めます。
choose	2つ以上の方向性のトレードオフを整理し、選択は保留します。
shape	まだ存在しない作業に向けて、台帳の行を空の枠として用意します。
audit	ブリーフに記載された制約のうち、実際に必要なものと、選択が固定化したものを検証します。
ask	質問をすべてまとめて返し、台帳には手を加えません。

ユーザーがコマンドを指定しない場合は、watchを実行します。届いた内容に応じて、この表から適切な姿勢を選び、添付ファイルよりもユーザーの言葉を優先してください。

届く内容	姿勢
スクリーンショット、リンク、コピーのブロックなど、1つの成果物	judge
2つ以上の選択肢、または明示された分岐	choose
作成されたものが何もない、意図だけの状態	shape
ブリーフ、または明示されたルールの一覧	audit
give meまたはlistという表現で質問を求める依頼	ask

このスキルはどのように実行しますか？

すべてのステップを順番に実行します。各ステップでは、1つのアクションと、そこから得られるべき結果を指定します。結果が指定された内容と異なる場合は、先に進む前に修正して、そのステップを再実行してください。 0. リクエストを判定します。mise run gate --text "<the request>" を実行します。not-design で始まる行が出た場合、ここで実行を終了し、このスキルは返信に何も加えません。design で始まる行が出た場合、ステップ 1 に進みます。結果：判定を示す行が 1 行出ます。not-design の場合、それ以上のステップは実行されません。

1. 台帳を読みます。mise run ledger show --file decision-ledger-<slug>.md を実行します。終了コード 1 は台帳が新しいことを意味するため、mise run ledger init --file decision-ledger-<slug>.md --slug <slug> を実行します。結果：ファイルが存在し、そこに記載済みの決定を一覧表示できます。
2. 2 つ目の表を使い、1 つの節で姿勢を示します。結果：返信に記載できる姿勢の名前が決まります。
3. アーティファクトから座標を特定します。アーティファクトが画像の場合、まず 2 行で、何を示す画像かと、どのような状態かを書きます。状態は populated、empty、error、loading、offline、disabled、mid-flow から選びます。画像には状態が含まれており、画像の説明だけではその状態が失われがちです。そして、多くの場合、その状態こそが決定事項です。次に mise run locate --file <artifact> を実行するか、リクエストを --text で渡します。状態が重要な場合は、その状態を表す語を --hint に渡します。結果：各候補のスコア、該当した用語の数とその用語を含む、順位付きの一覧が出ます。標準エラーに weak read の行が出た場合、最上位の候補が 1 つの用語だけに依存しているか、上位 2 つの差が小さすぎるため、順位を信頼できません。その場合はアーティファクトの種類を自分で名付け、--hint "<the words for what this is>" を付けて再実行します。これにより、語彙がカバーしていない分野でも適切に特定できます。
4. 質問を抽出します。mise run slice --category "<category>" --stage <stage> --match "<a noun from the artifact>" --limit 20 を実行します。結果：終了コード 0 と質問の一覧が出ます。標準エラーを確認します。widened: の行が出た場合、絞り込み条件が緩和されたことを返信で伝えます。質問が 1 つか 2 つしか見つからない場合は、アーティファクトの語を有効な絞り込み条件として維持し、それ以外の条件を先に緩和します。dropped match の行が出た場合、ナレッジベースにはあなたの専門分野で使う言葉で書かれた内容がないことを返信で伝え、残りの行は抽出結果ではなく実作業に基づいて書きます。--match にはアーティファクト自体にある語を渡してください。カテゴリだけでは、ここにある内容ではなく一般的な内容が返されます。
5. 質問を決定事項ごとにまとめます。複数の質問が通常、1 つの選択につながります。所見を削る前に、それぞれの所見が示す決定事項に置き換えます。たとえば、ラベルのないグリッドは指摘すべき欠陥ではなく、グリッドをどのように読み上げるかという、誰も決めていない事項です。結果：質問の一覧より短い決定事項の一覧ができ、所見はすべていずれかの行に含まれます。
6. 決定事項ごとに 1 行を書きます。mise run ledger add --file decision-ledger-<slug>.md --decision "<text>" --chosen "<text>" --trades "<text>" --risks "<text>" --origin <deliberate, inherited, or open> を実行します。ステップ 4 の質問がアーティファクトではなく行の根拠となった場合は、--source "<question id and url>" も指定します。結果：決定事項ごとに 1 行が追加され、どの行が調査から、どの行がライブラリから得られたかを示すファイルができます。
7. 書いた内容を数えます。mise run ledger count --file decision-ledger-<slug>.md --decision "<text>" を実行し、さらに show を実行して、返信に記載する行数と継承された行数を数えます。結果：記憶ではなくコマンドから取得した数値が得られます。ステップ 10 で、その数値とファイルの内容が照合されます。
8. 話すべきか、どの行について話すべきかをスクリプトに確認します。mise run speak --file decision-ledger-<slug>.md --rank を実行して、各行について不明な点が多い順に継承された行を並べます。次に mise run speak --file decision-ledger-<slug>.md --decision "<the first ranked row>" --origin inherited --live yes を実行します。結果：順位付きの一覧と、ask または hold で始まる行が出ます。その行が ask で始まる場合は、返信に質問を 1 つ記載します。
9. assets/reply-template.md を使って返信の草案を作成します。結果：それぞれ記入された 4 行ができます。
10. 草案を確認します。mise run check-reply --file <draft path> を実行します。ask の姿勢の場合は --full-slice を追加し、台帳が草案と同じ場所にない場合は --ledger-dir <folder> を追加します。このコマンドは返信に記載された台帳を読み、その件数をファイルと照合するため、コマンドで確認していない数値があるとここで失敗します。結果：draft passed every rule という行が出ます。それ以外の行が出た場合は修正内容を示しているため、修正して再実行します。

このスキルが発話するのはどんなときですか？

リソースのゲート：ここに記載されているパッケージファイルを使う前に、mise run validate を実行してください。

ステップ 8 でこれに答えます。スクリプトが回数を管理するため、毎回同じ答えになります。判断が現在進行中で、その選択が引き継がれたものであり、台帳での記録が 3 回未満の場合に発話します。それ以外の場合は常に沈黙し、いずれの場合も行を記録してください。沈黙するのが一般的で、正しい結果です。

このルールの根拠については、references/interruption.md を参照してください。

どのタイミングで読み込まれますか？

• references/coordinates.md：ステップ 3 で読みます。35 個のカテゴリ名、8 つのレンズ、段階的に広げる手順が記載されています。
• references/interruption.md：ステップ 8 の根拠が必要な場合、またはスキルが沈黙した理由をユーザーが尋ねた場合に読みます。
• references/ledger-format.md：ステップ 6 で読みます。各列に記録する内容が記載されています。
• assets/gate-terms.yaml：ステップ 0 で照合する語彙です。ゲートが読み込みます。
• assets/terms-index.yaml：質問からカテゴリごとに数えた用語です。ステップ 3 で mise run locate が読み込みます。
• assets/trade-terms.yaml：各分野が自らの仕事を表すのに使う言葉を手動で記録したものです。ステップ 3 で、集計された用語と併せて読み込みます。分野が誤った棚に分類された場合はこのファイルに追加し、その後 mise run bench を実行してください。
• assets/disciplines.yaml：職種名と、各職種の判断が属する棚を対応付けたものです。ステップ 3 で読み込み、専門用語よりも優先して重み付けします。
• references/disciplines.md：画面以外のものを扱う場合、職種が一覧にない場合、またはステップ 3 で成果物を分類できない場合に読みます。
• references/generation-contract.md：このスキルのレイアウト、タスクグラフ、チェックを変更する前に読みます。構造が満たすべきルールが記載されています。
• references/decisions.md：このスキルが現在の構成になっている理由を知る必要がある場合に、スクリプト、しきい値、語彙を変更する前に読みます。
• references/decisions-field.md：指標、フィクスチャ、またはライブラリが対応する職種の範囲についての質問では、references/decisions.md と併せて読みます。
• assets/index.yaml：カテゴリのインデックスです。スクリプトが読み込みます。
• assets/questions/：カテゴリごとに 1 ファイルあり、全 16,112 件の質問を収録しています。スクリプトがこれらを読み込み、返信では選択された行のみを引用します。
• assets/reply-template.md：ステップ 9 で読みます。
• mise run test：これらを実行してください。各コマンドに --help を付けると、フラグ、終了コード、実行例が表示されます。
• mise run crafts：このスキルがデザイン関連の職種にどこまで対応しているかを確認するために実行します。--thin を付けると、それぞれの職種の棚が十分に対応できていない職種を一覧表示します。
• mise run test：スクリプトを変更した後に mise run test を実行してください。
• examples/：実行するコマンドに対応するファイルを読みます。スライスを信頼する前に examples/example-widened-slice.md を読み、ステップ 3 で弱い読み取りを示す行が出力された場合は examples/example-weak-read.md を読み、作業が画像として届いた場合は examples/example-image-artifact.md を読み、台帳に引き継がれた行がない場合は examples/example-no-question.md を読みます。
• evals/：このスキルを使うのではなく、評価する場合に読みます。
• mise run bench：語彙、用語インデックス、スコアリングのいずれかを変更した後と、実際のデザイン作業で実行した後に実行してください。

実際の作業は、このスキルにどう残りますか？

このスキルを通じて実際のデザインタスクを実行するたびに、それが恒久的なフィクスチャになります。そのため、後から変更しても、このフィクスチャで修正した内容が気づかれないまま元に戻ることはありません。実際の作業を行った実行の最後に、次の手順を実行してください。

1. 現場で実際に使われた言葉でブリーフを保存します。保存先は evals/files/brief-<nn>-<slug>.txt です。結果：テストのようではなく、依頼そのもののように読めるファイルができます。
2. 正しいと判明した棚を、evals/files/briefs.json に新しいキーとして記録します。結果：キーが1つ追加され、既存のキーは変更されません。
3. ゲートで拒否すべき依頼があれば、evals/files/non-design.json に追加します。結果：ゲートが止めるべき依頼が1つ増えます。
4. mise run bench を実行します。終了コードが1の場合、低下したすべての指標が表示されます。原因を修正して、もう一度実行してください。結果：exit 0 が表示され、記録されたベースラインを下回る指標がなくなります。
5. 手順4が成功し、この実行でフィクスチャを追加した場合に限り、mise run bench --update を実行します。結果：以降の実行で下回ってはならないベースラインが設定されます。

evals/baseline.json にはゲートの指標と、各フィクスチャについて正しかった棚の順位が記録されています。重要なのは順位です。語彙が弱まると、棚がトップ3から外れるずっと前に、2位から5位へと下がります。その変化を検知できるのは順位だけです。

実行を成功させるために、記録された数値を決して下げないでください。指標の低下が示しているのは変更の問題であり、フィクスチャの問題ではありません。

私の分野でも使えますか？

リソースゲート：ここに記載されたパッケージファイルを使う前に、mise run validate を実行してください。

はい。最も手早い方法は、自分の仕事を伝えることです。assets/disciplines.yaml では、アートディレクターから船舶建築家、フラワーデザイナーまで、200の職種名を、その職種の意思決定が属する棚に対応づけています。そのため、分野を伝えるだけで、該当するスライスにたどり着けます。それぞれの職種に、その職種の言葉で実際の仕事を1行ずつ与えて65の職種で測定したところ、すべてがゲートを通過し、62職種は最初に正しい棚に分類され、65職種すべてがトップ3に入りました。

この手法は特定の分野に依存しませんが、ライブラリの充実度は均一ではありません。65の分野のうち9つは、該当する棚の内容が不足しています。それらの分野は、実行中に見つけることになるまで放置せず、references/disciplines.md に記載しています。画面、ブランド、製品の分野は特に充実しており、花、仕立て、照明機材の分野は比較的少なめです。棚の内容が少なくても、列の構成は変わりません。そのため、スライスをプロンプトとして読み、残りの行は実際の作業から作成してください。references/disciplines.md には、一覧にない分野の配置表と、次の人が同じ作業をしなくて済むように追加すべき2行が記載されています。

別のスキルに任せるべきものは何ですか？

事実は別の場所で扱います。デザインのコンテキストを記録するスキルが、トークン、画面一覧、受け入れ基準、明示されたルールを管理します。このスキルが扱うのは意思決定です。この境界は重要です。ブリーフに明示されたルールはすべて、誰かが選択し、制約として書き留めたものです。監査の観点では、まさにそれを検証します。画面の状態を列挙するスキルが状態一覧を管理し、このスキルはその状態に意思決定を結びつけます。

注意点

• ステップ 0 はデフォルトで続行します。別のクラフトが指定され、デザインの表層が含まれない場合にのみ停止します。デザインの会話は通常の言葉で進み、デザイン用語のリストではそのすべてを認識できないためです。
• カテゴリを手動で選ぶと、そのスライスは誤った棚に送られます。ステップ 3 は成果物を読み取ります。そのため、ステップ 4 の中ではなく、その前に実行します。
• ステップ 3 が提案し、あなたが判断します。26 分野の 26 件のブリーフで測定したところ、適切な棚が最初に選ばれたのは 24 回で、毎回トップ 3 に入りました。質問から数えた語彙と、その分野で使われる言葉を手作業でまとめた語彙という、2 つの語彙を読み取るため、「ローワーサード」「キルフィード」「バスの警告音」のような業界用語を使ったブリーフでも適切な棚に収まります。誤った順位付けが黙っていたことはないため、読み取り結果が弱い場合はメモではなく、--hint を渡す指示として扱ってください。
• --match を指定せずにカテゴリを使うと、目の前にあるものではなく、そのカテゴリに共通するものが返されます。成果物で使われている名詞を渡してください。
• ステップ 4 では stderr を確認してください。範囲が広がったスライスは精密なものと見分けがつかず、より広い問いに答えます。
• 書き出す前にグループ化してください。チェックアウト画面に関する 20 の質問は、通常 4、5 個の判断にまとまります。
• 気づいたことを記録しなければ、失われます。台帳には選択を記録するため、観察事項は、それが意味する選択として表現し、行を割り当ててください。返信に残したり、削除したりしないでください。
• 選択と構成の段階では、選択済みの列を空欄にしておいてください。空のセルが成果物です。
• 引き継がれた行があることを想定してください。すべての行が意図的に見える台帳は、ステップ 5 の監査を省略したサインです。また、引き継がれた行がひとつもない台帳では質問を作れません。これはステップ 10 で徹底されます。その場合、4 行目全体を「なし」にしてください。
• カテゴリ名は完全一致させてください。一致しない名前を指定すると、終了コード 2 で終了し、受け取った名前が表示されます。
• スライスの出力では、長いダッシュはカンマまたはコロンに置き換えられます。保存されたファイルでは句読点はそのままです。

このスキルはいつ完了しますか？

not-design 判定の場合、ステップ 0 で作業は完了し、何も書かず、何も伝えません。それ以外の場合は、台帳に判断ごとの行が 1 行ずつあり、すべての行に出所が記載され、今回実行したコマンドから取得した件数を使って返信がテンプレートに従い、mise run check-reply が draft passed every rule と表示した時点で作業は完了です。

ファクトリー実行契約

受け入れ可能な成果：指定されたデザイン意図を、レンダリングされたエビデンスに裏付けられたレビュー済みのデザイン判断台帳に変換します。最小のオーナーを変更しながら、現在のデザイン判断台帳の動作を維持します。

1. mise run ci で現在のパッケージを固定し、そのダイジェストを記録します。
2. mise run domain-research-policy を実行し、現在のデザイン判断台帳のソースと反証エビデンスを評価します。
3. 指定されたデザイン判断台帳の操作に対して mise run agentic-request を実行します。意味上の選択はモデルに委ねてください。
4. mise run decision-policy、mise run ci、および動作評価を実行します。失敗した場合は、最も下位のオーナーに戻ります。
5. mise run invocation-policy -- <receipt> を実行し、すべてのタスクを処理するか、ドメイン固有の理由に基づいて使用しないことを説明します。
6. 必要に応じて mise run improvement-policy を実行します。保護対象の次元に悪化がない場合に限り、変更する次元は 1 つだけにしてください。

契約が必要な場合に限り、mise run use-case-policy で assets/use-case-contract.json を読み込み、mise run evals で evals/evals.json を読み込みます。

Mise は、繰り返し可能な処理、順序、レシート、チェックを担います。モデルは解釈、因果関係の判断、創造的な作業、およびコードでは提供できない直接的な知覚を担います。権限がない場合、エビデンスが古い場合、またはゲートに失敗した場合は停止してください。