Ducklab

フルサイクルのソフトウェア開発ハーネスであり、デフォルトでマルチLLM、そして構造的に正直です。

まとめると： セルフホスト型開発ハーネス（Go エンジン + CLI + デスクトップ、Linuxファースト）・ ブリーフ → 要件 → 仕様 → プラン → ビルド → テスト → リリース ・ 判定は終了コードであり、モデルの意見ではない ・ ローカルモデル優先（llama.cpp、vLLM）＋ OpenAI 互換または Anthropic エンドポイント ・ 人間またはエージェントが MCP 上で操作でき、記録・属性付きの決定を残せる ・ Apache-2.0 ・ 自身を開発している（.ducklab/ 内の実行記録が証跡）。エージェントは AGENTS.md と llms.txt から始めます。

あなたがブリーフを与えると、要件・スペック・プランを作成し、1つのモデルまたは複数のモデルが議論しながらタスクを実行し、プロジェクトの実際のテストゲートを実行し、何かをコミットする前にあなたのために停止します。すべてのモデル呼び出しは記録されます。どのモデルも判定を下しません。

これはローカルモデル優先で作られました。このプロダクトの大部分を作ったのは、LAN内のvLLMボックスと localhost の llama.cpp サーバーで、どちらもコストゼロです。そしてホストモデルも同じリストに並び、同じエビデンスで評価されます。

これが存在する理由

多くのエージェンティックコーディングツールは、1つの強力なモデルを前提にそれを信用します。Ducklabは複数の安価なモデルを前提に、どれも信用しません:

• 判定するのはゲートであり、モデルではない。 判定はコマンドの終了コードです。テストを書く前にベースラインのグリーンを計測し、その後に新しいテストでレッドを計測し、すべての accept はコミットされた sha のクリーン・チェックアウトからゲートを再現します。再現できないものは何も来ず、再現に失敗した accept は自分のコミットを撤回します。

• どこでも非相関。 レビューは別のモデルが行い、レビューアーが誰がコードを書いたか（ペイロードに含まれないため、UIに隠れるのではなく）知ることはありません。トーナメントの審判はブラインドで選び、カウンシルの批評家はドラフトを読み、互いの意見を読みません。

• 作業は契約です。 タスクの成果物は実装者の番号付きチェックリストです。実装者は各番号で報告し、レビューアーは各項目を diff と照合し、未達の成果物があるとラバーダックが召喚されます。ラバーダックは、ブレーキ拒否、失敗連続、赤ゲートなど、実測された苦境のときにだけ目覚めるアドバイザーのシートで、noneを返すか、実装者を仕事に戻すメモ、またはstopを返します。

• シートはエビデンスで選ばれます。 すべてのダックリングは、自分の実行のインフォームド完成率、実行ごとのコスト、コーディング指数などをスコアカードとして持ち、これに基づきロスターボードがシートを提案します。ランキング基準は自由に並べ替えられます。提案はまれで、常に正当理由があります。合格率は Wilson の下限でランクし、最小3回の実行が必要で、ローカルは$0という価格だけで勝つことはありません。

• すべてには上限があります。 ターン、トークン、コスト、実時間、ツール出力、シェルコマンドラインのすべての天井は可視で、実行の途中でも、で変更でき、記録に残ります。

• ドキュマンはモデルのウィンドウに制限されません。 ウィギーをステージに追加すると、大きなシートは全体を読み、小さなシートには各ドキュメントがフィットするように事前に要約され、全文は ref_read 呼び出しの先にあり、誰も開かなかったドキュメントをゲートが指摘します。32kコンテキストのローカルモデルでも、25万字の参照資料をブリーフとして与えられます。ハーネスがワーキングメモリを担います。

そして存在の証明です：ducklabはducklabの中で開発されています。 プラン、バグ、リリース、過去90以上の accept タスクが、すべて自身のループを経ています。それらは、自身が評価するローカルモデルとホスト型モデルでジェラされた。直近の機能（マルチモデルチャット、コンサルタント・シート、ガイドレールの実行履歴）もダックが作り、人間がゲートしました。

Related MCP server: Loki Mode

ステータス

v0.6.1+ で、速いビースでの開発中です。七つのステージ、五つのモード、エビデンスと提案を備えるロスター・ボード、自動でダイジェストされるリファレンスドキュメント、デスクトップから管理できるスキル、画像（種類確認をした上で送信）とチャットできるコンサルタント・シット、スクリーンショット証拠のバグ、リリース、オートパイロット、CLI、デスクトップアプリがあります。さらに別のモデルが、記録・属性付きの決定を残しながらループ全体を操作できる MCP server もあります。

docs/status.md は、すべての受入条件を追跡し、丸めません。コードと括約が食い違った場合は、その乖離は docs/decisions/ にそのまま記録されます。

インストール

Go 1.25+ と git、デスクトップアプリには Node 22+ が必要です。

Linux版

CLI とエンジンは純粋なGoです。デスクトップは Wails v3 アプリで、GTK/WebKit 開発パッケージが必要です。

sudo apt install libgtk-3-dev libwebkit2gtk-4.1-dev   # Debian/Ubuntu names
make desktop && make install

Ubuntu 24.04+ では、デスクトップ実行に AppArmor プロファイルも必要です。 decision 0003 および packaging/apparmor/ を参照してください。

macOS

xcode-select --install    # the desktop build links against WebKit
brew install go node
make desktop && make install

誠実な注意：ducklab は Linux 上で日々開発・実行されています。CLI とエンジンはすべての make cross で darwin/amd64 用にクロスコンパイルされているだけですが、まだ Mac でデスクトップビルドはテストされていません。最初に Mac で試した人がテスターです。make installはどちらにせよ CLI とエンジンはインストールします。何かを壊れたら、連絡してください。お願いします。

共通

make install は ~/.local/bin にインストールします — 開発が PATH に入っていることを確認してください。デスクトップのバイナリが frontend/src より古い場合には、警告されます。古いバイナリを喜んで入れてしまうためです。

3つのバイナリ

プロバイダキーは呼び出し時にエンジンの環境から取得します。エンジンを起動する前に格納してください。または、キーリングから読むラッパー経由でデスクトップを起動してください。アプリは、取り込んだエンジンがないキーが、重房ウィンドウが持っていることを示し、その言葉の横に再起動ボタンを表示します。

一連のテサイクル、エンドツーエンド

デスクトップから実行：一致 → 新規プロジェクト, 次に サイクル → 下書き作成. ターミナルからは：

cd ~/dev/myproject
git init                                    # ducklab needs a git repo
ducklab project init --name MyProject       # auto-starts the engine if none is running

ducklab intake --from brief.txt             # brief        → requirements
ducklab spec                                # requirements → spec
ducklab plan                                # spec         → milestones and tasks

ducklab run T-001                           # build it
ducklab run accept r-20260729-...           # commit it

ducklab review T-001                        # read the commit
ducklab release plan --bump minor           # what shipped

各ステージはまず .proposed ファイルを作成し、あなたを待ちます。accept はそれを昇格させ、reject はその実行が残したものだけを正確に復元し、他には何も復元しません。「request changes」は、あらゆるドラフト（仕様、プラン、リリースノート）をあなたのメモを添えて送り返します。あなた（または明示的に与えた自律レベル）なしのコミットはされません。

事前ドキュメントは任意のステージに添付できます。--ref ~/wiki/product/（またはデスクトップの「付けいプロジェクト」）で、ファイルやディレクトリ全体をアーキテクトの背景情報として読み込みます。このとき、次の2つのルールがプロンプト中に明んに対明示されます。承認された要件がスコープを保持し、リファレンスとコードが矛盾する場合はコードが真実であることです。コーパスがシートのコンテキストを超える場合、各文書は一度だけダイジェスト（コンテンツハッシュをキャッシュ）され、全文は ref_read ツールでわざーコールで取得できます。また、ゲートには開かれなかったドキュメントが名前を挙げられます。32k のローカルモデルでも、25万字のリファレンス資料を解説されます。ハーネスがワーキングメモリを保有しています。

既存のコードベースを採用することも同じ方法です。インテイクが呼び出して「as-is」要件を作り、仕様では、そのセクションを as-built とマークし、プランは意図的に空白にします。新規作業はそして、バグ報告とプラン変更から始まりします。これが ducklab 自身の開発方法です。

プロジェクトは、自らが決めた真実源を .ducklab/project.toml に宣言します：ゲート（[verify] — クリーンのチェックアウトに必要な link_deps と setup を含む）、起動方法（プリフレイト付きの [run]）、プロジェクトのバイナリを再構築する方法（[install]）など。ducklab の中だけで完全に行えます。

モデルの追加

ducklab provider set openrouter --url https://openrouter.ai/api/v1 \
                                --key-env OPENROUTER_API_KEY
ducklab duckling set pato-sonnet --provider openrouter \
                                 --model anthropic/claude-sonnet-4.5 \
                                 --roles reviewer,judge --context 200000 \
                                 --cost-in 3.0 --cost-out 15.0
ducklab duckling test pato-sonnet --prompt "say OK"

--key-env は、環境変数の 名前 です。キーそのものではではありません。キーは設定ファイルに書かれず、API へ送信されず、シェル履歴にも残りません。

デスクトップの Roster ビューがシート割り当て場所です。 Flock からモードのシートへドラッグし、一括またはプロジェクト単位で、各ダックリングのエビデンスをカードで、エンジンからの提案をシートの横表示します。コーディング / 知能 / エージェント指数は、ダックリングが OpenRouter にある場合はそのソリュースインベアマークエンドポポイントから取得し、残りは自分の実行記録が供給します。

5つのモード

ducklab PICK T-001 --mode <モード>

絶対に行わないこと

これらは優先事項ではなく、土台となる制約です。

• モデルが判定を下すことは、ありません。 ゲートはコマンドの終了コードです。

• グリーンな候補は、バイト優位でそのまま適用されます。 通過後に候補を再生成することはありません。

• レビューアーがエンティティーが誰かを知ることはありません。

• クリーンチェックアウトから出さなかったものは、受け入れません。

• 「reject」が行うのは実行が書き込んだ内容だけを元に戻すことです。 他人の作業を分解しません。

• 上限なしのものはありません。

• 秘密情報がプロジェクト状態に触れることはありません。

• エンジンはループバック専用です。 リモートモードはありません。

スキル

skill とは、SKILL.md を置いたディレクトリです。.ducklab/skills/ プロジェクト固有のスキルを、マシン全体のスキルディレクトリ メタを project や複数プロジェクト共有させます（名前が重なるときは、プロジェクトのスキルがグローバルを優先します）。ドキュメントのみ形式、つまりスクリプトがなく、デフォルトです。モデルが読んで手順どおり実行するレシピがです。アーキテクトは adopt の前にサーベイガイドを読み（skill_list README）、コンサルタントはチャット内で読み、実行可能なスキルを 特徴 に skill_run するのはインプ Open only です。

スキルの管理はデスクトップ（ギア → スキル）から行います：スコープバッジと検証の問題を含む一覧、読む、起動、引数付きで実行、削除ができます。ダックリングが実行中に作成したスキルは、その実行が承認されるまではグレーアウトして pending acceptance と表示されます。スキルの提案は、コードの提案と同じゲートを通過します。

ducklab skill new house-style
ducklab skill run changelog-entry --arg summary="..."

The consultant

すべてのプロジェクトにはコンサルタント（名簿ボード上のCommonシート）が配置されます。「これについてチャット」ドアの背後と、ガイドレール内の自由形式チャットを担うモデルです。コード、実行、ボード、スキルを読み取りますが、決して書き込むことはなく、画像を受け付けます。壊れたビューのスクリーンショットを貼り付けて質問してください。ビジョンは想定ではなく検証されます。宣言されたビジョンシートは実際の画像リクエストで一度プローブされ、テキストのみのシートは幻覚的な回答をする代わりに言葉で貼り付けを拒否します。

別のモデルからducklabを操作する

ducklab mcp serve は、ループ全体をstdio上でMCPサーバーとして公開します。外部モデルが各結果を読み取り、ゲートを決定し（必須かつ記録された理由付き — 決定は「人間」ではなく approved_by: mcp:<client> として記録されます）、質問に答え、バグを報告し、計画を修正し、作業を開始します。エンジンの next リストが規範です。オペレーターは人間が実行できないアクションを実行できません。

コントリビューション

CONTRIBUTING.md を参照してください — ビルド方法、テストがアーキテクチャをどのように保護するか、作業がducklab自身のループをどのように流れるか、そしてどこから始めるか。短いバージョン:

make            # vet, test, build the frontend
go test ./...   # 38 packages
cd frontend && npx vitest run

ライセンス: Apache-2.0。コントリビューションは同じ条件で受け付けられます（ライセンスの§5 — CLAなし）。Ducklabの名前とアヒルはメンテナーのものです（§6）。

仕様

コードは、このリポジトリ内の文書化された仕様を実装しています。docs/spec/（00-VISIONから08-DESKTOP-UIまで）は規範レイヤーです — ビジョン、不変条件、プロトコル契約、受け入れ基準。システムが今日ある姿は .ducklab/docs/ にあります — ループ自体が維持する建設済み要件、仕様、計画であり、各バージョンは人間のゲートで署名されます。両者が意図的に異なる場合、その差異は docs/decisions/ に記録されます。両者の差分がロードマップであり、アライメントステージがそれを計算します。