初めてのグリーンフィールドプロジェクト
このチュートリアルは空ディレクトリを実際のビルドカードまで運ぶ。6つの計画成果物を書き、各々が2度裁かれる——議論の余地のないスクリプトに1度、批評家として読むモデルに1度。
スキルのインストールが先に必要だ：インストールと初回実行。
時間：1〜2時間。Scopeゲートで自分にどれだけ正直かによる。
歩くパイプライン
Section titled “歩くパイプライン”Idea -> Research -> Scope -> PRD -> ADR -> Contract -> Cards -> Build -> Review -> Deploy -> Verify-live -> Retro|------------------ planning (files in flow/) ------------------| |------- shipping (inside cards/) -------|計画はステージ 00 から 05 で、flow/ 配下のファイルとして生きる。出荷は cards/ の中で起きる。6つの計画ゲートがすべて通過するか、正直に記録されたdebtを持つまでカードは切れない。
ステップ1 — 「done」の意味を選ぶ
Section titled “ステップ1 — 「done」の意味を選ぶ”/flow project-type webプロジェクトタイプが、最後にハーネスが要求する証拠を決める：web なら稼働中のデプロイ済みURL、cli なら期待通りの出力と終了コードを伴う実際の呼び出し、library なら動く使用例付きのimportできる公開API、skill なら自らの完了定義に到達したインストール済みスキル。デフォルトは web。今設定すれば、間違った形の契約を書かずに済む。
ステップ2 — 成果物を誰が書くか決める
Section titled “ステップ2 — 成果物を誰が書くか決める”/flow mode teachteach モード——デフォルト——ではあなたがすべての計画成果物を書き、エージェントはゲートキープだけする。work モードではエージェントが一度インタビューし、ステージ00から05を自ら起草し、スコープの承認でのみ止まる。ゲートの縛りはどちらでも同一だ。違うのはキーボードに指があるのが誰かだけだ。
ハーネスを学んでいるなら、この最初のプロジェクトは teach のままにする。各ゲートが実際に何をチェックしているかが見える。
ステップ3 — ステージ00、アイデア
Section titled “ステップ3 — ステージ00、アイデア”/flow nextランナーは flow/00-idea.md を作り、ゲートを落とす。テンプレートが [FILL] マーカーと未チェックボックスだらけだからだ。ファイルを開き、3文のピッチを書く：誰が問題を抱え、今日何をしていて、代わりに何をするか。本当に満たしたボックスをチェックする。再度 /flow next を実行する。
スクリプトが通過したら、完了したばかりのステージの意味チャレンジをエージェントが適用する。スクリプトにできない半分だ：「問題」が変装した解決策なら、ピッチが苦しむ人物ではなく機能を記述しているなら、押し返してくる。
ここでプロジェクトを潰すことは正当な結果だ。 ステージ00で潰した弱いアイデアは1時間のコストだ。契約の後に潰した同じアイデアは1週間のコストだ。
ステップ4 — ステージ01、リサーチ
Section titled “ステップ4 — ステージ01、リサーチ”flow/01-research.md を既にあるもので埋める：競合、見た稼働システム、実際に確認した価格。このステージの規則は 先に調べろ——証拠であって雰囲気ではない だ。
ここの意味ゲートは異常に鋭い。捏造された調査は書くのが最も容易で、スクリプトが捕まえるのが最も難しいものだからだ。出典のない引用、開いていない競合、リンクのない市場数字——どこから来たか問われると思え。
ステージが本当に合わないなら——公開市場のない内製ツールなど——捏造するな。debtを記録して正直にスキップする：
/flow debt add "skip 01-research" "internal tool, no public market" "before public release"/flow skip 01-research --reason "internal tool, no public market"skip が進むのは、未解決debt行がそのステージを正確に名指しし、理由がセキュリティクラスでないときだけだ。
ステップ5 — ステージ02から04、scope、PRD、ADR
Section titled “ステップ5 — ステージ02から04、scope、PRD、ADR”- Scope（
flow/02-scope.md）はプロジェクトが救われるか失われるかする場所だ。機能に正直に等級を付ける。意味ゲートはすり替えを見ている——作りたいがためにC級の機能がB級に書き上げられる。 - PRD（
flow/03-prd.md）は生き残ったスコープを番号付き機能要件に変える。ここで書いたすべてのFRnは、後にカードに主張され、契約のインターフェースに serve されなければならない——その追跡は機械的に監査できる。 - ADR（
flow/04-adr.md）はアーキテクチャ決定を記録する。重要なのは却下したものとその理由だ。
各々の後に /flow next を実行する。未解決のものは ## Open decisions 見出し配下に - [ ] 箇条書きで行く。それらの箇条書きは同じゲートスキャナが数える。未解決の決定は、確定するか意識的に動かすまでステージを止める。
ステップ6 — ステージ05、契約
Section titled “ステップ6 — ステージ05、契約”flow/05-contract.md は継ぎ目であり、決してスキップできない唯一のステージだ。コードが存在する前にインターフェースを書く：webプロジェクトならメソッド・パス・認証・リクエストの形・レスポンスの形——CLIならコマンド・フラグ・出力の形・終了コード。
ここから先の規則は絶対だ：バックエンドは契約に向けてビルドし、UIは契約から消費する。形が間違っていたら、先に契約を修正してからコードを変える。今はnullやスタブで形を守れ。その実値が後のカードで出荷されるときも。
このゲートが通過すると、こう見える：
PASS: stage 05-contract gate clean. Planning is COMPLETE.All planning stages passed (or were debt-skipped). Run '/flow card' to create build cards.ステップ7 — 最初のカードを切る
Section titled “ステップ7 — 最初のカードを切る”/flow cardcards/C-001.md が書かれる。カードは1つのスコープ付きビルドセッションだ：allowed-filesリスト、実装する要件、実際に実行する ## Verify ブロック、ユーザー可視の証拠を記述する ## Independent test、空から始まる ## Evidence セクション。
ビルドの前に /flow recall を実行する——未解決debt、最新のレトロ、前カードのスコープ、promote済みプレイブックを読み戻す。過去の痛みを見た状態で始める。
ステップ8 — ビルドし、証明する
Section titled “ステップ8 — ビルドし、証明する”カードのallowed-filesリストが名指すものだけをビルドする。次に：
/flow check C-001## Evidence が空の間、カードは落ちる。コードが完璧で全テストが緑でもだ：
[x] status is 'done' but ## Evidence is empty (paste world-state proof: URL/curl/DB row)FAIL: C-001 has gate violations (above).真の証拠を貼る——webプロジェクトなら実際のcurl出力付きの稼働中URL、CLIなら実際の呼び出しと終了コード——再度チェックする：
PASS: C-001 is valid (status: done).- 6つの計画ゲート。各々が機械的に、次に意味的に裁かれる。
- 潰すことと、debtに裏打ちされた正直なスキップは、どちらも一級の結果だ。
- 契約はコードより先に書かれ、唯一スキップできないステージだ。
- 「Tests pass」は中間状態。完了とは現実世界の証拠だ。
- 日常ループは カードの作成とチェック。
- 各ステージが何から守るかは ステージパイプライン。
- ステップ8が厳しい理由は 完了とは現実世界の証拠。