circuit-resource-analysis

Circuit リソース分析

概要

有用な Circuit のプロダクト学習につながるリソースを分析します。関係性、 対比、実現可能性、プロダクトへの影響、そしてそのアイデアを保存する価値があるかに 焦点を当てます。

まず情報源の事実を確認する

結論を示す前に、入手可能な情報源のうち最も信頼性の高いものを使います。

• リソースが貼り付けられている場合は、その内容を分析します。
• リソースがリンクの場合は、情報源を開くか検索します。使用したリンクを引用します。
• リソースがローカルリポジトリまたはコードベースの場合は、ファイルを直接調べます。
• リソースが GitHub リポジトリの場合は、関連する動作の根拠となる README、例、ドキュメント、 コードパスを調べます。
• リソースが現在の Circuit の動作を説明している場合、それが可能か不可能かを述べる前に、 ローカルの Circuit リポジトリで確認します。

Circuit リポジトリで作業する場合は、まず docs/release/v1-launch-plan.md を読みます。プロダクト用語には UBIQUITOUS_LANGUAGE.md を使います。フローの実現可能性については、記憶よりも 現行のコードとコントラクトを優先します。

Circuit に関する参考資料：

• docs/release/v1-launch-plan.md
• UBIQUITOUS_LANGUAGE.md
• docs/flows/authoring-model.md
• docs/flows/block-catalog.json
• src/flows/catalog.ts
• src/flows/types.ts
• docs/architecture/run-process.md
• docs/ideas/README.md
• docs/ideas/catalog.json

リソースを分類する

分析する前に、入力がどの種類に当たるかを示します。

• コードベース、リポジトリ、ライブラリ、またはツール
• 記事、エッセイ、論文、発表、投稿、または会話
• ワークフローの例
• プロダクトのパターンまたは競合製品のパターン
• その他

次に、以下の該当する分析手順を選びます。複数に該当する場合は、 組み合わせてください。

コードベースと記事を分析する

以下の質問に答えます。

1. 核心となるアイデアは何ですか？
2. Circuit とどのように関係していますか？
3. Circuit とどのように異なりますか？
4. Circuit はそこから何を学べますか？
5. Circuit は何を応用または採用できますか？
6. Circuit に合わないものは何ですか？その理由は何ですか？

情報源の一般的な要約よりも、具体的なプロダクトへの示唆を優先します。 事実と解釈を分けてください。

ワークフローの例を分析する

ワークフローについては、実現可能性を率直に評価します。

1. Circuit のフローとして興味深いものですか？
2. Circuit は現在これをサポートできますか？
3. できる場合は、フローの構成案を示します。
4. できる場合は、Circuit が説明されているワークフローをどのように発展させられるかを述べます。
5. できない場合は、不足している部分を示します。
6. 不足している部分を検討する価値があるかを述べます。
7. それらがフロー、ブロック、ルート、チェック、トレース、または レポートのエコシステムをどのように変えるかを説明します。

Slack、Linear、GitHub、メール、その他のツールに投稿するワークフローでは、 「MCP が存在する」という説明だけで終わらせないでください。実際の境界を特定します。

• そのツールはホストエージェントから利用できますか？
• Circuit のステップでそのツールを意図的に受け取れますか？
• 認証はどのように処理されますか？
• 人による承認が必要ですか？
• アクションが実行されたことを証明する証拠は何ですか？
• そのアクションは、フローの本体、ルート、チェック、レポート、または 実行を囲むゲートウェイのどこに属しますか？

以下を区別します。

• 現時点で動作する：既存のコントラクトを使って、現行のリポジトリがサポートしています。
• 設定すれば動作する：エンジンの変更は不要ですが、セットアップが必要です。
• 新しいブロックまたはルートが必要：フローの作成方法を変更する必要があります。
• エンジンの作業が必要：ランタイムまたはコントラクトの変更が必要です。
• 適合しない：Circuit のプロダクトの方向性と相容れません。

保存する価値があるか判断する

最後に、明確な推奨を示します。

• 保存する：v1 以降の有望なフロー、ブロック、プロダクトの表面領域、証拠のパターン、 またはポジショニングに関する示唆につながる場合。
• 保存しない：アイデアが一般的すぎる、すでに網羅されている、Circuit との関連が弱い、 または実装の詳細が中心である場合。
• 保存を検討する：有望なアイデアだが、もう 1 つ根拠が必要な場合。

保存を推奨する場合は、以下を示します。

• 短いアイデアのタイトル
• 保存先の候補：docs/ideas/、フローのバックログ、ブロックエコシステムのメモ、リリースの ポジショニングに関するメモ、または「追加調査が必要」
• 優先度：高、中、または低
• 1～2 文で理由を説明

ユーザーから記録を依頼されない限り、アイデアのドキュメントを作成または編集しないでください。

回答の形式

ユーザーが詳しい説明を求めない限り、回答は簡潔にします。

標準では、次の形式を使います。

1. 要点：直接的な回答を1つ。
2. このリソースが伝えていること：簡潔な概要。
3. Circuit との適合性：関連点と相違点。
4. Circuit で今すぐ実現できるか？：主な障壁とともに、「はい」「いいえ」「一部可能」のいずれかを示します。
5. Circuit が学べること：具体的な教訓。
6. 保存する価値はあるか？：「はい」「いいえ」「場合による」のいずれかを示します。

具体例のほうがわかりやすい場合は、抽象的なプロダクト用語を避けます。