Menü
仕様合意→テスト→実装の順序を強制するスキル。AIが検証を偽装するアンチパターンの防止。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
CSW のユーザー向け UI・コピーの正典。ユーザー向け語彙(「環境」)、共有モードの3語(共有/分離/コピー)、選択行の見せ方(塗りのみ)、メニューバーを主機構にしない、コピーの一次ソースは LP、Claude 本体の現行用語への追従、並列 UI の分量・文体、禁止記号(em-dash/※/絵文字)を定める。アプリ UI・LP・docs のラベル/モード名/説明文/マイクロコピーを作る/変える前に読む。
用語・概念・UI・コピーを1箇所変えたら、全サーフェス（アプリ UI・トレイ・docs ja/en・README ja/en・LP ja/en・スクリーンショット・OG 画像）へ同時反映し、旧表現を全リポ grep で残存ゼロ確認する。スクショ等の非テキスト派生物は grep に映らないので明示列挙して再生成する。UI・用語・コピーを変えたら発動。
PR をマージする際のレビュー・マージ実行チェックリスト (Rust + Tauri v2 / CSW)。スコープ外変更・安全装置の格下げ・テスト負債・高リスクインフラファイル改変を検出し、CI green を確認したうえで自律的に squash merge する手順を定義する。
CI (GitHub Actions の Test / Build / Security job) が想定時間を大幅に超過した場合のハング検出と cancel / rerun フロー。macos-latest runner の混雑や cargo の依存取得・コンパイル stall 等、transient な GHA 側障害の典型対処。CI が想定より長く `in_progress` のまま動かない時に発動。
日本語の見出し・本文の折り返し / タイポグラフィ品質ゲート。日本語 UI・LP・ドキュメントのコピーやフォントサイズ、改行、行間に触れる前に必ず読む。英語の折り返しルールをそのまま日本語に当てると崩れる(禁則・文節・字面密度が違う)ため、JP 専用の規則・モダン CSS・モジュラースケール・実機検証手順を正典化する。design-taste-frontend を補完する JP 特化スキル。
LP(website/) と人間向けドキュメント(docs/・README) と実装(crates/) が「同じ一つの事実」を語っているかを横断監査する。用語・アーキテクチャ・CLI 表面・機能主張・ja/en 整合・禁止表現を点検し、不整合を file:line と修正案つきで報告する。リリース前やドキュメント/LP/実装を変えた後に実行する read-only 監査。
| name | spec_first_development |
| description | 仕様合意→テスト→実装の順序を強制するスキル。AIが検証を偽装するアンチパターンの防止。 |
[!CAUTION] AI は「できた」と報告する前に、自分でエビデンスを確認する義務がある。 GUI 変更ならスクリーンショット、core/CLI 変更ならテスト出力やコマンド実行結果を一次情報として確認する。サブエージェントの「PASS」報告を鵜呑みにしてはならない。
AI が修正後のブラウザ検証で「全て OK」と報告したが、実際には：
Read で開いて、またはツール出力で直接確認する仕様合意 → テスト作成(RED) → 実装(GREEN) → 検証(エビデンス付き)
docs/SPECIFICATION.md に追記 (仕様の正典)AskUserQuestion で) 仕様レビューを依頼cargo test の出力や実コマンド実行結果を、GUI なら cargo tauri dev でのスクリーンショットを自分で取得して確認するStep 1（仕様合意）に入る前段として、次の 2 つを必ず通します。どちらも「合意前にコードを書かない」を守るための前工程であり、着手直後に済ませます。
新しい機能に着手するとき、その機能や方針が既にリポジトリ内で言及・計画されていることが多くあります。既存の記述を見落としたまま「新しい思いつき」「今回の新設」として扱うと、方針の二重管理・用語の食い違い・既存計画との齟齬が生まれます。着手前に以下を実読し、既出かどうかを判定してください。
website/) の FAQ・features・use-case を 日本語版と英語版の両方 (website/index.html と website/ja/index.html) 確認する。docs/SPECIFICATION.md の「今後の方針」に相当する節を確認する。git log --oneline -30 など) を確認する。判定と扱い方:
website/ と docs/SPECIFICATION.md の計画節を必ず含めます。docs/ と crates/ だけに絞ると、ユーザー向けに既に約束済みの方針を見落とします。検証手順: 着手宣言の中で「この機能は LP / SPEC / 直近ログのどこに既出か（または既出なしを確認したか）」を 1 行で明示してから Step 1 に進みます。既出があれば、その参照箇所を仕様合意の起点にします。
便利な機能を作り込む前に、その機能を実際に使う対象ユーザーを特定します。対象がエンジニアや上級者に限られる場合、署名・公証・リリースパイプライン・ユーザーのシェル設定の書き換えといったコストを伴う重い GUI 機能よりも、軽い案内（ドキュメント・CLI の手順・手動レシピ）で目的を満たせることが多くあります。本筋の重い実装へ直行せず、軽い代替も並べて検討してください。
適用のしかた:
検証手順: 仕様に「対象ユーザー」と「採用した規模（重い実装 / 軽い案内）とその理由」を明記し、合意を取ってから Step 2（RED）へ進みます。