idea-to-ship

name	idea-to-ship
description	Turn a rough product or tool idea into a researched, implemented, tested, reviewed, pushed, and documented result. Use for autonomous end-to-end work that must compare competitors, inspect the local environment, choose a proven stack, build the solution, clean up Git, and produce an HTML handoff. Reuses focused research, implementation, and review skills instead of replacing them. Triggers: "take this idea to production", "research and build this", "build and ship this", "idea to implementation" 日本語: 「このアイデアを形にして」「競合調査から実装までやって」「最後まで自律的に作って」「調査して作ってpushまでして」 NOT for a small isolated edit, research-only request, or review-only request.
user-invocable	true

Idea to Ship

曖昧なアイデアを、根拠のある実装と再現可能なhandoffまで自律的に運ぶ。 調査だけ、実装だけ、reviewだけの依頼には使わず、対応するfocused skillを使う。

Core Contract

1. 最初のアイデアを仮Goalへ変換する。
2. 調査と実装で情報が増えるたびにGoalを具体化する。
3. 安全で可逆な作業は質問待ちにせず進める。
4. 進路を変える判断と外部への不可逆な変更だけ確認する。
5. 完了条件を証拠で監査し、Gitとhandoffまで終えてから完了とする。

Start

1. project-local instructionsと必須architecture docsを読む。
2. アイデア、対象ユーザー、期待する結果、既知の制約を抽出する。
3. 不足情報は明示的な仮定として置き、調査で検証する。
4. native Goal機能があれば仮Goalを作る。なければ作業planをGoalとして管理する。
5. 成功条件を観測可能な結果で3〜7個定義する。
6. 外部変更のauthorization envelopeを確認する。

Authorization Envelope

skill起動時の依頼文から許可範囲を判断する。「最後まで」「pushまで」「repoも作って」が明示されていれば、その範囲は再確認しない。

Action	Default
local read、Web research、test、build	自動実行
workspace内の実装と可逆な編集	自動実行
private repo作成、push、PR作成	明示済みなら自動実行
課金、公開repo、production deploy、data削除	必ず直前確認
merge、branch削除、既存remote変更	明示済みでなければ確認

判断方法と質問UIはdecision-gates.mdを読む。

Research and Decide

1. research-playbook.mdを読み、作るものに合うsourceを選ぶ。
2. direct competitors、adjacent solutions、OSS building blocks、do-nothing optionを比較する。
3. marketing claimではなく、公式docs、実装、pricing、利用者の不満、更新状況を集める。
4. local environmentを調べ、既存projectへ統合、OSS採用、fork、新規実装を比較する。
5. license、maintenance、security、migration cost、lock-inを確認する。
6. 採用方針とtech stackを証拠付きで決める。
7. Goal、成功条件、scope外を更新する。

調査結果で重大な前提が崩れた場合だけ質問する。回答待ちでも安全な調査とprototypeは続ける。

Choose the Home

状況	方針
既存projectに自然なextension pointがある	最小変更で統合
実績あるOSSが要件を満たす	導入または薄いadapterを実装
OSSは近いが差分が本質的	forkよりupstream拡張か独立実装を比較
適切な置き場所がない	project規約に沿うprivate repoを新設

新規repoではlocal convention、ghq root、GitHub owner、命名規則を調べる。許可範囲内ならprivate remote作成、適切なghq配下への配置、初期化、pushまで実行する。

Build Loop

1. riskyな変更ではbaseline testを先に実行する。
2. acceptance criteriaから最小の縦切り実装を選ぶ。
3. behaviorを証明するtestを先に書く。非現実的な場合は理由を記録する。
4. projectの既存patternとtoolchainで実装する。
5. unit、integration、user-facing scenarioの順に検証する。
6. failureを原因別に切り分け、実装修正とtest修正を混同しない。
7. 各milestone後にGoalとplanを更新する。

実装詳細は既存のautonomous-dev、project固有skill、domain skillを必要に応じて使う。指示が競合する場合はproject-local instructionsを優先する。

Review and Refactor Loop

1. tests、lint、typecheck、buildを実行する。
2. built-in reviewまたはcodex reviewで対象diffをreviewする。
3. correctness、security、performance、maintainability、project rulesの指摘を統合する。
4. criticalとwarningを修正する。
5. verificationとreviewを最大3回繰り返す。
6. 同じ問題が再発したら局所修正を止め、設計か前提を見直す。
7. behaviorが固定されてから重複、命名、責務境界だけrefactorする。
8. refactor後に全verificationを再実行する。

可能ならpost-reviewをreview loopとして再利用する。

Git Closeout

delivery-playbook.mdに従う。

1. unrelated user changesを除外する。
2. diffと生成物を監査する。
3. secret、大容量artifact、一時fileが含まれないことを確認する。
4. 意図単位でcommitを整理する。
5. 許可範囲内でbranchをpushし、upstreamを設定する。
6. project conventionがあればPRを作る。
7. git status --shortが空であることを確認する。
8. mergeやbranch削除はauthorization envelopeに含まれる場合だけ実行する。

Completion Audit

「問題が見つからない」ではなく、各成功条件を証明する。

Requirement	Required evidence
機能	acceptance testまたは再現可能なmanual scenario
品質	test、lint、typecheck、build、review結果
配布	remote、branch、commit、PRまたは明示した未実施理由
利用可能性	setupと動作確認手順
Goal達成	成功条件ごとのevidence mapping

証拠が不足する項目は未完了として扱う。環境制約で検証不能なら、制約と最短の追試手順を残す。

HTML Handoff

1. handoff-schema.mdに従ってJSONを作る。
2. 次のcommandで単一HTMLを生成する。

bun "$(agent-skill-path idea-to-ship)/scripts/render-handoff.ts" \
  --input /path/to/handoff.json \
  --output docs/ship-report.html

3. browserでHTMLを開き、desktopとmobile幅、console error、全手順を確認する。
4. 概要、意思決定、実装内容、検証証拠、使い方、注意点、Git状態を含める。
5. reportの場所を最終回答でlinkする。

Stop Conditions

• production credential、課金、法務判断など新しい権限が必要なら止める。
• 同じblockerが3回続き、安全な代替作業も尽きた場合だけblockedとする。
• 時間やcontext都合だけでscopeを縮めない。
• 完了監査とHTML handoffとGit closeoutが終わるまでcompleteにしない。