getting-started

概要

このスキルはセッションを初期化し、ユーザーの領域を特定して、適切なスキルファミリーに振り分け、ワークフローのコンテキストを確立します。すべてのタスクに適切なスキルフレームワークを適用することで、「構造化されていない思考」を防ぎます。

絶対原則

適用可能なスキルを最初に確認せずにタスクへ応答してはいけません 関連するスキルフレームワークを特定せずにタスクへ直接取りかかると、一般的で検証されておらず、価値の低い出力になります。

状態マシン

digraph getting_started_flow {
    "Start" [shape=doublecircle];
    "Step 1: Identify Domain" [shape=box];
    "Step 2: Check Skill Taxonomy" [shape=box];
    "Step 3: Establish Workflow Chain" [shape=box];
    "Gate: Skill Applicable?" [shape=diamond];
    "Step 4: Invoke Skill(s)" [shape=box];
    "Ready" [shape=doublecircle];

    "Start" -> "Step 1: Identify Domain";
    "Step 1: Identify Domain" -> "Step 2: Check Skill Taxonomy";
    "Step 2: Check Skill Taxonomy" -> "Gate: Skill Applicable?";
    "Gate: Skill Applicable?" -> "Step 3: Establish Workflow Chain" [label="yes"];
    "Gate: Skill Applicable?" -> "Ready" [label="no"];
    "Step 3: Establish Workflow Chain" -> "Step 4: Invoke Skill(s)";
    "Step 4: Invoke Skill(s)" -> "Ready";
}

このスキルを使用するタイミング

• 新しいチャットセッションの開始時。
• ユーザーが新しいプロジェクトやトピックを持ち込んだとき。
• リクエストへの取り組み方がわからないとき。

このスキルを使用しないタイミング

• すでにスキルを呼び出して進行中のタスクでは使用しません。
• 単純な一度限りの確認では使用しません。

基本プロセス

ステップ 1：領域を特定する

自問してください。このリクエストは、戦略的、分析的、物語的、修辞的、または対人関係的なものですか？（出典：システム設計）

ステップ 2：スキルの分類体系を確認する

以下の 6 つのファミリーと 41 個のスキルを参照してください。1％ルールを適用します。スキルが当てはまる可能性が少しでもある場合は、必ず言及してください。

6 つのスキルファミリー

meta（6 個のスキル） — 基盤とプロセスの徹底

• getting-started — セッションの初期化と振り分け（現在使用中）
• using-skills — スキル呼び出しの規律と 1％ルールの徹底
• writing-skills — ドキュメントとスキル作成のための TDD
• prompt-optimizer — 構造化されたプロンプト改善手法
• mental-model-library — 分野横断的な推論のリファレンス
• learning-accelerator — メタ学習と知識の統合

workflow（12 個のスキル） — 戦略的・分析的なワークフロー

• problem-framing — 発見のゲートと問題の定義
• stakeholder-discovery — オーディエンスとステークホルダーのマッピング
• market-context — 競争環境のコンテキスト
• competitive-analysis — 体系的な競合分析
• buyer-persona — JTBD に基づくペルソナ作成
• business-case — ROI と投資の論拠
• prd-writing — プロダクト要件（PR/FAQ 手法）
• pitch-deck — 投資家および社内向けのピッチ
• one-pager — エグゼクティブサマリー文書
• executive-briefing — 取締役会レベルのコミュニケーション
• assumption-audit — エビデンス検証のゲート
• stakeholder-review — 体系的なフィードバック収集

executive（9 個のスキル） — リーダーシップと意思決定

• strategy-clarity — 戦略的ポジショニングと競争優位性
• devils-advocate — 対立的なストレステスト
• operational-excellence — 実行システムと OKR
• platform-strategist — プラットフォームとアグリゲーターの分析
• ownership-coach — リーダーシップにおける当事者意識
• first-90-days — 新しい役割への移行プレイブック
• hiring-talent — 人材の評価と採用
• team-builder — カルチャーと心理的安全性
• decision-frameworks — 体系的な意思決定手法

narrative（4 個のスキル） — ストーリーテリングと創作

• fiction-architect — プロット構成と因果関係
• character-vulnerability — キャラクターの深みの検証
• world-building-logic — 内部整合性の構築
• dialogue-craft — 声とサブテキスト

rhetorician（5 個のスキル） — コミュニケーションと説得

• non-fiction-precision — 構成の明確さ
• copy-editor — 一文単位の文章品質
• resonance-engine — 感情的・説得的な効果
• memo-stress-tester — ビジネス文書のストレステスト
• scientific-advertising — エビデンスに基づく説得

dealmaker（5 個のスキル） — 交渉と影響力

• negotiation-tactician — 取引と契約の交渉
• influence-architect — 説得と力学
• rapport-builder — 関係構築と信頼の醸成
• feedback-coach — フィードバックの伝え方と受け止め方
• difficult-conversations — 重要な対話

ステップ 3：ワークフローの流れを確立する

タスクが戦略的または分析的な場合、ワークフローのどのフェーズ（発見、分析、成果物の作成、レビュー）が該当するかを判断します。（出典：システム設計）

ステップ 4：スキルを呼び出す

関連するスキルをユーザーと確認し、それらのフレームワークを使って進める許可を求めます。（出典：システム設計）

スキル間の呼び出し

必須のサブスキル：using-skills — 呼び出しの規律を徹底します。 推奨のサブスキル：problem-framing — ディスカバリーフェーズを開始します。

合理化テーブル

考え	実情
「ユーザーの質問は簡単だから、スキルを確認する必要はありません」	簡単な質問は、複雑な戦略上の課題のほんの一端であることがよくあります。
「スキルを確認すると、会話が遅くなります」	適切なスキルを見つけるのに 10 秒かけることで、10 分の手戻りを防げます。
「スキルを使わなくても、どう対処すればよいかはわかっています」	確証バイアスに陥っています。スキルは見落としを防ぐためにあります。
「どのスキルも完全には当てはまらないようです」	何も使わないのではなく、最も近いスキルを使うか、複数のスキルを組み合わせます。

危険信号

次のように考えたら、一旦止まりましょう。近道をしようとしています。

• 「まずこれに回答して、その後でスキルを確認すればいい」→ これは鉄の掟に反します。
• 「該当するスキルはないはずです」→ おそらく、最近スキルの分類体系を確認していません。
• 「この作業は急ぎなので、準備を省いてもよい」→ 緊急性が高いほど、ミスのリスクも高まるため、準備がより重要になります。

診断チェックリスト

• ユーザーの主な領域を特定しましたか？
• 該当するスキルがないか、6 つすべてのファミリーを確認しましたか？
• 呼び出すスキルをユーザーに伝えましたか？
• 提案する計画は、該当する場合、ワークフローの連鎖に沿っていますか？
• 隠れた前提条件（PRD の前にステークホルダーのマッピングが必要など）がないことを確認しましたか？

出典

• システム設計 — スキルファミリーディレクトリ。
• システム設計 — ワークフローチェーンアーキテクチャ。
• システム設計 — 鉄の掟。