pi-task：local model の coding request を復元可能な spec pipeline にする
Local coding agent でよく起きる問題は、model の能力不足だけではない。安定した作業リズムがないことも大きい。少し複雑な変更を頼むと、最初に見るべき context を外し、いくつか推測を足し、最後に一見もっともらしい plan を返してくる。問題は model size だけではなく workflow にある。長い prompt 一つに、要件整理、project 調査、外部資料確認、設計判断、spec 作成、自己レビューを全部背負わせると、どこか一段がずれた時点で後続もまとめて歪む。
今日見るのは mjasnikovs/pi-task。Earendil の Pi coding agent 向け extension で、狙いは「さらに賢い agent」を作ることではなく、local model に固定された task pipeline をかぶせることだ。README では core flow が refine、research、grill、compose、critique の五段階に分けられている。まず request を絞り、次に context を並行調査し、曖昧な点を問い、spec を書き、最後に品質を見直す。各 phase boundary は .pi-tasks/TASK_NNNN.md に保存されるので、crash、restart、cancel の後でも task を再開できる。
GitHub repository page、GitHub page embedded data、README、LICENSE、Tags、Releases page、package.json、git metadata を 2026-08-23 18:20 Asia/Shanghai 時点で確認すると、mjasnikovs/pi-task は 74 stars、5 forks。主要言語は TypeScript、license は AGPL-3.0-only。Repository created time は 2026-06-02 16:30:23 UTC、latest public push は 2026-08-23 10:02:39 UTC、default branch は main。GitHub Releases page には公開済み Release はなく、latest tag は v0.38.17、tag date は 2026-08-23、対応 commit は ae81dcb。npm package name は @mjasnikovs/pi-task、package version は 0.38.17、Pi 関連 peer dependencies は >=0.80.0。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | mjasnikovs/pi-task |
| 位置づけ | Pi coding agent 向け deterministic spec orchestration extension |
| Stars | 74 |
| Forks | 5 |
| 主要言語 | TypeScript |
| ライセンス | AGPL-3.0-only |
| 作成日時 | 2026-06-02 16:30:23 UTC |
| Latest push | 2026-08-23 10:02:39 UTC |
| Default branch | main |
| 最新 tag | v0.38.17、2026-08-23 |
| GitHub Release | 公開済み Release なし |
| npm package | @mjasnikovs/pi-task 0.38.17 |
| キーワード | Pi、local LLM、spec workflow、worker agents、resume、CLI |
重要なのは command 追加ではなく、曖昧な context を分解すること
pi-task の入口は普通の slash command に見える。/task、/task-plan、/task-auto、/task-resume、/task-config などだ。しかし本当に扱っている問題は command menu ではない。Local model が長い task の中で、すべての作業を一つの context に混ぜてしまう問題だ。
/task <prompt> は一つの開発 request を pipeline 全体に通す。refine phase は raw request をより明確な目標に整える。research phase は project files、API、external docs、tooling information を隔離された worker sessions に分担させる。grill phase は spec を書く前に必要な clarification を出し、context から答えられるものは自動で埋め、確定できないものだけを人に出す。compose はそれらを implementation spec にまとめる。critique は spec が十分に明確かどうかを見直す。
この分解には実務上の利点がある。Main session が raw noise を全部受け取らなくてよい。README では、web fetch、docs lookup、code exploration は temporary child sessions で行い、main session には distilled answer だけを返すと説明されている。これは local model では特に効く。Context が乱れるほど、小さい model は早い段階の誤りに引っ張られやすい。探索と要約を同じ context に詰め込むより、探索の副産物を child session 側に残すほうが安定しやすい。
もう一つの detail は persistence だ。各 task は .pi-tasks/TASK_NNNN.md として保存され、phase output、decisions、state が普通の Markdown file に残る。UI の中でしか見えない internal database ではなく、読めて、diff できて、手で確認できる text だ。長時間動く local agent workflow では、この素朴さが大事になる。途中で止まった時、restart point は「続けて」という一文ではなく、前段階で書かれた structured state になる。
local LLM に足しているのは process constraint
多くの agent tool は「autonomous planning」を強調する。ただし local model では、その autonomous planning 自体が不安定さの原因になることがある。pi-task は phase order を固定する。refine、research、grill、compose、critique の順番だ。Model は各 phase の中で働けるが、phase を勝手に飛ばしたり、research の推測をそのまま final spec にしたりはしにくい。
この設計は、いくつかの task type で特に使いやすい。第一に、requirements に gray area がある変更だ。たとえば「upload endpoint に rate limiting を追加する」。いきなり code を書かせると、limit の粒度、storage、error response、test strategy を model が勝手に仮定しがちだ。/task-plan は planning を明示的な conversation にする。Model の recommendation を受ける、手で回答する、途中で execution に進む、という形で重要な選択を切り出す。最後に /task へ渡されるのは decisions であり、単なる notes は要件として混ざらない。
第二に、repo や API をまたぐ task だ。research phase には web、docs、fetch、worker tools が含まれ、調査を独立 phase にする。Memory に頼った未検証の API を spec に混ぜないためだ。README でも tooling claims を verify する姿勢が示されている。AI が API name を間違えること自体より、その間違いを前提に後続 plan 全体が組まれるほうが危険だ。
第三に、多段 feature だ。/task-auto は大きな plan を一度で全部書こうとせず、まず ordered task titles に分け、それぞれの title を完全な /task pipeline に通す。各 subtask が自分の refine、research、grill、compose、critique を持つため、古くなった巨大 spec を使い回すより扱いやすい。Sequential execution と resumability を重視している点も、local long-running task に向いている。
一般的な agent orchestration tool との違い
Gumi では agent memory、code search、MCP tools をいくつも取り上げてきたので、pi-task を「agent を reliable にする tool」とだけ説明すると弱い。これは Pi agent の中に入る task harness に近く、外部知識ベースや汎用 plugin platform ではなく、task lifecycle を扱う。
一つ目の違いは、pipeline state を project directory の Markdown file に置くことだ。多くの agent framework は state を session store や web dashboard に隠す。失敗したとき、どの段階で破綻したか追いにくい。pi-task の task file は地味だが、developer には扱いやすい。Git に載せられるし、diff できるし、手で読める。
二つ目は、各 phase の責務を絞っていることだ。research は調査と要約を行い、grill は確定できない question を補い、compose が spec を書く。この boundary はよくある失敗を減らす。Model が調査前に結論を書き、その後の調査が結論を正当化するためだけに使われる、という流れを避けやすい。
三つ目は、local model の弱点を前提にしていることだ。README には loop detector、failure classifier、stuck reply retry、command timeout、verify/enforce settings などが出てくる。これは派手な product claim ではなく、local agent を長時間動かすと実際に出る問題だ。Hang、repetition、malformed output、command timeout、tool result の読み違い。pi-task は少なくともそれらを configuration surface に上げている。
四つ目は、MCP server ではなく Pi extension である点だ。この boundary は caveat でもある。Pi coding agent を使っていないなら、任意の MCP client にそのまま接続できる general component ではない。すでに Pi ecosystem で local model workflow を試している人向けの tool だ。
どう試すか
最小の試し方は、critical ではない repo を一つ選び、Pi で package を install することだ。
pi install npm:@mjasnikovs/pi-taskその後、中程度に複雑だが system を壊しにくい task で /task を試す。たとえば既存 API に rate limiting spec を書かせる、または CLI に config option を追加する、くらいの範囲がよい。最初に見るべきなのは code quality そのものではなく、生成される .pi-tasks/TASK_NNNN.md だ。Refine は goal を絞れているか。Research は project を本当に調べたか。Grill は重要な gray area を聞いたか。Compose は実行可能な spec になっているか。
Decision control を重視するなら、先に /task-plan を試すとよい。Database migration strategy、compatibility policy、error code design など、agent に勝手に決めてほしくない task に向いている。Model に question と recommendation を出させ、人が key decision を確認し、それから /task に渡す。すべての制約を長い prompt に押し込むより audit しやすい。
Multi-task behavior を見たいなら、小さな feature を /task-auto に渡す。最初から「system 全体を refactor する」といった request は避けたほうがよい。三から五個の小さな step、たとえば「CLI に config file support を追加し、test と docs も足す」くらいが向いている。Title の分解、逐次実行、失敗後の resume point が明確かを見る。
Caveats
第一に、project は若く、release 形態も npm/tag 寄りだ。Repository は 2026-06-02 作成、現在の stars は 74、GitHub Releases page には正式 Release entry がない。試用と観察にはよいが、team critical workflow をいきなり任せる段階ではない。
第二に、Pi への依存が強い。README には Earendil Pi coding agent >=0.80 が必要とあり、package.json にも Pi 関連 peer dependencies がある。Pi を使っていない developer にとっては、workflow design は参考になるが、tool 自体をすぐ再利用できるとは限らない。
第三に、extension は code を実行し、agent behavior に影響する。License は AGPL-3.0-only で、agent extension として local development environment に入る。Install 前には README、LICENSE、主要実装を読み、まず throwaway repo や sandbox environment で試すべきだ。
第四に、deterministic pipeline は正解を保証しない。長い prompt にすべてを混ぜる失敗は減らせるが、research が十分とは限らず、grill が正しい question を出すとも限らず、spec が常に正しいとも限らない。最終的には diff、tests、external API、安全境界を人間が確認する必要がある。
まとめ
mjasnikovs/pi-task が面白いのは、reliability を model の進化だけに任せていないところだ。Local LLM は drift する、hang する、context を忘れる。その前提で task を固定 phase に分解し、phase result を file に保存し、noise の多い research を child session に逃がし、最後の spec を main session に戻す。
万人向けの tool ではない。Pi ecosystem の tool であり、project も early stage だ。それでも local model で coding agent を動かしていて、「code は書けるのに task organization で迷走する」場面が多いなら、pi-task は見る価値がある。魔法ではなく、より engineering workflow に近い constraint chain を提供している。