Cursorは7月17日、Slack連携に3つの改善を追加しました。実行前に計画を提示する機能、複数リポジトリをまとめた名前付き環境、複数チャンネルの読み書きです。一次情報は公式changelogで確認できます。
これでエージェントを起動する手間は減ります。しかし実運用の難所は残ります。正しいリポジトリを選んだか、並列化してよい作業か、完了を何で証明するか、誰が差分をレビューするか、という連携設計です。
2026年7月18日にSkillselionのライブカタログを確認し、この流れに対応する6つのスキルを選びました。
1. 実装前に計画を固定する
writing-plansは188,754 installsでした。GitHubでソースを確認できます。
ファイル単位の変更点、細かいタスク、テスト、参照資料まで含む実行可能な計画を作ります。Slackでは、編集開始前に計画をスレッドへ投稿させるのが有効です。対象リポジトリの間違いや、移行処理の漏れを早い段階で止められます。
2. 独立した作業だけを並列化する
dispatching-parallel-agentsは138,691 installsでした。GitHubに実装があります。
複数リポジトリが見えると並列化したくなりますが、共通の型、DB migration、同じAPI contractを変更する作業は独立していません。共有境界を先に固定してから分割します。
3. タスクごとに新しいコンテキストを使う
subagent-driven-developmentは149,562 installsでした。GitHubで公開されています。
独立タスクごとに新しいsubagentを割り当て、仕様適合と品質を別々にレビューします。長いSlackスレッドの文脈を無条件に引き継がないため、別タスクの前提が混ざりにくくなります。
4. 完了報告を証拠に変える
verification-before-completionは148,104 installsでした。GitHubにソースがあります。
「完了しました」ではなく、実行したコマンド、exit status、対象commit、意図的に省略したテストを報告させます。Slackの緑色の返答はテスト結果ではありません。
5. 失敗したら推測で直さない
systematic-debuggingは191,037 installsでした。GitHubで公開されています。
4段階の手順でroot causeを特定してから修正します。複数リポジトリに対して推測ベースの変更を連続で加える事故を防ぎます。
6. レビュー依頼の入力を固定する
requesting-code-reviewは171,122 installsでした。GitHubに実装があります。
レビューには計画、正確なdiff範囲、テスト結果、既知の制約を渡します。「レビューしてください」だけでは、人間にもagentにも情報が足りません。
Slackからコード変更を始める前のチェックリスト
- 誰の権限で実行するか
- 変更可能なrepositoryとdirectoryはどこか
- 計画を誰が承認するか
- 並列タスクは本当に独立しているか
- 完了を証明するtestとbuildは何か
- commit、PR、環境のどこに変更履歴を残すか
- 中止とrollbackの手順はあるか
Slackはエージェントの起動面になります。だからこそ、裏側には権限、状態、検証、監査証跡が必要です。便利な起動方法と厳密な運用契約をセットで設計するのがポイントです。
SkillselionはAnthropic、OpenAI、Cursorとは提携していない独立系ディレクトリです。ライブカタログはskills.sh、GitHub、MCP registryの情報を毎日更新し、実際のinstall数を基に掲載しています。