ワンクリックでManusで任意のスキルを実行

始める

backend-spec-creator

スター3

フォーク2

更新日2026年4月23日 10:16

新機能の仕様書を docs/spec/ 配下に作成する。実装詳細を含めない純粋な仕様（目的・振る舞い・ルール・境界）に絞ってマークダウン化する。「仕様書作って」「spec 書いて」「〜の仕様まとめて」などで起動。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

JavaLangRuntimeException

JavaLangRuntimeException/manji-standard-server

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Spec Creator

新機能の仕様書を docs/spec/ 配下に作成する汎用スキル。

原則

仕様書は「何を作るか」を書く場所。「どう作るか」は書かない。

✅ 機能の目的、ユーザー価値
✅ 用語定義、エンティティ概念
✅ 振る舞い（入力・出力・状態遷移）
✅ ビジネスルール・制約
✅ エラー・境界条件
❌ 具体的な実装言語・フレームワーク
❌ ファイルパス、クラス名、関数名
❌ DB スキーマの具体的な型・テーブル名
❌ API のエンドポイント URL やステータスコードの詳細

仕様書は実装言語を変えても有効である、というのが指標。

実行手順

1. 必要情報の確認

ユーザーに以下を順番に確認（不明なら質問。自明なら省略）:

機能名: 仕様書ファイル名の元になる（kebab-case）
目的 / ユーザー価値: なぜこれが必要か
スコープ: 今回含める範囲 / 含めない範囲
前提: 既に決まっていること（UI デザイン、外部仕様、他機能との関係）
既存仕様との関係: 更新か新規か

2. 配置先の決定

docs/spec/
├── <feature-name>-spec.md          シンプルな機能
└── <domain>/                        大きな領域は配下にまとめる
    ├── <sub-feature>-spec.md
    └── overview.md

命名規則:

ファイル名は <name>-spec.md
領域が広い場合はディレクトリを切る

既存の docs/spec/ 構成を確認して、慣習に合わせる。

3. テンプレート

# <機能名> 仕様

## 1. 概要

### 目的
<なぜこの機能が必要か。ユーザー / ビジネス価値。>

### スコープ
- 含む: <箇条書き>
- 含まない: <箇条書き>

## 2. 用語定義

| 用語 | 定義 |
| --- | --- |
| <term> | <意味> |

## 3. 主要な振る舞い

### 3.1 <ユースケース名>

- **トリガー**: <いつ起きるか>
- **入力**: <必要な情報>
- **処理の流れ**:
  1. ...
  2. ...
- **結果**: <成功時の状態変化 / 出力>
- **関連ルール**: [4. ビジネスルール](#4-ビジネスルール) の R-XX

### 3.2 ...

## 4. ビジネスルール

- **R-01**: <ルール本文>
- **R-02**: <ルール本文>

各ルールには一意な ID を振る（後から実装・テストで参照できるように）。

## 5. 状態・ライフサイクル

<該当する場合のみ。Mermaid stateDiagram 推奨>

```mermaid
stateDiagram-v2
  [*] --> Draft
  Draft --> Active
  Active --> Archived

6. エラー・境界条件

条件	振る舞い
<条件>	<期待される振る舞い>

7. 非機能要件

<該当する場合のみ: パフォーマンス、セキュリティ、可用性>

8. オープン課題

<未決定事項>
...

9. 参考資料

<関連する仕様書、外部仕様、議事録>


### 4. 書くときの注意

- **ルール ID を必ず振る**。後続の実装・テスト・レビューで参照する
- **例を入れる**。抽象的な説明だけだと誤解される
- **「こうあるべき」ではなく「こうである」で書く**。仕様は決定事項
- **未決定は明示的に「未決定」と書く**。埋めるために推測しない
- **実装者への指示を書かない**（「～を実装すること」という文体は避ける）

### 5. 生成後の確認

- ユーザーに内容を提示して承認を得る
- 特に「オープン課題」セクションの扱い（空にすべきか、明示的に列挙すべきか）を確認
- 承認後に `docs/spec/` に書き込む

## いつ使わないか

- 既存仕様の軽微な修正 → `backend-spec-updater` を使う
- 実装計画書を書きたい → `backend-work-planner` を使う
- デバッグや調査 → 別スキル

## 関連

- [backend-spec-updater](../backend-spec-updater/SKILL.md) — 既存仕様の更新
- [backend-work-planner](../backend-work-planner/SKILL.md) — 仕様を元に実装計画書を作成

このリポジトリの他の Skills

同じリポジトリ

backend-work-planner

JavaLangRuntimeException/manji-standard-server

docs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。

2026-05-033

backend-code-reviewer

JavaLangRuntimeException/manji-standard-server

差分や指定コードを構造化されたレビュー観点（正確性・設計・テスト・可読性・セキュリティ）で読み、優先度付きで指摘する。修正は提案するが勝手に書き換えない。「レビューして」「コードレビュー」「セカンドオピニオン」などで起動。

2026-04-233

backend-codebase-explorer

JavaLangRuntimeException/manji-standard-server

未知のコードベースを最短で把握するための構造化探索を行う。言語・ビルドツール・アーキテクチャ・テスト方針・主要なエントリポイントを短時間でレポート化する。「このプロジェクト教えて」「コードベース調べて」「初見で入ったから概要ほしい」などで起動。

2026-04-233

backend-commit-splitter

JavaLangRuntimeException/manji-standard-server

未コミットの変更を依存関係と関心事に基づいて適切な粒度のコミットに分割する。自動生成物・手動実装・テスト・ドキュメントを分離し、レビューしやすい履歴を作る。「コミット分けて」「良い粒度でコミット」「この変更コミットにして」などで起動。

2026-04-233

backend-debug-session

JavaLangRuntimeException/manji-standard-server

バグ調査を場当たり的でなく体系的に進める。再現→仮説→検証→修正→回帰テストの順序を守り、仮説と事実を分けて記録する。「バグ調査して」「なぜか動かない」「デバッグ手伝って」などで起動。

2026-04-233

backend-dev-manager

JavaLangRuntimeException/manji-standard-server

汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。

2026-04-233

name	backend-spec-creator
description	新機能の仕様書を docs/spec/ 配下に作成する。実装詳細を含めない純粋な仕様（目的・振る舞い・ルール・境界）に絞ってマークダウン化する。「仕様書作って」「spec 書いて」「〜の仕様まとめて」などで起動。

Spec Creator

新機能の仕様書を docs/spec/ 配下に作成する汎用スキル。

原則

仕様書は「何を作るか」を書く場所。「どう作るか」は書かない。

✅ 機能の目的、ユーザー価値
✅ 用語定義、エンティティ概念
✅ 振る舞い（入力・出力・状態遷移）
✅ ビジネスルール・制約
✅ エラー・境界条件
❌ 具体的な実装言語・フレームワーク
❌ ファイルパス、クラス名、関数名
❌ DB スキーマの具体的な型・テーブル名
❌ API のエンドポイント URL やステータスコードの詳細

仕様書は実装言語を変えても有効である、というのが指標。

実行手順

1. 必要情報の確認

ユーザーに以下を順番に確認（不明なら質問。自明なら省略）:

機能名: 仕様書ファイル名の元になる（kebab-case）
目的 / ユーザー価値: なぜこれが必要か
スコープ: 今回含める範囲 / 含めない範囲
前提: 既に決まっていること（UI デザイン、外部仕様、他機能との関係）
既存仕様との関係: 更新か新規か

2. 配置先の決定

docs/spec/
├── <feature-name>-spec.md          シンプルな機能
└── <domain>/                        大きな領域は配下にまとめる
    ├── <sub-feature>-spec.md
    └── overview.md

命名規則:

ファイル名は <name>-spec.md
領域が広い場合はディレクトリを切る

既存の docs/spec/ 構成を確認して、慣習に合わせる。

3. テンプレート

# <機能名> 仕様

## 1. 概要

### 目的
<なぜこの機能が必要か。ユーザー / ビジネス価値。>

### スコープ
- 含む: <箇条書き>
- 含まない: <箇条書き>

## 2. 用語定義

| 用語 | 定義 |
| --- | --- |
| <term> | <意味> |

## 3. 主要な振る舞い

### 3.1 <ユースケース名>

- **トリガー**: <いつ起きるか>
- **入力**: <必要な情報>
- **処理の流れ**:
  1. ...
  2. ...
- **結果**: <成功時の状態変化 / 出力>
- **関連ルール**: [4. ビジネスルール](#4-ビジネスルール) の R-XX

### 3.2 ...

## 4. ビジネスルール

- **R-01**: <ルール本文>
- **R-02**: <ルール本文>

各ルールには一意な ID を振る（後から実装・テストで参照できるように）。

## 5. 状態・ライフサイクル

<該当する場合のみ。Mermaid stateDiagram 推奨>

```mermaid
stateDiagram-v2
  [*] --> Draft
  Draft --> Active
  Active --> Archived

6. エラー・境界条件

条件	振る舞い
<条件>	<期待される振る舞い>

7. 非機能要件

<該当する場合のみ: パフォーマンス、セキュリティ、可用性>

8. オープン課題

<未決定事項>
...

9. 参考資料

<関連する仕様書、外部仕様、議事録>


### 4. 書くときの注意

- **ルール ID を必ず振る**。後続の実装・テスト・レビューで参照する
- **例を入れる**。抽象的な説明だけだと誤解される
- **「こうあるべき」ではなく「こうである」で書く**。仕様は決定事項
- **未決定は明示的に「未決定」と書く**。埋めるために推測しない
- **実装者への指示を書かない**（「～を実装すること」という文体は避ける）

### 5. 生成後の確認

- ユーザーに内容を提示して承認を得る
- 特に「オープン課題」セクションの扱い（空にすべきか、明示的に列挙すべきか）を確認
- 承認後に `docs/spec/` に書き込む

## いつ使わないか

- 既存仕様の軽微な修正 → `backend-spec-updater` を使う
- 実装計画書を書きたい → `backend-work-planner` を使う
- デバッグや調査 → 別スキル

## 関連

- [backend-spec-updater](../backend-spec-updater/SKILL.md) — 既存仕様の更新
- [backend-work-planner](../backend-work-planner/SKILL.md) — 仕様を元に実装計画書を作成