seika139/scaffold

<!-- codex-profile-generated-from-prompt: prompts/scaffold.md -->

scaffold

この skill は Claude command /scaffold から変換した Codex 用 command skill です。

Codex での呼び出し

Codex CLI では /scaffold ではなく、$scaffold または /skills からこの skill を呼び出してください。 引数は $scaffold の後ろに自然文として続けます。

$scaffold <arguments>

元 prompt 内の $ARGUMENTS や slash command 表記は、$scaffold の後ろに書かれた引数として解釈してください。 Claude 専用の allowed-tools メタデータや ! command interpolation は Codex では自動適用されないため、必要な情報は通常の shell command で確認してください。

元 prompt

Scaffold

「こういうサービスを作りたい」という方向性から、技術設計ドキュメントと 実行可能な Issue セットを生成する。

目的

サービス構築の初期段階で必要な設計判断の叩き台を作り、人間の思考を加速する。 0 からの設計でも、チームの既存パターンを分析して一貫性のある提案をする。

引数のパースルール

/scaffold <作りたいものの説明> [--repo <owner/repo>] [--reference <参考リポジトリ>]

• 第1引数: 作りたいものの自然言語記述
• --repo: 設計対象のリポジトリ（既存リポジトリに機能追加する場合）
• --reference: 参考にするリポジトリ（省略時はカレントリポジトリ。Organization 内の他リポジトリも指定可能）

例

/scaffold "特許文書を検索・要約できるチャットボット"
→ 組織の既存リポジトリを分析して技術設計を提案

/scaffold "既存の検索をベクトル検索に置き換える" --repo org/repo
→ 既存コードベースを分析して移行設計を提案

/scaffold "管理画面を作りたい" --reference org/repo
→ 既存フロントエンドのパターンを参考に設計

/scaffold "Slack 通知機能を追加したい"
→ 機能追加の設計と Issue セットを生成

---

Step 1: 方向性の理解

1-1: ユーザーの入力を構造化する

入力から以下の情報を抽出する。不明な点はユーザーに質問する。

• 何を作るか: サービス/機能の概要
• 誰が使うか: ユーザーの種類（エンドユーザー、開発者、管理者）
• 規模感: 新規サービス / 既存サービスへの機能追加 / リファクタリング
• 制約: 既知の技術的制約やビジネス要件

1-2: 足りない情報を最小限の質問で補う

質問は 最大 3 つまで に絞る。判断材料が不足していても、仮定を置いて進め、 設計ドキュメントの中で「ここは要判断」と明示する方がよい。

いくつか確認させてください:

1. {質問1}
2. {質問2}
3. {質問3}

回答をいただければ設計に反映します。
分からない部分は仮置きで進めて、設計ドキュメント内で明示します。

---

Step 2: 既存パターンの分析

2-1: 参考リポジトリの調査

--reference で指定されたリポジトリ、またはカレントリポジトリの構造を分析する。 Organization 内の複数リポジトリを横断的に調査してもよい。

調査項目:

• 技術スタック: 言語、フレームワーク、主要ライブラリ
• ディレクトリ構造: レイヤー設計のパターン
• 設定管理: 環境変数、設定ファイル、シークレット管理
• CI/CD: ワークフロー、デプロイパイプライン
• インフラ: AWS サービス構成（CDK / Terraform の定義があれば）
• テスト: テスト戦略、使用ツール
• コード規約: linter / formatter 設定

2-2: チーム共通パターンの抽出

Organization 内で共通して使われているパターンを特定する:

# .github リポジトリの reusable workflows を確認
gh api repos/{owner}/.github/contents/.github/workflows --jq '.[].name' 2>/dev/null

# 主要リポジトリの技術スタックを確認
for repo in $(gh repo list {owner} --limit 10 --json name --jq '.[].name'); do
  echo "=== $repo ==="
  gh api "repos/{owner}/$repo/contents/pyproject.toml" --jq '.content' 2>/dev/null | base64 -d | head -5
  gh api "repos/{owner}/$repo/contents/package.json" --jq '.content' 2>/dev/null | base64 -d | head -5
done

---

Step 3: 設計ドキュメントの生成

以下の構造で ADR（Architecture Decision Record）風のドキュメントを生成する。

# 設計ドキュメント: {サービス/機能名}

## 1. 概要

### 背景

{なぜこれを作るのか}

### ゴール

{達成したいこと}

### スコープ外

{今回やらないこと（明示的に除外するもの）}

## 2. 技術スタック

| レイヤー       | 技術           | 選定理由                                 |
| :------------- | :------------- | :--------------------------------------- |
| 言語           | {言語}         | {理由：チームの既存パターンに合わせる等} |
| フレームワーク | {FW}           | {理由}                                   |
| DB             | {DB}           | {理由}                                   |
| インフラ       | {AWS サービス} | {理由}                                   |
| CI/CD          | {ツール}       | {理由}                                   |

### 選定の判断基準

- チームの既存スキルセットとの親和性
- 組織の reusable workflows との互換性
- 運用・保守コスト

## 3. アーキテクチャ

### システム構成図

{テキストベースの構成図}

### ディレクトリ構造

{提案するディレクトリ構造}

### データフロー

{主要なデータの流れ}

## 4. 要判断事項

{仮置きにした部分のリスト}

| #   | 判断事項   | 仮置きの値 | 判断に必要な情報           |
| :-- | :--------- | :--------- | :------------------------- |
| 1   | {判断事項} | {仮の選択} | {何が分かれば決められるか} |

## 5. 実装計画

### フェーズ分割

| フェーズ | 内容       | 工数目安 | 前提条件        |
| :------- | :--------- | :------- | :-------------- |
| 1        | {基盤構築} | {M}      | なし            |
| 2        | {コア機能} | {L}      | フェーズ 1 完了 |
| 3        | {UI/統合}  | {L}      | フェーズ 2 完了 |

### Issue 一覧（次の Step で詳細化）

---

Step 4: 設計ドキュメントのレビュー

生成した設計ドキュメントをユーザーに提示し、フィードバックを受ける。

上記の設計ドキュメントを確認してください。

- 技術スタックの選定に問題はありますか？
- 「要判断事項」で決められるものはありますか？
- フェーズ分割の粒度は適切ですか？
- 追加で考慮すべき制約はありますか？

フィードバックを反映した上で、具体的な Issue セットを生成します。

修正の要望があれば設計ドキュメントを更新する。 このステップは省略しない（設計の合意なしに Issue を作ると手戻りが大きい）。

---

Step 5: Issue セットの生成

設計ドキュメントのフェーズ分割に基づいて、具体的な Issue 草案を生成する。

Issue の粒度

• 1 Issue = 1 PR で完結する粒度にする
• 工数目安 S〜M（数時間〜1日）が理想
• L 以上のものはさらに分割を検討する

Issue 間の依存関係

Issue の依存関係を明示する。依存関係は Issue body のチェックリストで表現する。

## 概要

{概要}

## 前提

- [ ] #{依存する Issue 番号}: {タイトル}

## 完了条件

- [ ] {完了条件}

ユーザーへの確認

設計ドキュメントから以下の Issue セットを生成しました:

フェーズ 1: 基盤構築
  #1: {タイトル} (S)
  #2: {タイトル} (M) → #1 に依存

フェーズ 2: コア機能
  #3: {タイトル} (M) → #2 に依存
  #4: {タイトル} (S) → #2 に依存（#3 と並列可能）

全 {N} 件の Issue を起票してよろしいですか？
修正や追加があれば教えてください。

---

Step 6: Issue の起票

ユーザーの承認を得たら、依存関係の順序に従って Issue を起票する。

gh issue create \
  --repo {repo} \
  --title "{タイトル}" \
  --body "$(cat <<'EOF'
## 概要

{概要}

## 前提

{依存 Issue がある場合はチェックリスト}

## 完了条件

- [ ] {完了条件}

## 技術的な補足

{実装のヒント}

---
*🏗️ `/scaffold` による設計から起票*
*設計ドキュメント: {設計ドキュメントの場所 or 親 Issue の参照}*
EOF
)"

起票後の処理

• フェーズごとの親 Issue を作成し、個別の Issue を Sub Issue として紐づけることを検討する
• 設計ドキュメントは最初の Issue の body に含めるか、リポジトリの docs/ に PR として追加する

---

Step 7: 報告

🏗️ /scaffold 完了

対象: {サービス/機能名}
設計ドキュメント: {設計ドキュメントの場所}
起票した Issue: {起票数}件

フェーズ 1: 基盤構築
  - #{番号}: {タイトル} ({URL})
  - #{番号}: {タイトル} ({URL})

フェーズ 2: コア機能
  - #{番号}: {タイトル} ({URL})
  ...

次のステップ:
  1. 「要判断事項」を確認・決定する
  2. フェーズ 1 の Issue から `/solve-issue` で実装を開始する