replica-recon

replica-recon

このパックのほかのすべては、このスキルが書き出す内容をもとに構築されます。調査マップが不十分だとクローンも不十分になるため、ここには時間をかけてください。

出力先はユーザーのプロジェクトです。

replica/recon.md        the recon map (template: recon-map.md in this folder)
replica/features.csv    the feature matrix (template: features.csv in this folder)
replica/screens/        reference screenshots of the original. Never shipped.

何よりも先に、ルールを確認

このスキルでは、クリーンルーム方式で機能と UX パターンを再構築します。アプリの動作と、ユーザーがどのように操作するかを調べます。アプリが所有するものには一切手を付けません。

• **公開情報源とユーザー自身のアカウントのみを使用します。**ユーザー本人のものではないアカウントには決してログインせず、パスワードを尋ねず、どんな手段を使ってもペイウォールやログインを突破しないでください。
• **スクレイピングではなく、閲覧を行います。**クローラー、一括ダウンロード、ループ処理は禁止です。ブラウザツールがユーザー自身のブラウザーに接続されている場合は、ユーザーが同席した状態で、人間の速度でページを読みます。
• **ソースコードや非公開 API は扱いません。**アプリの JavaScript バンドルを読んだり保存したり、バイナリを逆コンパイルしたり、エンドポイントをコピーするためにネットワーク呼び出しを記録したりしないでください。公開 API のドキュメントを読むことは問題ありません。
• **利用規約を確認します。**アカウントを使って競合製品を構築することを利用規約で禁止している製品もあります。ユーザーのアカウントにそのような規約が適用される場合は、その旨を伝え、公開情報源のみを使用してください。
• スクリーンショットは参照用です。replica/screens/ に保存し、レイアウトの比較に使用します。クローンには決して含めません。

ステップ 1：範囲を決める

次の 3 点を尋ねるか、回答案を提示して同意を得ます。

1. **どのアプリを、どのプラットフォームで扱うか。**Web、iOS、Android、デスクトップ。
2. どの範囲を扱うか。「Notion 全体」はプロジェクトの範囲として広すぎます。「Notion のページ、ブロック、共有」なら適切です。デフォルトでは、ユーザーがお金を払う理由となる主要なワークフローを対象にします。
3. **誰を対象にするか。**ユーザー自身のビジネス、特定のニッチ市場、販売する製品など。

ステップ 2：情報源をリストアップする

まず、各行に URL を記載した情報源の表を作成します。価値の高い順に並べます。

情報源	得られる情報
ヘルプセンター／ドキュメント	最も網羅的な機能一覧と設定
料金ページ	重要な機能（利用制限の対象となる機能）
変更履歴	最近追加されたものや、チームが重要と考えているもの
アプリストアの掲載ページ	主要画面のスクリーンショット、製品のアピールポイント、評価
公開されている操作解説動画	実際の操作フローをクリックごとに確認できます
マーケティングサイト	ポジショニングと、製品側の言葉で説明された主要なワークフロー
ユーザー自身のアカウント	ユーザーが操作する、あらゆる状態を含む実際のアプリ
公開 API ドキュメント	データモデルをほぼ手間なく確認できます

ステップ 3：画面の一覧

画面ごとに 1 行を記載します。ID は S01、S02... のように固定し、ほかのすべてのファイルで参照します。

ID | 画面 | ルートまたは画面への移動方法 | 目的 | 主要コンポーネント | 確認した状態

状態は重要です。空、読み込み中、入力済み、エラー、権限拒否、モバイルなどがあります。記録していない空の状態は、実装されない空の状態です。

ステップ 4：ユーザーフロー

F01、F02... のように、目標と、そこに至るまでに通過する画面を記載します。

F01 Guest books a meeting
    S07 booking page -> S08 pick a time -> S09 details form -> S10 confirmed
    edge: no slots this week, time zone differs, slot taken while filling the form

最短の成功ルートでクリック数を数えます。この数が超えるべき基準になります。

ステップ 5：コンポーネント

ボタン、入力欄、日付選択、モーダル、テーブル、トースト、ナビゲーションなど、繰り返し使われる UI パーツをすべて記載します。名称、バリエーション、状態、使用される画面を記録します。これが replica-design のコンポーネント一覧になります。

ステップ 6：推定データモデル

エンティティ、フィールド、リレーションシップを、それぞれ根拠と確信度とともに記載します。

Booking  id, event_type_id, start_at, end_at, guest_name, guest_email,
         status (confirmed | cancelled | rescheduled), answers (json)
         evidence: S09 form fields, S10 confirmation, help article "Cancel a booking"
         confidence: high

推測は推測として明記します。replica-architect がこれを実際のスキーマに変換します。

ステップ 7：機能マトリックス

replica/features.csv を作成します（列：feature、area、priority、original、clone、notes）。優先度は must／should／could です。すべての行で clone を no にしておき、構築中に値を入力します。replica-diff がその達成度を評価します。

ステップ 8：クローンできないもの

理由を添えた skip 行として、正直に列挙します。ライセンス対象のコンテンツ（音楽カタログ、ストック素材ライブラリ）、ネットワークとそのユーザー、アプリが所有するデータ、パートナーとの契約、ハードウェア、規制対象のライセンス（銀行、医療）などです。「あらゆるアプリをクローンする」とは、機能と操作フローを再現することであり、アプリが所有するものを再現することではありません。

ステップ 9：規模を見積もる

画面、フロー、エンティティ、難所（リアルタイム処理、同期、決済、カレンダーやメールとの連携、オフライン対応）を洗い出します。規模を設定します。S（週末程度）、M（数週間）、L（四半期）、XL（範囲を再検討）。完全なクローンを作れるという約束はしません。

出力

replica/recon.md と replica/features.csv を作成し、5 行でまとめます。コアループ、画面数とフロー数、最も難しい 3 つの要素、対象外とする内容、次のステップ /replica-architect を記載します。