Theo氏、毎日使うskill 9本を「tstack」で公開 mergeまで任せる型も
開発者のTheo Browne氏が、Claude CodeとCodexで使えるエージェントのskill 9本を「tstack」としてGitHubで公開した。PRの作成から見張り、mergeまでをエージェントに任せる「full-send」や、3社のモデルにレビューさせる「council」が入っている。
記事の内容を自社でどう進めるか、内容が固まっていない段階でも相談できます。仕事の相談
毎週 1 回、その週の記事から 5 本と実践の 1 本を選んでメールで届けます。ニュースレターを購読する(無料)

開発者のTheo Browne氏が、自分が毎日使っているエージェントのskill 9本を「tstack」としてGitHubで公開した。Claude CodeとCodexで動き、PRの作成からレビュー、CIの見張り、mergeまでを手順として書いてある。中でも「full-send」は、人が見ていない間にエージェントがmergeまで進める前提のskillで、任せ方の線引きを考える材料になる。
9本はPRの流れをなぞる
READMEによると、tstackは「毎日使っているskillを、誰でも使えるように整えたもの」だ。公開は日本時間の10月24日で、ライセンスはMIT。確認した時点で、GitHubのスターは1,445だった。
skillは、エージェントに言葉をかけると動く。「full send」と言えばfull-send、「council」と言えばcouncilが動くといった具合だ。9本の中身は次のとおり。
- full-send: 変更を、人が見ていないままmerge済みのPRまで持っていく
- full-stop: full-sendと同じ作業をし、mergeの手前で止める
- council: 別々の会社の3つのモデルにレビューさせ、意見がそろうまで回す
- sol-loop: OpenAIの「GPT Sol」に、両者が納得するまでレビューさせる
- file-pr: 変更の一覧ではなく、問題から書き出す短いPRを出す
- takeover: ほかの人やエージェントのPRを、元の作者の名前を残して仕上げる
- babysit-pr: CIとレビューのbotを見張り、本当の指摘だけ直す
- modernize: 古いPRを最新に合わせ直し、残すべきかを決める
- leaving-pr-comments: エージェントが代わりに書くコメントの形を整える
skill同士は呼び合う。full-sendはsol-loop、file-pr、babysit-prを使うので、まとめて入れる必要がある。使うにはGitHubのCLI「gh」へのログインと、Pythonが要る。councilとsol-loopは、ほかの会社のモデルを動かせる環境が前提だ。同氏のエディター「T3 Code」があればその機能を使い、無ければ各ツールの標準の道具で動くという。
mergeまで人を待たない型
full-sendの説明は、利用者がこの作業を見ていないことを前提に書かれている。エージェントは変更を仕上げ、証拠をそろえ、sol-loopでレビューを受け、PRを出し、CIを見張り、条件がそろえばmergeする。最後の報告はずっと後まで読まれない、とまで書いてある。
勝手に進まないための決まりもある。mergeしてよいのは、証拠が差分のすべてを覆い、必須のチェックが通り、レビューのbotの指摘をすべて直すか理由を書いて退け、人のレビューに直しの求めが残っていない時だけだ。branchの保護を管理者の権限で飛び越えることは禁じている。データの削除や本番の環境に触る作業は許可の外で、その時は質問の道具で人に聞くよう求めている。
10月25日には、full-sendとfull-stopに「試験の許可」を足す変更が入った。プロジェクトのファイルが「試験の前に聞け」と決めていても、full-sendと頼んだこと自体をその許可とみなし、ブラウザーの操作や画面の確認まで含めて進めてよいとする内容だ。
慎重な人にはfull-stopがある
mergeまで任せるのが不安な人向けに、full-stopが用意されている。作業はfull-sendと同じで、PRがmergeできる状態になったら止まり、人に渡す。自動のmergeが設定されていれば、作業の前に外すよう書いている。
councilは、Claude Opus、GPT Sol、Gemini Proのように会社の違うモデルを3つ使う例を挙げる。3つの会社のモデルが使えない時は、別のモデルで代わりにせず、そのことを報告させる。READMEは、これらを「出発点」と呼ぶ。councilに座らせるモデルのような個人の設定はCLAUDE.mdかAGENTS.mdに書けば、skillを更新しても消えないとしている。
編集部の見方
tstackは、PRを出してから閉じるまでの手間を、言葉ひとつでエージェントに渡すための手順集だ。読む価値が高いのは、mergeしてよい条件と、人に聞くべき場面を細かく書いている点だ。ただしfull-sendは、プロジェクトに「試験の前に聞け」という決まりがあっても、full-sendと頼んだこと自体を試験の許可とみなす。上書きするのはこの試験の許可だけで、本番の環境に触る作業やデータの削除は今も人に聞く決まりだ。それでも自分のリポジトリで使うなら、まずfull-stopで止まる位置を確かめ、本番やデータに触れない範囲でfull-sendを試したい。
出典
に確認(日本時間)
- GitHubで公開した(github.com)
この記事は役に立ちましたか
ありがとうございます
ありがとうございます



