多くの team は「project state を code と一緒に持ちたい」と言うが、実際には code は Git、task は cloud issue system という二つの世界に分かれがちだ。その分離自体は悪くない。ただ、feature branch が 12 files を変更しているのに board 側には “in progress” しか残っていないと、reviewer も coding agent も commit history から context を推測し直すことになる。困るのは board がないことではなく、board が diff、branch、review に参加しないことだ。

今日取り上げる grinev/boardown は逆向きの approach を取る。task board は repository 内の .boardown/ directory に住む。release、epic、task は Markdown files で、branch switch、merge conflict、pull request diff と一緒に現れる。Jira や Linear を置き換えるというより、小さな team、個人 project、agent-heavy workflow に対して、「次に何をするか」も codebase の一部にする軽い選択肢を出している。

GitHub repository page、README、Releases、Tags、LICENSE、package.json、CLI package.json、公開 git history を 2026-07-28 時点で確認すると、grinev/boardown は 26 stars、1 fork。GitHub page は repository created time を 2026-05-01 23:45:37 UTC と示している。page と source structure から主要言語は TypeScript、license は MIT。default branch main の現在の HEAD は 5a86af0、commit time は 2026-07-28 09:29:24 UTC。candidate discovery 時点の latest push は 2026-07-28 09:29:29 UTC。最新 GitHub Release は v0.5.2 で、release page の published time は 2026-07-26 11:09:06 UTC。対応する tag は公開 git history 上で 2026-07-26 11:05:09 UTC。root package.json の version は 0.5.2、Node.js requirement は >=20、package manager は pnpm 10.33.3。CLI package は @grinev/boardown-cli 0.5.2 だ。

プロジェクト概要

項目内容
リポジトリgrinev/boardown
位置づけlocal-first / git-native な Markdown task board
Stars26
Forks1
主要言語TypeScript
ライセンスMIT
GitHub 作成時刻2026-05-01 23:45:37 UTC
現在の default branch commit5a86af0、2026-07-28 09:29:24 UTC
最新 push2026-07-28 09:29:29 UTC
最新 GitHub Releasev0.5.2、2026-07-26 11:09:06 UTC
CLI package@grinev/boardown-cli 0.5.2
実行要件Node.js >=20、pnpm 10.x
キーワードlocal-first、Markdown、Kanban、VS Code extension、desktop app、CLI、AI agents

Task state も code review できるべきだ

boardown の core design は素直だ。data は server database ではなく、project directory の .boardown/ に保存される。README では release、epic、task がそこに置かれ、code と同じように version、branch、diff されると説明している。developer から見ると、task change も review できる。agent から見ると、backlog はすでに見えている workspace 内にある。

この点は「また一つ Kanban UI が増えた」ことより重要だ。cloud task system は cross-team planning、permission、report、notification に強い。しかし repository の外にある。feature branch で checklist を分解し、caveat を足し、task を current release に移したとしても、PR reviewer がそれを見るとは限らない。boardown はその state change を Markdown diff にするので、小さな project では task context が別 tool に消えにくい。

Git の代償も隠していない。README は branch usage の習慣を明確に書いている。feature branch ではその branch に関係する task だけを触り、board 全体をついでに並べ替えない。task creation、dragging cards、release lifecycle のような structure change は main branch で行う。理由は実務的だ。Markdown は merge できるが、task ID、card move、cross-file delete/insert は conflict を生む。弱点を隠すのではなく、運用境界として示している。

三つの entry point が同じ .boardown/ を読む

boardown は Web UI だけの tool ではない。entry point は三つある。VS Code extension、Electron desktop app、command-line tool だ。README の install path も具体的で、extension は VS Code Marketplace と Open VSX、desktop app は GitHub Release assets、CLI は npm package @grinev/boardown-cli から入る。

agent workflow で一番軽いのは CLI だ。README には次の例がある。

npm i -g @grinev/boardown-cli
boardown --help

npx @grinev/boardown-cli release current

CLI は current directory から上に向かって .boardown/ を探す。--data-dir で明示することもできる。pipe または --json では stable JSON envelope を返すため、agent には扱いやすい。coding agent は UI state を推測しなくてよい。backlog を読み、current release を見て、task を移動し、notes を追加する。結果は reviewable な Markdown change として残る。

VS Code extension と desktop app は人間側の読み書き体験を担当する。どちらも同じ board UI を再利用し、同じ Markdown files を読む。file change があれば自動 refresh される。つまり、agent が CLI で task を動かすと、人間は editor や desktop app で同じ board の更新を見る。人間が card を動かせば、次に agent が読むのも同じ .boardown/ だ。

Agent を一等ユーザーとして扱っている

local-first tool の README には “AI-friendly” が一言だけ添えられていることが多い。boardown はもう少し具体的だ。task files は repository 内にあるので agent が自然に読める。CLI は JSON を machine interface として用意している。README は Claude Code、Cursor などの agent が backlog を読み、current release を選び、task を移動し、その変化を UI で live に見られると説明している。

これはよくある friction に効く。agent が plan を作っても、その plan は chat transcript にだけ残りやすい。次の session では途切れる。task board が repo 内にあれば、agent の plan と execution state には versionable な保存場所ができる。何度も Codex、Claude Code、Cursor agent を走らせる project では、「前回の plan を覚えておいて」と頼むより安定する。

reviewability も大きい。agent が task state を更新するとき、結果は見えない remote service に入るのではなく、.boardown/ 内の Markdown を変更する。reviewer は PR で、agent が task description を変に書き換えていないか、wrong release に動かしていないか、checklist を落としていないかを確認できる。code review の流れと合っている。

v0.5.2 の maintenance signal

今回の確認時点で、GitHub page は 7 releases と 7 tags を示し、公開 git history では約 135 commits が見える。最新 release v0.5.2 の release note は、document reference を popup で開き、そこから “View in docs” へ移れるようにしたことを中心にしている。大きな feature ではないが、日常利用の細部を磨いている signal ではある。

source level では、root package.json が MIT、ES module、Node >=20 を明記し、pnpm workspace で packages/* を管理している。CLI package の package.json は “Command-line and agent-facing interface for boardown task boards” と説明し、bin name は boardown、keywords には kanban、markdown、tasks、scrum、agent が入っている。README の positioning と矛盾しない。

project はまだ小さい。26 stars という数字は、主流採用には遠いことも示している。ただ、Gumi で見るべきなのは star count だけではない。明確な workflow value があるかどうかだ。boardown の value は具体的で、task state、agent operation、Git review を同じ surface に置くことにある。

向いている場面

一つ目は個人 project と小さな team だ。open source library や internal tool のために大きな project management system を維持したくないが、release、epic、task を README の todo list だけにはしたくない。boardown は Markdown checklist と cloud issue tracker の中間にある。

二つ目は branch を中心に作業する project だ。task が branch と一緒に動き、reviewer は task description、notes、checklist の変化も見られる。「なぜこの files を変えたのか」を説明する PR では、この context が効く。

三つ目は agent-heavy workflow だ。AI agent に planning、task breakdown、status update を任せるなら、CLI + JSON + Markdown diff の組み合わせは screenshot 的な board より automation に向いている。agent が code を書いたあと task を同期する、または current release から次の task を選ぶ、といった操作を repository 内に残せる。

四つ目は external SaaS に敏感な環境だ。boardown は cloud account、server、remote database を必要としない。README も no cloud、no server、no account を強調している。task data が外へ出るかどうかは、その Git repository をどこへ push するかに依存する。

注意点

第一に、git-native は conflict-free という意味ではない。複数 branch が同時に task を作成したり、task を動かしたり、release を並べ替えたりすれば、Markdown conflict は起きる。README の運用提案どおり、feature branch ではその branch の task だけを触り、structure change は main に寄せるのが現実的だ。

第二に、大規模 team の issue system 代替ではない。permission、cross-project reports、automation notification、support intake、product roadmap governance は、現在の boardown が解こうとしている問題ではない。repo-local planning surface として見るほうが正しい。

第三に、desktop app はまだ code-signed されていない。README は Windows SmartScreen や macOS quarantine の warning に触れており、初回起動には手動確認が必要になる。enterprise device では adoption barrier になりうる。

第四に、project は若い。2026-05-01 に作られ、まだ数か月の history しかない。stars と forks も少ない。試す価値はあるが、大規模に検証済みの infrastructure として扱う段階ではない。

まとめ

grinev/boardown が面白いのは、project management を大きくしようとしていないところだ。scope は狭い。task board は repository 内の Markdown で、UI、desktop app、CLI は同じ .boardown/ を中心に回る。この design によって task state は branch、diff、review に参加し、AI agent にも versionable な作業面ができる。

小さな project で Markdown で task を管理しているが、ちゃんと board UI も欲しい。あるいは coding agent に複数回の開発を任せていて、task state を chat history に散らしたくない。そういう場合、boardown は試す価値がある。Jira でも Linear でもない。project board を Git workflow に引き戻す、小さくて実用的な試みだ。