エンジニア以外のメンバーとともに開発ワークフローを回すClaudeスキル

はじめに

こんにちは、Insight Edge の日下です。

ここ最近のコーディングAIエージェントの進化は目覚ましく、以下のような光景が当たり前になってきました。

プロダクトオーナーやUXデザイナがAIツールでプロトタイプを作る
議事録・仕様書・設計メモといったドキュメント系の成果物もAIで作成しgitで管理する

特にバイブコーディングの広がりで、エンジニア以外もソースコードの形で成果物を作ることが増えました。弊社では AIが文脈を理解しやすいように、プロダクトのソースコードだけでなくデザイン成果物や設計ドキュメント、意思決定の経緯などもGitやGitHubに集約しています。こうしてソースコードとドキュメントの両面から、 Gitリポジトリを触るエンジニア以外のメンバー が増えてきています。

このとき、従来からGit/GitHubを使うエンジニア側と、新たに使い始めた側のそれぞれに悩みが生まれます。

エンジニア側 — 開発フローの説明や救援作業（作業支援、誤コミットの修正）など、エンジニア以外のメンバーが慣れるまでサポート負荷が高くなる
開発に参加するメンバー側 — Git/GitHubの作法や開発フローを学ぶ負担と、それを意識することによるアイデア具現化スピードの鈍化

「AIに任せればベストプラクティスが守られるのでは？」と思いきや、そうでもありません。最近のAIモデルはGitやGitHubの良い作法を知っていますし、インターネットを探せば素晴らしいスキルも多々あります。しかし、開発するプロダクトの特徴やフェーズ、チームの大きさなどに応じて、現場に適した開発フローは様々であり、そこに開発チームの工夫が表れます。だからこそ、自分のチームに適した開発手順を言語化してスキルに固める必要がありました。

本記事では、エンジニア以外のメンバーも含む開発チームで、バイブコーディングの速さや気軽さも尊重しつつ、GitやGitHubをお行儀よく活用した開発フローを実現するために私が作り育てたClaudeスキルを題材に、その設計思想と中身、実際の使い勝手をニールセンのユーザビリティ10原則に照らし合わせて紹介します。

※本記事は Claude Code の Skill 機能を前提としています。また、/d の動作には git コマンドと GitHub CLI（gh コマンド）がセットアップ済みであることが必要です。

設計の3本柱

/d のdはdevelopからとっています。このスキルの設計には3つの軸があります。共通するのは、 作業者が意識して開発フローに合わせるのではなく、スキルを使っているだけで自然にルールを守れる という発想です。

A. バイブコーディングの手を止めない

アイデアを高速に具現化する人の手を、複雑な開発プロセスで遅くしない。

お行儀のためのチェックリストや規約を増やすほど、利用者は「考える前に手順を思い出す」モードに入ります。これは思いつきを高速に形にするUXデザイナやプロダクトオーナーには致命的です。/dスキルは 思考のリズムを止めない ことを最優先にします。

具体的には、手順を覚えてもらうのではなく スキル側がすべて代行する 設計にしました。たとえば、利用者が /d issue 42 と打つことでIssueに着手するときの定型作業を実行し、作業ブランチ作成・push・方針コメント投稿まで自動で走ります。

B. 使いながらGit/GitHubの作法に慣れる

細かい作法を習ってから使うのではなく、使いながら徐々に作法を体得する。

ブランチ・コミット・PR・rebase…とGitの概念を最初に全部説明されると、それだけで利用者は挫折します。一方で「教えなくていい」とすると、利用者はずっと作法を知らないまま、エンジニアの救援が必要な状態が続きます。

/d スキルは 「必要最低限のコマンドを使うだけで、結果としてお行儀よく作業できていた」 状態を作りつつ、 裏で何が起こったかは可視化する 設計にしました。/d issue 実行時に「ブランチを作りました」「PRを作成しました」とログが出るので、利用者は使い続けるうちに「これはブランチを切っていたのか」「これがDraft PRか」と自然に理解していきます。また、issueやcommitなど重要な用語はGit/GitHubのエコシステムに合わせることで、エンジニアと同じ言語で開発に参加できるようにしています。

C. 覚えなければならない知識を減らす

使う側が頭の中に抱える「知識量」をできる限り減らす。

利用者の負担は 「次に何のコマンドを打つか」「どのスキルを呼ぶか」を毎回思い出すこと にあります。これを減らすために2つの仕掛けを入れました。

個別スキルではなくサブコマンド方式 — /d todo /d issue /d commit …といった操作を /d 1つのスキルに統合することで、利用者は最低限 /d だけ覚えればよく、 /d 42番のIssueに着手 のように自然言語で意図を伝えるだけでも適切なサブコマンドが実行されます
次のアクションは選択肢で提示 — スキル実行の終わりには必ず次の候補を出すことで、利用者は「次に何をすればよかったっけ」と考えずに済みます（後述する「再生より再認」）

結果として、利用者が頭に抱える「Git作法 + コマンド体系 + チーム運用ルール」の知識セットが大幅に圧縮されます。 覚えるべきは /d という入口だけ という状態が、参加ハードルを最小化します。

`/d` スキルの構造

スキル本体は ~/.claude/skills/d/SKILL.md 1ファイルです。フロントマター + サブコマンドごとの手順記述で構成されます。全文は以下に折りたたんで載せておきます。

SKILL.md 全文（クリックで展開）

---
name: d
description: GitHub Issue・Pull Request・ブランチ操作・コミット等の作法を定義した開発ワークフロースキル
argument-hint: "<todo|new|issue|commit|pr|review|improve|help> [args...]"
allowed-tools: Bash, Agent, Read
---

GitHub を起点とした開発ワークフローをサブコマンドを指定して実行する。引数なしで `/d` と実行された場合は `/d help` として動作した上で、次の行動を提案する。

サブコマンドが指定されずに文が続く場合（例: `/d 42番のIssueに着手して`）は、テキスト内容から利用者の意図を解釈し、適切なサブコマンドにマッピングして実行する。利用者は厳密なサブコマンド名を覚えていなくてもよい。

## 出力ルール

### yes/no 質問
AIによる「〜してよいですか？」「〜しますか？」のような closed questionや許可確認の末尾には `(y/n)` を付け、ユーザの回答負荷を軽減する。「他に修正はありますか？」のような実質的Open Questionには付けない。

### 表・箇条書きへの識別子付与
表・箇条書き・選択肢など、複数項目が並ぶ出力には必ず連番や記号の識別子を振る。Issue番号やPR番号など既存の識別子がある場合はそれを使い、無い場合は左端に `No` 列を追加する。これにより、後の会話でユーザが番号で行を指定できるようにする。

### 次のアクションの提示
サブコマンドの終わりには、可能な限り次のアクションの候補を選択肢として提示する。利用者に「次に何をすればよいか」を思い出させるのではなく、提示された選択肢から選ばせる（再生より再認）。

## 不満・改善提案の案内

利用者が `/d` スキルの挙動に不満を表明した場合: `/d improve <内容>` でスキル改善Issueを起票する。

## 共通ルール

### 並列実行
依存関係のない複数のコマンド・API呼び出しは常に並列実行する。逐次実行しない。独立したコマンドを見つけたら積極的に並列化する。

### ブランチ切り替え前の確認
`git checkout` の前に `git status --porcelain` で未コミット変更を確認する。変更がある場合は選択肢を提示:

1. **コミットして続行**
2. **worktree で並列作業** — `git worktree add ../<リポ名>-<新ブランチ> -b <新ブランチ> origin/main` → 別セッションを案内
3. **中断**

### main 最新取り込み
作業ブランチで `/d issue`（既存ブランチ checkout 時）または `/d commit`（push 前）に実行する。originのmainブランチに対する遅れを確認し、遅れがあれば `git merge origin/main` を提案する。

### ブランチ命名規則
`CLAUDE.md` に命名規則の定義があればそれに従う。なければデフォルトとして `<prefix>/<issue番号>-<英語kebab-case 5語以内>` を使用する。prefix はIssueのラベル・内容から判断:

- `feat/` — 新機能
- `fix/` — バグ修正
- `nf/` — 非機能（インフラ等）
- `doc/` — ドキュメント
- `process/` — 開発プロセス関連（CI、Claudeスキル等）
- `misc/` — その他

Issue 番号がない場合は `<prefix>/<英語kebab-case 5語以内>` とする。

### PR マージ確認
PR が Ready かつ最新コミットに対するレビューでマージ可能と判定されている場合、`gh pr merge <PR番号> --merge --delete-branch` を提案する。適用タイミング: `/d commit` で Ready PR 作成後、`/d review` で Ready 化後、`/d pr` で Ready 化後。

### レビュー実行

レビューは **Claude のレビュー用サブエージェント** で実行する。実装したコンテキストとは別のサブエージェントで実行することで、客観的な指摘を得る。

他人の PR をレビューする場合は先に対象ブランチを取得する。
チェックアウト前に元ブランチ名を退避し、ダーティーツリーでないことを確認する:

```bash
ORIG_BRANCH=$(git branch --show-current)
git status --porcelain   # 出力ありなら未コミット変更あり
```

未コミット変更がある場合は「ブランチ切り替え前の確認」を適用する。クリーンな状態を確認したら既存ローカルブランチを破壊しない方法で取得する:

#### レビュー手順

1. `COMMIT_SHA=$(git rev-parse HEAD)` で SHA を取得。`git fetch origin main` 後、`git diff origin/main...HEAD` + `git log origin/main..HEAD --oneline` を取得。`OWNER_REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner)` で owner/repo も取得
2. Agent ツールでレビュー用サブエージェントを起動する（`run_in_background: true`）。プロジェクトの設計基準やレビューガイドライン（`CLAUDE.md`、レビュー用エージェント定義、`docs/` 配下のガイドライン等があれば参照）に従ってレビューさせる。プロンプトに `diff`, `commits`, `commit_sha`, `owner_repo`, `pr_number`, `pr_author`, `is_own_pr`, `is_draft`, `post_to_pr=false`, `defer_ready=true` を渡す
3. 完了を待ち、結果を会話に表示（指摘一覧 + 総合判定）
4. 自分の PR の場合は各指摘の妥当性を評価する
5. `post_to_pr=true` の場合は次の「PR への投稿」を実行

#### PR への投稿 (`post_to_pr=true`)

skill 側で投稿する（レビュー用サブエージェントは二重投稿回避のため `post_to_pr=false`）:

- **総評コメント**: `gh pr review <PR番号> --comment --body "<本文>"`（自分の PR）/ `--approve` / `--request-changes`（他人の PR）
- **インラインコメント**: `gh api repos/{owner}/{repo}/pulls/<PR番号>/comments` を使用。各コメントに `commit_id` (= `COMMIT_SHA`), `path`, `line`, `side` が必須

投稿後、自分の Draft PR でマージ可能（高指摘なし）なら Ready 化:
1. PR タイトルから `WIP:` 削除
2. 本文を `Summary / Related Issue / Test plan` テンプレートに更新（`Closes`/`Refs` は「Related Issue とクローズ判定」に従う）
3. `gh pr ready <番号>`

### 変更確認
`git status --porcelain`、`git diff`、`git diff --cached` を3つ並列実行する。変更がなければエラー。

### ステージング判断
以下の懸念がないか確認する:

- `.env`、クレデンシャル系（`credentials.json`、`cred-*`、`*.pem`、`*.key` 等）
- `.gitignore` すべきファイル（`node_modules/`、`dist/`、`__pycache__/`、`.venv/` 等）
- ブランチ名から推測される作業内容と無関係なファイル

懸念がなければ全ファイルを自動ステージング（確認不要）。懸念があれば明示してユーザーに確認する。

### コミットメッセージ生成
変更内容から日本語で簡潔に自動生成する（確認不要）。ブランチ名に Issue 番号があれば `#<番号>` を含める。

## サブコマンド

### `/d todo`

自分が対応すべきものを表示する。
現在作業中のタスクがあるかどうかと、GitHub上でアサインされたIssue、メンション、レビュー依頼を確認する。

1. **2つを並列実行**:
   - (A) gitコマンドで現在の作業状況を確認 `git fetch origin && git branch --show-current && git status --porcelain`
   - (B) ghコマンドでGitHubを確認。GraphQL で一括取得:
     ```bash
     OWNER_REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
     gh api graphql -f query="{
       assignedIssues: search(query: \"repo:${OWNER_REPO} assignee:@me is:open is:issue\", type: ISSUE, first: 20) { nodes { ... on Issue { number title labels(first: 5) { nodes { name } } updatedAt } } }
       reviewRequested: search(query: \"repo:${OWNER_REPO} review-requested:@me is:open is:pr\", type: ISSUE, first: 20) { nodes { ... on PullRequest { number title author { login } updatedAt } } }
       mentions: search(query: \"repo:${OWNER_REPO} mentions:@me is:open\", type: ISSUE, first: 20) { nodes { ... on Issue { number title updatedAt } } }
       myOpenPRs: search(query: \"repo:${OWNER_REPO} is:open is:pr author:@me\", type: ISSUE, first: 20) { nodes { ... on PullRequest { number headRefName isDraft } } }
     }"
     ```

2. **fetch 完了後の確認**:
   - 現在のブランチが main なら `git rev-list HEAD..origin/main --count` で同期状態を確認。作業ブランチなら `gh pr view --json number,title,state,mergedAt,url` で PR 状態を確認
   - アサイン済み Issue について `git branch -r` を1回実行し、各 Issue 番号に対して `origin/*/<issue番号>-*` のパターンでブランチを探す → `myOpenPRs` から PR 有無を判定 → 未着手 / ブランチあり / PR #番号 (Draft|Ready)

3. **出力フォーマット**:
   ```
   ## 現在のブランチ
   - ⚠️/✓/🔧 の状態表示

   ## アサイン済み Issue
   | # | タイトル | 状態 | ラベル | 更新日 |

   ## レビュー依頼
   | # | タイトル | 作成者 | 更新日 |

   ## メンション
   | # | タイトル | 更新日 |
   ```

4. **次のアクション提案**: 優先度の高い順に次にやるべき作業を提案する。「main に戻りましょう」は提案しない（作業ブランチで `/d issue` を実行すれば自動的に origin/main ベースのブランチが作成されるため）

### `/d new <タイトル>`

新しい Issue を起票する（自分が取り組むとは限らない）。

1. 引数を要約してタイトルにする（なければユーザーに聞く）
2. `gh issue list --state open --json number,title` で既存の類似 Issue をチェック
3. 説明文の案を生成してユーザーに提示（経緯・現状・期待効果を含める）
4. `gh label list --json name,description` で適切なラベルを判定
5. `gh issue create --title "..." --body "..." --label "..."` で作成
6. URL を表示
7. **次のアクションを必ず選択肢として提示**（省略不可）:
   1. 自分をアサインして今から取り組む → `/d issue` の処理を続行
   2. 自分をアサインして作業に戻る → `gh issue edit <番号> --add-assignee "@me"` のみ
   3. 他の人をアサインする（対象者を指定）
   4. アサインせず終了

### `/d issue <番号またはURL>` （エイリアス: `/d i`）

既存 Issue に自分が取り組む。ブランチ作成・プッシュで着手を宣言してから方針コメントを投稿する。

1. Issue 番号を特定し、内容取得 + 自分をアサイン:
   ```bash
   gh issue view <番号> --json title,body,labels,assignees
   gh issue edit <番号> --add-assignee "@me"
   ```
2. `git fetch origin && git branch -a --list "*/<issue番号>-*"` で既存ブランチを確認:
   - **あり**: 他人のコミットがあればユーザーに確認。なければチェックアウト + 「main 最新取り込み」を実行
   - **なし**: Issue からブランチ名を生成（「ブランチ命名規則」参照）。**確認不要で** 作成・push する:
     ```bash
     git checkout -b "<prefix>/<番号>-<説明>" origin/main
     git push -u origin HEAD
     ```
3. 方針・実装計画をユーザーに提示 → 承認後 `gh issue comment` で投稿（投稿の確認不要）

**ここがポイント**: ブランチを push してIssueコメントを残すことで、他メンバーに「自分が #<番号> に着手中」が見えるようになる。重複着手を未然に防ぐ。

### `/d commit`

変更をコミット・プッシュし、PR が未作成なら Draft PR も作成する。

**ブランチ判定:**

- **`main` の場合**: 変更内容から prefix を判断し、ブランチ名を生成 → `git checkout -b "<prefix>/<説明>"` → 次の手順へ
- **作業ブランチの場合**: そのまま次の手順へ

**手順:**

1. 変更確認（共通ルール）
2. ステージング判断（共通ルール）
3. ブランチ名から Issue 番号を抽出（`feat/123-xxx` の `/` の後の数字）
4. コミットメッセージ生成 → `git add && git commit`
5. main 最新取り込み（共通ルール）
6. `git push -u origin HEAD`
7. `gh pr list --head <ブランチ> --json number,title,isDraft,url,author` で PR 確認
8. **レビュー実行**（`is_own_pr=true`, `post_to_pr=true`）:
   - **PR がない場合**: `/d pr` に従ってDraft PR 作成 → レビュー実行 — 初回レビューは精度優先
   - **PR が既存の場合**: 追加コミットの差分をレビュー
9. PR マージ確認（共通ルール）
10. 結果表示: コミットハッシュ・メッセージ、プッシュ先、PR URL、レビュー結果

### `/d pr`

Pull Requestを作成。または、作成済のPRに対して必要なアクションをする。

1. ブランチが `main` ならエラー
2. `gh pr view --json number,title,isDraft,url` で既存 PR 確認
3. **PR あり**: PR コメント確認 → 未対応あれば対応
4. `git fetch origin main` → `git log origin/main..HEAD --oneline` + `git diff origin/main...HEAD --stat` で差分取得
5. PR タイトル（70文字以内）と本文を生成（`概要 / 関連Issue / やったこと / やっていないこと`。`関連Issue` は共通ルールに従い `Closes`/`Refs`）
6. `git push -u origin HEAD` → PR なしなら Draft 作成、あればタイトル・本文を更新
7. レビュー実行（`is_own_pr=true`, `post_to_pr=true`, `effort=high`）→ 結果表示
8. URL 表示
9. PR マージ確認（共通ルール）

### `/d review`

作業ブランチの変更をレビュー。PR があればレビューとして投稿可能。

1. ブランチが `main` ならエラー
2. `gh pr view --json number,title,url,isDraft,author` で PR 確認。`gh api user --jq .login` と `author.login` を比較して `is_own_pr` を決定
3. レビュー実行（`is_own_pr=<判定>`, `is_draft=<取得値、なければtrue>`, `post_to_pr=false`, `effort=high`）→ 結果表示
4. **PR あり**: 投稿するか確認 → 投稿する場合は「PR への投稿」を実行（`post_to_pr=true`）。Draft かつマージ可能なら Ready 化が走る
5. PR マージ確認（共通ルール）

### `/d improve <改善内容>`

`/d` スキル自体の改善提案を Issue 起票する。

1. 引数があればそれを改善内容にする。引数がない場合は直前の会話の文脈（不満や違和感の表明、うまくいかなかった操作など）から推測する
2. 改善内容をもとに簡潔な Issue タイトル（日本語）を生成
3. Issue を作成:
   ```bash
   gh issue create --title "<タイトル>" --body "$(cat <<'EOF'
   ## 改善内容

   <スキル改善内容>

   ## 代替案

   <claudeの設定など、スキル自体の改善以外で実現可能な代替案>

   EOF
   )"
   ```
4. 作成した Issue の URL を表示

### `/d help`

以下をそのまま出力する:

```
## 開発プロセス

### (1) アサインされたタスクに取り組む
1. `/d` で自分のタスクを確認する
2. `/d issue <番号>` で Issue に着手する（アサイン→ブランチ作成→方針コメント）
3. 実装する
4. `/d commit` でコミット・プッシュ・PR作成
5. `/d review` でレビュー・Ready化

### (2) 新しい課題を起票する
`/d new <タイトル>` で Issue を作成する。自分で取り組むかどうかはその場で選択できる。

### (3) Issue を立てずに実装する
1. 実装する（main ブランチ上でも `/d commit` が自動でブランチを作成する）
2. `/d commit` でコミット・プッシュ・PR作成
3. `/d review` でレビュー・Ready化

### (4) このスキルの改善リクエスト
`/d improve <不満点や改善案>` で改善提案を Issue 起票する。

## コマンド一覧

| コマンド | 説明 |
|---|---|
| `/d` | `/d help` と同じ（サブコマンド省略時） |
| `/d todo` | 自分のアサインタスク・メンション・レビュー依頼を一覧 |
| `/d new <タイトル>` | 新規 GitHub Issue を起票 |
| `/d issue <番号>` (`/d i`) | 既存 Issue に着手（アサイン→ブランチ作成→方針コメント） |
| `/d commit` | コミット→push→Draft PR作成→AIレビュー |
| `/d pr` | PR 作成・更新 |
| `/d review` | 作業内容のレビュー |
| `/d improve <内容>` (`/d imp`) | スキル自身の改善提案を Issue 起票 |
| `/d help` | このヘルプを表示 |

## ヒント

- 厳密なサブコマンド名を覚えていなくても、`/d 42番のIssueに着手して` のように自然言語で指示すれば適切なサブコマンドが実行される
- 困ったら `/d` だけ打って、表示された選択肢から選べばよい
```

サブコマンド一覧

サブコマンド	役割
`/d`（引数なし）	`/d help` と同じ
`/d todo`	自分のアサインタスク・メンション・レビュー依頼を一覧
`/d new <タイトル>`	新規Issueを起票
`/d issue <番号>`	既存Issueに着手（アサイン→ブランチ作成→push→方針コメント）
`/d commit`	コミット→push→Draft PR作成→AIレビュー
`/d pr`	PRの作成・更新
`/d review`	作業内容のレビュー
`/d improve <内容>`	スキル自身の改善提案をIssue起票
`/d help`	全コマンド一覧と典型フローを表示

個別スキルではなくサブコマンド方式にしたことで、利用者は 「困ったら /d に続けてやりたいことを伝える」だけ で、スキルで規定したルールに則れます。

主役は `/d todo` / `/d issue` / `/d commit` / `/d review` の4つ

主役サブコマンドは、 作業者がもともと意識している作業アクション に対応します。

自分のタスクを確認する
着手する
成果物を提出する
レビューする

いずれも Git/GitHubとは無関係に作業過程に存在するアクション です。これらを主役に据え、ブランチ作成・PR作成・mainブランチ取り込みといったGit/GitHub起因の操作は内側に隠してAIが自動化します。

さらに /d todo はIssueのアサイン情報に基づいて着手すべきIssueを提案し、/d commit はコミットからPR作成、AIレビューまでまとめて実行するため、 典型フローで利用者が実際に打つのは /d todo→ /d commit の2つで済むことも多い です。

動かしてみる：2つの典型シナリオ

入口は2通りありますが、 どちらも最後は /d commit に合流し、PRベースの開発フローが進む のがポイントです。

シナリオA：Issue駆動で開発を進める場合

UXデザイナの佐藤さんに「ログイン画面の入力欄の余白を調整してほしい」という Issue #58 がアサインされた。

Step 1: /d todo で確認し、そのまま着手する

> /d todo

スキルは「現在のブランチ・アサイン済みIssue・レビュー依頼・メンション」を並列取得して整形表示し、 最後に「次に何をすべきか」まで提案します。

## 現在のブランチ
- ✓ main（クリーン）

## アサイン済み Issue
| #  | タイトル                              | 状態   | ラベル |
|----|---------------------------------------|--------|--------|
| 58 | ログイン画面の入力欄の余白を調整したい  | 未着手 | feat   |

（レビュー依頼・メンションはありません）

---
未着手の Issue が1件あります。優先度の高い #58 から着手しますか？
（アサイン → ブランチ作成 → push → 方針コメント まで実行します） (y/n)

/d todo は一覧を並べて終わりではなく、 「未着手の #58 から着手しますか？」と次の一手まで提案 します。利用者は表を眺めて「次に何をしよう」と考える必要がありません。ここで y と答えれば、着手処理がそのまま走ります。

# 「はい」と答えた後にスキルが実行する内部処理
gh issue edit 58 --add-assignee "@me"
git checkout -b "feat/58-login-margin" origin/main
git push -u origin HEAD
gh issue comment 58 --body "<実装方針>"

ブランチがpushされた瞬間、GitHubの他メンバーには「佐藤さんが #58 着手中」が見えます。 これだけで重複着手を大きく減らせます。

着手の入口は2通り、どちらでもよい — Issue番号が最初からわかっているなら、/d todo を経由せず /d issue 58 を直接打っても同じ着手処理に入ります。「/d todo の提案に乗る」か「/d issue を直接打つ」かは、利用者が好きな方を選べます。

Step 2: 実装 → /d commit

佐藤さんはClaude Codeに実装を任せ、完了したら /d commit を実行。 コミット → push → Draft PR → AIレビュー → Ready化 → マージ → Issueクローズ までが一気に流れます。

結局、利用者が打つのは /d todo（提案に乗って着手）→ /d commit の実質2コマンドだけ。ブランチ名やコミットメッセージ、PR本文を書く場面はありません。

補足：Issueがまだ無いときは `/d new` で起票する

シナリオAはアサイン済みの Issue #58 から始めましたが、そもそも取り組みたいことがまだIssueになっていないこともあります。その場合は /d new に概要を渡すだけで起票できます。

> /d new ログイン画面の入力欄の余白を調整したい

スキルは既存の類似Issueを確認したうえで、タイトル・説明文・ラベルの案を生成して起票し、作成後に 「誰が取り組むか」を選択肢で提示 します。

Issue #59 を作成しました： https://github.com/<owner>/<repo>/issues/59

続けてどうしますか？
1. 自分をアサインして今から取り組む（そのまま着手処理へ）
2. 自分をアサインして後で取り組む
3. 他の人をアサインする
4. アサインせず終了

1 を選べば、そのまま /d issue 相当の着手処理（アサイン → ブランチ作成 → push → 方針コメント）に流れます。 「起票 → 着手」がコマンドを打ち替えずに一本でつながる のがポイントです。起票だけして他の人に任せたい（3）、あとで自分でやる（2）といった分岐も、その場で選ぶだけで済みます。

また /d new は、機能追加のようなきちんとしたIssueだけでなく、 「このドキュメントを直してほしい」「Claudeのスキルを修正して」といったちょっとした作業依頼 にも気軽に使えます。口頭やチャットで流れがちな細かい依頼もIssueとして残り、依頼のハードルが下がります。さらに 受けた側が /d issue で着手するときには、AIがIssue本文（背景・経緯・期待する結果）を文脈として読み取れます。チャットの断片的なやり取りと違い、要件がまとまっているぶん、AIは意図を汲んだ実装や方針コメントを返しやすくなります。これは冒頭で触れた 「AIが文脈を理解しやすいようにGit/GitHubへ集約する」 流れに、気軽な起票がそのまま乗る形です。

シナリオB：Issueを立てず、思いついた改善案をいきなり作り始める場合

UXデザイナの佐藤さんは、ふと思いついたUIの改善案をその場でClaude Codeに作らせてみた。Issueも立てず、ブランチも main のままローカルに修正案ができあがっている。仕上がりが良かったので、そのまま /d commit を実行する。

> /d commit

このとき、スキルは変更内容を確認し、

変更内容から適切なブランチ名（ fix/update-signup-form-warning-message など）を判断
自動でブランチを切ってから コミット
そのブランチをpushし、Draft PRを作成
続けて AIレビューが走り、変更内容に問題がなければReady化

シナリオAと同じく、/d commit の先はDraft PR作成からAIレビュー・Ready化まで一気に流れます。佐藤さんは「ブランチを切り忘れた」「Issueを立て忘れた」と慌てる必要がなく、思いついた改善案を形にすることだけに集中できます。 「アイデアを止めずに作り、後から正しい形に整える」 ── バイブコーディングのリズムを保ったまま、結果的にお行儀の良い形に着地します。

スキル改善の経緯と考え方

/d は最初から今の姿だったわけではありません。初期はもっと細かく「ブランチを作る」「Pull Requestを作る」といった Gitの操作にも1つずつコマンドを紐づけており、個々の操作をAIで補完しているだけでした。エンジニアにとっては違和感がなくとも、エンジニア以外の利用者から見ると どのコマンドを打つか選ぶ時点でGitの知識が必要 で、開発フローの作法を覚える負担が残っていました。

そこで 「ツールではなく目的中心でスキルのあり方を決める」 ことを強く意識し、使いやすさを追求して改善を重ねました。判断軸として参照したのが、UX設計の古典である ヤコブ・ニールセンのユーザビリティ10原則 です。スキル開発は「自分が便利な機能を足す」方向に流れがちですが、10原則に照らすことで「これは利用者目線の仕様になっているか？」を問い直せました。

10原則は以下のとおりです（和訳は本記事での表記）。

Visibility of system status / 状態の可視性
Match between the system and the real world / 現実世界との調和
User control and freedom / ユーザーコントロールと自由
Consistency and standards / 一貫性と標準
Error prevention / エラー予防
Recognition rather than recall / 再生より再認
Flexibility and efficiency of use / 柔軟性と効率性
Aesthetic and minimalist design / 最小限デザイン
Help users recognize, diagnose, and recover from errors / エラー回復
Help and documentation / ヘルプとドキュメンテーション

この章では、特に大きく効いた 4つの改善 を、対応する原則とともに紹介します。

改善1：コマンドを「Git操作」から「作業アクション」へ（原則2 現実世界との調和）

最大の改善が、コマンド体系そのものの組み替えです。

Before — ブランチ作成・コミット・PR作成…と、Git/GitHubの操作を利用者が1つずつ呼び出す体系
After — /d todo（見る）・/d issue（着手）・/d commit（提出）・/d review（レビュー）の4つ。ブランチ作成やPR作成はこの内側に隠れる

原則2「現実世界との調和」は、 利用者が現実世界から類推するイメージにシステムを合わせよ という原則です。タスクを見る・着手する・成果物を提出する・レビューする ── いずれもGit/GitHubに関係なく開発の作業過程に存在するアクションであり、利用者が説明されなくてもする行動です。ここに揃えたことで「開発ツールの使い方を学ぶ」という壁が解消されました。

改善2：「誰が何をやっているか」が自然に見える（原則1 状態の可視性）

原則1「状態の可視性」は、 システムの状態を利用者に常に見えるようにせよ という原則です。/d ではこれを個人の画面にとどめず、 チームに対する作業状況の可視化 に広げました。改善1で「着手」の内側に束ねた一連の操作が、そのまま 着手宣言プロトコル として機能します。

/d issue 58 を実行した時点で、 アサイン + 作業ブランチのリモートpush + 方針コメントの投稿 が走ります。コミットがまだ無くても「私が #58 やってます」が周囲に見えるようになります。地味ですが、これだけで 実装を二重に進めてしまう事故 を大きく減らせます。自分から「やってます」と声を上げなくても着手した時点で自然に共有され、チーム全体での作業状況が見えやすくなります。

改善3：誤操作は注意ではなく仕組みで防ぐ（原則5 エラー予防）

原則5「エラー予防」は、 丁寧な注意喚起よりも、そもそもエラーが起きない設計を優先せよ という原則です。Gitを使っていて起きがちな失敗に対して、「気を付けてね」と促すのではなく仕組みで潰します。/d スキルを使いながら取り入れた予防の仕組みをいくつか紹介します。

#	起きがちな失敗	スキルでの解決
1	同じ内容のIssueを重複起票	起票前に既存Issueとの類似をチェック
2	mainで作業して直push	変更を検知し、自動でブランチを切ってからコミット
3	`test` `tmp` 等でブランチ名が乱立	Issue・変更内容から命名規則に沿って自動命名
4	同じIssueを別ブランチで重複着手	着手時に既存ブランチを確認、他人のコミットがあれば確認
5	`.env`・`node_modules` 等を誤commit	ステージング前に自動検知して確認
6	Issueと無関係なファイルが混入	ブランチ名から推測した作業内容と照合して警告
7	未コミット変更を抱えたままcheckout	切り替え前に確認し、コミット/中断を提示
8	ローカルのmainが古いまま進めてconflict地獄	作業着手時やpush前にmainとの差を自動チェックし取り込みを提案
9	Issue・コミット・PRの説明の作文が面倒で省略・雑になる	変更内容からAIがタイトル・本文・コミットメッセージ・PR説明を自動作文

改善4：思い出させない・迷わせない（原則6 再生より再認）

原則6は、認知科学でいう 「再生（recall）より再認（recognition）の方が遥かに楽」 という性質に基づく原則です。「次に何をすべきか」を利用者が思い出す（再生）必要をなくし、 提示された選択肢から選ぶ（再認） だけで正しい手順を歩めるようにします。

「次にやること」を選択肢で提示する

サブコマンドの終わりには、必ず 次の候補アクションを選択肢で提示 します。

/d todo の最後 → 優先度の高い順に次のタスクを提案
/d new で起票後 → 「自分をアサインして取り組む / アサインのみ / 他の人にアサイン / アサインしない」
/d commit のレビュー完了後 → 「マージしますか？ (y/n)」

利用者は「次に何をすればよかったっけ」と考える必要がなく、選ぶだけで正しい手順に乗れます。

リスト出力に必ず識別子を振る

「選ぶだけ」のやり取りを支えるため、表・箇条書き・選択肢など複数項目が並ぶ出力には、 必ず連番や記号の識別子を振る ルールにしました。Issue番号のような既存IDがあればそれを使い、無ければ連番を振ります。たとえば実装前に手順の計画を出させると、こうなります。

実装計画:
1. 入力欄コンポーネントの余白を変数化
2. ログイン画面へ適用
3. モバイル表示のスタイル調整
4. 他画面のフォームへ横展開
5. 不要になった旧スタイルの削除

どこまで進めますか？

地味ですが効果は大きく、利用者は 「一旦3まで進めて」「4と5は不要」 のように番号だけで指示できます。AIとのチャットでは対象を言葉で説明し直したり長い引用をコピペしたりが負担になりがちですが、識別子があるとやり取りが一気に短くなります。

10原則ダイジェスト：残りの原則も設計に対応づける

改善1〜4で使った原則（1・2・5・6）以外も、/d の設計判断のあちこちに対応しています。残り6つをダイジェストで紹介します。

原則3 ユーザーコントロールと自由 — Issue起点のフローに限定せず、mainでの思いつき着手も許容。破壊的操作の前には必ず (y/n) 確認
原則4 一貫性と標準 — issue commit などの用語は技術側に合わせ、利用者の用語習得やエンジニアとの意思疎通を重視
原則7 柔軟性と効率性 — 初心者は /d todo の提案に乗るだけで着手まで進み、慣れたら /d issue を直接打つ・エイリアス（/d i）を使うなど効率化できる。さらに /d improve でスキル自体を進化させられる
原則8 最小限デザイン — 覚えるべきコマンドを少なくし、自然言語でも動くようにすることで、スキルの使い方をシンプルに
原則9 エラー回復 — ワークフロー操作をAIが実施することで、エラー時もAIが能動的に調査・回復できる。使いづらさがあれば /d improve で不満を改善案としてIssue化できる
原則10 ヘルプとドキュメンテーション — /d help で全コマンドと典型フローを表示

おわりに

本記事では、Git/GitHubを使った開発フローをエンジニア以外のメンバーと協働して進めるためのスキルについて紹介しました。エンジニア以外のメンバーとともに開発するチームで、全員が安心して開発できる環境づくりの一助になれば幸いです。「こうしたらもっと良くなる」「自分のチームではこうしてる」などがあれば、是非コメントください！

Insight Edge Tech Blog

エンジニア以外のメンバーとともに開発ワークフローを回すClaudeスキル

はじめに

目次

設計の3本柱

A. バイブコーディングの手を止めない

B. 使いながらGit/GitHubの作法に慣れる

C. 覚えなければならない知識を減らす

`/d` スキルの構造

サブコマンド一覧

主役は `/d todo` / `/d issue` / `/d commit` / `/d review` の4つ

動かしてみる：2つの典型シナリオ

シナリオA：Issue駆動で開発を進める場合

補足：Issueがまだ無いときは `/d new` で起票する

シナリオB：Issueを立てず、思いついた改善案をいきなり作り始める場合

スキル改善の経緯と考え方

改善1：コマンドを「Git操作」から「作業アクション」へ（原則2 現実世界との調和）

改善2：「誰が何をやっているか」が自然に見える（原則1 状態の可視性）

改善3：誤操作は注意ではなく仕組みで防ぐ（原則5 エラー予防）

改善4：思い出させない・迷わせない（原則6 再生より再認）

「次にやること」を選択肢で提示する

リスト出力に必ず識別子を振る

10原則ダイジェスト：残りの原則も設計に対応づける

おわりに

はじめに

目次

設計の3本柱

A. バイブコーディングの手を止めない

B. 使いながらGit/GitHubの作法に慣れる

C. 覚えなければならない知識を減らす

/d スキルの構造

サブコマンド一覧

主役は /d todo / /d issue / /d commit / /d review の4つ

動かしてみる：2つの典型シナリオ

シナリオA：Issue駆動で開発を進める場合

補足：Issueがまだ無いときは /d new で起票する

シナリオB：Issueを立てず、思いついた改善案をいきなり作り始める場合

スキル改善の経緯と考え方

改善1：コマンドを「Git操作」から「作業アクション」へ（原則2 現実世界との調和）

改善2：「誰が何をやっているか」が自然に見える（原則1 状態の可視性）

改善3：誤操作は注意ではなく仕組みで防ぐ（原則5 エラー予防）

改善4：思い出させない・迷わせない（原則6 再生より再認）

「次にやること」を選択肢で提示する

リスト出力に必ず識別子を振る

10原則ダイジェスト：残りの原則も設計に対応づける

おわりに

`/d` スキルの構造

主役は `/d todo` / `/d issue` / `/d commit` / `/d review` の4つ

補足：Issueがまだ無いときは `/d new` で起票する