Say what you want. The harness runs the steps.やりたいことを言えば、ハーネスが段取りを回す。
This page shows how a day with Banto actually runs. First come four habits shared by every flow. Then three scenario flows: building something new, building an AI feature, and starting from a question. Every step is written the same way — the phrase you say, what happens, and what remains afterwards.
この頁は banto での 1 日の回し方を示す。最初に全フロー共通の 4 つの習慣、続いて 3 つの場面別フロー(新規開発・AI 機能・調べもの)。各ステップは「言うフレーズ → 起きること → 残るもの」の同じ型で書く。
Four habits that apply to every flowどの流れでも使う、4 つの習慣
Context management and workspace management. Everything else is scenario-specific.コンテキストの管理と、作業場の管理。それ以外は場面ごとの流れに任せてよい。
💾 When 💾 shows, /clear is safe💾 が出たら、安心して /clear
A statusline mark like 💾 01:14 means an auto-checkpoint was saved at 01:14. statusline の「💾 01:14」は、01:14 に自動チェックポイントが保存済みという印。
- The harness saves a checkpoint by itself after 5 idle minutes, or when context pressure rises. You do nothing.放置 5 分、またはコンテキスト逼迫で、ハーネスが裏でチェックポイントを自動保存する。あなたの操作は要らない。
- Once the mark shows, type
/clearfreely. The next session start re-injects the saved state, so the thread survives.印が出ていれば/clearしてよい。次のセッション開始時に保存内容が再注入されるので、作業の筋は途切れない。 - Clearing gives the whole context window back — responses get faster and cheaper.クリアするとコンテキストウィンドウを丸ごと取り戻せる。応答は速く、安くなる。
At a good stopping point, /save-checkpointいい区切りで /save-checkpoint
When work reaches a milestone, say /save-checkpoint (or just "save the state"). 区切りがついたら /save-checkpoint と打つ(「状態保存して」でも動く)。
- It writes what you are doing, how it got here, and what was decided — as a structured snapshot in the store.今の作業・経緯・確定した決定を、構造化スナップショットとして store に書く。
- Afterwards it recommends exactly one of
compactorclear. Follow the recommendation.保存後にcompactかclearのどちらか一方だけを推奨する。表示に従えばよい。 - It never runs either command itself — you type it. That keeps the timing in your hands.どちらのコマンドも自動では実行されない。打つのはあなたなので、タイミングは手の中に残る。
Watch the context color, not the token countコンテキスト残量は色で見る
The statusline usage indicator changes color at 40% / 60% / 80%. statusline の使用率表示は 40% / 60% / 80% で色が変わる。
- When the color advances, plan a
/save-checkpoint→/clearat the next stopping point.色が進んだら、次の区切りで/save-checkpoint→/clearを予定する。 - A hook reads the same number and starts recommending a fold before the window becomes expensive.同じ数値を hook も読んでいて、窓が高くつく前に畳む推奨が出る。
Leave branches and tasks to wsタスクと作業場は ws に任せる
You never type a git command. State the intent, and ws drives branches, worktrees, and merges. git コマンドは打たない。意図を言えば、ws がブランチ・worktree・マージを駆動する。
- "Start ~" opens an epic branch plus an isolated worktree. Parallel topics get parallel workspaces.「〜を始める」で epic ブランチと分離された worktree が開く。並行する話題は並行する workspace になる。
- "This work is done" runs test → merge → sync → cleanup on its own.「この作業終わった」で、テスト → merge → sync → 後片付けまで自動で進む。
- "Ship it" always stops for your confirmation before a PR is opened.「main に入れて」「出して」は、PR 作成の前に必ず確認が入る。
- "Keep going on the next task" finds the next unchecked item in
tasks.mdand implements it through to done.「次のタスク進めて」で、tasks.mdの未完了項目を見つけて実装まで完遂する。
Something new: ideology → spec → self-driving build新規開発は、思想 → 仕様 → 自走の一本道
Say each phrase in order. If there is no UI, skip step 2.順にフレーズを言うだけで、思想の確定から main への合流まで進む。画面が無いなら手順 2 は飛ばす。
-
Solidify the ideology思想を固める
A dialogue fixes why the product exists, who it repels, and what world it projects — six phases for a real product, one line for a throwaway experiment. The result is injected into CLAUDE.md and becomes the judgment filter every later step reads.なぜ作るか・誰を弾くか・どんな世界観かを対話で確定する。本物の製品なら 6 Phase、使い捨ての実験なら 1 行で済む。結果は CLAUDE.md へ注入され、以後の全ステップが読む判断フィルターになる。
-
If there is a screen: a design brief画面があるなら、デザインブリーフ
"Make it look nice" becomes a 14-axis brief, starting from who uses the screen and in what mood. The finished brief hands over to spec.「おしゃれに」という曖昧な依頼が、誰が・どんな気分で使うかを起点にした 14 観点のブリーフになる。仕上がったブリーフは spec へ引き継がれる。
-
Design first, build laterまず設計だけを作る
spec picks a format that matches the task's weight — PRD, Design Doc, RFC, ADR and more — and talks the design through with you. The three documents are saved to the store, so any later session can pick them up.spec がタスクの重さに合う形式(PRD・Design Doc・RFC・ADR など 6 種)を選び、対話で設計を詰める。3 点の文書は store に保存されるので、後のどのセッションからでも拾える。
-
Let it build itself自走で作らせる
The spec is broken into small tasks, then implement → verify → fix loops until everything is green. You are called exactly twice: when an interpretation of the spec splits, and right before anything enters main.spec が小型タスクへ分解され、実装 → 検証 → 修正が green になるまで周回する。あなたが呼ばれるのは 2 回だけ — 仕様の解釈が割れたときと、main に入れる直前。
-
Close the work, then ship作業を閉じて、出す
ws tests, merges, syncs, and cleans up. Saying "ship it" opens the PR — always after an explicit confirmation. Merging stays in your hands by default; a standing per-repo grant (
pr_merge: allow) can hand it to the harness.ws がテスト → merge → sync → 後片付けを行う。「出して」で PR 作成へ進むが、必ず明示の確認を挟む。マージは既定であなたの操作のまま — repo 単位の常設許可(pr_merge: allow)でハーネスに任せることもできる。
An AI feature follows the same shape, plus evalAI 開発は同じ型に、eval が足される
Adding an LLM to your app is ai-build. Creating or training a model itself is model-lab.アプリに LLM を組み込むなら ai-build、モデルそのものを作る・学習するなら model-lab を使う。
ai-build
"I want to build a RAG" runs requirements → design → build → eval as one flow. 「RAG を組みたい」の一言で、要件 → 設計 → 実装 → eval まで一気通貫で進む。
- First it searches the store for what you already know. If the method or model information is more than 14 days old, it researches the latest first.まず store を検索して既知の情報を確かめる。手法やモデルの情報が 14 日より古ければ、先に最新を調査する。
- Then it picks prompt / RAG / fine-tune, implements, and scores the result with an LLM-as-judge eval. "It runs" is not the finish line.そのうえで prompt・RAG・fine-tune を選んで実装し、LLM-as-judge の eval で採点する。「動いた」では終わらせない。
- Model ids, pricing, and API parameters are looked up in the claude-api reference, never answered from memory.モデル id・価格・API パラメータは記憶で答えず、claude-api リファレンスを引く。
model-lab
Training a model runs verification-first, from pretraining to a published paper. モデルを学習するなら、事前学習から論文公開までを検証中心で自走させる。
- The sequence is Frame → Survey → Design → Implement → Run (Mac → Nvidia → cloud) → Verify (eval, ablation, statistics) → Paper & publish.Frame → Survey → Design → Implement → Run(Mac → Nvidia → cloud)→ Verify(eval・ablation・統計)→ 論文公開の順で進む。
- A hook blocks any "done" claim that lacks a backing experiment. Paid compute and publishing always stop at a human gate.裏づけ実験のない「完了」主張は hook が止める。有料計算の起動と公開は必ず人間ゲートで止まる。
Questions go store-first, then the web調べものは store が先、web は後
Both paths leave their results in the store, so the same question is never researched twice.どちらの経路も結果が store に残る。同じ調査を二度しない。
search
"What did we decide about this?" searches decisions and past chats. No web. 「これ前に何て決めたっけ」で、決定ログと過去チャットを検索する。web には触れない。
- The query expands across synonyms and English/Japanese variants, then greps the store. The answer is a file and a line — not a guess.クエリを同義語・英日表記ゆれへ展開して store を grep する。返るのは該当ファイルと行であって、推測ではない。
research
"Look up the latest ~" checks the store first, then escalates to the web only on a miss. 「最新の〜を調べて」は、まず store を確認し、確信ヒットが無いときだけ web へ出る。
- Parallel agents find the sources and read the full text — no summarized guesses.並列エージェントが情報源を特定し、本文の全文を読む。要約頼みの推測はしない。
- Findings are saved under
docs/research/, so the next session simply remembers them.結果はdocs/research/に保存され、次のセッションはそれを「思い出す」だけで済む。