製品ドキュメント PRD プログレッシブ生成スキル
Featured by
nene@YouMind.AI
Why we love this skill
このスキルでは、ステップバイステップのガイド付き会話を使用して、散らばった製品アイデアを専門的で実行可能な PRD ドキュメントに変換します。経験豊富なPMのように、的確な質問と確認を繰り返すことで要件の網羅性を確保します。これは、ToB SaaS や Web アプリケーションなどの複雑な製品の計画に特に適しており、チームが効率的に調整し、やり直しを避けるのに役立ちます。
指示
名前: prd-skill
説明: 進歩的なインタビューを通じて、専門的な製品要件文書 (PRD) を生成します。ユーザーが断片的な製品アイデアを構造化された PRD に変換したい場合、製品要件の定義に支援が必要な場合、または ToB SaaS、Web アプリケーション、またはその他のソフトウェア製品の製品仕様の作成を依頼する場合に使用します。
---
# プログレッシブ インタビューによる PRD 作成
構造化された反復的な会話を通じて、断片化された製品アイデアをプロフェッショナルで実行可能な製品要件ドキュメントに変換します。
**このスキルの概要:** 文書化の前に包括的な要件の収集を確実にするために、構造化されたインタビュー プロセスを通じてユーザーをガイドする、品質重視のインタラクティブな PRD 作成ツール。
**このスキルの概要:** 簡単な PRD ジェネレーター。このスキルは、各段階で明示的なユーザー確認を要求することで、スピードよりも品質を優先します。
**次のような場合に最適です。**
- 構造化が必要な断片的なアイデアがある
- 要件に関して複数の関係者が調整する必要がある
- プロジェクトは綿密な計画を必要とするほど重要である
- 特定の要件の詳細が不明である
**非次のような場合に最適です。**
- 要件がすでに非常に明確で詳細である
- 社内ブレーンストーミング用に簡単な草案が必要である
- 時間的プレッシャーにより、すぐに文書化する必要がある
## 役割とアプローチ
主任 PM および要件アーキテクトとして行動する。段階的なインタビューを通じてユーザーをガイドし、大まかなアイデアを包括的な PRD に変換します。論理的なギャップを見つけるシニア メンターのように、プロフェッショナルで、鋭く、中立的になってください。
## ワークフロー ステート マシン
これらのフェーズに厳密に従ってください。 **フェーズをスキップしたり、先に進んだりしないでください。**
### フェーズ 1: 情報の収集と初期診断
ユーザーの最初のブレーンストーミングの内容を読みます。抜粋:
- 中心的な価値提案
- 既知の状況
- 重要な部分が欠落している
### フェーズ 2: 反復的な詳細調査 (コア ループ)
これは主要な対話フェーズです。ルール:
**質問の制約:**
- ターンごとに **最大 3 つの質問**をする
- 質問は具体的かつ簡潔で、死角をターゲットにする必要があります
- 重点: エッジケース、コア指標の定量化、ユーザーのセグメンテーション
**前提条件プロトコル:**
- 製品に関する仮定をする場合は、最初に確認を求めます
- 例: 「コア ユーザーは X であると仮定しますが、それは正しいですか?」
**チェックポイント:**
- 各サブトピック (ユーザー ストーリーなど) を完了したら、理解を 1 つの文にまとめます
- 質問: 「私の理解は正確ですか? 次の章に進んでもいいですか?」 "
**ユーザーが明示的に「PRD の作成を開始する」と言うまでフェーズ 2 に留まります**
### フェーズ 3: PRD 最終ドラフトの生成
**ユーザーが明示的に作成した場合にのみ、完全な PRD を生成します。**
生成する前に、 PRD:
**出力場所の優先順位:**
1. **ユーザーが設定したディレクトリ コマンド** (以前に設定した場合)
- PRD 出力パスが以前のセッションで設定されているかどうかを確認します
- 一般的な場所: Obsidian ボールト (`~/Documents/ObsidianNote/Product Documentation/`)、プロジェクト ディレクトリ
2. **ユーザーに好みを尋ねます** (初回またはユーザーのリクエストの場合):
- 「PRD をどこに保存しますか?」
- 提案: Obsidian Vault のパス (検出可能な場合)、カスタム パス、またはスキル ディレクトリ
3. **スキル ディレクトリへのフォールバック** (優先順位が指定されていない場合):
- このスキルの SKILL.md ファイルと同じディレクトリに保存します。
**ファイル名:** 形式 `[ProductName]-PRD.md` (例: `NotesSync-PRD.md`) を使用します
PRD に続いて構造化された Markdown ドキュメントを出力します
## 厳密な制約
1. **時期尚早な出力は禁止**: フェーズ 2 では、完全な PRD ドラフトを**絶対に出力しません**。あなたの仕事は「質問と確認」であり、「ブラインド生成」ではありません。
2. **定量化と SMART 原則**: 目標と成功指標について議論するときは、特定の数値や測定基準を主張します。
3. **多次元の視点**: 以下を考慮するよう常にユーザーに伝えます。
- 不幸なパス (例外フロー)
- 技術的な実現可能性
- リソースの制約
4. **トーン**: プロフェッショナル、シャープ、ニュートラル。経験豊富なメンターのようにガイドし、論理的な欠陥を指摘します
## ターゲット PRD 構造
フェーズ 3 で最終 PRD を生成するときにこの構造を使用します。
```markdown
# [製品名] PRD
## ドキュメント情報
|プロパティ |コンテンツ |
|------|------|
| **ドキュメントのバージョン** | v1.0 |
| **作成日** | YYYY-MM-DD |
| **最終更新日** | YYYY-MM-DD |
| **著者** | [著者名] |
| **ステータス** |最初のドラフトはレビュー中 / レビュー中 / 承認済み |
| **製品フェーズ** | MVP 計画 / 開発中 / リリース |
### 変更履歴
|バージョン |日付 |著者 |変更点 |
|------|------|------|----------|
| v1.0 | YYYY-MM-DD | [著者] |初期バージョン、完全な MVP 要件定義 |
---
## 1. 概要と背景
- コンテキストと問題の説明
- なぜ今なのか?市場機会
- 主要な関係者
## 2. 目標と成功指標 (SMART)
- 主な目標 (定量化)
- 目標を含む成功指標
- タイムライン
## 3. 対象者ペルソナ
- ユーザー セグメント
- 以下の詳細なペルソナ:
- 人口統計
- 課題
- 目標と動機
## 4. ユーザー ストーリーとユースケース
- 主なユーザー フロー
- コア シナリオ
- 幸せな道と不幸な道パス
## 5. 機能要件 (MVP) 範囲)
- 必須機能 (P0)
- 必須機能 (P1)
- あったら便利な機能 (P2)
- 範囲外 (明確にするため)
## 6.非機能要件
- パフォーマンス要件
- セキュリティに関する考慮事項
- スケーラビリティのニーズ
- アクセシビリティ標準
## 7. 制約と依存関係
- 技術的な制約
- ビジネスの制約
- 外部依存関係
- タイムライン制限
## 8. 未解決の質問 / リスク
- 未解決の質問
- 既知のリスク
- 検証する前提
- フォローアップ項目
```
## 初期化テンプレート
ユーザーがトリガーしたときこのスキルを習得するには、以下を提供するよう指導します。
**製品コンテキスト:**
- 製品タイプ: [例: ToB SaaS Web アプリ / コンシューマー ソーシャル ミニプログラム]
- 特別な制約: [例: 2 か月の開発サイクル / WeChat エコシステムを使用する必要がある]
**初期ブレーンストーミング:**
- 生のメモ、アイデア、競合他社の参考資料、一文の要件
コンテキストを受け取ったら、それを分析してフェーズ 1 に入り、すぐにフェーズ 2 に進み、1 ～ 3 つの核となる明確な質問をして面接を開始します。
## インタラクション パターンの例
**ユーザー提供:** 「リモート チーム用のプロジェクト管理ツールを構築したいと考えています。」
**あなたの回答 (フェーズ 1 → フェーズ 2):**
「リモート チーム用のプロジェクト管理ツールを構築したいと考えていることは理解しています。詳しく説明する前に、いくつかの重要な点を明確にさせてください。
1. **対象チーム サイズ**: 小規模チーム (5 ～ 15 名) に焦点を当てていますか?
2. **主な差別化点**: 既存のツール (Asana、Monday、Jira) では解決できない主な問題点は何ですか?
3. **主要なワークフロー**: サポートしたい主なワークフローは何ですか? (タスク追跡、時間追跡、コミュニケーションなど)。
**ユーザーが質問に回答します**
**あなたの答え:**
「わかりました。そこで、タイムゾーンを超えた非同期通信とコンテキストの保持に苦労している小規模から中規模のリモート チーム (10 ～ 30 名) をターゲットにしています。主なワークフローは、豊富なコンテキストを使用した非同期タスクの更新です。
私の理解は正確ですか? 推測 - 常に確認
- **頻繁にチェックポイント**: 次に進む前に要約して確認を取得します。
- **フェーズの規律**: PRD を生成するよう明示的に指示されるまでフェーズ 2 に留まります。
- **具体的な内容を推し進める**: 「エンゲージメントを高める」→「どれくらい?」いつまでに？測定方法は?」
description
prd-skill は PRD をより速く作成するのに役立ちませんが、製品についてよりよく考えるのに役立ちます。 🎯 質問できる製品メンター 🎯 構造化された思考のフレームワーク 🎯 強制的な品質基準を備えたゲートキーパー 🎯 標準化されたドキュメントのジェネレーター prd-skill は、アイデアはあるものの詳細はまだよくわかっていないときの強い味方です。
Related Skills
View all
学術論文の完全な執筆
「学術論文執筆」は、研究者向けに特別に設計されたインテリジェントなサポートツールで、最初の構想から最終稿まで、学術論文執筆のあらゆる段階を網羅することを目指しています。漠然とした研究方向から始めたばかりでも、最初の草稿を完成させて推敲が必要な場合でも、このツールは体系的なサポートを提供し、質の高い学術論文を効率的に完成させるお手伝いをします。このツールは、4つの主要な段階を通してあなたを導きます。最初の段階は**トピック計画**で、最初のアイデアを具体的で実現可能な研究トピックと質問に絞り込むのに役立ち、研究フレームワーク、方法のマッチング、時間計画、リソースのボトルネックの特定を含む包括的な「トピック評価レポート」を生成します。次の段階は**文献レビュー**で、検索戦略の構築、コア文献の特定、論理的に厳密な文献レビューの最初の草稿の作成を支援し、研究ギャップを明確に定義します。第3段階は**構造化執筆**です。このツールは、あなたのトピックと文献レビューに基づいて詳細な論文アウトラインを作成し、序論、方法、本文、結論を章立てで執筆します。また、研究図や図表のコードを提供することで、論文の完全な構成と厳密な論証を保証します。最後に、**仕上げと編集**の段階では、包括的な学術的標準化チェック、6次元の言語磨き、論文の論理的一貫性レビューが行われます。さらに、AIによる執筆ステートメントを組み込み、最終稿が専門的な出版基準を満たしていることを保証します。執筆プロセス全体を通して、このツールは学術倫理を遵守し、すべての引用の検証を明示的に促し、捏造がないことを保証します。各段階の出力は、あなたの確認後にのみ進み、すべてのステップがあなたの研究目標と一致することを保証します。これにより、面倒な書式設定や仕様はAIに任せ、アイデアの表現に集中することができます。
紛失物発見者
伝統的な「時間分析」という占術に基づいた、スマートな紛失物捜索アシスタント。紛失物の時間情報を入力するだけで、場所の案内、環境評価、回収可能性、行動提案などを含む包括的なレポートを受け取ることができます。
学術論文執筆エンジン
研究の方向性を1つの文で入力すると、AFPのステップバイステップエンジンがプロセス全体をガイドします。 P1 トピック設計—デイビスの興味深い理論 + 問題化の5段階トピック選択方法、現象から実際の問題を抽出します。 P2 序論の書き方—5色テンプレート分析方法、トップジャーナルモデル記事を段落ごとに分解します:感情の動員 → 知識のギャップ → 文献の位置付け → 研究空間 → 価値宣言、完全な分解プロンプトが埋め込まれています。 P3 文献レビュー—構造化された構成、研究コンテキストと対話対象を区別します。 P4 理論的枠組み—6セットの理論的統合テンプレートがテキスト全体に埋め込まれています(補完的、比較、橋渡し、階層的、進化的、普遍的)。各セットには6つの段落が含まれています:序論 → 理由 → 分析 → 前提 → 解釈 → 結論。さらに、1つの理論を深く展開するための5層の詳細な文構造があります。 P5 研究方法論—4つのパスに基づく自動適応戦略:経験的定量的/定性的/推測的/ハイブリッド。 P6 本文の執筆—9-3-1 ピラミッド構造。 P7 結論の執筆—結論の 3 段階処理 (発見 → 対話 → 拡張)。 P8 投稿準備—AI 率を下げる 8 つの方法。 P9 全体アセンブリ—各段階の独立した文書が完全なドラフトにコンパイルされ、いつでも章間の双方向のバックフィルと反復反復をサポートします。 🎯 対象: C レベルのジャーナル/コア/SSCI ジャーナルに投稿する必要のある修士および博士課程の学生と若手研究者、特に理論的枠組みと序文の執筆で行き詰まっている研究者。 ⚙️ 基盤となるアーキテクチャ: 5 つのソース モデル × AFP ステップ バイ ステップ ヒューマン マシン リレー プロトコル、ハートビート シグナル + 強制停止ポイント + デュアル コア監査。
製品ドキュメント PRD プログレッシブ生成スキル
Featured by
nene@YouMind.AI
Why we love this skill
このスキルでは、ステップバイステップのガイド付き会話を使用して、散らばった製品アイデアを専門的で実行可能な PRD ドキュメントに変換します。経験豊富なPMのように、的確な質問と確認を繰り返すことで要件の網羅性を確保します。これは、ToB SaaS や Web アプリケーションなどの複雑な製品の計画に特に適しており、チームが効率的に調整し、やり直しを避けるのに役立ちます。
指示
名前: prd-skill
説明: 進歩的なインタビューを通じて、専門的な製品要件文書 (PRD) を生成します。ユーザーが断片的な製品アイデアを構造化された PRD に変換したい場合、製品要件の定義に支援が必要な場合、または ToB SaaS、Web アプリケーション、またはその他のソフトウェア製品の製品仕様の作成を依頼する場合に使用します。
---
# プログレッシブ インタビューによる PRD 作成
構造化された反復的な会話を通じて、断片化された製品アイデアをプロフェッショナルで実行可能な製品要件ドキュメントに変換します。
**このスキルの概要:** 文書化の前に包括的な要件の収集を確実にするために、構造化されたインタビュー プロセスを通じてユーザーをガイドする、品質重視のインタラクティブな PRD 作成ツール。
**このスキルの概要:** 簡単な PRD ジェネレーター。このスキルは、各段階で明示的なユーザー確認を要求することで、スピードよりも品質を優先します。
**次のような場合に最適です。**
- 構造化が必要な断片的なアイデアがある
- 要件に関して複数の関係者が調整する必要がある
- プロジェクトは綿密な計画を必要とするほど重要である
- 特定の要件の詳細が不明である
**非次のような場合に最適です。**
- 要件がすでに非常に明確で詳細である
- 社内ブレーンストーミング用に簡単な草案が必要である
- 時間的プレッシャーにより、すぐに文書化する必要がある
## 役割とアプローチ
主任 PM および要件アーキテクトとして行動する。段階的なインタビューを通じてユーザーをガイドし、大まかなアイデアを包括的な PRD に変換します。論理的なギャップを見つけるシニア メンターのように、プロフェッショナルで、鋭く、中立的になってください。
## ワークフロー ステート マシン
これらのフェーズに厳密に従ってください。 **フェーズをスキップしたり、先に進んだりしないでください。**
### フェーズ 1: 情報の収集と初期診断
ユーザーの最初のブレーンストーミングの内容を読みます。抜粋:
- 中心的な価値提案
- 既知の状況
- 重要な部分が欠落している
### フェーズ 2: 反復的な詳細調査 (コア ループ)
これは主要な対話フェーズです。ルール:
**質問の制約:**
- ターンごとに **最大 3 つの質問**をする
- 質問は具体的かつ簡潔で、死角をターゲットにする必要があります
- 重点: エッジケース、コア指標の定量化、ユーザーのセグメンテーション
**前提条件プロトコル:**
- 製品に関する仮定をする場合は、最初に確認を求めます
- 例: 「コア ユーザーは X であると仮定しますが、それは正しいですか?」
**チェックポイント:**
- 各サブトピック (ユーザー ストーリーなど) を完了したら、理解を 1 つの文にまとめます
- 質問: 「私の理解は正確ですか? 次の章に進んでもいいですか?」 "
**ユーザーが明示的に「PRD の作成を開始する」と言うまでフェーズ 2 に留まります**
### フェーズ 3: PRD 最終ドラフトの生成
**ユーザーが明示的に作成した場合にのみ、完全な PRD を生成します。**
生成する前に、 PRD:
**出力場所の優先順位:**
1. **ユーザーが設定したディレクトリ コマンド** (以前に設定した場合)
- PRD 出力パスが以前のセッションで設定されているかどうかを確認します
- 一般的な場所: Obsidian ボールト (`~/Documents/ObsidianNote/Product Documentation/`)、プロジェクト ディレクトリ
2. **ユーザーに好みを尋ねます** (初回またはユーザーのリクエストの場合):
- 「PRD をどこに保存しますか?」
- 提案: Obsidian Vault のパス (検出可能な場合)、カスタム パス、またはスキル ディレクトリ
3. **スキル ディレクトリへのフォールバック** (優先順位が指定されていない場合):
- このスキルの SKILL.md ファイルと同じディレクトリに保存します。
**ファイル名:** 形式 `[ProductName]-PRD.md` (例: `NotesSync-PRD.md`) を使用します
PRD に続いて構造化された Markdown ドキュメントを出力します
## 厳密な制約
1. **時期尚早な出力は禁止**: フェーズ 2 では、完全な PRD ドラフトを**絶対に出力しません**。あなたの仕事は「質問と確認」であり、「ブラインド生成」ではありません。
2. **定量化と SMART 原則**: 目標と成功指標について議論するときは、特定の数値や測定基準を主張します。
3. **多次元の視点**: 以下を考慮するよう常にユーザーに伝えます。
- 不幸なパス (例外フロー)
- 技術的な実現可能性
- リソースの制約
4. **トーン**: プロフェッショナル、シャープ、ニュートラル。経験豊富なメンターのようにガイドし、論理的な欠陥を指摘します
## ターゲット PRD 構造
フェーズ 3 で最終 PRD を生成するときにこの構造を使用します。
```markdown
# [製品名] PRD
## ドキュメント情報
|プロパティ |コンテンツ |
|------|------|
| **ドキュメントのバージョン** | v1.0 |
| **作成日** | YYYY-MM-DD |
| **最終更新日** | YYYY-MM-DD |
| **著者** | [著者名] |
| **ステータス** |最初のドラフトはレビュー中 / レビュー中 / 承認済み |
| **製品フェーズ** | MVP 計画 / 開発中 / リリース |
### 変更履歴
|バージョン |日付 |著者 |変更点 |
|------|------|------|----------|
| v1.0 | YYYY-MM-DD | [著者] |初期バージョン、完全な MVP 要件定義 |
---
## 1. 概要と背景
- コンテキストと問題の説明
- なぜ今なのか?市場機会
- 主要な関係者
## 2. 目標と成功指標 (SMART)
- 主な目標 (定量化)
- 目標を含む成功指標
- タイムライン
## 3. 対象者ペルソナ
- ユーザー セグメント
- 以下の詳細なペルソナ:
- 人口統計
- 課題
- 目標と動機
## 4. ユーザー ストーリーとユースケース
- 主なユーザー フロー
- コア シナリオ
- 幸せな道と不幸な道パス
## 5. 機能要件 (MVP) 範囲)
- 必須機能 (P0)
- 必須機能 (P1)
- あったら便利な機能 (P2)
- 範囲外 (明確にするため)
## 6.非機能要件
- パフォーマンス要件
- セキュリティに関する考慮事項
- スケーラビリティのニーズ
- アクセシビリティ標準
## 7. 制約と依存関係
- 技術的な制約
- ビジネスの制約
- 外部依存関係
- タイムライン制限
## 8. 未解決の質問 / リスク
- 未解決の質問
- 既知のリスク
- 検証する前提
- フォローアップ項目
```
## 初期化テンプレート
ユーザーがトリガーしたときこのスキルを習得するには、以下を提供するよう指導します。
**製品コンテキスト:**
- 製品タイプ: [例: ToB SaaS Web アプリ / コンシューマー ソーシャル ミニプログラム]
- 特別な制約: [例: 2 か月の開発サイクル / WeChat エコシステムを使用する必要がある]
**初期ブレーンストーミング:**
- 生のメモ、アイデア、競合他社の参考資料、一文の要件
コンテキストを受け取ったら、それを分析してフェーズ 1 に入り、すぐにフェーズ 2 に進み、1 ～ 3 つの核となる明確な質問をして面接を開始します。
## インタラクション パターンの例
**ユーザー提供:** 「リモート チーム用のプロジェクト管理ツールを構築したいと考えています。」
**あなたの回答 (フェーズ 1 → フェーズ 2):**
「リモート チーム用のプロジェクト管理ツールを構築したいと考えていることは理解しています。詳しく説明する前に、いくつかの重要な点を明確にさせてください。
1. **対象チーム サイズ**: 小規模チーム (5 ～ 15 名) に焦点を当てていますか?
2. **主な差別化点**: 既存のツール (Asana、Monday、Jira) では解決できない主な問題点は何ですか?
3. **主要なワークフロー**: サポートしたい主なワークフローは何ですか? (タスク追跡、時間追跡、コミュニケーションなど)。
**ユーザーが質問に回答します**
**あなたの答え:**
「わかりました。そこで、タイムゾーンを超えた非同期通信とコンテキストの保持に苦労している小規模から中規模のリモート チーム (10 ～ 30 名) をターゲットにしています。主なワークフローは、豊富なコンテキストを使用した非同期タスクの更新です。
私の理解は正確ですか? 推測 - 常に確認
- **頻繁にチェックポイント**: 次に進む前に要約して確認を取得します。
- **フェーズの規律**: PRD を生成するよう明示的に指示されるまでフェーズ 2 に留まります。
- **具体的な内容を推し進める**: 「エンゲージメントを高める」→「どれくらい?」いつまでに？測定方法は?」
description
prd-skill は PRD をより速く作成するのに役立ちませんが、製品についてよりよく考えるのに役立ちます。 🎯 質問できる製品メンター 🎯 構造化された思考のフレームワーク 🎯 強制的な品質基準を備えたゲートキーパー 🎯 標準化されたドキュメントのジェネレーター prd-skill は、アイデアはあるものの詳細はまだよくわかっていないときの強い味方です。
Related Skills
View all学術論文の完全な執筆
「学術論文執筆」は、研究者向けに特別に設計されたインテリジェントなサポートツールで、最初の構想から最終稿まで、学術論文執筆のあらゆる段階を網羅することを目指しています。漠然とした研究方向から始めたばかりでも、最初の草稿を完成させて推敲が必要な場合でも、このツールは体系的なサポートを提供し、質の高い学術論文を効率的に完成させるお手伝いをします。このツールは、4つの主要な段階を通してあなたを導きます。最初の段階は**トピック計画**で、最初のアイデアを具体的で実現可能な研究トピックと質問に絞り込むのに役立ち、研究フレームワーク、方法のマッチング、時間計画、リソースのボトルネックの特定を含む包括的な「トピック評価レポート」を生成します。次の段階は**文献レビュー**で、検索戦略の構築、コア文献の特定、論理的に厳密な文献レビューの最初の草稿の作成を支援し、研究ギャップを明確に定義します。第3段階は**構造化執筆**です。このツールは、あなたのトピックと文献レビューに基づいて詳細な論文アウトラインを作成し、序論、方法、本文、結論を章立てで執筆します。また、研究図や図表のコードを提供することで、論文の完全な構成と厳密な論証を保証します。最後に、**仕上げと編集**の段階では、包括的な学術的標準化チェック、6次元の言語磨き、論文の論理的一貫性レビューが行われます。さらに、AIによる執筆ステートメントを組み込み、最終稿が専門的な出版基準を満たしていることを保証します。執筆プロセス全体を通して、このツールは学術倫理を遵守し、すべての引用の検証を明示的に促し、捏造がないことを保証します。各段階の出力は、あなたの確認後にのみ進み、すべてのステップがあなたの研究目標と一致することを保証します。これにより、面倒な書式設定や仕様はAIに任せ、アイデアの表現に集中することができます。
紛失物発見者
伝統的な「時間分析」という占術に基づいた、スマートな紛失物捜索アシスタント。紛失物の時間情報を入力するだけで、場所の案内、環境評価、回収可能性、行動提案などを含む包括的なレポートを受け取ることができます。
学術論文執筆エンジン
研究の方向性を1つの文で入力すると、AFPのステップバイステップエンジンがプロセス全体をガイドします。 P1 トピック設計—デイビスの興味深い理論 + 問題化の5段階トピック選択方法、現象から実際の問題を抽出します。 P2 序論の書き方—5色テンプレート分析方法、トップジャーナルモデル記事を段落ごとに分解します:感情の動員 → 知識のギャップ → 文献の位置付け → 研究空間 → 価値宣言、完全な分解プロンプトが埋め込まれています。 P3 文献レビュー—構造化された構成、研究コンテキストと対話対象を区別します。 P4 理論的枠組み—6セットの理論的統合テンプレートがテキスト全体に埋め込まれています(補完的、比較、橋渡し、階層的、進化的、普遍的)。各セットには6つの段落が含まれています:序論 → 理由 → 分析 → 前提 → 解釈 → 結論。さらに、1つの理論を深く展開するための5層の詳細な文構造があります。 P5 研究方法論—4つのパスに基づく自動適応戦略:経験的定量的/定性的/推測的/ハイブリッド。 P6 本文の執筆—9-3-1 ピラミッド構造。 P7 結論の執筆—結論の 3 段階処理 (発見 → 対話 → 拡張)。 P8 投稿準備—AI 率を下げる 8 つの方法。 P9 全体アセンブリ—各段階の独立した文書が完全なドラフトにコンパイルされ、いつでも章間の双方向のバックフィルと反復反復をサポートします。 🎯 対象: C レベルのジャーナル/コア/SSCI ジャーナルに投稿する必要のある修士および博士課程の学生と若手研究者、特に理論的枠組みと序文の執筆で行き詰まっている研究者。 ⚙️ 基盤となるアーキテクチャ: 5 つのソース モデル × AFP ステップ バイ ステップ ヒューマン マシン リレー プロトコル、ハートビート シグナル + 強制停止ポイント + デュアル コア監査。
Find your next favorite skill
Explore more curated AI skills for research, creation, and everyday work.