判断はCLIが導出する
review agentはfindingsを返し、blocking findingの有無からCLIがverdictを導出します。
CLI-FIRST ENGINEERING WORKFLOW
request.md in, pull request out.
SpecRunnerは、実装・レビュー・検証を再開可能なPipelineとして実行します。agentは作業と発見を担い、合否・遷移・再試行制限はCLIが管理します。
$ npx specrunner run docs-quickstart --json
01requestpass受け入れ基準 3件を検証
02designpassspec 1件を作成
03implementdone3 files changed
04verifypasstypecheck · test · lint
05reviewpassblocking findings 0
{ "result": "pr-created",
"step": "pr-create",
"prUrl": "https://github.com/.../pull/128" } pull request created · awaiting human review
PIPELINE
作業を進め、判断は分離する
Standard Pipelineはrequestを検証し、設計・実装・検証・レビューを経てPull Requestを作成します。指摘があれば予算内で修正し、判断材料が足りなければ人間へ戻します。
- 01Request
入力と受け入れ基準を検証
- 02Design
変更の仕様と境界を設計
- 03Implement
テストと実装を作成
- 04Verify
build・typecheck・test・lint
- 05Review
差分と適合性を確認
- 06Pull Request
人間の確認へ引き渡す
Finding
findingがあれば修正、Implementへ戻る
Escalation
予算超過・判断不足は人間へ戻す
Human boundary
mergeは人間が判断
DESIGN PRINCIPLES
LLMを信用しないことで、LLMを使い切る
stateをprocessに閉じない
実行履歴と成果物をjournal、branch、change folderへ残し、停止後も同じstateから再開します。
merge判断は人間に残す
PipelineがPull Requestを作成した後も、差分とchecksを人間が確認してmergeします。
GET STARTED
最初の1件をCLIで通す
- 01
初期化する
install、init、login、doctorを実行します。
- 02
requestを書く
要件、スコープ外、受け入れ基準をrequest.mdへ記述します。
- 03
Pipelineを実行する
runのresult contractを保存し、停止時は状態を確認してresumeします。
- 04
PRを確認して閉じる
差分とchecksを確認し、merge後にjobをarchiveします。
EXTEND
制御点を保ったまま拡張する
実行プロファイル
standard、fast、design-onlyからPipelineを選択。
Rules
既存stepへrepository固有の規律を追加。
Custom reviewers
独立したreview lensをcode-review後へ追加。
Resume
escalationや失敗の状態を確認し、同じjobを再開。
TRUST BOUNDARY
信頼境界を明示して使う
request.mdとcommit historyはagentへ渡るtrusted inputです。Pipeline完走はmerge承認を意味しません。GitHub Issue連携は基本フローではなく、承認と人間の対応を伴う運用オプションです。
安全性と保証を読むSTART SMALL
小さなrequestから始める
まずは境界と検証方法が明確な変更を1件通し、実行結果と運用手順を確認します。