with one click
spec-test
仕様駆動設計。仕様書からクラス責務を分析し、純粋関数を特定、テストファーストで単体テストを設計する。既存Planに追記。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
仕様駆動設計。仕様書からクラス責務を分析し、純粋関数を特定、テストファーストで単体テストを設計する。既存Planに追記。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
SwiftUI のレイアウト落とし穴・ベストプラクティス・非推奨パターンと、 iOS / watchOS アプリの実機配布 (Provisioning / App Group / Code Signing / Apple Watch Developer Mode / Xcode 15+ Debug dylib) トラブルシューティング のガイド。コード生成・修正時に既知のレイアウトバグを防ぎ、 App Group + watchOS + Apple Watch の実機インストール失敗を 7 段階フレームワークで診断・解消する。 Use when: SwiftUI のコードを書く・修正するとき。 レイアウト崩れを修正するとき。safeAreaInset や ViewThatFits を使うとき。 マルチデバイス対応するとき。iOS + watchOS アプリの実機ビルド / 配布で provisioning / App Group / Manual Signing / Apple Watch の UDID / Xcode 自動署名の 罠に詰まったとき。Apple Watch に "Could not install at this time" が出たとき。 Triggers: "SwiftUI", "layout", "safeAreaInset", "ViewThatFits", "GeometryReader", "レイアウト", "崩れ", "表示バグ", "iPhone SE", "ATT", "ATTrackingManager", "requestTrackingAuthorization", "AdMob", "広告", "Provisioning Profile", "App Group", "Manual Signing", "Code Signing", "Apple Watch", "watchOS", "Install できない", "Could not install at this time", "Bundle ID 紐付け", "Xcode Automatic Signing", "embedded.mobileprovision", "Spaceship", "App Store Connect API", "WKCompanionAppBundleIdentifier", "Dev
アプリ名・サービス名の命名を、5つの専門エージェントチームで多角的に評価・決定するスキル。 ブランディング、商標/法的リスク、デジタルプレゼンス(SEO/ASO/SNS)、国際展開(多言語/発音)の 4観点から候補を提案・調査・議論し、コンテキストファイルと議事録で次回セッションへ引き継ぐ。 Use when: アプリ名を決めたい、サービス名を変更したい、プロダクト名を検討したい、 ネーミングブレスト、名前の商標チェック、アプリ名のリネーム。 Triggers: "アプリ名", "サービス名", "プロダクト名", "ネーミング", "名前を決め", "リネーム", "rename", "app name", "naming", "ブランド名", "商標チェック"
仕様書・要件定義からソフトウェアアーキテクチャを設計するスキル。 5人の専門エージェント(Architecture Lead・Module Designer・Dependency Analyst・ Platform Expert・Devil's Advocate)が協議しながら、 モジュール分割・依存関係・データフロー・インターフェース設計を行う。 成果物は構造化されたアーキテクチャ設計書(Markdown)。 Use when: 仕様書からどう設計するか迷っている時、モジュール分割の方針を決めたい時、 技術スタックに合ったアーキテクチャパターンを選びたい時、 設計書を作成したい時。 Triggers: "アーキテクチャ設計", "arch design", "仕様書から設計", "モジュール分割", "設計書を作りたい", "アーキテクチャを考えて", "コンポーネント設計", "依存関係を設計", "どう設計する", "design the architecture", "design from spec"
App Store / Google Play 用のプロモーションスクリーンショットを Pencil (.pen) で生成する Agent Team スキル。creative-director が戦略を立て、screenshot-designer が Pencil で デザインを構築し、copy-writer がコピーを提供し、spec-validator が技術仕様を数値検証し、 quality-reviewer が最終品質を確認する。5エージェント体制で高品質なスクリーンショットを生成。 Use when: App Store スクリーンショットを作りたい、プロモーション画像を作成したい、 スクショのデザインをしたい。 Triggers: "スクリーンショット作成", "App Store 画像", "プロモーションスクショ", "screenshot creator", "スクショ作って", "App Store 素材"
ブランチ作成、コミット、PR作成までのGitワークフローを支援する
エージェントを長時間稼働させて大きな実装タスクを完遂するためのスキル。 TODO ファイル (.md) を管理しながら、高レベル TODO → 細かい TODO に分解 → 実装 → サブエージェントによるレビュー → 不足分の TODO 追加 のサイクルを回す。 コンテキストが大きくなっても TODO ファイルが状態の真実の源泉として機能するため、 長時間・大規模な変更でも迷子にならずに着実に完遂できる。 team-plan や team-implement とは異なり、1人のメインエージェントが逐次的に実装し、 各段階をレビューエージェントが品質検証する。 Use when: 大きな実装タスクを段階的に進めたい、エージェントに長時間任せたい、 実装中に TODO を追加しながら進めたい、各ステップの品質をサブエージェントにレビューさせたい、 長時間の実装を構造化したい、放置しても安心して任せられる実装フローが欲しい。 Triggers: "long-run", "段階的に実装", "TODO駆動で実装", "大きな実装", "ステップバイステップで実装", "レビューしながら実装", "long run implement", "実装を進めて", "大規模実装", "iterative implement", "長時間実装", "エージェントに任せて", "放置で実装"
| name | spec-test |
| description | 仕様駆動設計。仕様書からクラス責務を分析し、純粋関数を特定、テストファーストで単体テストを設計する。既存Planに追記。 |
| disable-model-invocation | false |
| allowed-tools | Read, Glob, Grep, Edit |
仕様書を受け取り、テストファーストでクラス設計と単体テストを設計し、既存のPlanドキュメントに自動追記するスキル。
このスキルが呼び出されたら、以下を自動で実行する:
引数で渡された仕様書(または直前の会話で提示された仕様)を分析し、以下を抽出:
分析結果をEditツールで既存Planファイルの末尾に追記する。
追記した内容のサマリーを報告。
以下のフォーマットでPlanファイルに追記する:
---
## 仕様駆動設計: <機能名>
### ドメインモデル
#### Entities
| Entity | 識別子 | 主要属性 | 振る舞い |
|--------|--------|---------|---------|
| <名前> | <ID> | <属性> | <メソッド> |
#### Value Objects
| VO | 属性 | 不変条件 |
|----|------|---------|
| <名前> | <属性> | <制約> |
#### Domain Events
| Event | トリガー | ペイロード |
|-------|---------|-----------|
| <名前> | <発火条件> | <データ> |
### クラス設計
#### 1. <ClassName>
**責任:** <単一責任を1文で>
| メソッド | 入力 | 出力 | 副作用 | 純粋? |
|---------|------|------|--------|-------|
| <名前> | <型> | <型> | <内容> | ✅/❌ |
**依存:** <インターフェース名>
### 純粋関数一覧 ⭐
| 関数 | カテゴリ | 入力 | 出力 | 場所 |
|------|---------|------|------|------|
| `<名前>` | <カテゴリ> | <型> | <型> | <ファイルパス> |
### 単体テスト設計 ⭐
#### 純粋関数テスト: `<関数名>`
| ID | カテゴリ | 入力 | 期待結果 | 説明 |
|----|---------|------|---------|------|
| EQ-01 | 同値 | <値> | <結果> | <説明> |
| BV-01 | 境界 | <値> | <結果> | <説明> |
| ERR-01 | エラー | <値> | <結果> | <説明> |
#### クラステスト: `<ClassName>`
| ID | メソッド | シナリオ | 事前条件 | 入力 | 期待結果 | モック |
|----|---------|---------|---------|------|---------|--------|
| C-01 | <メソッド> | <シナリオ> | <状態> | <値> | <結果> | <依存> |
**テスト観点:**
- 状態遷移: 初期状態 → メソッド実行 → 期待状態
- 不変条件: 常に満たすべき制約
- 境界条件: 状態の境界でのふるまい
- 異常系: 例外、エラーハンドリング
### 保守性チェック
#### SOLID原則
- [ ] S: 単一責任 - クラスの変更理由は1つか?
- [ ] O: 開放閉鎖 - 拡張に開き、修正に閉じているか?
- [ ] D: 依存性逆転 - 具象ではなく抽象に依存しているか?
#### テスタビリティ
- [ ] 依存は注入可能か?
- [ ] 副作用は分離されているか?
- [ ] 外部APIはインターフェース経由か?
### テストファースト実装順序
1. [ ] Layer 1: 純粋関数 + test
2. [ ] Layer 2: ドメインサービス + test
3. [ ] Layer 3: インフラ層
| カテゴリ | プレフィックス | シグネチャ |
|---|---|---|
| validation | validate*, isValid* | (input: T) => ValidationResult |
| format | format*, truncate*, strip* | (input: string) => string |
| parse | parse*, extract* | (input: string) => T | null |
| predicate | is*, should*, can*, has* | (input: T) => boolean |
| select | select*, choose*, pick* | (candidates: T[], criteria) => T |
| calculate | calculate*, compute*, count* | (inputs: T) => number |
| build | build*, create*, make* | (parts: P) => T |
scripts/analyze.sh で分析ワークフローやパターンを確認できる:
./scripts/analyze.sh --steps # 分析ステップを表示
./scripts/analyze.sh --patterns # 純粋関数パターンを表示
./scripts/analyze.sh --template # 追記テンプレートを表示
./scripts/analyze.sh --all # すべて表示
/spec-test <plan_file_path> <仕様の説明>
または仕様書を先に提示してから:
/spec-test <plan_file_path>