model.filterTitle

バックエンド開発専門のskillsを作りたい。 名前：dev-backend 書き込んでよい場所 //任意のディレクトリ **これ以外は書き換えない。** 画面・コンポーネントの不具合を見つけたら `dev-frontend` へ依頼を出す。 (上記は任意) 起動コマンド /dev-backend

以下の概念について、3つの深さで同時に説明してください。 # 出力形式 ## 1. たとえ話（150字以内） 日常のものに置き換えて説明する。専門用語を1つも使わない。 ## 2. このたとえが崩れるところ 上のたとえ話が間違って伝えている点を必ず1つ以上挙げる。 （たとえ話は必ずどこかで嘘をつく。そこを先に潰す） ## 3. 正確な説明（400字以内） 専門用語を使ってよい。ただし初出の用語には（ ）で1行の説明を付ける。 ## 4. これを知っていると何ができるか 実際の場面を2つ。「テストに出る」ではなく「作業中のこの判断ができる」の形で書く。 ## 5. 次に知るべきこと この概念の1つ隣にある、知らないと必ず詰まる概念を1つだけ。理由を添えて。 # 制約 - 「一般的には〜と言われています」で逃げない。断定できる部分は断定し、諸説ある部分は「諸説ある」と明示する。 - 私が既に知っている前提で話さない。前提知識が必要な場合は、それも1行で説明する。 - 5つのセクションすべてを埋める。埋まらない場合は理由を書く。 # 知りたい概念 （ここに貼る） # 私の現在地 （例：名前は聞いたことがあるが中身を知らない / 使っているが仕組みを知らない）

以下の原稿を、音声読み上げ（TTS）に渡せる形に整えてください。 # 出力形式 ## 1. 読み上げ用の原稿 そのまま読み上げエンジンに渡せる本文。 ## 2. 変換した箇所の一覧 | 元の表記 | 変換後 | 理由 | |---|---|---| ## 3. 読み方が確定できなかった箇所 （固有名詞など。推測せずここに出す） # 変換のルール - 算用数字は読み方どおりに開く（例：「3つ」→「みっつ」、「2024年」→「にせんにじゅうよねん」） - 単位・記号を言葉にする（% → パーセント、〜 → から、／ → または）。言葉にできない装飾記号（●、■、→ など）は読み上げないので削除する。 - 英字の略語は読み方を指定する（API → エーピーアイ）。ただし一般に定着した語はそのまま。 - 括弧の中身は、読み飛ばすか本文に溶かす。括弧のまま残さない。 - 箇条書きの「・」は読ませない。文としてつなぐ。 - 長い一文は、意味の切れ目で句点に分ける。一文は60文字以内。 - 同じ語の連続で言い淀む箇所を直す。 # やらないこと - 内容を要約・省略しない。全部読める形にする。 - 敬体・常体を勝手に変えない。 - 読み方が複数あり得る固有名詞を、推測で1つに決めない（3番に出す）。 # 原稿 （ここに貼る）

以下のテーマで、60秒以内の縦型ショート動画の構成を作ってください。 # 手順（この順番を守る） ## ステップ1：冒頭3秒のフックを3案 それぞれ性格を変える。 - A案：意外な事実を言い切る - B案：見る人の失敗を言い当てる - C案：結論を先に見せる 各案について：読み上げる言葉（15文字以内）／同時に画面に出るもの。 ## ステップ2：本編の構成（フックはA案を仮採用して書く） | 秒数 | 話す内容 | 画面に映すもの | |---|---|---| （3秒刻みで最後まで） ## ステップ3：最後の1文 次に何をしてほしいか。1つだけ。 # 制約 - 挨拶・自己紹介・チャンネル説明を入れない。1秒も使わない。 - 「今日は〜について解説します」という前置きを入れない。いきなり中身から始める。 - 1カットは3秒以内。同じ画が3秒以上続く構成にしない。 - 読み上げ文は1文20文字以内。息継ぎで切れる長さにする。 - 音無しで見る人がいる前提で、話す内容は必ず画面上のテキストでも追えるようにする。 - フックはA案のまま本編まで書き切る。別の案で見たいときは「B案で書き直して」と返せばよいので、ここで確認を求めて止まらない。 # テーマ （ここに貼る） # 想定視聴者 （例：これから始める人 / もう使っているが伸び悩んでいる人）

以下のものに付ける名前を3案ください。 # 3案の方向性を変える - A案：何をするかで名付ける（動作ベース） - B案：何であるかで名付ける（役割ベース）。ただし関数に付ける場合は「何を返すか／実行後どんな状態になるか」で名付ける - C案：既存コードの語彙に合わせる（周辺の命名に馴染ませる） # 各案について書くこと - 名前 - 読み下し（この名前を声に出したとき、何をするものだと聞こえるか） - この名前が嘘になる条件（将来どんな仕様変更が入ると、実態と合わなくなるか） - 長さ（文字数） # 最後に 3案のうちどれを推すか、理由1行で。 # 制約 - 略語を使う場合は、その略語が周辺コードで既に使われている場合のみ。新しい略語を発明しない。 - data / info / manager / util / helper / handler を単体で使う案は出さない（何も言っていない名前）。 - 否定形の真偽値（isNotReady など）は出さない。 # 名前を付けたいもの - 種類：（変数 / 関数 / クラス / ファイル / テーブル / API のどれか） - 何をするか・何であるか： - 周辺で既に使われている名前：

以下の機能を実装する計画を立ててください。コードはまだ書かないでください。 # 出力形式 ## 1. この機能が満たすべき条件 仕様を、確認できる形の箇条書きに直す（「〜のとき、〜になる」の形）。 仕様に書かれていない判断が必要な箇所は ❓要確認 を付けて列挙する。 ## 2. 触るファイル | ファイル | 新規/変更 | 何をする | |---|---|---| ## 3. 実装の順番 ステップごとに： - やること - この時点で動作確認する方法（画面のどこを見る／何を実行する） - ここで止めても既存機能が壊れていないか（Yes/No。Noならなぜ） ## 4. 失敗したときの挙動 通信エラー・権限エラー・二重送信・途中で失敗した場合に、それぞれどう振る舞うか。 ## 5. やらないこと 今回のスコープから外すものを明示する。 # 制約 - ステップは1つあたり「30分〜1時間で終わる」粒度に割る。 - 既存コードの構造が分からない箇所は推測で書かず、❓要確認 にする。 - 「その後リファクタリング」のような中身の無いステップを置かない。 # 作りたい機能 （ここに貼る） # 今の作りで分かっていること （フレームワーク、関連しそうな既存ファイル など）

以下の関数に対するテストを書いてください。 # 内訳を指定する - 正常系：3件（代表的な入力） - 境界値：5件以上。次の観点を1つずつ検討する（空、0、1件、上限ちょうど、上限+1、最大値、null／undefined）。 その関数に当てはまらない観点は、黙って飛ばさず「該当なし：理由」と1行書く。 - 異常系：3件（型が違う、必須が無い、想定外の並び） # 出力形式 1. テストコード（そのまま実行できる完全な形。import も含める） 2. 各テストが何を守っているかを1行コメントで各ケースの上に書く 3. 最後に「このテストでは守れていない範囲」を箇条書きで正直に書く # 特別ルール 実装を読んでいて「これはバグでは」と思う箇所があったら、 それを再現するテストを別セクション「落ちるはずのテスト」に分けて書き、 なぜ落ちると考えるかを添えてください。通るテストと混ぜないこと。 # 制約 - テストフレームワークは指定に従う（指定が無ければ質問する。勝手に選ばない）。 - モックは必要最小限。何をモックしたかを明記する。 - 「テストしやすいように実装を変えましょう」という提案は、テストを書いた後に別セクションで。 # テストフレームワーク （例：Vitest / Jest / pytest。分からなければ「不明」と書く） # 対象のコード （ここに貼る）

以下のコードをレビューしてください。 # 出力形式（この順序を固定） ## 1. 壊れる（このままだと動かない・データが壊れる） - [問題] / 再現する条件：どんな入力・状態でそうなるか / 修正案： ## 2. いずれ困る（今は動くが、条件が変わると壊れる） - 同上 ## 3. 好みの範囲（命名・書き方） - 同上 # 制約 - 各セクションで該当が無ければ「該当なし」と書く。埋めるために軽微な指摘を昇格させない。 - 「〜した方がよいでしょう」ではなく、そのまま貼れる修正後のコードを添える。 - 指摘は多くても各セクション5件まで。多いときは重い順に絞り、「他に軽微な指摘が◯件あります」と件数だけ書く。 - 動作を変えるリファクタ提案には、必ず「これで挙動が変わる点」を明記する。 - コード外の情報（設計意図・要件）が無いと判断できない指摘は、断定せず「要確認」として質問の形にする。 # 前提 - 言語 / フレームワーク： - このコードの役割： - 呼び出され方（誰がいつ実行するか）： # コード （ここに貼る）

以下のエラーの原因候補を、確度の高い順に3つ挙げてください。 # 出力形式 各候補について： ### 候補N：[原因の一言] - 確度：高 / 中 / 低 - なぜそう考えたか：エラーメッセージのどの行を根拠にしたか引用する - これで確かめられる：実行するコマンド、または見るべきファイルと行 - 当たっていた場合の直し方： # 制約 - 修正コードをいきなり出さない。まず切り分ける手順を出す。 - 「環境によります」「バージョンの問題かもしれません」で終わらせない。確かめる方法まで書く。 - 情報が足りず候補を絞れない場合は、推測で埋めずに「これを教えてほしい」を3つまで挙げる。 - 候補1が外れていた場合に次に何を見るか、順路が分かるように書く。 # 環境 - 言語 / フレームワークとバージョン： - OS： # エラー全文 （ここに貼る。省略せず全文） # 直前にやったこと （例：パッケージを追加した、ファイルを移動した、など）

以下の企画について、通さない側の立場でレビューしてください。 # あなたの役割 この企画に自分の金を出すか判断する立場。通せば損をするかもしれない当事者として読む。 # 禁止 - 良い点を書かない（褒める行を1行も入れない） - 「素晴らしいアイデアですね」等の前置きを書かない - 一般論の指摘（「競合調査が必要です」など、どの企画にも言えること）を書かない # 出力形式 ## これが失敗するとしたら、原因はこれ（上位3つ） 1. [具体的な失敗シナリオ] — なぜそうなるか / 起きる確率の見立て（高・中・低） ## 企画者が気づいていなさそうな前提 - [暗黙に正しいと仮定されていること] — これが崩れると何が起きるか ## 数字の検算 企画中の数字を1つずつ検算する。根拠の無い数字は「根拠不明」と指摘する。 数字が1つも書かれていない場合は「検算できる数字が無い」とだけ書く。それ自体が指摘になる。 ## 覆る条件 どんな事実・数字が出てきたら、この否定的な評価を撤回するか。具体的な指標で書く。 # 企画 （ここに貼る）