db-apply

name	db-apply
description	DB申請JiraチケットをもとにSQLを検証・生成し、レビュアー向けのレビューMDを出力する
disable-model-invocation	true

db-apply コマンド

DB申請プロジェクト（Jira: DB）のチケットを処理するためのスキル。 チケットを読み込み、対話的な確認フローでSQLの正しさを検証し、レビュアー向けのMDを出力する。

引数

$ARGUMENTS にJiraチケット番号が入る（例: DB-1953）。 引数が空の場合は「処理するDB申請チケット番号を教えてください」と聞く。

---

定数

• Jira cloudId: goals-inc.atlassian.net
• DBプロジェクトキー: DB
• 出力ディレクトリ: ~/work/google_drive/db-apply/yyyymmdd/（yyyymmddは実行日）

---

フェーズ 1: チケット情報収集

1-1. メインチケットの取得

mcp__atlassian__getJiraIssue でチケットを取得する。取得フィールド:

• summary, description, status, issuetype, assignee, reporter, created
• comment, attachment, issuelinks

1-2. 関連チケットの取得

以下の2経路で関連チケットを探す:

a) issuelinks から

• outwardIssue / inwardIssue のキーを全て取得し、mcp__atlassian__getJiraIssue で内容を読む

b) description テキスト内のチケット番号から

• INQUIRY-XXXX, BUG-XXXX, HANZO-XXXX 等のパターンを正規表現で抽出
• 見つかったチケットも mcp__atlassian__getJiraIssue で取得する

チケット番号の表示ルール

チケット番号を画面に表示する際は、必ずクリッカブルなMarkdownリンクにする:

• 形式: [TICKET-NUMBER](https://goals-inc.atlassian.net/browse/TICKET-NUMBER)
• 例: [INQUIRY-6657](https://goals-inc.atlassian.net/browse/INQUIRY-6657)
• 対象: DB申請本文、関連チケット一覧、確認フロー、レビューMD内のすべてのチケット番号

1-3. 添付ファイル・外部リンクの確認

添付ファイル (attachment フィールド) がある場合:

• SQLファイル（.sql）・CSVファイル（.csv）・テキストファイル: MCPでは取得不可。ユーザーに依頼する:

  「添付ファイル {filename} が必要です。 チケット（Jira）を開き、添付ファイルをクリックしてダウンロードし、 内容をここに貼り付けてください。」

• 画像ファイル（PNG/JPG）: JiraもConfluenceもinline画像は blob: URLのため取得不可。 画像の内容が重要な場合は「このスクリーンショットに何が写っていますか？」とユーザーに説明を求める。

Googleスプレッドシート / Googleドキュメントリンク がdescriptionに含まれる場合:

• ユーザーに以下のように依頼する:

  「チケットにGoogleスプレッドシートのリンクがあります: [URL] アクセスしてSQL等の内容をコピーして貼り付けていただけますか？」

その他アクセス不可なリンクがある場合も同様にユーザーに取得依頼する。

1-4. 情報不足の確認

収集した情報で以下が不明な場合、ユーザーに問い合わせる:

• 対象のcompany_id / shop_id / 具体的なレコードID が不明
• 実行意図が読み取れない
• SQLが全く存在しない（チケットにもスプレッドシートにも無い）

問い合わせ文例:

「チケットに〇〇の情報が見当たりませんでした。Slackや元のINQUIRYチケットなど他に情報源はありますか？」

---

フェーズ 2: 内容の整理と意図確認

収集した情報をもとに、以下を整理する:

1. 何をしたいか（目的）: 1〜2文で要約
2. 対象データ: 業態名 / 店舗名 / テーブル / レコードID等
3. 操作の種類: INSERT / UPDATE / DELETE / SELECT のどれか
4. 既存SQL: チケットに記載されているか否か

整理したら、ユーザーに確認する（AskUserQuestionツールを使用）:

「このJiraチケットは『〇〇をしたい』ということで正しいですか？」 選択肢: 「はい、正しい」 / 「違う、補足します」

「違う」を選んだ場合はユーザーの補足を聞いてから次へ進む。

---

フェーズ 3: 対話的な確認フロー（DBへの接続確認）

このフェーズの目的: 実行するSQLが正しいと「人間が理解できる根拠」を積み上げる。

DB接続は /query-db スキルの手順に従う（staging を優先し、確認が取れたら本番でも同様に確認する）。

フロー構造

各ステップは以下の形式で進める:

▶ ステップ N: 〇〇の確認

このチケットの対象は〜〜なので、まず以下のクエリで現状を確認しましょう。

```sql
-- 確認クエリ
SELECT ...;

実行してください。結果が〜〜になっていれば正しいです。

ユーザーが実行結果を貼り付けたら、期待値と照合し、OK/NGを判定する。
- OK → 「確認できました。次のステップへ進みます。」
- NG → 「期待と異なります。〇〇の可能性があります。」と原因を説明し、対処を提案する。

### 確認ステップの設計方針

操作の種類ごとに確認クエリを設計する:

**DELETE の場合**
1. 削除対象レコードが存在することを確認
2. 削除対象の周辺レコード（外部キー参照など）に影響がないことを確認
3. 削除後の期待状態を確認するSELECT（実行SQL後に使う）

**UPDATE の場合**
1. 更新対象レコードの現在値を確認
2. 更新後の期待値が妥当であることを確認
3. 影響範囲（件数）を確認

**INSERT の場合**
1. 挿入先テーブルの構造・制約を確認
2. 重複・競合が無いことを確認
3. 参照整合性（外部キー先が存在するか）を確認

### stagingと本番の扱い

- **staging**: `query-db` スキルで接続して自動実行してよい（readonly）
- **production**: 確認クエリは実行してよい。実行SQLは出力するだけで**Claude自身は実行しない**（ユーザーが実行する）

---

## フェーズ 4: 実行SQLの生成・整備

### SQL生成方針

- チケットにSQLが既にある場合 → 内容をレビューし、問題があれば修正案を提示する
- チケットにSQLがない場合 → フェーズ3の確認結果をもとに生成する

### SQLの必須要件

1. **トランザクション**: 必ず `BEGIN;` / `COMMIT;` / `ROLLBACK;` で囲む
2. **コメント**: 各ステートメントに「何をするか」のコメントを記載
3. **安全ガード**: WHERE句に十分な絞り込み条件（ID指定など）を入れ、誤爆を防ぐ
4. **件数確認**: `-- → DELETE N であること` のようなコメントで期待件数を明示
5. **確認SELECT**: COMMIT前に結果確認のSELECTを含める

### SQLフォーマットルール（sql-formatスキルに準拠）

- キーワードは小文字
- 行頭カンマ（`,` で始める）
- `where 1=1` で条件を連結しやすくする（複数条件の場合）
- インデントは2スペース

---

## フェーズ 5: レビューMDの出力

### 出力先

`~/work/google_drive/db-apply/yyyymmdd/DB-XXXX_review.md`

yyyymmddは実行日、XXXXはチケット番号。

### MDの構成（簡潔に。ダラダラ書かない）

```markdown
# DB-XXXX: [チケットサマリー]

## 概要
[1〜2文。何を、なぜ実行するか]

## 対象
| 項目 | 値 |
|------|-----|
| 業態 | 〇〇（company_id: ...） |
| 店舗 | 〇〇（shop_id: ...） |
| テーブル | job_targets, job_statuses |
| 件数 | 各1行 |

## 確認フロー（実施済み）

### ✅ ステップ1: [確認内容]
```sql
-- 確認クエリ
SELECT ...;

結果: [実際の結果を貼り付け]
判定: 対象レコードが存在することを確認

✅ ステップ2: ...

...

実行SQL

BEGIN;

-- [処理の説明]
DELETE FROM ...
WHERE ...;
-- → DELETE 1 であること

-- 確認
SELECT ...;
-- [期待値の説明]

-- 問題なければ:
COMMIT;
-- 問題があれば:
-- ROLLBACK;

バックアップ

[削除・更新対象レコードの現在値。COMMITを取り消す場合の復元方法]

関連チケット

### 出力後の案内

> 「レビューMDを出力しました: `~/work/google_drive/db-apply/yyyymmdd/DB-XXXX_review.md`
> Jiraへの回答（コメント貼り付け等）はご自身でお願いします。」

---

## パーミッション

以下は自動で実行してよい（ユーザー確認不要）:
- Jiraチケットの読み取り（mcp__atlassian__getJiraIssue, searchJiraIssuesUsingJql）
- staging DBへのreadonly接続・クエリ実行
- `~/work/google_drive/db-apply/` への書き込み（レビューMD出力）
- 関連チケット・添付ファイルの読み取り

以下はユーザーに確認してから行う:
- production DBへのクエリ実行（確認SELECTであっても一言添える）
- Jiraへのコメント投稿（基本的にスキルは行わない）

---

## 注意事項

- **SQLは絶対に書き込みを実行しない**: productionでのINSERT/UPDATE/DELETEはスキルが実行しない。出力して「実行してください」と伝える
- **staging検証を原則とする**: 本番実行前にstagingで確認クエリを実行して事実を確かめる
- **UUIDは変わる**: staging/productionでIDが異なる可能性がある。確認クエリで特定してからSQLに反映する
- **スプレッドシートのSQLは必ずレビューする**: ユーザーが貼り付けたSQLをそのまま使わず、安全ガードが十分か確認する