Skills

/shape

要望を実装可能な仕様に整える。要件深掘り・画面遷移・API設計・ワイヤーフレームまで。

About

要望を実装可能な仕様に整える。要件深掘り・画面遷移・API設計・ワイヤーフレームまで。

Category:Planning
Scope:universal

Usage

Use when user says "shape", "要件定義", "仕様を詰める", "機能設計", "これ作りたい".

Requirements

MCP SERVERS

Atlassian
Slack
Figma
Pencil

Install

Agent:
curl -sf /api/skills/shape/download | tar xz -C .claude/skills/

Download / Upload

ZIP でダウンロード

→ Claude.ai: Customize > Skills にアップロード

Source

Shape

ふわっとした要望を、実装可能な仕様に整える。

入力

  • $ARGUMENTS: 要望の説明（口頭、Slackスレッド、既存Jiraチケットキーなど）
  • 入力が曖昧な場合は質問で深掘りする

定数

  • cloudId: 実行時に getAccessibleAtlassianResources で取得する

手順

1. 要望の取り込み

入力ソースに応じてコンテキストを収集する:

  • 口頭/テキスト: そのまま受け取る
  • Slack スレッド: slack_read_thread でスレッド内容を取得
  • Jira チケット: getJiraIssue で既存チケットの description を取得
  • Figma URL: get_design_context でデザインコンテキストを取得

2. コードベース探索

要望に関連する既存コードを探索し、現状の設計パターンを把握する:

  • 関連するルート、サービス、コンポーネントの特定
  • 既存の類似機能のパターン確認（同じパターンを踏襲すべきか判断）
  • データモデル（Prisma schema）の確認
  • 影響範囲の把握

目的: 新規実装ではなく、既存アーキテクチャに沿った設計方針を決めるため。

3. 要件の深掘り（対話的）

ユーザーに質問を投げて要件を具体化する。以下の観点で曖昧な点を洗い出す:

必ず確認すること:

  • 誰が・何を・なぜ: ユーザーストーリーとして成立するか
  • 正常系: メインのハッピーパスは何か
  • 異常系: エラー時の振る舞い（ユーザーに何を見せるか）
  • 境界条件: 権限、テナント差異、既存データとの整合性
  • 非機能要件: セキュリティ、パフォーマンス上の制約

フロントエンドがある場合:

  • 画面一覧と遷移（どの画面からどの画面へ、条件は何か）
  • 各画面の状態（初期表示、ローディング、エラー、空状態）
  • テナント間の差異（SDH vs EAST で何が違うか）

API がある場合:

  • エンドポイント一覧（メソッド、パス、認証要否）
  • リクエスト/レスポンスの概要（詳細なスキーマではなく方針）
  • 外部API連携があるか（MedicalBase 等）

質問は一度に 2-3 個ずつ、AskUserQuestion を使って選択肢付きで投げる。 ユーザーが「もう十分」と言うまで、または曖昧な点がなくなるまで繰り返す。

4. 仕様書の作成

深掘り結果を以下の構成で仕様書にまとめる:

# [機能名]

## 背景・目的
なぜこの機能が必要か。ビジネス上の理由。

## ユーザーストーリー
- [ ] 〇〇として、△△したい。なぜなら□□だから。

## 画面・遷移（フロントエンドがある場合）
### 画面一覧
| 画面名 | URL | 説明 |
|--------|-----|------|

### 遷移図
（ASCII or テキストで画面遷移を記述）

### 各画面の状態
- 初期表示 / ローディング / エラー / 空状態

## API 設計（バックエンドがある場合）
### エンドポイント一覧
| メソッド | パス | 認証 | 概要 |
|----------|------|------|------|

### 設計方針
- どのサービス層に追加するか
- 既存パターンの踏襲（例: 「signin の get-firebase-token.ts と同じパターン」）
- データモデル変更（あれば）

## セキュリティ・非機能要件
該当する場合のみ記載。

## 受け入れ条件 (AC)
- [ ] 具体的で検証可能な条件
- [ ] エッジケースも含む

## 影響範囲
- 既存機能への影響
- テナント間の差異

5. ワイヤーフレーム作成（任意）

フロントエンドの画面がある場合、ユーザーに「ワイヤーフレームを作成しますか？」と確認する。

Yes の場合:

  1. get_guidelines(topic="web-app") でデザインガイドラインを取得
  2. get_style_guide_tags → get_style_guide でスタイルガイドを取得
  3. open_document("new") で新規 .pen ファイルを作成
  4. batch_design で画面ごとのワイヤーフレームを作成
  5. get_screenshot で結果を確認し、ユーザーにレビューしてもらう

ワイヤーフレームはビジュアルデザインではなく レイアウトと情報構造 に集中する。

6. 仕様書の出力

ユーザーに出力先を確認する:

  • Confluence（デフォルト）: createConfluencePage で仕様書ページを作成
    • スペースとページの親をユーザーに確認
    • ワイヤーフレームがある場合はスクリーンショットを添付
  • ローカル: docs/specs/ に Markdown ファイルとして保存

出力後、仕様書のリンクを返す。

最後に「チケット分割しますか？ → /carve で分割できます」と案内する。

注意事項

  • コード例は書かない。設計方針とパターンの参照先を示す
  • 技術的な詳細は実装フェーズ（plan モード）で詰める
  • 質問は選択肢付きで投げる（自由記述より判断しやすい）
  • 既存の類似機能がある場合は「LLAM-951 と同じパターン」のように参照する
  • テナント差異（SDH/EAST）は常に意識する