Create or reframe deep tech messaging from technology-centric to value-centric. Accepts any source material — repositories, websites, technical notes, proposals, pitch decks — and guides users through hearing, diagnosis or planning, writing or rewriting, and verification. Trigger when user mentions rewriting tech messaging, improving positioning, fixing website copy, creating customer-facing content from a repo or technical notes, making their technology story more compelling, or creating new messaging from scratch.
ディープテック企業の技術者が、自社技術の「見せ方」を作り・磨き上げるためのSkill。リポジトリ・サイト・技術メモなど素材を渡すと、技術の価値が伝わるテキストをゼロから作成、または既存のテキストを改善する。
トリガー条件:
最初の提案: 以下の4ステージで進めることを提案する:
「整理せず雑に投げてOK。質問しながらコンテキストを集めます」と伝える。
進め方の選択: 最初の提案と合わせて、進め方を選んでもらう。AskUserQuestionツールが利用可能な場合は選択UIで提示する:
進め方は途中でいつでも切り替えられる。
単一テキストの場合: ユーザーが1つのテキストだけを改善・作成したい場合は、ステージを厳密に分けず、ヒアリングしながら診断・生成まで一気に進めてよい。検証（Stage 4）も簡易に行う。
目的: 技術の本質、顧客、現状のメッセージングを理解する。
URLの場合、WebFetchの結果をまず確認する。 サイトの中身が見えていない疑いがあれば、情報抽出より先にdeep-prismを提案する（後述「可視性チェックの判断基準」参照）。
素材（リポジトリ、サイト、資料、メモ等）を受け取ったら、まず以下を自分で読み取る:
素材から読み取れない以下の情報を質問する。ユーザーは箇条書きでも雑なメモでも構わない:
サクサクモードの場合: 選択肢で答えられる質問はAskUserQuestionで提示する（例: 「ターゲット読者は？」→ エンジニア / 経営層 / 投資家）。自由記述が必要な質問（定量データ、技術の核心等）はテキストで聞く。
素材から読み取った情報は要約してユーザーに確認する。引用には出典箇所へのリンクを添える。「この理解で合っていますか？」
ユーザーが提供する素材の形式は問わない:
素材を受け取ったら:
以下が明確になったら、Stage 2に進む提案をする:
既存メッセージングがあるかどうかも確認し、診断・設計の進め方を判断する。
既存メッセージングがあれば診断から入る。加えて新規に作るべきテキストがあれば設計も行う。既存メッセージングがなければ診断をスキップし、設計から入る。
目的: 現在のメッセージングがどの成熟度にあり、どんな問題パターンがあるかを特定する。
まず references/references.md の「診断基準」セクションを読む。 成熟度モデル（Phase 1〜4）、シグナルワード、問題パターン（8種）が記載されている。これらの基準を使って診断する。
検出した問題を一覧にして提示する。各問題に:
ユーザーに「この診断で合っていますか？追加や修正はありますか？」と確認する。
診断が終わった時点で、類似の技術的パラダイムシフトを上手く売れた企業の事例を調べるかどうかをユーザーに提案する。
提案の仕方: 「似たようなパラダイムシフト型の技術が上手くメッセージングできた事例を調べると、方向性の参考になります。Web検索で調べますか？ 時間がかかるのでスキップもできます。」
リサーチする場合:
以下のResearch Briefを作成し、Researcher sub-agentを起動する。Researcherの実行中にStage 2の設計作業を並行して進めてよい。
## Research Brief
### 技術の概要
[ヒアリングで把握した技術の核心]
### 診断結果の要約
- 現在のPhase: [Phase X]
- 主要な問題パターン: [検出された問題]
### リサーチの焦点
- [技術の特性に基づく具体的なリサーチ質問]
- 例: 「シミュレーション領域でPhase 1→3の転換に成功した企業のメッセージング」
Agent toolで以下のように起動する:
agents/researcher.md の内容を読み込み、その後にResearch Briefをインラインで埋め込むResearcherの出力（リサーチ結果）は、Stage 3のテキスト生成時に参照する。
目的: 何を作るかの優先順位とターゲット読者を決める。
以下から、ユーザーの状況に合わせて優先度の高いものを提案する:
| テキスト種別 | 長さ | 優先度の目安 |
|---|---|---|
| ミッション / タグライン | 短 | 最優先。他のすべてのテキストの方向性を決める |
| 会社説明（1段落） | 短 | 高。ピッチ・サイト・提案書に繰り返し使う |
| サービス名・サービス説明 | 短 | 高。顧客が最初に触れる接点 |
| 事例タイトル・事例概要 | 短 | 中〜高。実績があるなら早めに作る |
| 導入の流れ | 短 | 中。問い合わせ後の不安を下げる |
| サービス紹介ページ | 長 | 高。サイト訪問者が最も読むページ |
| 事例記事（本文） | 長 | 中〜高。実績を深く伝える |
| 技術解説記事 | 長 | 中。技術者の信頼を得る |
| 会社紹介資料 | 長 | 中。提案書・ピッチに使う |
「まず何を作りますか？おすすめは○○です。理由は〜」と提案する。
Stage 1でターゲット読者は確認済み。ここでは追加で以下を確認する:
以下をまとめてユーザーに確認する:
ユーザーに「この方針で進めてよいですか？」と確認する。
目的: Stage 2の結果に基づいてテキストを生成し、ユーザーとの対話を継続する。
Stage 2の診断結果とreferences/references.md、references/examples.mdを参照してテキストを生成する。
Agent toolが利用可能な場合、Writer sub-agentに生成を委譲できる。診断の思考過程が渡らないため認知的バイアスが軽減される一方、コンテキストが欠落するリスクもある。
使う場合は、以下のWriting Briefを作成してsub-agentに渡す:
## Writing Brief
### コンテキスト
- 技術の核心: [1段落で要約]
- ターゲット読者: [誰に読ませたいか]
- 閲覧場面: [どの場面で読まれるか]
- 期待するアクション: [読んだ後にどう動いてほしいか]
### 診断結果（構造化）
- 現在のPhase: [Phase X → 目標Phase Y]
- 検出された問題パターン: [番号とテキスト引用]
- 維持すべき要素: [既に効いている表現・数字]
### 作成するテキスト
- 種別: [タグライン / サービス説明 / 事例記事 等]
- 長さ: [短い / 長い]
### リサーチ結果（Researcherの出力がある場合）
- [類似事例の要約]
- [応用できるパターン]
### 制約
- [ユーザーが「違う」と言った方向性]
- [技術的に正確でなければならない表現]
- [前回のフィードバック（リトライの場合）]
agents/writer.md の内容を読み込み、その後にWriting Briefをインラインで埋め込む。リファレンスファイルのパスも伝える要素ごとにテキストの長さを判断し、進め方を変える。1つのドキュメント内でも、タグラインは短いテキスト、セクション本文は長いテキストのように要素単位で切り替える。どちらも「案を出す→合ってる/違う」の構造は同じ。
複数の要素を扱う場合は、1つの要素を確定してから次に進む。 複数の改善案をまとめて出さない。確定した要素はその場でファイルに反映する。 全部まとめて最後に反映しない。
Step 1: 構成案
Step 2: セクション単位で執筆
Step 3: 通し読みと調整
ユーザーへの説明:
各案には効果説明を含める。ユーザーに提示する際、以下の基準で調整する。
説明に含めること:
例:
避けること:
途中の全体チェック（複数テキストを扱う場合）:
各テキストの確定:
全テキストの最終版が揃ったら:
目的: 作成・変換したテキストを、生成過程を知らないReviewer sub-agentで独立に検証する。
完成したテキスト全体をまとめ、以下のReview Requestを作成する:
## Review Request
### テキスト
[完成したテキスト全体]
### 最低限のコンテキスト（検証に必要な正解情報）
- この会社が実際にやっていること: [1行]
- ターゲット読者: [誰]
- 期待するアクション: [何をしてほしいか]
### テスト指示
1. 理解度テスト: テキストだけを読んで「何の会社か」「誰のどんな問題を解決するか」「競合との違いは」に答えよ
2. アクション誘発テスト: [ターゲット読者]として読み、問い合わせたいと思うか。理由と不足情報を述べよ
3. 3層カバレッジ: 事業成果 / 能力 / 技術的裏付けの3層がカバーされているか
Agent toolで以下のように起動する:
agents/reviewer.md の内容を読み込み、その後にReview Requestをインラインで埋め込むcontext: fork を使う理由（最重要）: 生成過程を一切知らない状態で評価することで、「自分の出力を自分で評価する甘さ」を排除する。Reviewerが見るのは完成テキストと正解情報だけ。
Reviewerの出力（テスト結果）をユーザーに提示する。
ReviewerがFAILを出した場合:
テキスト修正で対応可能な問題の場合:
### Reviewer フィードバック（第N回）
- テスト結果: [PASS/FAIL の一覧]
- 問題箇所: [具体的なテキスト引用]
- 改善指示: [何をどう直すべきか]
- 優先度: [FAIL の深刻度順]
上流に起因する問題の場合:
テストで問題が検出されなくなったら、ユーザーに最終確認を依頼する:
問題があればStage 3に戻って修正する。
完成したテキストを一箇所にまとめて提示する。次回の改善時に参照できるようにする:
Reviewerのテストを全てパスし、ユーザー自身の最終確認が完了したら完了。
メッセージングが完成し、まだ提案していなければ、「メッセージングは整いました。次は、このサイトが検索エンジンやAIからちゃんと見えているか確認しませんか？」と提案し、deep-prismスキルを案内する。
セッション中に以下のシグナルがあった場合のみ、完了時にフィードバックを提案する。シグナルがなければ案内しない。
提案時の流れ:
フィードバック方法を提示する:
「話しながらIssueを作る」が選ばれた場合、スキルのどこを直せばいいかを特定できるよう質問する。ユーザーが自由に話してくれる場合はそちらを優先する
ヒアリング結果を整理してIssue本文を作成し、ユーザーに確認してから gh issue create で発行する。ghが使えない場合はIssue本文を提示してURLを案内する
トーン:
技術的正確性:
やりすぎない:
進め方の切り替え:
ワークフローの柔軟性:
フレームワークの説明:
references/frameworks.md を読んで回答する変換パターンの参照:
references/examples.md を参照する