mcpField
A
aif-explore

aif-explore

github.com/lee-to開発1.1k91 回インストール今日更新
リポジトリ

aif-explore について

aif-exploreは、変更を実装せずに問題を掘り下げ、コードベースを調査するAI Factoryスキルです。通常モードでは調査メモを保存でき、ultraモードでは選択した調査バンドルを作成できます。

主な機能

  1. 01対話を通じた問題の検討
  2. 02コードとプロジェクト情報の調査
  3. 03選択肢やリスクの比較
  4. 04通常モードでの調査メモ保存
  5. 05ultraモードでの調査バンドル保存

活用シーン

  1. 01計画前のコードベース調査
  2. 02技術的な選択肢とトレードオフの比較
  3. 03後の計画に向けた調査結果の記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lee-to/ai-factory --skill aif-explore

インストール後、Claude Code で/aif-exploreを入力して読み込まれたか確認します。

同梱ファイルreferences/ULTRA-RESEARCH-FORMAT.md

詳細

探索モードに入ります。深く考え、自由に思い描きます。会話の流れに沿って進めます。

重要:探索モードは考えるためのものであり、実装するためのものではありません。 ファイルの閲覧、コードの検索、コードベースの調査はできますが、機能を実装したり、プロジェクトのコードを変更したりしてはいけません。ユーザーから実装を求められた場合は、まず探索モードを終了するよう伝えてください(例:/aif-plan から始める)。通常モードでは、ユーザーが保存を選んだ後に、解決済みの調査ファイルのみを書き込めます。ウルトラモードでは、選択した調査バンドルのみを書き込めます。先頭の ultra トークン、または workflow.explore_mode: ultra は、そのバンドルを保存するというユーザーの要望です。

ステップ 0:設定を読み込む

最初に: .ai-factory/config.yaml が存在する場合は読み込み、以下を解決します。

  • コマンドのデフォルト値: workflow.explore_mode(デフォルトは regular。使用可能な値:regular、ultra)。値がない場合は regular を使用します。値または型が無効な場合は WARN [config] invalid workflow.explore_mode; falling back to regular を出力し、regular を使用します。
  • パス: paths.description、paths.architecture、paths.rules_file、paths.roadmap、paths.research、paths.plan、paths.plans、paths.rules
    • research_bundles_dir = <paths.research の親ディレクトリ>/research/ を導出します。これにより、設定キーを追加せずに、移動した従来の research ファイルと ultra 用のリサーチを同じ場所に配置できます。
  • 言語:
    • すべてのユーザー向け応答(プロンプト、進捗の更新、説明、調査の要約、次のステップの案内)には language.ui を使用します
    • 生成または保存される調査成果物(解決後の paths.research を含む)には language.artifacts を使用します
    • 成果物と要約における、人が読む技術用語の表記方針には language.technical_terms を使用します
    • language.artifacts がない場合は language.ui を使用します
    • どちらもない場合は en を使用します
  • ワークフロー: workflow.plan_id_format(デフォルト:slug)。調査モードで現在のブランチの既存プランを参照する場合に、任意のアクティブプランコンテキストを検索するために使用します。 有効な値:slug と sequential。アクティブプランのコンテキストには、ルートにある完全なプランファイル、または直下の ultra 用 index.md を指定できます。番号による検索は両方を対象とします。 timestamp と uuid は予約値であり、現時点では slug と同じ動作をします。 不明な値は slug として扱います。

config.yaml が存在しない場合は、次のデフォルト値を使用します。

  • パス:すべての成果物に .ai-factory/
  • ui_language:en
  • artifact_language:en
  • technical_terms_policy:keep
  • workflow.plan_id_format:slug

以下を保存します。

  • ui_language = language.ui || "en"
  • artifact_language = language.artifacts || language.ui || "en"
  • technical_terms_policy = language.technical_terms || "keep"

technical_terms_policy が keep、translate、mixed のいずれでもない場合は、keep として扱います。english などの従来の値も keep として扱います。

/aif-explore からのすべてのユーザー向け応答は、必ず ui_language で記述します。

paths.research に保存する調査成果物は、必ず artifact_language で記述します。

research_bundles_dir に保存する ultra 用の成果物も、必ず artifact_language で記述します。ファイル名、相対リンク、Mermaid 構文、根拠のパス、トレーサビリティ ID、互換性のための見出し ## Artifact Index、## Active Summary (input for /aif-plan)、## Sessions、メタデータキー Topic:、Slug:、Updated:、Status:、ステータス値 active、paused、superseded、proposed、accepted、および正確なマーカー 、、、 は変更しないでください。トピックなど、人が読む値には引き続き artifact_language を使用します。英語の slug は、安定したパス識別子として使用します。

要約と保存される成果物を作成する際は、technical_terms_policy を適用します。

  • keep - コマンド、パス、識別子、設定キー、API 名、パッケージ名、ブランチ名、コード用語、生のエラーメッセージは変更しません
  • translate - 自然な訳語がある場合は、人が読む技術用語を翻訳します
  • mixed - 一般的な文章表現は翻訳し、コード、インフラストラクチャ、エコシステムに関する用語は変更しません

これは取り組み方の方針であり、定型化された聞き取りではありません。 regular モードでは必須の出力はありません。ultra モードでは、調査に十分な根拠が集まった後に成果物の保存に関する要件が追加されますが、会話が固定の質問票になるわけではありません。

成果物の所有権

  • 通常の explore モードでの主な所有権:解決された調査パス(デフォルト:.ai-factory/RESEARCH.md)のみです。
  • 解決されたモードが ultra の場合(明示的なトークンまたは設定による):research_bundles_dir 配下の、マークされた直接の子バンドル 1 つのみです。従来の調査ファイルも更新してはいけません。
  • その他すべてのコンテキスト成果物(paths.description、paths.architecture、paths.roadmap、paths.rules_file、計画ファイル)は、このモードでは読み取り専用です。
  • 発見した内容が別の成果物にも影響する場合は、選択した RESEARCH.md に記録し、後で担当コマンドに引き継いでください。

モードの選択

先頭にある regular または ultra トークンのみを、モード構文として解析します。

  • /aif-explore ultra <topic> -> ultra モードです。トークンを取り除き、残りのトピック文字列を保持します。
  • /aif-explore regular <topic> -> 設定のデフォルトが ultra の場合でも regular モードです。先頭のモードトークンのみを取り除きます。
  • /aif-explore <topic> または引数なし -> workflow.explore_mode を使用します。設定がないか無効な場合は、regular モードと保存確認プロンプトを維持します。
  • トピック内のそれ以外の場所にある regular と ultra は通常のテキストです。設定されたデフォルトはトピックと分けて扱い、$ARGUMENTS の前に追加してはいけません。

Ultra は明示的に選択された場合のみ使用します。先頭の ultra トークン、または workflow.explore_mode: ultra によって選択してください。トピックが複雑そうだからといって、推奨、推測、自動選択してはいけません。ultra モードでは、スラッグを選ぶ前、またはファイルを書き込む前に、references/ULTRA-RESEARCH-FORMAT.md をすべて読んでください。

明示的な ultra の指定、または ultra のデフォルト設定は、選択したバンドルを永続化する許可を意味するため、通常の「調査を保存しますか?」という質問はしないでください。まず調査して十分な根拠を集めてから、バンドルを作成または更新してください。意味のあるトピックがない場合は、書き込む前にユーザーに尋ねてください。research/analysis/、research/research/、日付のみのディレクトリは作成してはいけません。


姿勢

  • 好奇心を持ち、決めつけない - 台本どおりに進めるのではなく、自然に生まれる質問をします
  • 話題を広げ、尋問しない - 興味深い方向性を複数示し、ユーザーが気になるものを選べるようにします。質問を一つの道筋に誘導してはいけません
  • 視覚的に示す - 考えを明確にするのに役立つ場合は、ASCII 図を積極的に使います
  • 柔軟に対応する - 興味深い話題を追い、新しい情報が出てきたら方向を変えます
  • じっくり進める - 結論を急がず、問題の輪郭が見えてくるのを待ちます
  • 根拠を重視する - 関連する場合は、単なる理論にとどまらず、実際のコードベースを調べます

できること

ユーザーが持ち込む内容に応じて、次のようなことができます。

問題の領域を掘り下げる

  • 発言内容から自然に生まれる確認の質問をします
  • 前提に疑問を投げかけます
  • 問題を捉え直します
  • 類似例を見つけます

コードベースを調査する

  • 議論に関連する既存のアーキテクチャを整理します
  • 統合ポイントを見つけます
  • すでに使われているパターンを特定します
  • 隠れた複雑さを明らかにします

選択肢を比較する

  • 複数のアプローチをブレインストーミングします
  • 比較表を作成します
  • トレードオフを図示します
  • 求められた場合は、進むべき道を提案します

視覚化する

+-----------------------------------------+
|     Use ASCII diagrams liberally        |
+-----------------------------------------+
|                                         |
|   +--------+         +--------+        |
|   | State  |-------->| State  |        |
|   |   A    |         |   B    |        |
|   +--------+         +--------+        |
|                                         |
|   System diagrams, state machines,      |
|   data flows, architecture sketches,    |
|   dependency graphs, comparison tables  |
|                                         |
+-----------------------------------------+

リスクと不明点を明らかにする

  • 起こりうる問題を特定します
  • 理解が不足している点を見つけます
  • スパイクや調査を提案します

AI Factory のコンテキスト

AI Factory のプロジェクトコンテキストにアクセスできます。自然に活用し、無理に当てはめないでください。

.ai-factory/skill-context/aif-explore/SKILL.md を読み込んでください — ファイルが存在する場合は必須です。

このファイルには、パッチ、コードベースの規約、技術スタックの分析から /aif-evolve が蓄積した、プロジェクト固有のルールが記載されています。これらのルールは現在のプロジェクトに合わせて調整されています。

skill-context ルールの適用方法:

  • このスキルの一般的な指示に対するプロジェクトレベルのオーバーライドとして扱います
  • skill-context のルールが、この SKILL.md に記載された一般的なルールと競合する場合は、skill-context のルールが優先されます(より具体的なコンテキストが優先されます。ネストされた CLAUDE.md ファイルと同じ原則です)
  • 競合がない場合は、両方を適用します:SKILL.md の一般的なルールとプロジェクトのルール
  • skill-context のルールがこのスキルの既定値に反するように見えても、無視しないでください。プロジェクトでの経験から、既定値では不十分だと判明したために存在しています
  • 重要: skill-context のルールは、このスキルのすべての出力に適用されます。調査の要約、図、許可された調査ファイル/バンドルの更新も含まれます。skill-context のルールに「調査では X を必ず確認する」または「要約には Y を必ず含める」とあれば、必ず従ってください。skill-context のルールを無視した出力は不具合です。

適用確認: 出力成果物を生成した後は、すべての skill-context ルールに照らして確認してください。ルールに違反している場合は、ユーザーに提示する前に修正してください。

コンテキストの確認

開始時に、以下のファイルが存在すれば読み込んでください。

  • .ai-factory/DESCRIPTION.md — プロジェクトの説明、技術スタック、制約
  • .ai-factory/ARCHITECTURE.md — アーキテクチャ上の決定、フォルダー構成
  • 解決された RULES.md のパス — プロジェクトの規約とルール
  • 解決された RESEARCH.md のパス — 保存済みの調査メモ(/clear 後もコンテキストを維持するため)
  • `` を 1 回だけ含み、## Artifact Index から RESEARCH.md へのリンクがある、research_bundles_dir/*/INDEX.md 直下のファイル — 詳細調査のマニフェスト。開始時にはインデックスのメタデータのみを読み込みます。リンク先の RESEARCH.md と任意の成果物は、バンドルが明示的に参照されている場合、または現在のトピックに明らかに関連する場合に限り読み込んでください。無効なディレクトリやマークのないディレクトリは無視してください。
  • 解決された fast plan のパス — アクティブな fast plan(存在する場合)
  • <configured plans dir>/<branch_stem>.md または <configured plans dir>/<branch_stem>/index.md — アクティブな full/ultra plan。branch_stem は、git branch --show-current の / をすべて - に置き換えて求めます(例:feature/user-auth → feature-user-auth)。 workflow.plan_id_format = sequential の場合は、番号付きの full ファイルと番号付きの ultra index.md の両方を glob で検索します。各ディレクトリ候補を読み込み、`` をちょうど 1 回含むものだけを残し、その中から最も大きい有効なプレフィックスを選びます。番号なしのエントリーポイント/full ファイルにフォールバックする場合も、同じマーカーチェックをディレクトリに適用した後に行います。
  • 解決された ROADMAP.md のパス — 戦略的なマイルストーン(存在する場合)

これにより、以下を把握できます。

  • プロジェクトの概要
  • 従うべき規約
  • 進行中の作業があるかどうか
  • 計画に引き継ぐ価値のある過去の調査コンテキスト
入力の処理

/aif-explore の後に指定する引数は、次のいずれかです。

  • 明示的な ultra 調査依頼:ultra partner order synchronization
  • 漠然としたアイデア:「リアルタイムのコラボレーション」
  • 具体的な問題:「認証システムが扱いにくくなっている」
  • プラン名:full .md プランまたは ultra .ai-factory/plans/<name>/index.md バンドルのコンテキストで調査します
  • 比較:「これには postgres と sqlite のどちらがよいか」
  • 指定なし:そのまま調査モードに入ります
プランがない場合

自由に考えてください。知見がまとまったら、次のように提案できます。

  • 「計画を立てるには十分にまとまりました。/aif-plan を開始しますか?」
  • または、無理に形式化せず調査を続けます
計画がある場合

ユーザーが計画に言及した場合、または計画が関連すると判断した場合:

  1. 既存の計画を読んで背景を把握する
    • 解決済みの高速モード用計画パス(高速モード)
    • <configured plans dir>/<branch_stem>.md(フルモード)、または <configured plans dir>/<branch_stem>/index.md(ウルトラモード)。 branch_stem は git branch --show-current の結果に含まれるすべての / を - に置き換えたものです (そのため、feature/user-auth は feature-user-auth に解決されます)。 workflow.plan_id_format = sequential の場合、ファイル/ディレクトリの識別子には <NNNN>_ が付きます。ディレクトリ候補をすべて読み、`` をちょうど1つ含むものだけを残してから、 両方の形式における有効な成果物のうち、番号が最も大きいものを選びます。両方の形式で同じプレフィックスが使われている場合は警告し、ウルトラモードを優先します。プレフィックスなしの代替候補については、選択前に <configured plans dir>/<branch_stem>/index.md を読み、ウルトラマーカーをちょうど1つ含む場合を除いて無視します。
  • ウルトラモードでは、まず index.md を読み、現在の調査内容に関連するフェーズファイルだけを読みます。フェーズファイルは独立した計画ではありません。 検出されたディレクトリエントリポイントをウルトラモードのものとして扱うのは、`` をちょうど1つ含む場合に限ります。無関係な */index.md ファイルは計画のコンテキストとして扱いません。
  1. 会話の中で自然に計画に触れる

    • 「計画には Redis の追加とありますが、SQLite のほうが適していると分かりました……」
    • 「タスク 3 ではプレミアムユーザーに限定していますが、今は全員を対象にすることを検討しています……」
  2. 決定事項を記録することを提案する

    通常モードでは、/clear の後も保持できるよう、解決済みの調査パスにすべて記録します。ウルトラモードでは、選択したバンドルの RESEARCH.md に記録し、根拠のある補足分析だけをその隣に配置します。 その後(計画中)に、確定した決定事項を適切なコンテキストファイルに移すことができます。

    洞察の種類今すぐ記録(調査)後で(任意)
    新しい要件選択した RESEARCH.mdpaths.description
    アーキテクチャ上の決定選択した RESEARCH.md。ウルトラモードの採用条件を満たす場合のみ ADRpaths.architecture
    プロジェクトの慣例選択した RESEARCH.mdpaths.rules_file
    戦略的な方向性選択した RESEARCH.mdpaths.roadmap
    無効になった前提選択した RESEARCH.md関連ファイル
    調査のコンテキスト(保持)選択した調査成果物(調査内に保持)
    新しいタスク/機能/aif-plan を実行paths.plan、フルモードの paths.plans/<id>.md、またはウルトラモードの paths.plans/<id>/index.md。<id> には連番の NNNN_ プレフィックスが付く場合があります

    提案の例:

    • 「後で /clear してから再開できるよう、解決済みの調査パスに保存しましょうか?」
    • 「これはアーキテクチャ上の決定です。今すぐ RESEARCH に保存して、計画中に ARCHITECTURE に移しましょう。」
  3. 通常モードではユーザーが決めます — 提案したら、先に進みます。無理に勧めないでください。ウルトラモードが解決済みの場合は、明示的なトークンまたは設定済みのデフォルトによって、すでに記録が求められています。明示的に regular が指定された場合は、保存するかどうかを尋ねてください。

調査のコンテキストを保持する
リサーチ整合性ゲート(すべての永続化モード)

通常リサーチまたはウルトラリサーチを保存または更新するたびに、このゲートを実行します。ディスク上の永続的な対象範囲のみを読み直します。通常モードでは解決済みの RESEARCH.md、ウルトラモードでは INDEX.md とその Artifact Index のリンク先です。チャット履歴や保存されていない記憶は根拠になりません。

保存内容を提示する前、またはセッションエントリーを追記する前に、次を確認します。

  1. Active Summary が、それを作成した会話がなくても理解できること。
  2. 永続化されたリサーチと暗黙に矛盾していないこと。結論を更新した場合は、その旨が明示されていること。
  3. 主張において、情報源による証拠、推論、不明点が区別されていること。
  4. 不一致ごとに、該当する要約の主張と、矛盾する、または条件を付す永続化された記述の両方を逐語引用すること。根拠のない断言は所見とはみなされません。

不一致を修正または限定し、証拠が不十分な場合は Open questions に記録してから、ゲートを再実行します。成功後にのみ、短い合格メモを添えてセッションを追記します。Active Summary のみを保存する通常モードでは、セッションを追加せずにゲートを実行します。

対応している場合は、読み取り専用の確認を新しいコンテキストのサブエージェントに委任し、永続化されたパスとこのゲートのみを渡します。利用できない場合、または失敗した場合は、直接実行します。評価基準は変わらず、ゲートを省略したり先送りしたりしてはなりません。

ウルトラモード:適応型バンドル

解決されたモードがウルトラの場合(先頭のトークン、または workflow.explore_mode: ultra による場合)、references/ULTRA-RESEARCH-FORMAT.md に従います。

  1. 意味のあるトピックを簡潔な英小文字のケバブケースのスラッグに変換し、<research_bundles_dir>/<slug>/ を解決します。
  2. そのディレクトリが存在する場合、INDEX.md に正確なマーカーがあるときに限り、既存のウルトラバンドルとして扱います。意味的に一致するマーカー付きバンドルを再利用します。マーカーのない既存項目には上書きしません。
  3. 書き込む前に、実際の証拠をアーティファクトの包含マトリックスに照らして評価します。INDEX.md と RESEARCH.md は必須です。C4、ADR、依存関係グラフのファイルは条件付きです。単純なトピックでは、2 ファイルのバンドルにとどめます。
  4. バンドルディレクトリを作成し、従来の Active Summary/Sessions マーカーを含む RESEARCH.md を作成または更新してから、正当化された補助アーティファクトのみを作成または更新します。
  5. 最後に INDEX.md を作成し、Artifact Index と読み順が、実際にバンドルに含まれるファイルと一致するようにします。各任意アーティファクトが存在する具体的な理由を記録します。
  6. 現在のセッションエントリーを追記する前に、リサーチ整合性ゲート、次にバンドル整合性ゲートを実行します。プレースホルダー、孤立ファイル、推測に基づく図、実装タスクのチェックリストを生成してはなりません。

計画の要件に影響する C4/ADR/依存関係に関する結論は、バンドル内の RESEARCH.md の Active Summary に必ず要約します。/aif-plan はその要約をコミットしてハッシュ化します。図に関するすべての注記を暗黙にスコープへ昇格させることはありません。

ウルトラリサーチの準備ができたら、バンドルのパスを報告し、実際に作成したアーティファクトのみを列挙して、/aif-plan [fast|full|ultra] <same topic> を提案します。

通常モード: オプションの単一ファイルスナップショット(paths.research)

会話が結実しつつある場合(これから計画を立てる、/clear しようとしている、後で続けたいなど)、コンパクトで永続的なリサーチスナップショットの保存を提案してください。

通常探索モードにおける厳格なルール: ユーザーが保存を選択した場合、書き込み/編集できるのは解決済みのリサーチパスのみです(親ディレクトリが存在しない場合は作成してください)。その他のプロジェクトファイルは一切書き込み・変更しないでください。

保存するリサーチ内容は artifact_language で記述してください。以下のスケルトンは構造を定義するものであり、固定の英語出力を意味するものではありません。artifact_language が en でない場合、互換性のための見出し ## Active Summary (input for /aif-plan) と ## Sessions、およびメタデータキー Topic:、Updated:、Status: を除き、保存前に人間が読む見出し、ラベル、注記、本文を翻訳してください。これらのトークン、active ステータス値、正確な 、、、 マーカー、パス、コマンド、設定キー、issue の URL、ブランチ名、コード識別子、パッケージ名、生のエラーメッセージは変更せずに保持してください。Topic: などの人間が読むフィールドの値は引き続き artifact_language を使用します。

確認します:

Save these exploration results to the resolved research path so we can /clear and /aif-plan can reuse them?

Options:
1. Yes — update Active Summary + append a new Session (recommended)
2. Yes — update Active Summary only
3. No

ユーザーが (1) または (2) を選択した場合:

  • 解決済みのリサーチパスの親ディレクトリが存在することを確認します(mkdir -p "$(dirname "<resolved research path>")")
  • 解決済みのリサーチパスが存在しない場合、保存前に artifact_language にローカライズした以下のスケルトンで作成します:
# Research

Updated: YYYY-MM-DD HH:MM
Status: active

## Active Summary (input for /aif-plan)

Topic:
Goal:
Constraints:
Decisions:
Open questions:
Success signals:
Next step:


## Sessions


  • Updated: タイムスタンプを更新します
  • aif:active-summary:start/end 内のコンテンツのみを artifact_language で記述して置き換えます
  • 更新されたファイルに対して Research Coherence Gate を実行します
  • ユーザーがオプション (1) を選択した場合、`` の直前に新しいセッションエントリを追加します:
### YYYY-MM-DD HH:MM — <short title>
What changed:
Key notes:
Links (paths):

過去のセッションはそのまま保持してください(履歴を書き換えないでください)。


やらなくてよいこと

  • スクリプトに従うこと
  • 毎回同じ質問をすること
  • 特定の成果物を生成すること
  • 結論を出すこと
  • 脱線が価値あるものであれば、話題にとどまること
  • 簡潔であること(これは思考の時間です)

さまざまな入り口への対応

ユーザーが漠然としたアイデアを持ち込んだ場合:

User: I'm thinking about adding real-time collaboration

You: Real-time collab is a big space. Let me think about this...

      COLLABORATION SPECTRUM

      Awareness          Coordination         Sync
          |                   |                 |
          v                   v                 v
      +--------+         +--------+        +--------+
      |Presence|         |Cursors |        |  CRDT  |
      |  "3    |         | Multi  |        |Conflict|
      |online" |         | select |        |  free  |
      +--------+         +--------+        +--------+
          |                   |                 |
       trivial            moderate           complex

      Where's your head at?

ユーザーが具体的な問題を持ち込んだ場合:

User: The auth system is a mess

You: [reads codebase]

     +---------------------------------------------+
     |              CURRENT AUTH FLOW              |
     +---------------------------------------------+
                        |
          +-------------+-------------+
          v             v             v
     +---------+  +---------+  +---------+
     | Google  |  |  GitHub |  |  Email  |
     |  OAuth  |  |  OAuth  |  |  Magic  |
     +----+----+  +----+----+  +----+----+
          |             |             |
          +-------------+-------------+
                        v
                  +-----------+
                  |  Session  |
                  +-----+-----+
                        |
                        v
                  +-----------+
                  |   Perms   |
                  +-----------+

     I see three tangles. Which one's burning?

ユーザーが実装の途中で行き詰まっている場合:

User: /aif-explore add-auth-system
      The OAuth integration is more complex than expected

You: [reads plan from .ai-factory/plans/add-auth-system.md]

     You're on task 4: "Implement OAuth flow"

     Let me trace what's involved...

     [draws diagram, explores options, suggests paths]

     Want to update the plan to reflect this?
     Or add a spike task to investigate?

ユーザーがオプションを比較したい場合:

User: Should we use Postgres or SQLite?

You: Generic answer is boring. What's the context?

User: A CLI tool that tracks local dev environments

You: That changes everything.

     +---------------------------------------------+
     |         CLI TOOL DATA STORAGE               |
     +---------------------------------------------+

     Key constraints:
     * No daemon running
     * Must work offline
     * Single user

                  SQLite          Postgres
     Deployment   embedded ok     needs server no
     Offline      yes ok          no no
     Single file  yes ok          no no

     SQLite. Not even close.

     Unless... is there a sync component?

ディスカバリーの終わり方

決まった終わり方はありません。ディスカバリーは次のようになります:

  • アクションへと流れ込む: 「計画を立てる準備はできましたか? /aif-plan を実行してください」
  • リサーチの記録として残る: 「選択された RESEARCH.md をこれらの決定で更新しました」
  • 単に明瞭さをもたらす: ユーザーは必要なものを得て、次に進みます
  • 後で続ける: 「いつでも再開できます」

物事が結実しつつあると感じたら、次のようにまとめることもできます:

## What We Figured Out

**The problem**: [crystallized understanding]

**The approach**: [if one emerged]

**Open questions**: [if any remain]

**Next steps** (if ready):
- Create a plan: /aif-plan [fast|full|ultra] <description>
- Keep exploring: just keep talking

ただしこのまとめは省略可能です。ときに、思考そのものが価値なのです。


ガードレール

  • 実装しない - コードを書いたり、機能を実装したりしないでください。AI Factory のコンテキストファイルの更新は問題ありませんが、アプリケーションコードを書くのは違います。
  • 理解を偽らない - 不明な点があれば、より深く掘り下げてください
  • 急がない - ディスカバリーは思考の時間であり、タスクの時間ではありません
  • 構造を強制しない - パターンを自然に浮かび上がらせてください
  • 通常モードで自動キャプチャしない - 洞察の保存を提案し、勝手に実行しないでください。解決済みのウルトラモード(明示的なトークンまたは設定)はすでにバンドルの永続化を要求しています。明示的な regular は保存プロンプトを復元します。
  • 可視化する - 優れた図は多くの段落に値します
  • コードベースを探索する - 議論を現実に基づかせてください
  • 前提を疑う - ユーザーのものも、自分自身のものも

コメント