linear、プライベートで使うと操作多いかと思ったけど、MCP使ったら全然問題ないや。最高。
Tech
d2が便利すぎて感動してる。
d2 playを見つけて思わずポストしてる。
sonnet4.6。opus4.5より好む開発者が多かったり、スコアがopus4.5に近いなど、かなり期待できそう
OpenCode のコマンド、スキル、エージェントの違いは何ですか？
2026年2月7日土曜日
Reddit の opencodeCLI コミュニティより：Commands, skills, and agents in OpenCode: what’s the difference? スキルを使用するには、明示的に「use xyz skill」と言うことができます。 また、スキルはリファレンスドキュメントではないと言えます。どちらかというとSOPドキュメントに近いです。例えば、スキルにユニットテストの作成方法を入れることはできません。いや、入れることはできますが、効果的ではありません。しかし、gh cli経由でpull requestを作成する方法をスキルに入れることはできます（個人的には、私はmcpダイエット中です。cliの使い方に関するスキルを作成するだけです。デフォルトでは、必要な場合や明示的に呼び出されない限り、contextに追加されません）。 リファレンスドキュメントが必要な場合は、AGENTS.md（または他のinstructionsドキュメント）に入れるか、globをサポートするopencode-rules pluginを使用できます（つまり、*.controller.tsを見ると、そのドキュメントをactivateできることがわかります）。 また、追加情報として： • commandsにはautocompleteがあります。/と入力すると、利用可能なすべてのcommandsが表示されます。何があるか確認しやすくなります。スキルの場合は、利用可能なスキルをリストするようにpromptする必要があり、tokenを使用します（あるいは、opencodeのconfigを確認して目視で確認するだけです） • commandsには$1、$2、$3などのパラメータを持たせることができます • スキルは組み合わせ可能です。例えば、1つのpromptでtdd skillとsecurity skillを使用できます。しかし、1つのpromptで/tddと/securityを実行することはできません • 個人的には、スキルがcommandにもなり得るし、その逆もあり得るケースが多々あると感じています。そのような場合、ロジックはスキルに入れます。そしてcommandでは、「use xyz skill. $ARGUMENTS」のように記述します • agentsとsubagentsは、system promptsを定義できるため強力です • subagentsは独自のcontextを持ちます。これは素晴らしいことです。なぜなら、context windowを消費すればするほど、modelは賢くなくなるからです。したがって、最小限のsubagentは最高の知能で動作します！欠点は、各subagentが同じcontextをloadする必要がある可能性があることです（つまり、すべてがAGENTS.mdを読み取る）ので、より多くのtokenを消費します • agentsはsubagentsをorchestrate（統制）できます • conditionalsやloopsを含むworkflowを実行したい場合は、おそらく独自のagentを作成する必要があります • agentsとsubagentsは、あるmodel（例：GPT-5.2）に別のmodelの作業（例：Opus 4.5）をreviewさせることで、human-in-the-loopの関与を減らすための優れた方法です
💬🧑💻👀 agent-skills/skills/react-best-practices at main · vercel-labs/agent-skills · GitHub
Apple ショートカットを使った文字起こしのワークフロー。こういう活用方法いいな。 youtu.be/ib7AMtzI8…
これは保存版だ。ありがたい
1Mトークン時代の到来か、、、
mem.ai 👀 https://get.mem.ai/ mem.ai なるメモアプリ
Mem 2.0は、アルファテストとベータテスト期間中はどなたでも無料でご利用いただけます。Mem 2.0の正式リリース時には、価格プランを発表いたします。
https://support.mem.ai/category/42-pricing
まだ無料で使えるらしいけど、正式版になったらいくらになるのかな・・・
DrizzleとKysely
2024年11月16日土曜日
手元で利用しているORM、DrizzleからKyselyに移行しよう。 主に抱えたIssueは以下。 Objectへのマッピング オブジェクトのマッピングを行う際に、SQLレイヤでJsonオブジェクトの構造化を完結したい。 だた、Drizzleの場合、Queryで生成されたSQLにて発行されたエイリアスがネストされたクエリ内でマッピングされずにSQLが実行されないというIssueがあった。 そのため、Queryの利用をやめ、Aggregating resultsでの実装を試みた。 試みたが、結局のところSQLのレイヤではなくロジックでマッピングという事になり、パフォーマンスやロジックの堅牢性に懸念があるのでやめた。 まだDrizzleは1.0バージョンではないのでProduction環境への利用にも不安が残るので、Kyselyを試す。
なるほど、iPhoneミラーリングでMac側からスクロールできないなどの状態になっているアプリは、iOSウェイの実装から外れている可能性があるな・・・。
asdfが使いにくいしmiseに鞍替えする。nodeのinstall早い。Rust製らしいので早い？ asdfはシンタックスも使いにくかったし、goでは確かメンテナンスされてなかったり、色々とガタが来ていたのでよい。 Comparison to asdf | mise-en-place
SqurespaceからCloudflareにドメイン移管をしてしまったせいで、ブログがダウンしてしまっている… 移管完了まで、耐え忍ぶのだ、、、