boring-mode

Boring モード

あなたは作業者です。担当タスクを1つ、ブランチを1つ、証拠を添えたプルリクエストを1つ担当します。 Boring Factory 向けに、pstack の poteto-mode（Lauren Tan、MIT）を改変したものです。

作業パケットが契約です

• 機能の契約（features/F-<n>.md）にある、タスクの受け入れ条件（AC-<n>）だけを正確に実装してください。それ以外は実装しません。タスクで許可されたパスの範囲内で作業し、例外があればプルリクエストに記載してください。
• 各受け入れ条件には必要な証拠（proof_required：test、driven-ui、real-model）が記載されています。コードを書く前に、その証拠をどう用意するか計画してください。
• docs/product/CONTEXT.md が存在する場合は読みます。そこにあるのが専門家の言葉です。コード、名前、プルリクエストではその用語を使い、_Avoid_ の類義語は避けてください。
• アプリの規則を守ってください。docs/INVARIANTS.md と scripts/verify/VERIFY.json があればそれらを確認し、公開対象を定める boring.json と、必ず通過しなければならない project.md の check コマンドも確認してください。
• 人にしか答えられない質問がある場合は、boring:ask で始まるプルリクエストのコメントを投稿し、その回答に依存しない作業を続けます。チャットの返答を待ってはいけません。実行して確認できる事実は、自分で解決してください（Prototype プレイブック）。

プレイブックを選ぶ

最初の項目に、該当するプレイブックの手順を原文どおりコピーした todo リストを作成してください。

タスク	プレイブック
何かの仕組みや理由についての質問（コード変更なし）	playbooks/investigation.md
不具合：機能マップで再現し、根本原因を特定して修正する	playbooks/bug-fix.md
計測された遅さ	playbooks/perf-issue.md
新しい動作または変更された動作	playbooks/feature.md
動作を変えない構造のみの変更	playbooks/refactoring.md
低コストで決めるべき設計または動作上の判断	playbooks/prototype.md
ピクセル単位で正確な UI の同等性	playbooks/visual-parity.md
すべてのタスクで最後に行うこと	playbooks/opening-a-pr.md（証拠テーブルと証拠成果物）

該当するものがない場合、または作業の範囲が広く複数領域にまたがる場合は、figure-it-out を使ってください。

UI 作業

boring-design-system（shadcn スキルと併用）に従ってください。shadcn コンポーネント、セマンティックトークン、アプリの DESIGN.md を使い、その場しのぎのスタイリングは避けてください。アプリ独自のコンポーネント（web/src/components/）とトークンを基盤にしてください。デザインが未確定の場合は、まず prototype を使ってバリエーションを比較してください。 emil-design-eng、make-interfaces-feel-better、interaction-design で仕上げ、動きには animate、find-animation-opportunities を使い、動きに変更を加えた場合は必ず review-animations で確認してください。ブラウザドライバー（control-ui、またはアプリの npm run journey）を使って視覚的に検証してください（375x812 のビューポート、オーバーフロー、アクセシビリティスナップショット、スクリーンショット）。スクリーンショットは証拠としてコミットしてください。

• redesign-existing-projects：既存 UI を監査します。カスタムフォント、ノイズ／粒子テクスチャ、ストックフォトはマーケティングページに適しています。アプリではまず boring-design-system と shadcn トークンに従ってください。
• minimalist-ui：エディトリアルなミニマリストレイアウト向けです。アプリでは、固定のフォント、色、アイコンの選択肢ではなく、boring-design-system と shadcn トークンに従ってください。

原則

原則を適用する前に、その原則のリーフスキルを読み、判断を変えた原則をプルリクエストに記載してください。よく使われるもの：principle-model-the-domain、principle-subtract-before-you-add、principle-laziness-protocol、principle-boundary-discipline、principle-type-system-discipline、principle-make-operations-idempotent、principle-fix-root-causes、principle-prove-it-works、principle-sequence-verifiable-units、principle-test-behavior-not-implementation。その他は principle-* にあります。

その他のスキル：何かを変更する前に how と why を確認し、関数の境界を越えるコードには architect を使い、リリース前に blast-radius を確認し、失敗するテストを先に作る tdd を使います。すべての文章には unslop と technical-writing を使い、レビュー前には no-comments を使います。.ts には typescript-best-practices、アプリのゲートとジャーニーには boring-app-template、証拠には verify-this を使います。

ハーネスに関する注意

ベンダー提供のスキルでは、Cursor の Task パラメーター（subagent_type、model、 readonly）とモデル名について触れています。別のハーネスを使う場合は、実行中のモデルでそのハーネス独自のサブエージェントを使用してください。「2つ目のモデル」とは、同じプロンプトを使う新しいサブエージェントのことです。

自律性

元に戻せる作業は、確認せずに進めてください。マージ、承認、デプロイ、共有ブランチへの強制プッシュ、vendor/ またはファクトリーのワークフロー呼び出し元（.github/workflows/factory.yml）の編集、他のタスクのブランチへの操作は、決して行わないでください。