impeccable

本番品質のフロントエンドインターフェースを設計し、反復的に改善します。実際に動作するコード、確かなデザイン上の判断、卓越した仕上がりを実現します。

セットアップ

作業を進める前に、必ず次の手順を実行してください。

1. セッションごとに node .agents/skills/impeccable/scripts/context.mjs を一度実行してください。ランタイムにこのスキルの読み込み済みベースディレクトリが表示された場合は、代わりに node <skill-base-dir>/scripts/context.mjs を実行してください。作業ディレクトリはスキルのディレクトリではなく、ユーザーのプロジェクトにしてください。リクエストでモノレポ内のファイル、ルート、アプリが指定または示唆されている場合は、具体的なパスを推定し、同じコマンドに --target <path> を追加してください。この会話ですでに出力を確認している場合は、再実行しないでください。このスクリプトは、プロジェクトの PRODUCT.md（存在する場合は DESIGN.md も）を Markdown ブロックとして出力するか、ファイルがないことを通知します。出力された内容に従ってください。出力に NO_PRODUCT_MD が含まれている場合、ユーザーが init、teach、craft、shape を実行した場合、またはその表現がゼロから構築するフローのいずれかに明確に当てはまる場合（例：「ランディングページを構築／作成する」「新しいアプリを設計する」「機能を形にする」）は、まず reference/init.md に進んでください。それら以外のコマンドで、既存コードを対象とする範囲限定の evaluate／refine／enhance／fix／iterate リクエストの場合は、init に進んではいけません。既存コードをコンテキストとして、（手順 4 に従って）対象の画面からレジスターを推定して作業を進め、後でユーザーが実行できる選択肢として $impeccable init を一度提案してください。PRODUCT.md がなくても、範囲限定のリクエストを妨げてはいけません。出力の末尾に UPDATE_AVAILABLE 指示がある場合は、それに従ってください（ユーザーに一度だけ更新を確認してから、作業を続けます）。更新確認によって現在の作業を妨げてはいけません。
2. ユーザーがサブコマンド（craft、shape、audit、polish など）を実行した場合は、次にそのコマンドのリファレンスを必ず読んでください。プロジェクトがネイティブの場合（context.mjs の指示にある ios／android／adaptive）は、reference/<command>.md またはネイティブ版（例：reference/audit.native.md）を読みます。どちらか一方のみで、両方読んではいけません。これは必須です。リファレンスに定められたフローを省略すると、ユーザーが期待する手順を飛ばすことになります。
3. 既存のデザインシステム、規約、コンポーネントを把握してください。プロジェクトのファイル（CSS／トークン／テーマ／代表的なコンポーネントまたはページ）を少なくとも 1 つ読んでください。手順 2 でサブコマンドのリファレンスを読んでいる場合も必須です。既存の仕組みが機能するなら活用し、UX が向上するなら別の方法を選んでください。
4. 該当するレジスターのリファレンスを読んでください。これは必須です。省略すると、ありきたりな出力になります。プロジェクトがマーケティング、ランディングページ、キャンペーン、長文コンテンツ、ポートフォリオ（デザイン自体が製品）に該当する場合は reference/brand.md を読んでください。アプリ UI、管理画面、ダッシュボード、ツール（デザインが製品を支える）の場合は reference/product.md を読んでください。次の優先順位で判断します。（1）タスクの手がかり（「ランディングページ」か「ダッシュボード」か）、（2）作業対象の画面（ページ、ファイル、ルート）、（3）PRODUCT.md の register フィールド。
5. PRODUCT.md の ## Platform が ios または android の場合は、reference/<platform>.md も読んでください（HIG／Material 3 の規約）。adaptive（クロスプラットフォームで両方に対応する場合）は、両方のファイルを読みます。web、未設定、認識されない値の場合は、追加で読むものはありません。該当する場合は context.mjs が指示を出力します。
6. プロジェクトが新規で、手順 3 で既存の CSS トークン／テーマ／確定済みブランドカラーが見つからない場合は、node .agents/skills/impeccable/scripts/palette.mjs を実行して、ブランドのシードカラーと構成のガイダンスを取得してください。これをプライマリブランドカラーの基準にします。スクリプトの指示に従い、OKLCH を全体で使用して、これを中心に残りのパレット（bg、surface、ink、accent、muted）を構成してください。手順 3 で既存のトークンに確定済みのブランドカラーが見つかった場合に限り、この手順を省略できます。その場合は、既存のアイデンティティを維持することを優先してください。

デザインの指針

プロトタイプや出発点ではなく、そのままリリースできる本番品質のコードを作成してください。ユーザーから指示がない限り、近道はしないでください（迷った場合は確認してください）。完全な実装（美しく、レスポンシブで、高速かつ精密で、バグがなく、ブランドに沿ったもの）に仕上がるまで作業を続けてください。細部へのこだわりを大切にしてください。作成したページ、セクション、コンポーネントは、利用可能なツール（ブラウザーでのスクリーンショット撮影やコンピューター操作など）を使って、実地で検証してください。GPT は驚くべき仕事を成し遂げられます。妥協しないでください。

一般的なルール

色

• コントラストを確認してください。 本文テキストは背景に対して 4.5:1 以上、大きなテキスト（18px 以上、または太字で 14px 以上）は 3:1 以上にしてください。プレースホルダーテキストにも、くすんだグレーをデフォルトで使うのではなく、同じ 4.5:1 のコントラストが必要です。最もよくある問題は、色味のあるほぼ白の背景に、くすんだグレーの本文テキストを置くことです。コントラストが基準に近い場合でも、本文色を色調の濃い側に寄せてください。「エレガントさ」のために薄いグレーを使うことが、AI のデザインが読みにくく感じられる最大の原因です。
• 色付きの背景にグレーのテキストを置くと、色がぼやけて見えます。背景と同じ色相の濃い色合いか、テキスト色の透明度を使ってください。

タイポグラフィ

• 本文の行の長さは 65～75ch 以下にしてください。
• 似ているものの同一ではないフォントを組み合わせないでください（幾何学的なサンセリフ同士、人文主義的なサンセリフ同士など）。セリフ体とサンセリフ体、幾何学的な書体と人文主義的な書体のように、対照的な組み合わせにするか、同じファミリーを複数のウェイトで使ってください。
• ヒーロー／ディスプレイ見出しの上限は clamp() の最大値で ≤ 6rem（約 96px）にしてください。それを超えると、デザインではなくページが大声で叫んでいるようになります。
• ディスプレイ見出しの文字間隔は ≥ -0.04em にしてください。それより詰めると文字が接触し、デザインではなく窮屈に見えます。
• h1～h3 には text-wrap: balance を使って行の長さを整え、長い文章には text-wrap: pretty を使って孤立行を減らしてください。

現在見落としている、タイポグラフィに関する重要な上限が 1 つあります。

• ディスプレイ見出しの文字間隔は ≥ -0.04em にしてください。ディスプレイ用の h1 にデフォルトで使っている -0.05～-0.085em では、文字が接触して窮屈に見えます。タイトなグロテスク体なら -0.02～-0.03em で十分です。-0.04em が下限です。

レイアウト

• 間隔に変化をつけて、リズムを生み出してください。
• カードは安易な答えです。本当に最適な表現方法である場合にのみ使ってください。カードの入れ子は常に避けてください。
• 1 次元のレイアウトには Flexbox、2 次元には Grid を使ってください。flex-wrap のほうがシンプルなのに、安易に Grid を使わないでください。
• ブレークポイントなしでレスポンシブグリッドを作る場合は、repeat(auto-fit, minmax(280px, 1fr)) を使ってください。
• 意味のある z-index の階層（ドロップダウン → スティッキー要素 → モーダルの背景 → モーダル → トースト → ツールチップ）を構築してください。999 や 9999 のような場当たり的な値は使わないでください。

モーション

• モーションは意図を持って設計し、後付けにしないでください。実装の一部として検討してください。
• 本当に必要な場合を除き、CSS のレイアウトプロパティをアニメーションさせないでください。
• 指数関数的なカーブ（ease-out-quart / quint / expo）でイーズアウトしてください。バウンスや弾性のある動きは使わないでください。
• より高度なモーションが必要な場合は、ライブラリ（motion、gsap、anime.js、lenis など）を使ってください。
• モーションの軽減への対応は必須です。すべてのアニメーションに、@media (prefers-reduced-motion: reduce) での代替手段（通常はクロスフェードまたは即時切り替え）を用意してください。
• リスト内の項目を順に表示する演出は適切です。問題なのは、すべてのセクションに同じ表示演出を一律に適用することです。各表示演出は、その内容に合ったものにしてください。一律の演出を避けるために、モーションのないページをリリースする必要はありません。
• 表示アニメーションは、コンテンツが初期状態ですでに見えている状態を保ちながら、表示を引き立てるものにしてください。クラスによるトランジションでコンテンツの表示を制御しないでください。トランジションは非表示のタブやヘッドレスレンダラーで停止するため、表示演出が実行されず、セクションが空白のままリリースされることがあります。
• 洗練されたモーションに使える素材は、transform / opacity だけではありません。効果を実質的に高め、滑らかな動きを保てる場合は、ぼかし、backdrop-filter、clip-path、mask、シャドウ／グローも活用してください。

インタラクション

• overflow: hidden または overflow: auto のコンテナ内で position: absolute を使って描画したドロップダウンは、コンテナからはみ出た部分が切り取られます。ネイティブの <dialog>／popover API、position: fixed、またはポータルを使って、スタッキングコンテキストの外に表示してください。

新規プロジェクトのみ（既存の作業がない場合）

色とテーマ

• OKLCH を使用します。
• クリーム／サンド／ベージュのボディ背景は、2026年の飽和した AI デフォルトです。 暖色系ニュートラルの帯全体（OKLCH L 0.84-0.97、C < 0.06、色相 40-100）は、何と呼ぶかにかかわらず、クリーム／サンド／紙／羊皮紙として認識されます。--paper、--cream、--sand、--bone、--flour、--linen、--parchment、--wheat、--biscuit、--ivory のようなトークン名も、それ自体が手がかりになります。ブリーフが「温かみのある、伝統的な、家族向けの海岸沿いのイタリアン」や「雑誌のような温かみ」や「編集上の抑制」であれば、それをほぼ白の暖色系背景に置き換えてはいけません。それが AI のやり方です。次のいずれかを選びます。（a）彩度の高いブランドカラーをボディに使う（テラコッタ、オックスブラッド、濃いオーカー、ほぼ黒）、（b）色度 0 の真のオフホワイト（または暖色に寄せず、ブランド独自の色相に色度を寄せる）、（c）ブランド独自の色合いがはっきりと感じられる、より暗い中間調のティンテッドニュートラル。「温かみ」は、ボディ背景ではなく、アクセントカラー、タイポグラフィ、画像で表現します。
• ティンテッドニュートラル：ブランドの色相に向けて色度を 0.005～0.015 加えます。「ブランドの雰囲気に合うから」という理由で暖色系または寒色系に色味を寄せるのをデフォルトにしないでください。それはプロジェクト間の画一化につながります。
• テーマを選ぶとき、ダークとライトのどちらもデフォルトではありません。「ツールはダークが格好いいから」ダークにするのでも、「安全策として」ライトにするのでもありません。選ぶ前に、物理的な場面を一文で書いてください。誰が、どこで、どんな環境光の下、どんな気分で使うのか。その一文だけで答えが決まらないなら、具体性が足りません。決まるまで詳細を加えてください。
• 色を選ぶ前に、カラー戦略を決めます。コミットメントの軸に沿った 4 つの段階があります。
  • 抑制：ティンテッドニュートラルに、使用面積 10% 以下の単一のアクセントカラーを加えます。製品のデフォルト、ブランドのミニマリズムに適しています。
  • コミット：彩度の高い 1 色で、表面の 30～60% を占めます。アイデンティティを重視するページにおけるブランドのデフォルトです。
  • フルパレット：3～4 個の役割を定め、各色を意図的に使います。ブランドキャンペーンや製品のデータビジュアライゼーションに適しています。
  • 全面染め：表面そのものが色です。ブランドのヒーローセクションやキャンペーンページに適しています。

絶対に避けるもの

該当箇所を見つけたら書き換えてください。以下のいずれかを書こうとしている場合は、構成を変えてください。

• 側面だけのアクセント罫線。 カード、リスト項目、コールアウト、アラートに、色付きのアクセントとして 1px を超える border-left または border-right を使うこと。意図的な使用は避けてください。全辺の罫線、背景色の淡い色合い、先頭の番号やアイコン、または罫線なしに書き換えてください。
• グラデーション文字。 background-clip: text とグラデーション背景の組み合わせ。装飾であり、意味を持たせるべきではありません。単色を使ってください。強調にはウェイトやサイズを使ってください。
• デフォルトとしてのグラスモーフィズム。 装飾目的でぼかしやガラス風カードを使うこと。まれに、明確な目的がある場合に限って使うか、使わないでください。
• ヒーロー指標のテンプレート。 大きな数字、小さなラベル、補足統計、グラデーションのアクセント。SaaS の陳腐な表現です。
• 同一のカードグリッド。 アイコン＋見出し＋テキストの同じサイズのカードを延々と繰り返すこと。
• すべてのセクションの上に置く、小さな大文字で字間を広げたアイブロウ。 2023 年ごろのキッカー（見出しの上に置く、小さく字間を広げた大文字のテキスト「ABOUT」「PROCESS」「PRICING」など）は、今や AI で使い古された定型表現です。ブリーフに関係なく生成物の 55〜95％に現れるのは、それが見分ける手掛かりである証拠です。意図的なブランドシステムとして使う名前付きキッカーは個性になりますが、すべてのセクションにアイブロウを置くのは AI らしい文法です。別のリズムを選んでください。
• デフォルトの骨組みとして使う番号付きセクションマーカー（01／02／03）。 すべてのセクションの上に 01 · About / 02 · Process / 03 · Pricing を置くのは、アイブロウの悪習を一段深くしたものです。「ランディングページではこうする」という理由で反射的に使い、骨組みにしてしまいます。セクション自体が実際の 3 ステップのプロセス、順序付きのフロー、型付けされたタイムラインなど、順序に読者が必要とする情報が含まれる場合に限り、番号には意味があります。1 ページに意図的な番号付きの順序を 1 つ使うのは個性になりますが、サイト全体のすべてのセクションで番号付きアイブロウを使うのは AI らしい文法です。
• コンテナからはみ出すテキスト。 長い見出し語、大きな clamp のスケール、狭いグリッドの組み合わせは、タブレットやモバイルで見出しのはみ出しを引き起こします。すべてのブレークポイントで見出しのコピーを確認してください。はみ出す場合は、clamp の最大値を下げるか、コピーを書き換えてください。ビューポートもデザインの一部です。

Codex 特有の欠陥（最もよくある見分ける手掛かりです。避けて書き換えてください）。

• 同じ要素に border: 1px solid X と、M ≥ 16px の box-shadow: 0 Npx Mpx ... を設定すること。「ゴーストカード」のパターンです。ボタンやカードに 1px の罫線と、広く柔らかなドロップシャドウを組み合わせます。両方を併用しないでください。どちらか一方だけを選んでください（ブランドカラーの単色罫線、またはぼかしが 8px 以下の明確なシャドウ）。装飾として両方を使ってはいけません。
• カード／セクション／入力欄に border-radius: 32px+ を使うこと。角を丸めすぎています。カードは 12〜16px までにしてください。タグやボタンは完全なピル形状でもかまいません。カードに 24／28／32／40px を選ぶのは Codex の見分ける手掛かりです。「異常に丸みを帯びた」デザインを望むブランドはありません。
• 手描き風／ラフな SVG イラスト。loose-sketch、*-sketch、doodle、wavy などのクラス名、feTurbulence／feDisplacementMap による「紙の粒子」フィルター、具体的な題材（カワウソ、テーブルとフォーク、アルバムカバーなど）を描こうとする 5〜30 個のパスによる粗雑な場面。こうした表現は遊び心ではなく、素人っぽく見えます。実際のアセットで場面を描けない場合は、イラストを載せないでください。代替としてラフな SVG を使おうとしないでください。
• repeating-linear-gradient(...) によるストライプ背景。body:before やセクション背景の斜めストライプは、Codex が施すだけの装飾です。使わないでください。
• 装飾的なグリッド背景。linear-gradient(... 1px, transparent 1px) と background-size を使って二軸の CSS グリッドを重ねるのは、実際のキャンバス、地図、設計図、計測ツールの表面でない限り、Codex の見分ける手掛かりになります。代わりに、製品の構造、実際の成果物、または無地の表面を使ってください。
• メタ批評的なコピー。概念を名指ししたうえで皮肉めいた修飾語を重ねたり、藁人形論法を立てて「訂正」したりすること。具体的な主張をしてください。

AI らしさのチェック

このインターフェースを見て、誰もが疑いなく「AI が作った」と言えるなら、失敗です。レジスターをまたぐ失敗は、上記の絶対的な禁止事項です。レジスター固有の失敗は、それぞれのリファレンスに記載されています。

カテゴリー反射チェック。 2 つの視点の高さで実行します。2 つ目の視点で、1 つ目では見逃すものを見つけます。

• 一次チェック： カテゴリーだけからテーマと配色を推測できるなら、それはトレーニングデータで最初に現れる反射です。分野から答えが明白でなくなるまで、シーンを表す文と色の戦略を練り直します。
• 二次チェック： カテゴリーとアンチリファレンスを組み合わせて美的な系統を推測できるなら（「SaaS 風のクリーム色ではない AI ワークフローツール → エディトリアルなタイポグラフィ」、「紺と金ではないフィンテック → ターミナルを基調とするダークモード」）、それはさらに一段深いところにある落とし穴です。最初の反射は避けられていますが、2 つ目は避けられていません。どちらの答えも明白でなくなるまで練り直します。ブランドレジスターの反射的に避けるべき美的スタイルのリストには、現在飽和状態にある系統が記載されています。

コマンド

コマンド	カテゴリ	説明	リファレンス
craft [feature]	構築	方針を固めてから、機能をエンドツーエンドで構築します	reference/craft.md
shape [feature]	構築	コードを書く前に UX/UI を計画します	reference/shape.md
init	構築	プロジェクトのコンテキストを設定します：PRODUCT.md、DESIGN.md、ライブ設定、次のステップ	reference/init.md
document	構築	既存のプロジェクトコードから DESIGN.md を生成します	reference/document.md
extract [target]	構築	再利用可能なトークンやコンポーネントをデザインシステムに取り込みます	reference/extract.md
critique [target]	評価	ヒューリスティック評価による UX デザインレビューを行います	reference/critique.md
audit [target]	評価	技術品質を確認します（a11y、パフォーマンス、レスポンシブ対応）	reference/audit.md · ネイティブ： reference/audit.native.md
polish [target]	改善	リリース前に最終的な品質チェックを行います	reference/polish.md
bolder [target]	改善	無難なデザインや平凡なデザインを大胆にします	reference/bolder.md
quieter [target]	改善	強すぎるデザインや刺激の強いデザインを抑えます	reference/quieter.md
distill [target]	改善	本質を残し、複雑さを取り除きます	reference/distill.md
harden [target]	改善	本番運用に備えて、エラー、i18n、エッジケースに対応します	reference/harden.md
onboard [target]	改善	初回利用時のフロー、空の状態、利用開始の導線を設計します	reference/onboard.md
animate [target]	強化	意図のあるアニメーションや動きを追加します	reference/animate.md
colorize [target]	強化	モノクロの UI に戦略的に色を加えます	reference/colorize.md
typeset [target]	強化	タイポグラフィの階層やフォントを改善します	reference/typeset.md
layout [target]	強化	余白、リズム、視覚的な階層を整えます	reference/layout.md
delight [target]	強化	個性や印象に残る工夫を加えます	reference/delight.md
overdrive [target]	強化	従来の限界を超えて攻めた表現にします	reference/overdrive.md
clarify [target]	修正	UX コピー、ラベル、エラーメッセージを改善します	reference/clarify.md
adapt [target]	修正	さまざまなデバイスや画面サイズに合わせて調整します	reference/adapt.md · ネイティブ： reference/adapt.native.md
optimize [target]	修正	UI のパフォーマンスを診断し、改善します	reference/optimize.md
live	反復	ビジュアルバリアントモード：ブラウザーで要素を選び、代替案を生成します	reference/live.md

管理用コマンドが 3 つあります：pin <command>、unpin <command>、hooks <on|off|status|...>。詳細は以下をご覧ください。

ルーティングルール

1. 引数なし：ユーザーは「何をすればよいですか？」と尋ねています。メニューは固定表示ではなく、コンテキストに応じた内容にします。セットアップ時に context.mjs はすでに実行されています。実行結果が NO_PRODUCT_MD の場合、プロジェクトにはまだコンテキストが記録されていないため、$impeccable init を最も推奨される項目として先頭に表示し、その理由を 1 行で説明したうえで、残りの項目も下に表示します。黙って init に進んではいけません。それ以外の場合は、node .agents/skills/impeccable/scripts/context-signals.mjs を一度実行して JSON を読み込み、シグナルに基づく理由をそれぞれ 1 行添えて、価値の高い次のコマンドを 2～3 件 先頭に表示し、その後にカテゴリごとにまとめた全メニュー（上の表）を表示します。コマンドを自動実行してはいけません。推奨はユーザーが確認する提案です。 シグナルをもとに判断してください。従うべきスコアはありません。

   • setup.hasDesign が false で、setup.hasCode が true → document（ビジュアルシステムを記録します）。
   • critique.latest が null → プロジェクトはまだ一度も批評されていません。セットアップ済みで実際の画面があるプロジェクトでは、$impeccable critique <surface> を提案するのが有力なデフォルトです。
   • critique.latest が低い score または 0 以外の p0 / p1 を含む → polish（そのスナップショットをバックログとして読み取ります）、またはスナップショットが古そうなら critique を再実行します。
   • git.changedFiles が単一の画面を指している → そのファイル名を挙げて、対象をそれらのファイルに絞り、audit または polish を実行します。
   • devServer.running が true → ブラウザー内で反復作業できる live が利用可能です。false の場合は、live を最初に提案しないでください。live と同梱の detect.mjs はウェブ専用です。 setup.platform が ios、android、または adaptive の場合は、どちらも最初に提案しないでください。ブラウザーオーバーレイと HTML ルールエンジンはネイティブアプリのコードには適用されません。
   • それ以外の場合は、init の「推奨される開始ポイント」の手順と同様に、setup.register に合わせて、意図ごとに正確に分類します（新規作成／既存のものを改善／ビジュアル面で反復）。

   scan.targets が空でなく、setup.platform が ios／android／adaptive 以外の場合は、node .agents/skills/impeccable/scripts/detect.mjs --json <scan.targets joined by spaces> を 1 回実行してください（ローカルファイルを対象にする同梱の検出ツールです。ネットワークも npx も使用せず、HTML／CSS を読み取るため、ネイティブプロジェクトでは実行しません）。scan.via は対象を示します。git-changes（ダーティーツリーにあるマークアップ／スタイルファイル。最も関連性の高い対象）、source-dir（例：src、app）、html、または root です。検出結果を提案に反映します。品質／コントラストの検出結果が多い場合は audit または polish、特定のスロップパターンが検出された場合は対応するコマンド（グラデーションテキストやアイブロウには quieter ／ typeset、平坦またはグレーのパレットには colorize など）を提案します。これは推測より優先される、実際の最新シグナルです。detect がエラーになった場合、またはツリーが大きく実行に時間がかかる場合はスキップし、ユーザーに audit を自分で実行するよう勧めてください。これを理由に提案を保留してはいけません。

   要点を絞った提案を 2～3 件にし、入力する正確なコマンドを示してください。メニューはあくまでフォールバックです。最初に提案を示してください。

2. 最初の単語がコマンドと一致する（上記の表、または pin ／ unpin ／ hooks）場合は、そのリファレンスファイルを読み込みます（ネイティブプラットフォームでは表のネイティブ版を読み込みます。セットアップ手順 2 の 1 ファイルルールに従ってください）。その指示に従います。コマンド名より後のすべてが対象です。

3. 最初の単語が一致しないが、意図が明確に 1 つのコマンドに対応する（例：「余白を修正して」→ layout、「このエラーメッセージを書き直して」→ clarify、「色が平坦に感じる」→ colorize）場合は、そのコマンドのリファレンス（同じネイティブ版ルールに従う）を読み込み、コマンドを実行したものとして進めます。候補となるコマンドが 2 つある場合は、一度だけどちらかを尋ねます。

4. 明確に一致するコマンドがない場合は、一般的なデザインの依頼として扱います。セットアップ手順、一般ルール、および読み込み済みのレジスターリファレンスを適用し、引数全体をコンテキストとして使用します。

セットアップ（コンテキスト収集、レジスター）はこの時点ですでに読み込まれています。サブコマンドは $impeccable を再度呼び出しません。

最初の単語が craft または shape の場合、あるいはルーティングルール 3 によってユーザーの意図が明確にいずれかのコマンドに対応する場合は、セットアップを先に実行します。ただし、その後のフローは対応するリファレンス（reference/craft.md または reference/shape.md）に従います。どちらもゼロから作成するフローです。セットアップで init がブロッカーとして呼び出された場合は、init を完了してコンテキストを更新してから、元のコマンドと対象に戻ります。

teach は init の非推奨エイリアスです。ユーザーが入力した場合は、reference/init.md を読み込み、init が実行されたものとして進めます。

ピン留め／ピン留め解除

ピン留めすると、$<command> で $impeccable <command> を直接呼び出す、独立したショートカットが作成されます。ピン留め解除すると、そのショートカットが削除されます。スクリプトは、プロジェクト内に存在するすべてのハーネスディレクトリに書き込みます。

node .agents/skills/impeccable/scripts/pin.mjs <pin|unpin> <command>

有効な <command> は、上記の表にある任意のコマンドです。スクリプトの結果を簡潔に報告してください。成功した場合は新しいショートカットを確認し、エラーの場合は stderr をそのまま伝えてください。

フック

$impeccable hooks <on|off|status|ignore-rule|ignore-file|ignore-value|reset> は、このプロジェクトのデザイン検出フックを管理します。このフックは、UI ファイルが直接編集された後に検出器を自動実行し、検出結果をシステムリマインダーとして表示します。詳しい手順は reference/hooks.md に記載されています。ユーザーが引数を指定して $impeccable hooks を実行した場合は、このファイルを読み込んでください。