asdf

[せせり｜個人web開発者 @sesere115]

ここ1ヶ月ほど、codexで死ぬほど開発してますが以下の感じでAGENT書いておくと割と体験が改善されました

「これは社内向けサービスであり、開発中のPJのため後方互換やデータ移行は行わず、常に理想的かつKISSなコードに書き換えて下さい。開発は以下のサイクルで行って下さい」

↓

[Maki@Sunwood AI Labs. @hAru_mAki_ch]

dots用の8時間お願いプロンプト改造してみた！！
これで寝ます！！！

___

これから8時間就寝します。各セッションの残タスクを、これまでの依頼・承認の範囲で自律的に進めてください。設計業務では複数ペルソナによるレビュー・修正・再レビューを行い、作業過程をタイムラプス動画にできるよう、容量を管理しながら記録してください。

【進行ルール】
・最初に各セッションの目的、現在の成果物、残タスク、承認済みの範囲を確認し、優先順位をつけて着手してください。
・利用可能なゴール設定やDotsの定期確認を使い、停止した未完了セッションを再開してください。
・行き詰まった場合は原因と試した方法を記録し、別の解決方法へ切り替えてください。
・私の回答や追加承認が必要な作業は保留し、進められる別の作業を続けてください。
・重要な変化だけ通知してください。
・実行していない操作や検証、保存を、完了したように報告しないでください。

【設計業務：複数ペルソナによるレビュー】
対象に応じて、少なくとも以下のペルソナを作成してください。各ペルソナの専門領域、評価基準、懸念事項を明記し、それぞれ独立した観点でレビューしてください。

設計担当：要求、寸法、構造、機能、部品間の整合性
製造・組立担当：加工性、材料、公差、組立順序、工具のアクセス、コスト
品質・安全担当：故障、誤使用、耐久性、危険箇所、検査可能性
解析・検証担当：物理的な妥当性、荷重条件、計算・解析の前提、検証方法
利用者・保守担当：使いやすさ、操作性、清掃、修理、交換
統合レビュー担当：部品間の干渉、要求の抜け、レビュー間の矛盾、全体の成立性

複数エージェントを利用できる場合は役割を分担し、利用できない場合も役割ごとにレビューを分けてください。

レビューは次の順で実施してください。
「要求・制約・合格条件の整理 → 全体構想レビュー → 重要断面・接続部のレビュー → 部品ごとの詳細レビュー → 修正 → 再レビュー → 全体の整合性確認」

・各指摘には、対象箇所、根拠、重要度、修正案、確認方法を記録してください。
・画像だけで判断せず、可能な範囲で寸法、断面、干渉、材料特性、計算、解析、実際の操作結果を確認してください。
・参照した仕様、物理法則、資料と、仮定・推測を区別してください。
・修正後は、指摘が解消したかに加えて、他の部品や機能に新しい問題を生んでいないか確認してください。
・重大指摘が解消し、合格条件を満たすまで、修正と再レビューを繰り返してください。
・レビューの回数や全員の賛成だけで合格にせず、確認できた証拠をもとに判断してください。
・時間やツールの制約で未検証の項目は明確に残してください。同じ指摘が解消しない場合は、前提や設計方法を見直してください。

【スクショ・タイムラプス用の記録】
作業過程を、後からタイムラプス動画にできるよう記録してください。以下の撮影は、後述の容量管理ルールに従って実施してください。

・作業開始時、主要な操作の前後、レビュー時、修正の前後、検証時、完成時にスクリーンショットを撮影してください。
・画面を操作している間は、可能なら30〜60秒間隔でも撮影してください。変化が少ない場合や長い待機中は撮影間隔を延ばしてください。
・実際の作業画面を保存し、撮り忘れた過程を再現画像で補わないでください。
・撮影前に画面を整え、不要なウィンドウやダイアログを閉じ、対象が見やすいズーム・視点・表示状態にしてください。
・解像度と画面比率は可能な限り統一してください。
・CADでは全体図、主要方向、断面、詳細箇所を撮影してください。修正前後は同じ視点と倍率で比較できるようにしてください。
・個人情報、認証情報、秘密情報が映り込まないようにしてください。

画像はセッション別・工程別に整理し、「連番_日時_工程_対象_修正版」の規則で命名してください。撮影日時、画像ファイル名、操作内容、変更点、関連するレビュー指摘を一覧に記録し、画像と設計版を対応づけてください。

画面録画は、スクショに加えて必要な場合のみ、容量に余裕があれば併用してください。

終了前に、保存した画像から時系列のタイムラプス動画を作成してください。目安は1〜3分で、工程名の短い字幕と、修正前後・完成状態が分かる場面を入れてください。動画を作成できない場合も、連番画像、撮影一覧、動画化手順を残してください。

【容量管理】
・保存容量を常に意識し、作業開始時、撮影中の定期確認、動画生成前後に、使用量と空き容量を確認してください。
・今回生成する記録用画像・動画・動画化用一時ファイルの合計容量は、原則「開始時の空き容量の10％以内、かつ最大2GB」を目安にしてください。保存先に既存の制限があれば、そちらを優先してください。

[paji.eth @paji_a]

寝る前Dotsにこれ頼むと最高→「これから8時間就寝しますので、各セッションの残タスクを、これまでの依頼・承認の範囲で自律的に進め、利用可能なゴール設定やDotsの定期確認で停止した未完了セッションを再開し、行き詰まったら別の解決方法へ切り替え、私の入力待ちは保留して他の作業を進め、重要な変化だけ通知し、8時間後に完了事項・残タスク・保留理由を報告してください」

[notargs @notargs]

@mazic44 「Workを使うなど、使用量を消費する作業を行うときは必ずSol6.1を使ってください。また、そういった作業が必要な際はユーザーに確認を取ってください」というruleは設定していて、そこそこ効いてくれてそう。

[くるしば | ソフトバンクよりReact本発売中 @shiba_program]

AIにコードを書かせる前に、作るものの仕様をAIと合意しておける「OpenSpec」が良さそう

チャットで頼むだけだと、途中で何を作ってたのかブレたり、最初に言ったことが抜け落ちたりするけど、それを「先に仕様をファイルに書かせる」ことで防ぐ仕組み

例えば「ダークモードを追加したい」と頼むと、コードを書く前にAIがこの4つを作ってくれる

・なぜやるのか
・要件と「〜したら〜になる」のシナリオ
・技術的な進め方
・実装のチェックリスト

人間はそれを読んでOKを出してから実装させて、終わったら仕様が履歴として残る

仕様ファイルは特別な書き方じゃなくて普通のMarkdownなので、読むのも直すのも気軽なのがいい

しかもOpenSpec自体がOpenSpecで開発されてて、リポジトリに本物の仕様と進行中の変更がそのまま置いてあるので、書き方の見本にもなる

Claude CodeやCursor、Codexなど30以上のAIツールで使える

AIで1つアプリを作り切ったあと、2つ目を作るときに入れてみると違いがわかりやすいはず

[大賀 愛一郎 (oga_aiichiro) @oga_aiichiro]

AI臭くて読みにくい文章を自然で読みやすい日本語へ書き直すスキル『yomiyasu』をリリースしました。

従来の「単語を禁止する手法」から改善し、統語構造(誰が何をどうした)の復元と、比喩動詞の具体化に特化しています。

Claude Code, Codexなどで今日から利用できます。

https://t.co/jqtBwZsmvJ

[yousukezan @yousukezan]

AIにレビューさせてる人がちらほらいて全部放り込んだほうが良い気もするので全ページあるレビュー版も置いときます。619ページあります。
https://t.co/kpDfoy3Ex9

[せせり｜個人web開発者 @sesere115]

僕がよくやるのは「lunaを5台起動し、それぞれにランダムなペルソナを与えてサービスを自由に使わせてわかりづらい点やバグがなかったかを報告させてレポートにして提出して下さい」とかです

取りまとめのAIが賢いやつ選んどけば後は僕が細かく指示するより全然良い感じに進めてくれる

[せせり｜個人web開発者 @sesere115]

最近のcodex開発は

1. chatgptのchatをgithubと接続してコードを読ませつつ今後の方針を相談
2. まとまったらgithubにissueを作成
（＝ここまでcodexの枠を消費しない）

3. codexにissueを消化させる

簡単な設計に関してはこのフローでコストをcodexからある程度剥がしてバランスよく消化できます

[松濤Vimmer @shotovim]

常駐させている Mac Miniと定期実行ツールの相性が良すぎて大活躍している。

[AM09:21 @AM09_21]

これマジでバカおもろい

(結構問題数多いので、ゆっくりやるのが良さそう)

[ふっく｜東大卒AI社長 @fukku_ai_BD]

そういうの本当に助かる。コピーして即Claude Codeに食わせた。

[AM09:21 @AM09_21]

すでに話者がもう一人居ます...! すごい！！！！
https://t.co/MDMxxGBwDw

かなりの文体や情報が削られてしまうので汎用的なタスクには向かないなぁと思いつつ、明確さが重要になる分野だと自然言語よりも圧倒的に議論しやすいことが分かりました！

でも同じプロンプトで出力される形式が不安定すぎるので、ちゃんと作ろうと思ったら明示的定義をもっと含めないといけないかも......

長所も欠点も分かるX-benchmark、ﾒﾁｬ優秀かもしれない

[氏家（うじいえ） @yasu42]

最近知ったこと。
iPhoneのlogで撮って、富士フイルムのLUT を当てるだけでかなりそれっぽくなる。
お手軽エモ編集としていいんじゃないでしょうか、これ。
今度はポートレートやコスでもやってみたいわね。

[AM09:21 @AM09_21]

AIに自律開発させるときは、こういうHTMLダッシュボードをVibe-Codedでもいいから毎回簡単に用意するべき定期
向こうから非同期で質問投げつつ、こっちはSlackとかDiscordとかTelegramで回答するみたいなのが良さげ

(成果物は常に最新を追うようにしといて、成果物に対してテキトウなレビューをスマホかなんかで投げれるとさらに良き。こういうダッシュボード系は開発ごとに表示したい情報が異なるので、テンプレとかは作らずに毎回0から軽く作っている)

[太田賢一／Design Mgr @kenichiota0711]

これは素晴らしいskillですね...！実際使ってみたら、自然な日本語文章が書けました。
https://t.co/saMmH0SySZ

[はじめ｜コスパの良いSEO×LLMO @tetsu_tetsu333]

すごい。
JevでSEO内部リンク解析ツールを作ったのですが、想像以上に精度が高かったです。

100記事の内部リンク解析で、かかった費用は78円。

サイトURLを入れるだけで
・全記事の本文と既存リンクを取得
・「この記事からこの記事へリンクすべき」を提案
・リンクを入れる具体的な文章を特定
・実際に使うアンカーテキストも提示
・現在と改善後の内部リンク構造を可視化
・結果をExcelやCSVでダウンロード
まで自動でやってくれます。

実際に結果を見ると、「そこそこ！」という箇所へ内部リンクを提案してくれていました。
※大好きなCocoonさんのサイト拝見しました

仕組みはこんな感じ↓
・robots.txtやサイトマップから記事URLを自動収集
・各記事のtitle、H1〜H3、本文、既存内部リンクを抽出
・TF-IDFと類似度計算で、関連性が高い記事の組み合わせを事前に絞り込み
・リンク先ごとに、リンク元記事内の関連性が高い文章を抽出
・本文内に実在する語句からアンカー候補を作成
・Jevが「本当にリンクすべきか」をYes／Noで判定
・Jevが設置箇所、アンカー、リンクの役割を選択
・推奨確率と確信度が基準以上の候補だけを採用
・既存リンクと追加候補をマッピングして可視化

すべての記事同士をJevに総当たりさせるのではなく、通常のコードで候補を絞り、意味を理解しないと決められない部分だけをJevに任せています。

Jevは文章生成よりも、大量の判断や分類が得意なので、内部リンク分析とかなり相性がよさそうです。

使ってみたい人いますか？
思ったよりお金もかからなかったので、ニーズが高ければどこかで無料公開しようと思います。

[karla @karlarboledas]

Acaban de convertir Claude Code, Codex y Cursor en un senior developer real.

Gratis.

Se llama Superpowers y ya tiene 204.000 estrellas en GitHub.

El problema con los agentes a partir de cierto tamaño de proyecto es siempre el mismo:

Van directo al código.
Debuggean a ciegas.
Abandonan los tests.
Y cuando el proyecto crece, empiezan a alucinar.

Superpowers lo resuelve forzando el proceso de un ingeniero senior:

→ Brainstorming siempre antes de escribir una sola línea
→ TDD red/green sin excepciones (borra el código si no hay test previo)
→ Subagentes en paralelo con git worktrees aislados
→ Contexto bajo control durante horas de trabajo autónomo

El flujo ya no es "prompt → código → rezar":

Brainstorm → Spec → Plan → TDD → Subagentes → Review → Ship

Cero código antes de tener tests pasando.

Compatible con Claude Code, Codex, Cursor, Gemini CLI, OpenCode y Copilot CLI.

100% open source. Licencia MIT.

Ya no escribes prompts a ciegas.
Tu agente trabaja como un senior.

guárdalo y sígueme para más → @karlarboledas

Os dejo el link de la repo aquí ⬇️

[ういにゃん【アニソンDJ】 @ui_nyan]

ChatGPT Codexの燃費がわるすぎるのでOpenCodeインストールしてそこからSolを使ってるんだけど、おなじ5時間枠/週枠で倍以上の効率でちゃっててヤバい...
ハーネス変えるとこんなに違うんだ...

[Claude Code Studio @ClaudeCode_love]

【海外で話題】
Claude Codeが作る画面の「なんかダサい」を消す道具が無料で公開された😳
その名も ーーー Taste Skill
https://t.co/PDQY4ClXrP

これ何がヤバいかというと👇
・入れるのは1行、npx skills add Leonxlnx/taste-skill
・業種・読む人・空気・動きの量・配置の型を、書き始める前に読み取らせる
・色と文字の決まりを1枚の表にしてから使わせる
・明るい画面と暗い画面を、最初から両方そろえさせる
・作り直す時は、今の画面のどこが悪いかを先に点検させる
・出す前に、自分で決まりを満たしたか確認させる
・GitHubの星は8.8万、MITなので改変も商用も自由
・中身は指示文のファイルなので、開いて自分で書き換えられる

これまでのAIコーディング👇
「動くものは作れる。でも見た目が全部同じ顔になる」

でもTaste Skillは違う。
デザインの決まりを先に読ませてから
書き始めさせる。

つまり
・Cursor
・Claude Code
・Codex
どれで書いていても、同じ型が効く。

つまりAIの見た目問題が、モデル側ではなく指示側で直る。

しかもこれ、有料の拡張じゃない。
誰でも中身を読めて書き換えていい形で出てくる2026年、
正直どうかしてる（最大級の賛辞）。

AIコーディングの弱点だった"見た目"が、1行で埋まる。
Claude Codeで画面まで作ってる人、これ入れない理由がない。

見た目が整っても、中の手順が散らかっていると結局作り直しになる。
Claude Codeを"開発チーム"側に寄せるSkills 67選、こちらの記事にまとめてます👇