spec-runner 1.2.0 → 1.3.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 +17 -10
- package/package.json +1 -1
- package/spec-runner/templates/.claude/rules/coding.md +13 -1
- package/spec-runner/templates/.claude/skills/architecture-skill-development/SKILL.md +4 -2
- package/spec-runner/templates/.github/instructions/coding.instructions.md +13 -1
- package/spec-runner/templates/.github/skills/architecture-skill-development/SKILL.md +4 -2
package/README.md
CHANGED
|
@@ -1,8 +1,12 @@
|
|
|
1
1
|
# spec-runner
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
AI は設計を飛ばして実装に走る。`docs/` があっても読まないし、仕様が曖昧なまま動くコードを返す。
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
`spec-runner` はそれを防ぐ。**`docs/` を正本にした開発フロー**を AI に守らせるための rules / agents / skills を、**Claude Code（`.claude/`）** と **GitHub Copilot（`.github/`）** にインストーラ一発で配る。
|
|
6
|
+
|
|
7
|
+
フローは `要件定義 → 概要設計 → 詳細設計 → TDD → 実装`。AI はこの順序で docs を読み書きしながら進み、設計なしに実装フェーズへ進めない。
|
|
8
|
+
|
|
9
|
+
インストール後は `architecture-skill-development` を使ってプロジェクトのアーキテクチャを定義し、そこから **プロジェクト専用 skill** を生やす。汎用 skill はその土台にすぎない。
|
|
6
10
|
|
|
7
11
|
## インストール
|
|
8
12
|
|
|
@@ -42,15 +46,22 @@ curl -sSL https://raw.githubusercontent.com/TEEE88/spec-runner/main/install.sh |
|
|
|
42
46
|
|
|
43
47
|
### 同梱するベース skill
|
|
44
48
|
|
|
49
|
+
**セットアップ用**（プロジェクト初期に使い、完了後はアーカイブする）
|
|
50
|
+
|
|
45
51
|
- `architecture-definition`: 新規プロジェクトで docs と architecture contract を起こす
|
|
46
52
|
- `existing-project-to-docs`: 既存コードから docs の draft と構造化情報を起こす
|
|
47
53
|
- `architecture-skill-development`: architecture contract から project 専用 skill を育てる
|
|
48
|
-
- `
|
|
49
|
-
- `
|
|
54
|
+
- `docs-driven-seed`: DDD 向けの project 専用 skill の種（`style: ddd` のとき）
|
|
55
|
+
- `simple-seed`: レイヤードアーキテクチャ向けの project 専用 skill の種（`style: layered` のとき）
|
|
56
|
+
|
|
57
|
+
**開発ループ用**（日常的に使う）
|
|
58
|
+
|
|
59
|
+
- `design-change`: 変更要求に対して影響調査 → ADR → 設計修正 → TDD で進める
|
|
50
60
|
- `test-driven-development`: アプリケーションコード向けの TDD を徹底する
|
|
51
61
|
- `harness-engineering`: rules / agents / skills / templates 自体を改善する
|
|
62
|
+
- `commit`: コミットメッセージの生成とコミット実行
|
|
52
63
|
|
|
53
|
-
`docs/`
|
|
64
|
+
`docs/` の中身は、導入後にこれらの skill を使ってプロジェクトごとに作る。
|
|
54
65
|
|
|
55
66
|
## 推奨フロー
|
|
56
67
|
|
|
@@ -87,13 +98,9 @@ SPEC_RUNNER_FORCE=1 npx spec-runner
|
|
|
87
98
|
- `spec-runner/templates/.claude/`
|
|
88
99
|
- `spec-runner/templates/.github/`
|
|
89
100
|
|
|
90
|
-
### 構想メモ
|
|
91
|
-
|
|
92
|
-
- `docs/ハーネスエンジニアリング構想.md`
|
|
93
|
-
|
|
94
101
|
## バージョン運用ルール
|
|
95
102
|
|
|
96
|
-
-
|
|
103
|
+
- **開発のたびに `package.json` の `version` を更新してからコミットする**
|
|
97
104
|
- バージョンは原則 SemVer に従い、迷う場合はパッチを 1 つ上げる
|
|
98
105
|
|
|
99
106
|
## ライセンス
|
package/package.json
CHANGED
|
@@ -24,10 +24,22 @@ paths: ["src/**", "tests/**"]
|
|
|
24
24
|
|
|
25
25
|
## コメント
|
|
26
26
|
|
|
27
|
+
### 原則（全プロジェクト共通）
|
|
28
|
+
|
|
27
29
|
- **言語**: 日本語
|
|
28
|
-
- **インラインコメント**: ビジネスロジックの「なぜ」を説明する場合のみ。処理内容の「何」は書かない
|
|
29
30
|
- **変更履歴コメント禁止**: 変更経緯はコードに書かない。git の commit message で管理する
|
|
30
31
|
|
|
32
|
+
### プロジェクト固有の決定事項
|
|
33
|
+
|
|
34
|
+
> `architecture-skill-development` で以下をチームで合意し、`<...>` を書き換える。
|
|
35
|
+
|
|
36
|
+
- **インラインコメント（なぜ）**: `<ビジネスロジックの判断理由は必ず書く / 任意>`
|
|
37
|
+
- **処理ブロックのコメント（何）**: `<禁止（命名で表現する） / 複雑なフローに限り許可>`
|
|
38
|
+
- **ファイル / モジュールレベルのコメント**: `<必須 / 任意 / 不要>`
|
|
39
|
+
- **関数・クラスの docコメント**: `<常に必須 / 公開 API のみ / 複雑なものだけ / 不要>`
|
|
40
|
+
- **TODO / FIXME マーカー**: `<許可する（課題管理ツールの番号を添える） / 禁止>`
|
|
41
|
+
- **セクション区切りコメント**: `<許可する場合はフォーマットを記載 / 禁止>`
|
|
42
|
+
|
|
31
43
|
## 言語・型固有ルール
|
|
32
44
|
|
|
33
45
|
> このセクションを言語・フレームワークに合わせて書き換える。
|
|
@@ -109,8 +109,10 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
|
|
|
109
109
|
`architecture.yaml` の `language` と `folder_structure` を参照して、以下を実際の値に置き換える。
|
|
110
110
|
|
|
111
111
|
1. **命名規則**: 言語の慣習に合わせてテーブルの規則・例を書き換える
|
|
112
|
-
2.
|
|
113
|
-
|
|
112
|
+
2. **コメント規約**: `## コメント` の「プロジェクト固有の決定事項」をユーザーと合意してから書き換える
|
|
113
|
+
- インラインコメント（なぜ）・処理ブロック（何）・docコメント・TODO/FIXME・セクション区切りの各方針を決定する
|
|
114
|
+
3. **言語・型固有ルール**: `<your-language-and-type-rules>` を言語・フレームワークに合わせた具体的なルールに書き換える
|
|
115
|
+
4. **プロジェクト構造**: `<your-project-structure>` を `folder_structure` の実際のディレクトリ構成に書き換える
|
|
114
116
|
|
|
115
117
|
上記の `integrations` ルールに従って反映する。
|
|
116
118
|
|
|
@@ -23,10 +23,22 @@ applyTo: "src/**,tests/**"
|
|
|
23
23
|
|
|
24
24
|
## コメント
|
|
25
25
|
|
|
26
|
+
### 原則（全プロジェクト共通）
|
|
27
|
+
|
|
26
28
|
- **言語**: 日本語
|
|
27
|
-
- **インラインコメント**: ビジネスロジックの「なぜ」を説明する場合のみ。処理内容の「何」は書かない
|
|
28
29
|
- **変更履歴コメント禁止**: 変更経緯はコードに書かない。git の commit message で管理する
|
|
29
30
|
|
|
31
|
+
### プロジェクト固有の決定事項
|
|
32
|
+
|
|
33
|
+
> `architecture-skill-development` で以下をチームで合意し、`<...>` を書き換える。
|
|
34
|
+
|
|
35
|
+
- **インラインコメント（なぜ）**: `<ビジネスロジックの判断理由は必ず書く / 任意>`
|
|
36
|
+
- **処理ブロックのコメント（何）**: `<禁止（命名で表現する） / 複雑なフローに限り許可>`
|
|
37
|
+
- **ファイル / モジュールレベルのコメント**: `<必須 / 任意 / 不要>`
|
|
38
|
+
- **関数・クラスの docコメント**: `<常に必須 / 公開 API のみ / 複雑なものだけ / 不要>`
|
|
39
|
+
- **TODO / FIXME マーカー**: `<許可する（課題管理ツールの番号を添える） / 禁止>`
|
|
40
|
+
- **セクション区切りコメント**: `<許可する場合はフォーマットを記載 / 禁止>`
|
|
41
|
+
|
|
30
42
|
## 言語・型固有ルール
|
|
31
43
|
|
|
32
44
|
> このセクションを言語・フレームワークに合わせて書き換える。
|
|
@@ -109,8 +109,10 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
|
|
|
109
109
|
`architecture.yaml` の `language` と `folder_structure` を参照して、以下を実際の値に置き換える。
|
|
110
110
|
|
|
111
111
|
1. **命名規則**: 言語の慣習に合わせてテーブルの規則・例を書き換える
|
|
112
|
-
2.
|
|
113
|
-
|
|
112
|
+
2. **コメント規約**: `## コメント` の「プロジェクト固有の決定事項」をユーザーと合意してから書き換える
|
|
113
|
+
- インラインコメント（なぜ）・処理ブロック（何）・docコメント・TODO/FIXME・セクション区切りの各方針を決定する
|
|
114
|
+
3. **言語・型固有ルール**: `<your-language-and-type-rules>` を言語・フレームワークに合わせた具体的なルールに書き換える
|
|
115
|
+
4. **プロジェクト構造**: `<your-project-structure>` を `folder_structure` の実際のディレクトリ構成に書き換える
|
|
114
116
|
|
|
115
117
|
上記の `integrations` ルールに従って反映する。
|
|
116
118
|
|