yodogawa 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/.windsurf/templates/documentation-rules.md +143 -0
- package/.windsurf/templates/project/01-requirements/01-system-overview.md +49 -0
- package/.windsurf/templates/project/01-requirements/02-features-implemented.md +73 -0
- package/.windsurf/templates/project/01-requirements/03-features-planned.md +75 -0
- package/.windsurf/templates/project/01-requirements/04-non-functional-requirements.md +115 -0
- package/.windsurf/templates/project/01-requirements/05-user-stories.md +124 -0
- package/.windsurf/templates/project/02-behavior/01-scenarios.md +406 -0
- package/.windsurf/templates/project/03-domain/01-domain-model.md +338 -0
- package/.windsurf/templates/project/03-domain/02-ubiquitous-language.md +153 -0
- package/.windsurf/templates/project/04-design/01-tech-stack.md +360 -0
- package/.windsurf/templates/project/04-design/02-repository-structure.md +390 -0
- package/.windsurf/templates/project/04-design/03-screen-design.md +586 -0
- package/.windsurf/templates/project/04-design/04-data-model.md +211 -0
- package/.windsurf/templates/project/04-design/05-api-spec.md +221 -0
- package/.windsurf/templates/project/04-design/06-architecture.md +183 -0
- package/.windsurf/templates/project/04-design/07-infrastructure.md +180 -0
- package/.windsurf/templates/tasks/task-template/a-definition.md +143 -0
- package/.windsurf/templates/tasks/task-template/b-research.md +185 -0
- package/.windsurf/templates/tasks/task-template/c-implementation.md +197 -0
- package/.windsurf/workflows/a-001-SetupDocStructure.md +165 -0
- package/.windsurf/workflows/a-002-InitializeProject.md +229 -0
- package/.windsurf/workflows/a-003-CreateScenarios.md +130 -0
- package/.windsurf/workflows/a-004-DefineDomainModel.md +133 -0
- package/.windsurf/workflows/a-005-CreateDomainDiagram.md +114 -0
- package/.windsurf/workflows/a-006-ReviewRequirementsDomain.md +132 -0
- package/.windsurf/workflows/a-007-DefineTechStack.md +121 -0
- package/.windsurf/workflows/a-008-DefineRepositoryStructure.md +118 -0
- package/.windsurf/workflows/a-009-DefineScreenDesign.md +121 -0
- package/.windsurf/workflows/a-010-DefineDataModel.md +125 -0
- package/.windsurf/workflows/a-011-DefineAPISpec.md +123 -0
- package/.windsurf/workflows/a-012-DefineArchitecture.md +119 -0
- package/.windsurf/workflows/a-013-DefineInfrastructure.md +120 -0
- package/.windsurf/workflows/a-014-ReviewDesign.md +122 -0
- package/.windsurf/workflows/b-001-CreateTaskDirectory.md +71 -0
- package/.windsurf/workflows/b-002-CreateTaskDefinition.md +165 -0
- package/.windsurf/workflows/b-003-CreateTaskResearch.md +412 -0
- package/.windsurf/workflows/b-004-CreateTaskImplementation.md +97 -0
- package/.windsurf/workflows/b-005-ReviewTask.md +312 -0
- package/.windsurf/workflows/c-001-ImplementTask.md +493 -0
- package/.windsurf/workflows/c-002-UpdateDocumentation.md +797 -0
- package/.windsurf/workflows/x-Accessibility-Check.md +469 -0
- package/.windsurf/workflows/x-Bundle-Optimize.md +386 -0
- package/.windsurf/workflows/x-CI-FixFailure.md +636 -0
- package/.windsurf/workflows/x-CI-Setup.md +641 -0
- package/.windsurf/workflows/x-Code-Refactor.md +71 -0
- package/.windsurf/workflows/x-Code-ResearchAndReview.md +78 -0
- package/.windsurf/workflows/x-Component-Create.md +359 -0
- package/.windsurf/workflows/x-Context-CatchUp.md +63 -0
- package/.windsurf/workflows/x-Database-Seed.md +300 -0
- package/.windsurf/workflows/x-Dependencies-Update.md +315 -0
- package/.windsurf/workflows/x-DevEnvironment-Setup.md +437 -0
- package/.windsurf/workflows/x-Logging-Add.md +682 -0
- package/.windsurf/workflows/x-Migration-Create.md +354 -0
- package/.windsurf/workflows/x-Problem-RootCauseAnalysis.md +65 -0
- package/.windsurf/workflows/x-Repository-Push.md +375 -0
- package/.windsurf/workflows/x-Repository-PushToGithub.md +72 -0
- package/.windsurf/workflows/x-Requirements-Clarify.md +61 -0
- package/.windsurf/workflows/z-CreateWorkflow.md +77 -0
- package/README.md +280 -0
- package/bin/cli.js +74 -0
- package/package.json +28 -0
|
@@ -0,0 +1,375 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: ローカル変更を検証し、安全なコミットとリモートリポジトリへのプッシュを行うワークフロー(GitHub/GitLab対応)
|
|
3
|
+
auto_execution_mode: 1
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Repository-Push (x-Repository-Push)
|
|
7
|
+
|
|
8
|
+
## 目的
|
|
9
|
+
|
|
10
|
+
- ローカル変更をレビュー・テストした上で、適切なブランチ運用とコミットメッセージでリモートリポジトリにプッシュする。
|
|
11
|
+
- コンフリクトやCI失敗を未然に防ぎ、チームと共有できる状態で提出する。
|
|
12
|
+
- GitHub、GitLab など複数のGitホスティングサービスに対応する。
|
|
13
|
+
- 必要なドキュメンテーション更新や追跡情報を整備した上で変更を公開する。
|
|
14
|
+
|
|
15
|
+
## 前提
|
|
16
|
+
|
|
17
|
+
- ローカルリポジトリがリモート(origin)と接続されている。
|
|
18
|
+
- コミット対象の変更内容を把握しており、未保存ファイルや不要な変更がない。
|
|
19
|
+
- 動作確認に必要なテストやビルドコマンドが実行でき、依存ツールが揃っている。
|
|
20
|
+
- 認証情報(PAT / SSH鍵など)が有効で、リモートリポジトリへの push 権限がある。
|
|
21
|
+
- プッシュ前に README / ドキュメント / ワークフローを更新する必要がある場合は、その方針を決めている。
|
|
22
|
+
|
|
23
|
+
## 手順
|
|
24
|
+
|
|
25
|
+
### 1. リモートリポジトリの確認
|
|
26
|
+
|
|
27
|
+
**リモートURLの確認**:
|
|
28
|
+
```bash
|
|
29
|
+
git remote -v
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
**プラットフォームの特定**:
|
|
33
|
+
- github.com → GitHub
|
|
34
|
+
- gitlab.com → GitLab
|
|
35
|
+
- その他のセルフホストインスタンス
|
|
36
|
+
|
|
37
|
+
**認証方法の確認**:
|
|
38
|
+
- SSH: `git@github.com:user/repo.git`
|
|
39
|
+
- HTTPS: `https://github.com/user/repo.git`
|
|
40
|
+
|
|
41
|
+
### 2. 最新状態への同期
|
|
42
|
+
|
|
43
|
+
**ブランチ戦略の確認**:
|
|
44
|
+
- GitHub Flow: main ブランチから feature ブランチ
|
|
45
|
+
- GitLab Flow: main → pre-production → production
|
|
46
|
+
- Git Flow: develop → feature, develop → release
|
|
47
|
+
- Trunk-based: main ブランチのみ
|
|
48
|
+
|
|
49
|
+
**同期コマンド**:
|
|
50
|
+
```bash
|
|
51
|
+
# 現在の状態確認
|
|
52
|
+
git status
|
|
53
|
+
|
|
54
|
+
# リモートの最新状態を取得
|
|
55
|
+
git fetch --prune
|
|
56
|
+
|
|
57
|
+
# ベースブランチを最新化(例: main)
|
|
58
|
+
git checkout main
|
|
59
|
+
git pull origin main
|
|
60
|
+
|
|
61
|
+
# 作業ブランチに戻る
|
|
62
|
+
git checkout <feature-branch>
|
|
63
|
+
|
|
64
|
+
# 最新の変更を取り込む(リベースまたはマージ)
|
|
65
|
+
git rebase origin/main
|
|
66
|
+
# または
|
|
67
|
+
git merge origin/main
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
### 3. ローカル検証
|
|
71
|
+
|
|
72
|
+
**テスト実行**:
|
|
73
|
+
```bash
|
|
74
|
+
# Lint チェック
|
|
75
|
+
<lint-command>
|
|
76
|
+
|
|
77
|
+
# ユニットテスト
|
|
78
|
+
<test-command>
|
|
79
|
+
|
|
80
|
+
# E2Eテスト(必要に応じて)
|
|
81
|
+
<e2e-test-command>
|
|
82
|
+
|
|
83
|
+
# ビルド確認
|
|
84
|
+
<build-command>
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
**検証項目**:
|
|
88
|
+
- [ ] すべてのテストが通過する
|
|
89
|
+
- [ ] Lint エラーがない
|
|
90
|
+
- [ ] ビルドが成功する
|
|
91
|
+
- [ ] 新機能が正常に動作する
|
|
92
|
+
- [ ] 既存機能に影響がない
|
|
93
|
+
|
|
94
|
+
**エラーが出た場合**:
|
|
95
|
+
- エラーを修正
|
|
96
|
+
- 再度テストを実行
|
|
97
|
+
- 成功を確認してから次のステップへ
|
|
98
|
+
|
|
99
|
+
### 4. 変更内容の整理
|
|
100
|
+
|
|
101
|
+
**変更の確認**:
|
|
102
|
+
```bash
|
|
103
|
+
# 変更されたファイルを確認
|
|
104
|
+
git status
|
|
105
|
+
|
|
106
|
+
# 変更内容の詳細を確認
|
|
107
|
+
git diff
|
|
108
|
+
|
|
109
|
+
# ステージングエリアの確認
|
|
110
|
+
git diff --staged
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
**不要なファイルの除外**:
|
|
114
|
+
- [ ] 一時ファイルが含まれていない
|
|
115
|
+
- [ ] ビルド成果物が含まれていない(.gitignore で管理)
|
|
116
|
+
- [ ] 機密情報が含まれていない
|
|
117
|
+
- [ ] デバッグコードが削除されている
|
|
118
|
+
|
|
119
|
+
**コミット単位の分割**(必要に応じて):
|
|
120
|
+
- 大きな変更は複数のコミットに分割
|
|
121
|
+
- 各コミットは独立して意味のある単位に
|
|
122
|
+
- 論理的に関連する変更をまとめる
|
|
123
|
+
|
|
124
|
+
### 5. ドキュメントとメタ情報の更新
|
|
125
|
+
|
|
126
|
+
**ドキュメント更新**:
|
|
127
|
+
- [ ] README.md の更新(新機能、使い方)
|
|
128
|
+
- [ ] CHANGELOG.md の更新(変更内容、バージョン)
|
|
129
|
+
- [ ] API ドキュメントの更新
|
|
130
|
+
- [ ] コメント・JSDoc の更新
|
|
131
|
+
|
|
132
|
+
**Issue/タスク管理との連携**:
|
|
133
|
+
- GitHub: `Fixes #123`, `Closes #456`
|
|
134
|
+
- GitLab: `Closes #123`, `Related to #456`
|
|
135
|
+
- Jira: `PROJ-123`, `PROJ-456`
|
|
136
|
+
|
|
137
|
+
### 6. コミットの実行
|
|
138
|
+
|
|
139
|
+
**コミットメッセージの作成**:
|
|
140
|
+
|
|
141
|
+
チーム規約に従ったフォーマットを使用:
|
|
142
|
+
|
|
143
|
+
**Conventional Commits 形式**:
|
|
144
|
+
```
|
|
145
|
+
<type>(<scope>): <subject>
|
|
146
|
+
|
|
147
|
+
<body>
|
|
148
|
+
|
|
149
|
+
<footer>
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
**Type の種類**:
|
|
153
|
+
- `feat`: 新機能
|
|
154
|
+
- `fix`: バグ修正
|
|
155
|
+
- `docs`: ドキュメント
|
|
156
|
+
- `style`: フォーマット
|
|
157
|
+
- `refactor`: リファクタリング
|
|
158
|
+
- `test`: テスト追加
|
|
159
|
+
- `chore`: ビルド・設定変更
|
|
160
|
+
|
|
161
|
+
**コミット実行**:
|
|
162
|
+
```bash
|
|
163
|
+
# ファイルをステージング
|
|
164
|
+
git add <files>
|
|
165
|
+
|
|
166
|
+
# コミット
|
|
167
|
+
git commit -m "feat: add user authentication
|
|
168
|
+
|
|
169
|
+
- Add login/logout functionality
|
|
170
|
+
- Add JWT token management
|
|
171
|
+
- Add protected routes
|
|
172
|
+
|
|
173
|
+
Fixes #123
|
|
174
|
+
|
|
175
|
+
🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
|
176
|
+
|
|
177
|
+
Co-Authored-By: Claude <noreply@anthropic.com>"
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
**コミット履歴の整理**(必要に応じて):
|
|
181
|
+
```bash
|
|
182
|
+
# 直前のコミットを修正
|
|
183
|
+
git commit --amend
|
|
184
|
+
|
|
185
|
+
# 複数コミットを整理(インタラクティブリベース)
|
|
186
|
+
git rebase -i HEAD~3
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
### 7. プッシュ前の最終確認
|
|
190
|
+
|
|
191
|
+
**確認項目**:
|
|
192
|
+
- [ ] `git status` が clean である
|
|
193
|
+
- [ ] 不要な stash が残っていない
|
|
194
|
+
- [ ] コミットメッセージが正しい
|
|
195
|
+
- [ ] テストが通過している
|
|
196
|
+
- [ ] ドキュメントが更新されている
|
|
197
|
+
|
|
198
|
+
**リモートの最新状態確認**:
|
|
199
|
+
```bash
|
|
200
|
+
# リモートの変更を確認
|
|
201
|
+
git fetch
|
|
202
|
+
|
|
203
|
+
# リモートとの差分を確認
|
|
204
|
+
git log origin/<branch>..HEAD
|
|
205
|
+
|
|
206
|
+
# 必要なら再度リベース
|
|
207
|
+
git rebase origin/<base-branch>
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
### 8. リモートリポジトリへのプッシュ
|
|
211
|
+
|
|
212
|
+
**プッシュコマンド**:
|
|
213
|
+
|
|
214
|
+
**初回プッシュ(ブランチが存在しない場合)**:
|
|
215
|
+
```bash
|
|
216
|
+
git push -u origin <branch-name>
|
|
217
|
+
```
|
|
218
|
+
|
|
219
|
+
**通常のプッシュ**:
|
|
220
|
+
```bash
|
|
221
|
+
git push origin <branch-name>
|
|
222
|
+
```
|
|
223
|
+
|
|
224
|
+
**強制プッシュ(慎重に)**:
|
|
225
|
+
```bash
|
|
226
|
+
# リベース後など、必要な場合のみ
|
|
227
|
+
git push --force-with-lease origin <branch-name>
|
|
228
|
+
|
|
229
|
+
# 注意: main/master への強制プッシュは避ける
|
|
230
|
+
```
|
|
231
|
+
|
|
232
|
+
**プッシュ結果の確認**:
|
|
233
|
+
- プッシュが成功したか確認
|
|
234
|
+
- エラーがあればログを確認
|
|
235
|
+
- リモートブランチが作成されたか確認
|
|
236
|
+
|
|
237
|
+
### 9. Pull Request / Merge Request の作成
|
|
238
|
+
|
|
239
|
+
**プラットフォーム別のコマンド**:
|
|
240
|
+
|
|
241
|
+
**GitHub CLI**:
|
|
242
|
+
```bash
|
|
243
|
+
# PR作成
|
|
244
|
+
gh pr create --title "Add user authentication" --body "Implements login/logout functionality. Fixes #123"
|
|
245
|
+
|
|
246
|
+
# PR の状態確認
|
|
247
|
+
gh pr status
|
|
248
|
+
|
|
249
|
+
# PR のURLを開く
|
|
250
|
+
gh pr view --web
|
|
251
|
+
```
|
|
252
|
+
|
|
253
|
+
**GitLab CLI**:
|
|
254
|
+
```bash
|
|
255
|
+
# MR作成
|
|
256
|
+
glab mr create --title "Add user authentication" --description "Implements login/logout functionality. Closes #123"
|
|
257
|
+
|
|
258
|
+
# MR の状態確認
|
|
259
|
+
glab mr list
|
|
260
|
+
|
|
261
|
+
# MR のURLを開く
|
|
262
|
+
glab mr view --web
|
|
263
|
+
```
|
|
264
|
+
|
|
265
|
+
**Web UIでの作成**:
|
|
266
|
+
- GitHub: リポジトリページで "Compare & pull request" ボタン
|
|
267
|
+
- GitLab: リポジトリページで "Create merge request" ボタン
|
|
268
|
+
|
|
269
|
+
**PR/MR テンプレートの記入**:
|
|
270
|
+
- [ ] 変更内容の説明
|
|
271
|
+
- [ ] 影響範囲
|
|
272
|
+
- [ ] テスト結果
|
|
273
|
+
- [ ] スクリーンショット(UI変更の場合)
|
|
274
|
+
- [ ] レビュワーの指定
|
|
275
|
+
- [ ] ラベルの設定
|
|
276
|
+
- [ ] マイルストーンの設定(必要に応じて)
|
|
277
|
+
|
|
278
|
+
### 10. CI/CD の監視
|
|
279
|
+
|
|
280
|
+
**CI/CD パイプラインの確認**:
|
|
281
|
+
- GitHub Actions: リポジトリの "Actions" タブ
|
|
282
|
+
- GitLab CI/CD: リポジトリの "CI/CD > Pipelines"
|
|
283
|
+
|
|
284
|
+
**確認項目**:
|
|
285
|
+
- [ ] すべてのジョブが成功している
|
|
286
|
+
- [ ] テストが通過している
|
|
287
|
+
- [ ] ビルドが成功している
|
|
288
|
+
- [ ] デプロイが成功している(該当する場合)
|
|
289
|
+
|
|
290
|
+
**CI失敗時の対応**:
|
|
291
|
+
1. ログを確認してエラー原因を特定
|
|
292
|
+
2. ローカルで再現して修正
|
|
293
|
+
3. 修正をコミット・プッシュ
|
|
294
|
+
4. CI が成功するまで繰り返す
|
|
295
|
+
|
|
296
|
+
### 11. チームへの通知
|
|
297
|
+
|
|
298
|
+
**通知方法**:
|
|
299
|
+
- Slack / Microsoft Teams / Discord へ通知
|
|
300
|
+
- メール通知
|
|
301
|
+
- プロジェクト管理ツール(Jira, Asana等)への更新
|
|
302
|
+
|
|
303
|
+
**通知内容**:
|
|
304
|
+
- 変更内容の概要
|
|
305
|
+
- PR/MR のURL
|
|
306
|
+
- 影響範囲
|
|
307
|
+
- レビュー依頼
|
|
308
|
+
- テスト結果
|
|
309
|
+
|
|
310
|
+
## 完了条件
|
|
311
|
+
|
|
312
|
+
- ローカルブランチがリモートリポジトリにプッシュされている
|
|
313
|
+
- テスト・Lint・CI が成功している
|
|
314
|
+
- Pull Request / Merge Request が作成されている(該当する場合)
|
|
315
|
+
- 必要なドキュメント更新・Issueリンク・レビュー依頼が整備されている
|
|
316
|
+
- チームへの通知が完了している
|
|
317
|
+
|
|
318
|
+
## エスカレーション
|
|
319
|
+
|
|
320
|
+
- **プッシュが失敗する**:
|
|
321
|
+
- 認証情報を確認(PAT, SSH鍵)
|
|
322
|
+
- リモートURLを確認
|
|
323
|
+
- プッシュ権限を確認
|
|
324
|
+
- ネットワーク接続を確認
|
|
325
|
+
|
|
326
|
+
- **プッシュ後のCIが失敗する**:
|
|
327
|
+
- ログを確認して原因を特定
|
|
328
|
+
- ローカルで再現して修正
|
|
329
|
+
- 対応が難しい場合はチームリードへ報告
|
|
330
|
+
|
|
331
|
+
- **コンフリクトが解消できない**:
|
|
332
|
+
- ベースブランチの変更を確認
|
|
333
|
+
- コンフリクトファイルを手動マージ
|
|
334
|
+
- チームメンバーと調整
|
|
335
|
+
|
|
336
|
+
- **セキュリティやコンプライアンスの問題**:
|
|
337
|
+
- セキュリティチームへ報告
|
|
338
|
+
- レビュープロセスに従う
|
|
339
|
+
- 必要に応じて変更を取り下げ
|
|
340
|
+
|
|
341
|
+
## ベストプラクティス
|
|
342
|
+
|
|
343
|
+
- **小さく頻繁にコミット**: 大きな変更は複数のコミットに分割
|
|
344
|
+
- **意味のあるコミットメッセージ**: 変更内容が分かりやすいメッセージ
|
|
345
|
+
- **テストを先に実行**: プッシュ前に必ずテストを実行
|
|
346
|
+
- **ドキュメントを更新**: 変更に伴うドキュメント更新を忘れない
|
|
347
|
+
- **レビューを依頼**: 重要な変更は必ずレビューを受ける
|
|
348
|
+
- **CI/CDを監視**: プッシュ後のCI/CD結果を確認
|
|
349
|
+
- **main/masterへの直接プッシュを避ける**: ブランチ戦略に従う
|
|
350
|
+
- **強制プッシュは慎重に**: `--force-with-lease` を使用し、共有ブランチでは避ける
|
|
351
|
+
|
|
352
|
+
## 参考: プラットフォーム別の機能
|
|
353
|
+
|
|
354
|
+
**GitHub**:
|
|
355
|
+
- Pull Request (PR)
|
|
356
|
+
- GitHub Actions (CI/CD)
|
|
357
|
+
- GitHub Projects (プロジェクト管理)
|
|
358
|
+
- GitHub Discussions (ディスカッション)
|
|
359
|
+
- GitHub CLI: `gh`
|
|
360
|
+
|
|
361
|
+
**GitLab**:
|
|
362
|
+
- Merge Request (MR)
|
|
363
|
+
- GitLab CI/CD
|
|
364
|
+
- GitLab Issues (課題管理)
|
|
365
|
+
- GitLab Wiki (ドキュメント)
|
|
366
|
+
- GitLab CLI: `glab`
|
|
367
|
+
|
|
368
|
+
**共通機能**:
|
|
369
|
+
- ブランチ保護
|
|
370
|
+
- コードレビュー
|
|
371
|
+
- CI/CD パイプライン
|
|
372
|
+
- Issue/課題管理
|
|
373
|
+
- Wiki/ドキュメント
|
|
374
|
+
- Webhooks
|
|
375
|
+
- API アクセス
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: ローカル変更を検証し、安全なコミットとGitHubへのプッシュを行うための手順
|
|
3
|
+
auto_execution_mode: 1
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Repository-PushToGithub (x-Repository-PushToGithub)
|
|
7
|
+
|
|
8
|
+
## 目的
|
|
9
|
+
|
|
10
|
+
- ローカル変更をレビュー・テストした上で、適切なブランチ運用とコミットメッセージで GitHub にプッシュする。
|
|
11
|
+
- コンフリクトやCI失敗を未然に防ぎ、チームと共有できる状態で提出する。
|
|
12
|
+
- 必要なドキュメンテーション更新や追跡情報を整備した上で変更を公開する。
|
|
13
|
+
|
|
14
|
+
## 前提
|
|
15
|
+
|
|
16
|
+
- ローカルリポジトリが GitHub 上のリモート(origin)と接続されている。
|
|
17
|
+
- コミット対象の変更内容を把握しており、未保存ファイルや不要な変更がない。
|
|
18
|
+
- 動作確認に必要なテストやビルドコマンドが `run_command` で実行でき、依存ツールが揃っている。
|
|
19
|
+
- 認証情報(PAT / SSH鍵など)が有効で、GitHub への push 権限がある。
|
|
20
|
+
- プッシュ前に README / ドキュメント / ワークフローを更新する必要がある場合は、その方針を決めている。
|
|
21
|
+
|
|
22
|
+
## 手順
|
|
23
|
+
|
|
24
|
+
1. **最新状態への同期**
|
|
25
|
+
- `git status` で変更状況を確認する。
|
|
26
|
+
- ベースブランチを最新化する (`git fetch --prune`)。
|
|
27
|
+
- 作業ブランチにチェックアウトし、必要であれば `git rebase origin/<base>` または `git merge origin/<base>` を実施する。
|
|
28
|
+
|
|
29
|
+
2. **ローカル検証**
|
|
30
|
+
- 影響範囲に応じて lint、静的解析、ユニットテスト、E2Eテストなどを `run_command` で実行する。
|
|
31
|
+
- Playwright MCP や Chrome DevTools MCP が必要な場合は挙動確認を行い、スクリーンショット・ログを取得する。
|
|
32
|
+
- エラーが出た場合は修正し、再実行して成功を確認する。
|
|
33
|
+
|
|
34
|
+
3. **変更内容の整理とコミット準備**
|
|
35
|
+
- `git status`・`git diff` を確認し、不要ファイルが含まれていないかチェックする。
|
|
36
|
+
- 粒度が大きすぎる場合はコミット単位を分割する。
|
|
37
|
+
- `git add` でコミット対象をステージし、`git diff --staged` で最終確認を行う。
|
|
38
|
+
- コミットメッセージはチーム規約(例: Conventional Commits)に従って作成する。
|
|
39
|
+
|
|
40
|
+
4. **ドキュメントとメタ情報の更新**
|
|
41
|
+
- 変更に伴い README、CHANGELOGなどを更新する必要があれば反映する。
|
|
42
|
+
- Issue やタスク管理ツールとの関連を明記(コミット本文に `Fixes #123` 等)。
|
|
43
|
+
|
|
44
|
+
5. **コミットの実行**
|
|
45
|
+
- `git commit` を実行し、メッセージを確定する。
|
|
46
|
+
- 過去コミットの修正が必要な場合は `git commit --amend` や `git rebase -i` を利用し、履歴を整える。
|
|
47
|
+
|
|
48
|
+
6. **プッシュ前の最終確認**
|
|
49
|
+
- `git status` が clean であること、不要な stash が残っていないことを確認する。
|
|
50
|
+
- 直前にベースブランチへ変更が入っていないか `git fetch` で確認し、必要なら再度リベースする。
|
|
51
|
+
|
|
52
|
+
7. **GitHub へのプッシュ**
|
|
53
|
+
- `git push origin <branch>` を実行する。
|
|
54
|
+
- 初回プッシュでブランチが存在しない場合は `-u` オプションで追跡ブランチを設定する。
|
|
55
|
+
- プッシュ結果を確認し、エラーがあればログに基づいて対処する。
|
|
56
|
+
|
|
57
|
+
8. **フォローアップ**
|
|
58
|
+
- Pull Request を作成する場合はテンプレートに沿って記入し、レビュワー・ラベルを設定する。
|
|
59
|
+
- CI/CD の結果を監視し、失敗があれば原因を調査する。
|
|
60
|
+
- 必要に応じてチームへ通知し、変更内容・影響範囲・テスト状況を共有する。
|
|
61
|
+
|
|
62
|
+
## 完了条件
|
|
63
|
+
|
|
64
|
+
- ローカルブランチが GitHub にプッシュされ、変更内容が共有可能な状態になっている。
|
|
65
|
+
- テスト・Lint・CI が成功している(または合理的な理由とともに失敗を説明している)。
|
|
66
|
+
- 必要なドキュメント更新・Issueリンク・レビュー依頼が整備されている。
|
|
67
|
+
|
|
68
|
+
## エスカレーション
|
|
69
|
+
|
|
70
|
+
- プッシュ後のCIが失敗した場合、速やかに原因を確認し修正する。対応が難しい場合はチームリードへ報告する。
|
|
71
|
+
- コンフリクトが解消できない場合や、ベースブランチ側の大規模変更が原因で作業が停滞した場合は、関係者と調整する。
|
|
72
|
+
- セキュリティやコンプライアンスに影響する変更を含む場合は、セキュリティチームやレビュープロセスに従う。
|
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: あいまいな要求や仕様を整理し、補足質問と前提確認を体系化して共有するためのクラリフィケーションワークフロー
|
|
3
|
+
auto_execution_mode: 1
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Requirements-Clarify (x-Requirements-Clarify)
|
|
7
|
+
|
|
8
|
+
## 目的
|
|
9
|
+
|
|
10
|
+
- 初期要求や仕様ドラフトの不明点・矛盾・前提不足を迅速に洗い出し、確かな理解を得る。
|
|
11
|
+
- 機能・非機能・制約・リスクを観点別に整理し、意思決定者へ明確な質問セットを提示する。
|
|
12
|
+
- 想定されるユースケースと除外範囲を明文化し、後続の設計・実装フェーズをスムーズに開始する。
|
|
13
|
+
|
|
14
|
+
## 前提
|
|
15
|
+
|
|
16
|
+
- 対象プロジェクトのリポジトリ/仕様資料へアクセスでき、関連ドキュメントを参照できること。
|
|
17
|
+
- README、開発ガイドライン、既存ワークフローが最新状態であることを確認する。
|
|
18
|
+
- 要求元が回答可能なコンタクト手段(Issue, PR, チャット等)が明確で、質問の優先度や回答期限を設定できること。
|
|
19
|
+
- 高機密情報を扱う場合は、組織の情報セキュリティポリシーに従い共有範囲を制限する。
|
|
20
|
+
|
|
21
|
+
## 手順
|
|
22
|
+
|
|
23
|
+
1. **コンテキスト収集**
|
|
24
|
+
- 依頼メッセージ、既存の仕様書、議事録、関連する Issue/PR を読み込み、現時点で提示されている情報源をリスト化する。
|
|
25
|
+
- `run_command` や MCP(Context7, DeepWiki など)を利用し、関連ドキュメントやコード断片を検索する。
|
|
26
|
+
|
|
27
|
+
2. **要求の要約とゴール仮説の作成**
|
|
28
|
+
- 要求の目的・背景・成功指標を 3〜5 行で短く要約し、現時点の理解(What / Why / For whom)を明文化する。
|
|
29
|
+
- 既知の制約(スケジュール、技術スタック、依存サービスなど)と前提をリスト化する。
|
|
30
|
+
|
|
31
|
+
3. **ギャップと不確定要素の抽出**
|
|
32
|
+
- 機能要件、非機能要件、データ要件、UX 要件、運用要件など観点別に、不足情報・矛盾・曖昧表現を列挙する。
|
|
33
|
+
- 過去事例や類似プロジェクトの知見から想定されるリスクや特殊ケースを付記する。
|
|
34
|
+
|
|
35
|
+
4. **検証と補足調査**
|
|
36
|
+
- 重要度が高い項目についてはコードベースやドキュメントを確認し、既存実装との整合性や影響を下調べする。
|
|
37
|
+
- ブラウザやAPIの現状挙動を再確認する必要があれば Playwright MCP や Chrome DevTools MCP で挙動を収集する。
|
|
38
|
+
|
|
39
|
+
5. **質問リストと仮定の整理**
|
|
40
|
+
- 優先度(High/Medium/Low)を付けて質問をグルーピングし、回答が必要な理由や想定される選択肢を明記する。
|
|
41
|
+
- 回答を待つ間に採用した暫定的な仮定や推奨案を併記し、回答後のアクションもセットで提示する。
|
|
42
|
+
|
|
43
|
+
6. **サマリーと次のアクション提示**
|
|
44
|
+
- 要約、主要な不確定点、質問リスト、暫定方針、推奨タイムラインを 1 ページ以内にまとめる。
|
|
45
|
+
- コミュニケーション手段(Issue コメント、PR、専用チャンネル等)に合わせた形式で共有し、回答期限とフォローアップ方法を明確化する。
|
|
46
|
+
|
|
47
|
+
7. **フォローアップとドキュメント化**
|
|
48
|
+
- 回答が得られた項目を更新し、仕様ドキュメントやワークフローの関連セクションへ反映する。
|
|
49
|
+
- 未回答項目・保留事項を TODO として登録し、スプリント計画や backlog に連携する。
|
|
50
|
+
|
|
51
|
+
## 完了条件
|
|
52
|
+
|
|
53
|
+
- 仕様理解のサマリーと明確な質問リストが作成・共有され、回答期限や次ステップが合意されている。
|
|
54
|
+
- 回答済み項目に基づき仕様ドキュメントが更新され、仮定や暫定決定が明文化されている。
|
|
55
|
+
- 未解決事項が TODO として管理され、責任者とフォローアップ方法が設定されている。
|
|
56
|
+
|
|
57
|
+
## エスカレーション
|
|
58
|
+
|
|
59
|
+
- 重要な不明点が解消できずスケジュールや品質に重大な影響が出る場合は、プロダクトオーナーやステークホルダーへ早期に報告する。
|
|
60
|
+
- セキュリティ・法務・プライバシーに関わる疑問が発生した場合は、専門チームへ確認し自己判断で進めない。
|
|
61
|
+
- コミュニケーションが滞った場合は、チームリードやマネージャーへ状況を共有し、回答者の調整を依頼する。
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 新規ワークフローを作成するときに、目的・前提・手順・品質チェック・公開・フィードバックまでを標準化し、再利用性とガバナンスを担保するための手順書
|
|
3
|
+
auto_execution_mode: 1
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /create-workflow
|
|
7
|
+
|
|
8
|
+
## 目的
|
|
9
|
+
|
|
10
|
+
- Windsurfリポジトリに新しいワークフローを追加する際の手順を標準化し、作業のばらつきを抑える。
|
|
11
|
+
- READMEとベストプラクティスの方針を反映し、再利用可能なドキュメントを素早く整備する。
|
|
12
|
+
|
|
13
|
+
## 前提
|
|
14
|
+
|
|
15
|
+
- 作成先リポジトリが`.windsurf/workflows/`配下でMarkdown運用されていること(@README.md)。
|
|
16
|
+
- Cascadeが利用可能なツール・Rules・Memoriesの権限を把握していること(@slash-commands-best-practices.md)。
|
|
17
|
+
- 追加するワークフローの目的・対象ユーザー・完了条件が依頼元から共有済みであること。
|
|
18
|
+
|
|
19
|
+
## 手順
|
|
20
|
+
|
|
21
|
+
1. 情報収集
|
|
22
|
+
|
|
23
|
+
- 依頼文や関連資料を確認し、ワークフローの目的と制約を整理する。必要に応じて依頼元へ質問する。
|
|
24
|
+
- `@README.md`と`@slash-commands-best-practices.md`を読み、最新ポリシー・命名規約・文字数上限(12,000文字)を再確認する。
|
|
25
|
+
|
|
26
|
+
2. スラッグとスコープを決定
|
|
27
|
+
|
|
28
|
+
- ファイル名は用途が即座に想起できる短いスラッグにする(例: `build-and-test.md`)。
|
|
29
|
+
- コマンド名(`/slug`)と対象範囲が一意であるか調査し、重複・競合があれば整理する。
|
|
30
|
+
|
|
31
|
+
3. 作成テンプレートの準備
|
|
32
|
+
|
|
33
|
+
- セクション例: 目的 / 前提 / 手順 / 完了条件 / エスカレーション。必要に応じて入力仕様・参考リンク・検証項目を追加する。
|
|
34
|
+
- YAML frontmatterは使用せず、Markdown本文のみで構成する。
|
|
35
|
+
|
|
36
|
+
4. 手順の詳細化
|
|
37
|
+
|
|
38
|
+
- 各ステップは番号付きまたは箇条書きで、Cascadeに期待するアクションと意図を明示する。
|
|
39
|
+
- 分岐は「IF ... THEN ...」、反復は「FOR EACH ...」など自然言語構文で記述し、曖昧な表現を避ける。
|
|
40
|
+
- CLIやMCPツールを利用する場合は名称と目的を明記し、権限や安全策が必要ならRules/Memoriesへの依存を記述する。
|
|
41
|
+
|
|
42
|
+
5. コンテキスト最適化と参照設計
|
|
43
|
+
|
|
44
|
+
- 長文資料は`@path/to/doc.md`形式で参照し、ワークフロー内テキストは必要最小限に保つ。
|
|
45
|
+
- 他ワークフローを再利用する場合は「Call /workflow-name」と明記し、チェイン構築を想定した粒度に分割する。
|
|
46
|
+
|
|
47
|
+
6. 品質チェック
|
|
48
|
+
|
|
49
|
+
- 以下を確認し、未達の場合は修正する。
|
|
50
|
+
- コマンド名と目的が直感的か。
|
|
51
|
+
- コンテキスト制限を満たし、冗長表現がないか。
|
|
52
|
+
- 依存ツール・前提条件・エスカレーション手順が明示されているか。
|
|
53
|
+
- 成功判定・完了報告フォーマットが定義されているか。
|
|
54
|
+
- セキュリティや権限に関する注意点が必要に応じて記載されているか。
|
|
55
|
+
|
|
56
|
+
7. レビューと公開
|
|
57
|
+
|
|
58
|
+
- 変更差分をセルフレビューし、必要ならチームレビューを依頼する。
|
|
59
|
+
- `.windsurf/workflows/slug.md`を追加し、`git status`で不要な変更が含まれていないことを確認する。
|
|
60
|
+
- READMEへ新しいワークフローの概要やリンクを追記する場合は同時に更新する。
|
|
61
|
+
- テストや検証が必要なら実施し、得られたフィードバックを反映する。
|
|
62
|
+
|
|
63
|
+
8. フィードバックループ
|
|
64
|
+
|
|
65
|
+
- 利用者からの改善提案を記録し、定期的に`@slash-commands-best-practices.md`へ反映を検討する。
|
|
66
|
+
- 重複内容が生じた場合は統合・再編を検討し、DRY原則を維持する。
|
|
67
|
+
|
|
68
|
+
## 完了条件
|
|
69
|
+
|
|
70
|
+
- 新規ワークフローMarkdownが目的・前提・明確な手順・完了報告を備えている。
|
|
71
|
+
- READMEや関連資料に必要な追記が完了し、差分がレビュー可能な状態である。
|
|
72
|
+
- 依頼元へ成果物と差分を共有し、レビュー結果待ちの状態になっている。
|
|
73
|
+
|
|
74
|
+
## エスカレーション
|
|
75
|
+
|
|
76
|
+
- ツール権限や安全性が不明な場合は、依頼元またはリポジトリ管理者に確認し、自律的な推測で危険な操作を行わない。
|
|
77
|
+
- 既存ルールや他ワークフローと競合が判明した場合は、ガバナンス担当へ相談し調整する。
|