product-founder-os

これは何か

product-founder-os は、GPT や Codex と一緒にプロダクト開発を進めるための運用リポジトリです。 役割は、曖昧なアイデアをその場で処理して終わるのではなく、 「何を作るのか」「今どこまで進んでいるのか」「何を変えたのか」を repo の中で追える状態に保つことです。

AI と一緒に開発していると、コードに入るのが早すぎたり、 仕様が会話の中だけで変わって docs に残らなかったり、 「できたつもり」のまま次へ進んでしまったりしがちです。 このリポジトリは、そうした崩れ方を減らすために、 project seed、product brief、functional spec、roadmap、current sprint、change request、done definition といった中核ファイルを source of truth として扱います。

誰向けか

このリポジトリは、GPT や Codex を使って、複数回のやり取りをまたぎながらプロダクトを形にしていきたい人向けです。

• アイデアはあるが、まだ仕様が固まり切っていない個人開発者
• small SaaS や static tool を、企画から整理しながら進めたい人
• コードはあるが、何を作っているかの定義が弱い repo を立て直したい人
• 複数セッションで作業を継続するたびに、毎回話をやり直したくない人
• 要件変更を repo 上で明示的に管理したい人

逆に、単発の小さな script を今すぐ1本だけ書きたい場合や、 企画整理を飛ばしてコードだけ進めたい場合には向きません。

何ができるか

作るものを言語化する

project seed、product brief、target user、problem、scope、non-goals を整理し、アイデアを「作業できる形」にします。

仕様と計画をつなぐ

functional spec、roadmap、task backlog、current sprint、done definition を作り、実装の前提を repo に残します。

変更を明示する

change-requests.md を使って要件変更を記録し、docs を先に更新してから実装側を変える流れを取りやすくします。

基礎の破損を見つける

baseline docs の不足、markdown link の切れ、placeholder の残り、code fence の崩れなどを helper script で確認できます。

モード

Discover

何を作るのかを確認し、project seed と assumptions を作る段階です。

Define

product brief、spec、scope、success criteria を固める段階です。

Plan

roadmap、task backlog、current sprint を作り、今どこを進めるかを明確にする段階です。

Build

current sprint を基準に implementation、または implementation guidance を進める段階です。

Adjust

要件変更を change request と source-of-truth docs に反映してから方向転換する段階です。

Ship

done definition、acceptance criteria、handoff docs を見ながら、現在の区切りが本当に完了かを確認する段階です。

含まれているもの

Core instructions

README.md、SKILL.md、AGENTS.md、DISCLAIMER.md、LICENSE を含みます。

Documentation

docs/ に intake、definition、spec、design、planning、execution、quality、handoff を収録しています。

Examples and templates

examples/ と templates/ に worked example、starter example、template files を収録しています。

Scripts

create_project_docs.py、check_doc_links.py、validate_foundation.py、bootstrap_new_product.py を含みます。

使い方

このリポジトリは、文書置き場として読むより、「プロダクト作業の進め方を固定する repo」として使うと分かりやすいです。

1. まず README.md を読み、repo 全体の位置づけと workflow を把握する。
2. SKILL.md を読み、assistant がどう動くべきかを確認する。
3. AGENTS.md と core docs を開き、source of truth の優先順位と current state を把握する。
4. product が未定義なら、何を作るかを先に聞き、project seed と brief を固める。
5. roadmap.md、task-backlog.md、current-sprint.md を更新する。
6. その後で implementation を current sprint ベースで進める。
7. 要件変更が入ったら change-requests.md を更新し、そのあとで方向転換する。

全体像だけ知りたいなら README と worked example を見るだけでも十分です。 実際に使うなら validation scripts と bootstrap helper まで見るのが自然です。

Bootstrap helper

新しいプロダクト案の叩き台を一気に作りたい場合は、次の helper を使えます。

python3 scripts/bootstrap_new_product.py "Your Product Name" --one-line "One-line description" --user "target user"

これにより、starter seed / brief / spec / roadmap / sprint / done definition をまとめて生成できます。 ただし、完成版を自動生成するものではなく、最初の土台を作るための補助です。

なぜ NicheWorks が公開するのか

NicheWorks は、実務で使える小さな tool や workflow asset を公開するラインです。 product-founder-os もその一つで、AI と一緒にプロダクトを進める時に崩れやすい部分を、 repo structure と docs workflow で整えるための asset として公開されています。

これは万能な product generator を名乗るものではありません。 むしろ、「何を作っているのか」「何が変わったのか」「今どこまで終わっているのか」を repo 上で見失わないための、地味でも役立つ土台として置かれています。

FAQ

関連リンク

免責事項

このページおよびリンク先のリポジトリは、情報提供と practical workflow の整理を目的として公開されています。 内容の完全性、特定目的への適合性、プロダクトの成功は保証されません。 実際の product decision や implementation の最終判断には human review が必要です。