lathe-cli 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +118 -0
- package/bin/_lathe-lib.sh +38 -0
- package/bin/check-deps.sh +42 -0
- package/bin/lathe +51 -0
- package/bin/lathe-init +101 -0
- package/bin/lathe-meta +14 -0
- package/bin/lathe-process +88 -0
- package/bin/lathe-sync +20 -0
- package/bin/lathe-target +14 -0
- package/package.json +35 -0
- package/template/develop/bin/sync.sh +50 -0
- package/template/develop/harness/CLAUDE.md +134 -0
- package/template/develop/harness/agents/coder.md +145 -0
- package/template/develop/harness/agents/reviewer.md +155 -0
- package/template/develop/harness/hooks/commit-runs.sh +47 -0
- package/template/develop/harness/hooks/copy_transcript.sh +93 -0
- package/template/develop/harness/hooks/log.sh +53 -0
- package/template/develop/harness/plan_template.html +146 -0
- package/template/develop/harness/settings.json +47 -0
- package/template/develop/harness/skills/planning/SKILL.md +83 -0
- package/template/develop/harness/workflow/default.yaml +205 -0
- package/template/git-hooks/post-merge +21 -0
- package/template/main/README.md +25 -0
- package/template/meta-overlay/improvements/.gitkeep +0 -0
- package/template/meta-overlay/meta/.claude/settings.json +5 -0
- package/template/meta-overlay/meta/.claude/skills/improvement-recording/SKILL.md +92 -0
- package/template/meta-overlay/meta/.claude/skills/log-reading/SKILL.md +134 -0
- package/template/meta-overlay/meta/CLAUDE.md +133 -0
|
@@ -0,0 +1,146 @@
|
|
|
1
|
+
<!DOCTYPE html>
|
|
2
|
+
<html lang="ja">
|
|
3
|
+
<head>
|
|
4
|
+
<meta charset="UTF-8">
|
|
5
|
+
<title>Plan: {{run_id}}</title>
|
|
6
|
+
<script type="module">
|
|
7
|
+
import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs';
|
|
8
|
+
mermaid.initialize({ startOnLoad: true });
|
|
9
|
+
</script>
|
|
10
|
+
<style>
|
|
11
|
+
body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif; max-width: 880px; margin: 2em auto; padding: 0 1em; line-height: 1.6; color: #222; }
|
|
12
|
+
h1 { border-bottom: 2px solid #333; padding-bottom: 0.3em; }
|
|
13
|
+
h2 { border-bottom: 1px solid #ccc; margin-top: 2em; padding-bottom: 0.2em; }
|
|
14
|
+
h3 { margin-top: 1.5em; }
|
|
15
|
+
code { background: #f4f4f4; padding: 0.1em 0.3em; border-radius: 3px; font-size: 0.9em; }
|
|
16
|
+
pre { background: #f8f8f8; padding: 1em; border-radius: 4px; overflow-x: auto; }
|
|
17
|
+
blockquote { border-left: 4px solid #aaa; margin: 1em 0; padding: 0.3em 1em; color: #555; background: #fafafa; }
|
|
18
|
+
table { border-collapse: collapse; width: 100%; margin: 0.5em 0; }
|
|
19
|
+
th, td { border: 1px solid #ccc; padding: 0.5em; text-align: left; vertical-align: top; }
|
|
20
|
+
th { background: #f4f4f4; }
|
|
21
|
+
|
|
22
|
+
.meta { background: #f4f4f4; padding: 1em; border-radius: 4px; font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: 0.88em; }
|
|
23
|
+
.meta div { margin: 0.15em 0; }
|
|
24
|
+
|
|
25
|
+
.status { display: inline-block; padding: 0.15em 0.6em; border-radius: 3px; font-weight: bold; font-size: 0.9em; }
|
|
26
|
+
.status.draft { background: #fff3a3; color: #5a4a00; }
|
|
27
|
+
.status.awaiting_approval { background: #ffd9a8; color: #6a3d00; }
|
|
28
|
+
.status.approved { background: #c8e6c9; color: #1b4d1f; }
|
|
29
|
+
.status.in_progress { background: #b3e0ff; color: #003d66; }
|
|
30
|
+
.status.amended { background: #f8c9d4; color: #5e0018; }
|
|
31
|
+
.status.completed { background: #d0d0d0; color: #333; }
|
|
32
|
+
|
|
33
|
+
.risk { color: #b00; }
|
|
34
|
+
.contract { border: 2px solid #333; padding: 1em 1.2em; margin-top: 2.5em; background: #fcfcfc; }
|
|
35
|
+
.contract h2 { margin-top: 0; border-bottom: 1px solid #555; }
|
|
36
|
+
|
|
37
|
+
.placeholder { color: #888; font-style: italic; }
|
|
38
|
+
</style>
|
|
39
|
+
</head>
|
|
40
|
+
<body>
|
|
41
|
+
|
|
42
|
+
<h1>計画書 / Plan</h1>
|
|
43
|
+
|
|
44
|
+
<div class="meta">
|
|
45
|
+
<div>run_id: <code>{{run_id}}</code></div>
|
|
46
|
+
<div>session_id: <code>{{session_id}}</code></div>
|
|
47
|
+
<div>created_at: {{created_at}}</div>
|
|
48
|
+
<div>workflow_template: <code>{{workflow_template_path}}</code></div>
|
|
49
|
+
<div>status: <span class="status {{status}}">{{status}}</span></div>
|
|
50
|
+
</div>
|
|
51
|
+
|
|
52
|
+
<h2>1. タスク解釈</h2>
|
|
53
|
+
|
|
54
|
+
<h3>1.1 受領した依頼(原文)</h3>
|
|
55
|
+
<blockquote>{{original_request}}</blockquote>
|
|
56
|
+
|
|
57
|
+
<h3>1.2 orchestrator の理解</h3>
|
|
58
|
+
<p>{{interpreted_task}}</p>
|
|
59
|
+
|
|
60
|
+
<h3>1.3 目的・スコープ・前提</h3>
|
|
61
|
+
<table>
|
|
62
|
+
<tr><th>項目</th><th>内容</th></tr>
|
|
63
|
+
<tr><td>目的</td><td>{{goal}}</td></tr>
|
|
64
|
+
<tr><td>スコープ内</td><td>{{in_scope}}</td></tr>
|
|
65
|
+
<tr><td>スコープ外</td><td>{{out_of_scope}}</td></tr>
|
|
66
|
+
<tr><td>前提条件</td><td>{{assumptions}}</td></tr>
|
|
67
|
+
</table>
|
|
68
|
+
|
|
69
|
+
<h2>2. 採用ワークフロー</h2>
|
|
70
|
+
<p>テンプレート: <code>{{workflow_template_path}}</code></p>
|
|
71
|
+
<p><strong>選択理由:</strong> {{workflow_rationale}}</p>
|
|
72
|
+
|
|
73
|
+
<h2>3. 実装計画</h2>
|
|
74
|
+
|
|
75
|
+
<h3>3.1 アーキテクチャ概要</h3>
|
|
76
|
+
<p>{{architecture_summary}}</p>
|
|
77
|
+
|
|
78
|
+
<h3>3.2 構造図</h3>
|
|
79
|
+
<pre class="mermaid">
|
|
80
|
+
{{architecture_diagram}}
|
|
81
|
+
</pre>
|
|
82
|
+
|
|
83
|
+
<h3>3.3 主要な変更</h3>
|
|
84
|
+
<table>
|
|
85
|
+
<tr><th>パス</th><th>種別</th><th>内容</th></tr>
|
|
86
|
+
{{change_rows}}
|
|
87
|
+
</table>
|
|
88
|
+
|
|
89
|
+
<h2>4. 役割分担</h2>
|
|
90
|
+
<table>
|
|
91
|
+
<tr><th>Agent</th><th>担当</th><th>非担当(誤解防止)</th></tr>
|
|
92
|
+
<tr><td>coder</td><td>{{coder_responsibilities}}</td><td>{{coder_non_responsibilities}}</td></tr>
|
|
93
|
+
<tr><td>reviewer</td><td>{{reviewer_responsibilities}}</td><td>{{reviewer_non_responsibilities}}</td></tr>
|
|
94
|
+
</table>
|
|
95
|
+
|
|
96
|
+
<h2>5. 成果物 / Deliverables</h2>
|
|
97
|
+
<ul>
|
|
98
|
+
{{deliverables}}
|
|
99
|
+
</ul>
|
|
100
|
+
|
|
101
|
+
<h2>6. 受入条件 / Acceptance Criteria</h2>
|
|
102
|
+
<table>
|
|
103
|
+
<tr><th>ID</th><th>条件</th><th>検証手段</th></tr>
|
|
104
|
+
{{acceptance_rows}}
|
|
105
|
+
</table>
|
|
106
|
+
|
|
107
|
+
<h2>7. リスク・未解決の質問</h2>
|
|
108
|
+
<p class="placeholder">空にできない場合、status は draft のまま、phase=contract に進まないこと。</p>
|
|
109
|
+
<ul>
|
|
110
|
+
{{open_questions}}
|
|
111
|
+
</ul>
|
|
112
|
+
|
|
113
|
+
<h2>8. 実行フロー</h2>
|
|
114
|
+
<pre class="mermaid">
|
|
115
|
+
{{execution_flow_diagram}}
|
|
116
|
+
</pre>
|
|
117
|
+
|
|
118
|
+
<div class="contract">
|
|
119
|
+
<h2>契約セクション</h2>
|
|
120
|
+
<p>本計画書は orchestrator と human の合意である。承認された内容からの逸脱には再承認を要する。</p>
|
|
121
|
+
|
|
122
|
+
<table>
|
|
123
|
+
<tr><th>項目</th><th>記録</th></tr>
|
|
124
|
+
<tr><td>提出日時</td><td>{{submitted_at}}</td></tr>
|
|
125
|
+
<tr><td>承認日時</td><td>{{approved_at}}</td></tr>
|
|
126
|
+
<tr><td>承認者</td><td>{{approver}}</td></tr>
|
|
127
|
+
<tr><td>完了日時</td><td>{{completed_at}}</td></tr>
|
|
128
|
+
<tr><td>状態</td><td><span class="status {{status}}">{{status}}</span></td></tr>
|
|
129
|
+
</table>
|
|
130
|
+
|
|
131
|
+
<h3>修正履歴</h3>
|
|
132
|
+
<p class="placeholder">append-only。古い記述を消さない。逸脱が起きた場合は何を、なぜ変えたかを記録する。</p>
|
|
133
|
+
<ol>
|
|
134
|
+
{{revision_history}}
|
|
135
|
+
</ol>
|
|
136
|
+
|
|
137
|
+
<h3>承認に伴う合意事項</h3>
|
|
138
|
+
<ul>
|
|
139
|
+
<li>本計画書 3.3 に記載されたファイル以外を変更しない</li>
|
|
140
|
+
<li>本計画書 6 の受入条件を全て満たすことをもって完了とする</li>
|
|
141
|
+
<li>逸脱が必要な場合は status を amended に戻し再承認を得る</li>
|
|
142
|
+
</ul>
|
|
143
|
+
</div>
|
|
144
|
+
|
|
145
|
+
</body>
|
|
146
|
+
</html>
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
{
|
|
2
|
+
"env": {
|
|
3
|
+
"CLAUDE_CODE_DISABLE_AUTO_MEMORY": "1"
|
|
4
|
+
},
|
|
5
|
+
"hooks": {
|
|
6
|
+
"SessionStart": [
|
|
7
|
+
{ "hooks": [{ "type": "command", "command": "hooks/log.sh SessionStart" }] }
|
|
8
|
+
],
|
|
9
|
+
"UserPromptSubmit": [
|
|
10
|
+
{ "hooks": [{ "type": "command", "command": "hooks/log.sh UserPromptSubmit" }] }
|
|
11
|
+
],
|
|
12
|
+
"PreToolUse": [
|
|
13
|
+
{ "hooks": [{ "type": "command", "command": "hooks/log.sh PreToolUse" }] }
|
|
14
|
+
],
|
|
15
|
+
"PostToolUse": [
|
|
16
|
+
{ "hooks": [{ "type": "command", "command": "hooks/log.sh PostToolUse" }] }
|
|
17
|
+
],
|
|
18
|
+
"SubagentStart": [
|
|
19
|
+
{ "hooks": [{ "type": "command", "command": "hooks/log.sh SubagentStart" }] }
|
|
20
|
+
],
|
|
21
|
+
"SubagentStop": [
|
|
22
|
+
{
|
|
23
|
+
"hooks": [
|
|
24
|
+
{ "type": "command", "command": "hooks/log.sh SubagentStop" },
|
|
25
|
+
{ "type": "command", "command": "hooks/copy_transcript.sh" }
|
|
26
|
+
]
|
|
27
|
+
}
|
|
28
|
+
],
|
|
29
|
+
"PreCompact": [
|
|
30
|
+
{
|
|
31
|
+
"hooks": [
|
|
32
|
+
{ "type": "command", "command": "hooks/log.sh PreCompact" },
|
|
33
|
+
{ "type": "command", "command": "hooks/copy_transcript.sh" }
|
|
34
|
+
]
|
|
35
|
+
}
|
|
36
|
+
],
|
|
37
|
+
"Stop": [
|
|
38
|
+
{
|
|
39
|
+
"hooks": [
|
|
40
|
+
{ "type": "command", "command": "hooks/log.sh Stop" },
|
|
41
|
+
{ "type": "command", "command": "hooks/copy_transcript.sh" },
|
|
42
|
+
{ "type": "command", "command": "hooks/commit-runs.sh" }
|
|
43
|
+
]
|
|
44
|
+
}
|
|
45
|
+
]
|
|
46
|
+
}
|
|
47
|
+
}
|
|
@@ -0,0 +1,83 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: planning
|
|
3
|
+
description: タスク受領時に計画書HTMLを起草・保存する手順。plan_template.html を雛形として用い、`plans/<run_id>.html` に出力する。計画書は人間との契約書として機能するため、合意可能な粒度・検証可能な受入条件・図を含むこと。
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# planning
|
|
7
|
+
|
|
8
|
+
## いつ使うか
|
|
9
|
+
新しいタスクを受領した直後、coder/reviewer に dispatch する前。計画から逸脱して再承認が要る場合の改訂時にも使う。
|
|
10
|
+
|
|
11
|
+
## 出力先と run_id
|
|
12
|
+
- 雛形：`plan_template.html`
|
|
13
|
+
- 出力：`plans/<run_id>.html`
|
|
14
|
+
- run_id 命名（**例外なし**）：`YYYYMMDD-HHMMSS-<short_slug>`
|
|
15
|
+
- timestamp 部は `date -u +%Y%m%d-%H%M%S` で必ず取得した実時刻。手書き禁止
|
|
16
|
+
- slug はタスクの主題を 3-5 単語、ケバブケース、英数字とハイフンのみ
|
|
17
|
+
- 例（OK）：`20260510-143022-add-login` / `20260511-094501-fix-cors-bug`
|
|
18
|
+
- 例（**禁止**）：`add-login.html` / `task-001.html` / `wc-cli.html` / `<slug>-<n>.html` 等、timestamp が無いもの
|
|
19
|
+
- 改訂時：同じ run_id のファイルを上書きし、契約セクションの「修正履歴」に追記
|
|
20
|
+
- 計画書を書き始める前に必ず `date -u +%Y%m%d-%H%M%S` を Bash で取得し、その値を timestamp 部に使う。これは workflow の出発点で行う最初の操作です
|
|
21
|
+
|
|
22
|
+
## 雛形の使い方
|
|
23
|
+
雛形は `{{...}}` プレースホルダを含む。これを全て埋める。空欄を残さない。書くことがない欄は「該当なし」と明記する（沈黙しない）。
|
|
24
|
+
|
|
25
|
+
## セクションごとの埋め方
|
|
26
|
+
|
|
27
|
+
### 1. タスク解釈
|
|
28
|
+
雛形では 1.1 / 1.2 / 1.3 に分かれている。
|
|
29
|
+
- **1.1 受領した依頼（原文）**：原文をそのまま引用。改変しない
|
|
30
|
+
- **1.2 orchestrator の理解**：自分の言葉で言い直す。原文をなぞるのではなく、目的・スコープ・前提を解きほぐす。言い直しが原文より短くなったら情報を落としすぎている
|
|
31
|
+
- **1.3 目的・スコープ・前提**：表を埋める。「スコープ内」「スコープ外」を両方書く（境界の合意が後の逸脱判定の基準になる）。前提条件は「これが崩れたら計画が崩れる」事項を列挙
|
|
32
|
+
|
|
33
|
+
### 2. 採用ワークフロー
|
|
34
|
+
- `workflow/` から1つ選ぶ（YAML ファイル）
|
|
35
|
+
- 「なぜこのテンプレートか」を必ず書く。デフォルト（`workflow/default.yaml`）を選ぶときも理由を書く
|
|
36
|
+
|
|
37
|
+
### 3. 実装計画
|
|
38
|
+
- **3.1 概要**：文章で全体像
|
|
39
|
+
- **3.2 構造図**：Mermaid（`flowchart` `classDiagram` `sequenceDiagram` から適切なもの）。図なしは認めない
|
|
40
|
+
- **3.3 主要な変更**：追加・変更・削除されるファイルを明示
|
|
41
|
+
|
|
42
|
+
### 4. 役割分担
|
|
43
|
+
雛形は3列：Agent / 担当 / 非担当（誤解防止）。
|
|
44
|
+
- 「担当」と「非担当」の両方を埋める。非担当を明記することで scope creep を防ぐ
|
|
45
|
+
- 「coder：実装全般、reviewer：レビュー全般」のような曖昧記述を禁止する
|
|
46
|
+
- 「全部やらせる」は禁止。分担を明確にする
|
|
47
|
+
|
|
48
|
+
### 5. 成果物
|
|
49
|
+
- 完了時に存在しているべき具体物（ファイル・機能・ドキュメント）
|
|
50
|
+
|
|
51
|
+
### 6. 受入条件
|
|
52
|
+
- **検証可能な形で書く**。「動くこと」ではなく「`pnpm test` が緑になる」「`/login` で email/password を送ると 200 が返り `/dashboard` へリダイレクト」のように
|
|
53
|
+
- 検証手段が思い浮かばない条件は曖昧。書き直す
|
|
54
|
+
|
|
55
|
+
### 7. リスク・未解決の質問
|
|
56
|
+
- 計画段階で曖昧な点があれば全部ここに出す
|
|
57
|
+
- 1つでもあるなら status は `draft` のまま。承認には進まない
|
|
58
|
+
|
|
59
|
+
### 8. 実行フロー
|
|
60
|
+
- Mermaid `sequenceDiagram` で actors（Human, Orchestrator, Coder, Reviewer）と呼び出し順を描く
|
|
61
|
+
- 採用ワークフローと整合していること
|
|
62
|
+
|
|
63
|
+
### 契約セクション
|
|
64
|
+
- 提出日時・承認日時・承認者・完了日時・status を記録
|
|
65
|
+
- 修正履歴は append-only。古い記述を消さない。逸脱が起きた場合は「何を、なぜ変えたか」を記録する
|
|
66
|
+
- 「承認に伴う合意事項」セクションは雛形のまま残す。タスク固有の合意があれば追記する
|
|
67
|
+
|
|
68
|
+
## 図は Mermaid で書く
|
|
69
|
+
将来 PR で人間に渡されることを想定し、GitHub が描画できる Mermaid を使う。画像埋め込みや独自記法は使わない。
|
|
70
|
+
|
|
71
|
+
## status 遷移
|
|
72
|
+
|
|
73
|
+
```
|
|
74
|
+
draft → awaiting_approval → approved → in_progress → completed
|
|
75
|
+
↑ ↓
|
|
76
|
+
amended ←── （逸脱発生時）
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
- 起草中は `draft`
|
|
80
|
+
- 人間に出した時点で `awaiting_approval`
|
|
81
|
+
- 承認を受けたら `approved`、dispatch 開始で `in_progress`
|
|
82
|
+
- 完了で `completed`
|
|
83
|
+
- 実行中に計画変更が必要になったら `amended` に戻し、修正→再承認
|
|
@@ -0,0 +1,205 @@
|
|
|
1
|
+
name: default
|
|
2
|
+
version: 1
|
|
3
|
+
description: >
|
|
4
|
+
レベル1、どのプロジェクトでも使える最低限のワークフロー。
|
|
5
|
+
計画 → 契約 → 実装 → レビュー → 完了 の一直線。
|
|
6
|
+
レビュー結果次第で実装に戻る。
|
|
7
|
+
|
|
8
|
+
adoption_criteria:
|
|
9
|
+
- タスクの粒度が単一の機能追加・バグ修正・小規模リファクタ程度
|
|
10
|
+
- 関係するファイルが少数（目安：10ファイル以下）
|
|
11
|
+
- 既存のテスト/ビルド基盤が機能している
|
|
12
|
+
- 仕様が比較的明確（曖昧点を計画段階で解消可能）
|
|
13
|
+
not_for:
|
|
14
|
+
- 大規模な多段階実装（複数機能同時開発）
|
|
15
|
+
- リサーチを伴うタスク（phase 0 として spike が要る）
|
|
16
|
+
- 複数 reviewer の ensemble（cross-model review）
|
|
17
|
+
- E2E/QA を含むフルスタックタスク
|
|
18
|
+
- インフラ・デプロイを伴うタスク
|
|
19
|
+
|
|
20
|
+
actors:
|
|
21
|
+
human: 依頼者・承認者
|
|
22
|
+
orchestrator: 計画・dispatch・統合（メインの Claude）
|
|
23
|
+
coder: 実装担当 subagent
|
|
24
|
+
reviewer: レビュー担当 subagent
|
|
25
|
+
|
|
26
|
+
phases:
|
|
27
|
+
- id: intake
|
|
28
|
+
order: 1
|
|
29
|
+
actor: orchestrator
|
|
30
|
+
input: human からの依頼文
|
|
31
|
+
output: 解釈メモ（計画書「1. タスク解釈」の下書き）
|
|
32
|
+
success: 依頼を自分の言葉で言い直せる、目的・スコープ・前提が抽出できている
|
|
33
|
+
failure:
|
|
34
|
+
condition: 依頼が曖昧で解釈できない
|
|
35
|
+
action: human に逆質問、次に進まない
|
|
36
|
+
|
|
37
|
+
- id: plan
|
|
38
|
+
order: 2
|
|
39
|
+
actor: orchestrator
|
|
40
|
+
input: 解釈メモ
|
|
41
|
+
output: plans/<run_id>.html (status=draft)
|
|
42
|
+
procedure: planning skill に従う
|
|
43
|
+
success:
|
|
44
|
+
- 計画書の全セクションが埋まっている
|
|
45
|
+
- 構造図と実行フロー図が両方ある
|
|
46
|
+
- 受入条件が全て検証可能な形で書かれている
|
|
47
|
+
- リスク・未解決の質問が洗い出されている
|
|
48
|
+
failure:
|
|
49
|
+
condition: 未解決の質問が空にならない
|
|
50
|
+
action: phase 3 に進まず human に質問
|
|
51
|
+
|
|
52
|
+
- id: contract
|
|
53
|
+
order: 3
|
|
54
|
+
actor: [orchestrator, human]
|
|
55
|
+
input: 計画書 (draft)
|
|
56
|
+
output: 計画書 (approved)
|
|
57
|
+
procedure: |
|
|
58
|
+
1. 計画書 status を awaiting_approval に変更
|
|
59
|
+
2. human に提示（path を伝える）
|
|
60
|
+
3. human の応答により分岐：
|
|
61
|
+
- 承認: status=approved、承認日時・承認者を記録
|
|
62
|
+
- 修正要求: status=draft に戻し、修正履歴に記録、phase=plan に戻る
|
|
63
|
+
- 却下: タスク終了
|
|
64
|
+
success: status = approved
|
|
65
|
+
failure:
|
|
66
|
+
condition: 承認得られず
|
|
67
|
+
action: タスク終了 or 計画見直し
|
|
68
|
+
|
|
69
|
+
- id: implement
|
|
70
|
+
order: 4
|
|
71
|
+
actor: coder
|
|
72
|
+
input:
|
|
73
|
+
- 計画書HTMLのパス
|
|
74
|
+
- 実装スコープ（計画書 3.3 全体、または分割した一部）
|
|
75
|
+
- 関連受入条件
|
|
76
|
+
output: coder report
|
|
77
|
+
procedure: |
|
|
78
|
+
1. orchestrator は計画書 status を in_progress に変更
|
|
79
|
+
2. coder を Task tool で起動、最小限の context で dispatch
|
|
80
|
+
3. coder report を受領
|
|
81
|
+
success: coder report の status = success
|
|
82
|
+
failure:
|
|
83
|
+
- condition: status = partial
|
|
84
|
+
action: 不足分を特定、追加 dispatch（最大1回）
|
|
85
|
+
- condition: status = failed
|
|
86
|
+
action: phase=review に進まず escalate（implementation_failed）
|
|
87
|
+
|
|
88
|
+
- id: review
|
|
89
|
+
order: 5
|
|
90
|
+
actor: reviewer
|
|
91
|
+
input:
|
|
92
|
+
- 計画書HTMLのパス
|
|
93
|
+
- coder report
|
|
94
|
+
- 変更ファイル一覧
|
|
95
|
+
output: reviewer report
|
|
96
|
+
procedure: |
|
|
97
|
+
1. reviewer を Task tool で起動
|
|
98
|
+
2. reviewer report を受領
|
|
99
|
+
success: report が返ってくる（verdict は次 phase で判定）
|
|
100
|
+
failure:
|
|
101
|
+
condition: reviewer が検証不能（コマンド不明・環境不備）
|
|
102
|
+
action: orchestrator が補助情報を渡して再 dispatch、または human escalate
|
|
103
|
+
|
|
104
|
+
- id: decide
|
|
105
|
+
order: 6
|
|
106
|
+
actor: orchestrator
|
|
107
|
+
input: reviewer report
|
|
108
|
+
output: 次の遷移先
|
|
109
|
+
transitions:
|
|
110
|
+
- verdict: approve
|
|
111
|
+
next: close
|
|
112
|
+
- verdict: request_changes
|
|
113
|
+
next: iterate
|
|
114
|
+
- verdict: block
|
|
115
|
+
next: iterate
|
|
116
|
+
condition: blockが初回
|
|
117
|
+
- verdict: block
|
|
118
|
+
next: escalate
|
|
119
|
+
condition: blockが2回目以降
|
|
120
|
+
reason: review_block_persistent
|
|
121
|
+
|
|
122
|
+
- id: iterate
|
|
123
|
+
order: 7
|
|
124
|
+
actor: [orchestrator, coder]
|
|
125
|
+
input: reviewer findings
|
|
126
|
+
output: 修正された実装
|
|
127
|
+
procedure: |
|
|
128
|
+
1. findings を coder dispatch 用に整形（blocker/major のみ。minor/nit は次回機会へ）
|
|
129
|
+
2. coder を再起動、findings を渡す
|
|
130
|
+
3. 完了後 phase=review に戻る
|
|
131
|
+
success: 修正完了し review に戻れる
|
|
132
|
+
failure:
|
|
133
|
+
condition: iteration_count > limits.max_iterations
|
|
134
|
+
action: escalate (repeated_failure)
|
|
135
|
+
|
|
136
|
+
- id: close
|
|
137
|
+
order: 8
|
|
138
|
+
actor: orchestrator
|
|
139
|
+
input: approve された実装と reviewer report
|
|
140
|
+
output:
|
|
141
|
+
- 計画書 status を completed に更新
|
|
142
|
+
- human への完了報告
|
|
143
|
+
completion_report_includes:
|
|
144
|
+
- run_id
|
|
145
|
+
- 計画書HTMLへのリンク
|
|
146
|
+
- 変更ファイル一覧
|
|
147
|
+
- 受入条件の最終ステータス
|
|
148
|
+
- reviewer の positive_notes 抜粋
|
|
149
|
+
- 次回への申し送り（minor/nit で残したもの）
|
|
150
|
+
|
|
151
|
+
flow:
|
|
152
|
+
start: intake
|
|
153
|
+
default_path: [intake, plan, contract, implement, review, decide, close]
|
|
154
|
+
back_edges:
|
|
155
|
+
- from: contract
|
|
156
|
+
to: plan
|
|
157
|
+
when: 修正要求
|
|
158
|
+
- from: decide
|
|
159
|
+
to: iterate
|
|
160
|
+
when: verdict in [request_changes, block]
|
|
161
|
+
- from: iterate
|
|
162
|
+
to: review
|
|
163
|
+
when: 修正完了
|
|
164
|
+
|
|
165
|
+
limits:
|
|
166
|
+
max_iterations: 3 # phase 4-7 のループ上限
|
|
167
|
+
partial_retry_max: 1 # phase 4 で partial の追加 dispatch 上限
|
|
168
|
+
|
|
169
|
+
escalation:
|
|
170
|
+
triggers:
|
|
171
|
+
- phase: intake
|
|
172
|
+
condition: 解釈不能
|
|
173
|
+
reason: spec_unclear
|
|
174
|
+
payload: [依頼文, 自分の解釈の限界]
|
|
175
|
+
- phase: plan
|
|
176
|
+
condition: 未解決質問が空にならない
|
|
177
|
+
reason: spec_ambiguous
|
|
178
|
+
payload: [質問リスト, 選択肢]
|
|
179
|
+
- phase: implement
|
|
180
|
+
condition: coder status=failed
|
|
181
|
+
reason: implementation_failed
|
|
182
|
+
payload: [coder report 最終出力]
|
|
183
|
+
- phase: iterate
|
|
184
|
+
condition: iteration_count > max_iterations
|
|
185
|
+
reason: repeated_failure
|
|
186
|
+
payload: [全 reviewer report の差分, 試行履歴]
|
|
187
|
+
- phase: decide
|
|
188
|
+
condition: block が2回連続
|
|
189
|
+
reason: review_block_persistent
|
|
190
|
+
payload: [block findings, 実装履歴]
|
|
191
|
+
- phase: any
|
|
192
|
+
condition: 予算超過
|
|
193
|
+
reason: budget_exceeded
|
|
194
|
+
payload: [これまでの成果, 続行/打切判断]
|
|
195
|
+
|
|
196
|
+
deviation_policy: |
|
|
197
|
+
任意の phase で計画書の内容を変更する必要が生じた場合：
|
|
198
|
+
1. phase を中断
|
|
199
|
+
2. 計画書 status を amended に変更
|
|
200
|
+
3. 修正履歴に「何を、なぜ変えるか」を記録
|
|
201
|
+
4. phase=contract に戻り再承認を得る
|
|
202
|
+
5. 承認後、中断していた phase から再開
|
|
203
|
+
|
|
204
|
+
逸脱しても計画書を更新しないのは契約違反。
|
|
205
|
+
orchestrator が最も避けるべき失敗。
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# post-merge — auto-run sync.sh after a merge into develop.
|
|
3
|
+
#
|
|
4
|
+
# Lathe stores harness/ as the source of truth on develop. Whenever a meta PR
|
|
5
|
+
# (or any other change) lands on develop, target/.claude/ needs to be regenerated.
|
|
6
|
+
# This hook does that locally for the worktree where the merge happened.
|
|
7
|
+
#
|
|
8
|
+
# UI-side merges (GitHub web) do NOT fire this. Run `lathe sync` manually after
|
|
9
|
+
# `git pull` in those cases.
|
|
10
|
+
|
|
11
|
+
set -uo pipefail
|
|
12
|
+
|
|
13
|
+
BRANCH="$(git symbolic-ref --short HEAD 2>/dev/null || true)"
|
|
14
|
+
[ "$BRANCH" = "develop" ] || exit 0
|
|
15
|
+
|
|
16
|
+
REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null)" || exit 0
|
|
17
|
+
SYNC="$REPO_ROOT/bin/sync.sh"
|
|
18
|
+
[ -x "$SYNC" ] || exit 0
|
|
19
|
+
|
|
20
|
+
echo "[lathe post-merge] running sync.sh on develop..."
|
|
21
|
+
"$SYNC"
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# {{project_name}}
|
|
2
|
+
|
|
3
|
+
This is the main worktree. Your application code lives here.
|
|
4
|
+
|
|
5
|
+
## Layout
|
|
6
|
+
|
|
7
|
+
This project was initialized with [Lathe](https://github.com/yutaro0915/Lathe). The
|
|
8
|
+
project root contains three sibling worktrees backed by a shared bare git repo:
|
|
9
|
+
|
|
10
|
+
- `main/` — this worktree, your app code
|
|
11
|
+
- `develop/` — target agent's harness lives here, runs/ are auto-committed
|
|
12
|
+
- `meta/` — meta agent improves the harness from runs/
|
|
13
|
+
|
|
14
|
+
## Typical workflow
|
|
15
|
+
|
|
16
|
+
```sh
|
|
17
|
+
# in main/, vibe code on a feature branch
|
|
18
|
+
git checkout -b feature/X # base off main (or develop, your call)
|
|
19
|
+
# ... edit code ...
|
|
20
|
+
git add . && git commit
|
|
21
|
+
git push -u origin feature/X
|
|
22
|
+
gh pr create --base develop # PR to develop where target processes
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
See the project root's README or `lathe help` for more.
|
|
File without changes
|
|
@@ -0,0 +1,92 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: improvement-recording
|
|
3
|
+
description: target harness に加えた改善を improvements/<id>/ に記録する。summary.md(何を、なぜ、何を根拠に)と changes.patch(git diff)の書き方を扱う。target に変更を加える際に参照する。
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# improvement-recording
|
|
7
|
+
|
|
8
|
+
## 何を記録するか
|
|
9
|
+
|
|
10
|
+
target に変更を加えたら、そのたびに `improvements/<id>/` を作る。記録の目的は、後から人間(自分自身を含む)が「いつ・何を・なぜ変えたか」を辿れるようにすること。
|
|
11
|
+
|
|
12
|
+
軽微な変更でも記録する。記録するコストが高ければ「軽微なら飛ばす」判断が紛れ込み、振り返りが効かなくなる。
|
|
13
|
+
|
|
14
|
+
## id の付け方
|
|
15
|
+
|
|
16
|
+
`YYYYMMDD-HHMMSS-<slug>`
|
|
17
|
+
|
|
18
|
+
slug は変更の主題を 3-5 単語、ケバブケース、英数字とハイフンのみ。例：
|
|
19
|
+
|
|
20
|
+
- `20260511-093015-tighten-planning-skill`
|
|
21
|
+
- `20260511-110422-add-deviation-check-hook`
|
|
22
|
+
|
|
23
|
+
## 配置
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
improvements/<id>/
|
|
27
|
+
├── summary.md
|
|
28
|
+
└── changes.patch
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
必要なら補足ファイルを足してよい(観察メモ、参照ログの抜粋など)。固定スキーマではない。
|
|
32
|
+
|
|
33
|
+
## summary.md に書くこと
|
|
34
|
+
|
|
35
|
+
最低限、次が読み取れるように書く：
|
|
36
|
+
|
|
37
|
+
- **何を変えたか** — 触ったファイル、変更の要旨
|
|
38
|
+
- **なぜ変えたか** — どのログから何を観察し、どう解釈したか
|
|
39
|
+
- **何を期待しているか** — 適用後に何が改善されるか(観察可能な形で)
|
|
40
|
+
- **副作用の可能性** — 思いつくリスク、想定していない動作
|
|
41
|
+
|
|
42
|
+
形式は決めない。短い変更なら数行で済むし、込み入った変更なら長くなる。テンプレートに従うことより、後から読んで理解できることを優先する。
|
|
43
|
+
|
|
44
|
+
参考に、軽い変更の例：
|
|
45
|
+
|
|
46
|
+
```markdown
|
|
47
|
+
# planning skill のチェックリスト削除
|
|
48
|
+
|
|
49
|
+
## 何を
|
|
50
|
+
.claude/skills/planning/SKILL.md の末尾「良い計画書のチェック」と「ありがちなミス」を削除。
|
|
51
|
+
|
|
52
|
+
## なぜ
|
|
53
|
+
runs/20260511-* を 5 件読んだところ、orchestrator が計画書を起草する段階で、本文と末尾チェックリストを両方参照して context が長くなっていた。チェックリストの内容は本文に重複して書かれており、削っても情報は失われない。
|
|
54
|
+
|
|
55
|
+
## 期待
|
|
56
|
+
計画書起草時の context 消費が減る。orchestrator がチェックリスト消化を目的化する傾向も減るはず。
|
|
57
|
+
|
|
58
|
+
## リスク
|
|
59
|
+
チェックがないと抜けが出る可能性はある。次の数 run で計画書の質が落ちないか確認する。
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
込み入った変更ならもっと書くし、根拠ログの行番号や session_id を引用する。
|
|
63
|
+
|
|
64
|
+
## changes.patch
|
|
65
|
+
|
|
66
|
+
`git diff` でそのまま生成できる形式。`git apply` で再現可能であること。
|
|
67
|
+
|
|
68
|
+
```bash
|
|
69
|
+
git diff > improvements/<id>/changes.patch
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
複数ファイルにまたがる変更も1つの patch にまとめる。論点が複数あるなら improvement を分ける(1 改善 = 1 論点)。論点が分かれていない束ね patch は、後で「この部分だけ revert」ができなくなる。
|
|
73
|
+
|
|
74
|
+
## 1 改善 1 論点
|
|
75
|
+
|
|
76
|
+
1つの improvement が複数の独立した変更を含むと、後から効果検証ができない。「この変更でうまくいったが、別の変更で悪化した」が混ざる。
|
|
77
|
+
|
|
78
|
+
迷ったら分ける。
|
|
79
|
+
|
|
80
|
+
## 記録のタイミング
|
|
81
|
+
|
|
82
|
+
target に書き込む前に summary.md の下書きを始めてもよいし、書き込んだ後にまとめてもよい。決まった順序はないが、変更が確定したら忘れる前に記録を完成させる。後回しにすると、何を考えていたかが薄れる。
|
|
83
|
+
|
|
84
|
+
## 既存改善の参照
|
|
85
|
+
|
|
86
|
+
過去の improvement を読み返すのは推奨。同じ箇所を繰り返し触っているなら、根本原因を見落としているサインかもしれない。
|
|
87
|
+
|
|
88
|
+
```bash
|
|
89
|
+
ls improvements/
|
|
90
|
+
# 同一ファイルを触った過去 improvement を探す
|
|
91
|
+
grep -l "planning/SKILL.md" improvements/*/summary.md
|
|
92
|
+
```
|