app-evolver

アプリケーションエボルバー

アプリケーションがユーザーにもたらす実際の成果を向上させます。応用可能な仕組みを抽出し、現在のプロダクトとの適合性を見極め、許可された改善を実装し、アプリケーションを利用する側の画面を通じて検証します。

これをオーケストレーション用のスキルとして使用します。リポジトリーのエンジニアリング、リサーチ、履歴へのアクセス、リリース作業は、それぞれ既存の担当者に任せます。スキルを対象とする場合は skill-evolver を使用します。競合情報の調査だけを行う場合は competitors-analysis を使用します。新しいプロダクト仕様を作成する場合は、利用可能な要件ワークフローを使用します。既存の担当者を別の実行エンジンに置き換えないでください。

1. アプリケーションと未達の成果を特定する

リサーチや編集を始める前に、次の事項を明確にします。

• 対象となるアプリケーション、リポジトリー／ref、プラットフォーム、ランタイムまたはデプロイの正確な識別情報。
• ユーザーからの当初の依頼、現在のプロダクト契約、進行中の段階。長期的なポジショニングと、今回選択された作業を区別します。
• ユーザーから見える改善点、反証可能な受け入れ基準、許可された成果物、保護対象の動作やデータ、作業の終了条件。
• 分析のみか実装も許可されているか、また、回答によって成果が変わる未解決のプロダクト上の選択肢。
• 学習タスクの範囲。プロダクト全体や競合に関する幅広い学習では、単一の技術シナリオを調査対象に選ぶ前に、特定したデバイスとオペレーターの役割、および影響に関する判断を含む、想定されるユーザー成果の全体を、リサーチの問いを定める制約とします。単一の機能や既知の不具合に関するタスクは狭い範囲に保ち、プロダクト全体のレポートに広げないでください。

過去にユーザーが決定した内容を再利用し、不足情報や実際に未解決の選択肢についてのみ、現在の会話で質問します。利用可能な場合は、ホストの質問ツールを使用します。根拠、選択肢、それぞれの結果、推奨案を示してください。ユーザーの決定を別のエージェントに委ねないでください。

複数のアプリケーションを扱う場合は、それぞれの契約と受け入れ確認の経路を個別に特定します。あるアプリで成功した設計、権限、測定方法も、別のアプリでは未検証の提案です。現在の契約を確認せずに、デスクトップ版の契約をそのモバイル版に適用しないでください。

リポジトリーの指示と関連するドメインスキルを読みます。判断に使用するコードは不変のrefに固定し、現在のランタイム／設定は別途確認します。他の作業者による変更を保護し、編集前に担当範囲の重複を調整します。 再開時には、最新の依頼、実際の成果物、未完了の根拠を照合し、当初の計画を再実行するのではなく、最初に未達となっている成果から続行します。ユーザーが前提を訂正した場合、注意の向け先を変更した場合、またはタスクの範囲を明示的に変更した場合も、同様に照合します。現在の指定に合わせて対象を更新し、置き換えられた前提に依存する結論だけを撤回し、それ以外の検証済みの事実は再利用します。現在許可されているタスクの範囲に基づいて、次のリサーチの問いを選びます。一例の訂正を、その例全体がタスクになったこととみなさないでください。また、実際に範囲が狭められた場合は、その変更を単なる付随的な発言として扱わず、反映してください。

2. 根拠に基づいて機会と制約を把握する

変更を選択する前に、エビデンスと適合性をお読みください。 インターフェースの階層や製品全体の体験の分断に関する批判がある場合は、 局所的な視覚上の修正を選択する前に、 その構造の比較を確認してください。

既存のユーザージャーニー、アセット、サービス、テスト、実装の担当者をまず確認します。 依頼された場合、またはユーザーの環境で必要な場合は、利用可能な過去の作業や個人のコレクションを検索します。 明示的に依頼された調査の範囲を実施し、詳細な調査や履歴の調査を手早い確認に黙って置き換えてはいけません。 調査範囲について、判断に必要な根拠が得られた時点で、その範囲の調査を終了します。

履歴は、明示的に許可された範囲内でのみ使用します。所有するインデックスと正確なセッションリーダーを通じて取得し、 ユーザー／アシスタント／ツールの役割と子エージェントのプロンプト／結果へのリンクを保持します。 非公開の推論は除外します。取得できない範囲、古い範囲、不完全な範囲を明示し、 範囲を限定しない生の履歴スキャンに切り替えてはいけません。 アシスタントの結論は仮説として扱い、ユーザーの賛同や現在の事実とみなしてはいけません。

競合については、機能一覧だけでなく、実装と現在の一次情報を確認します。 リポジトリの根拠にはcompetitors-analysisを使用し、リポジトリ以外の製品については利用可能な調査担当者を活用します。 改訂内容を確認し、観察された動作と主張を区別します。 ソースへのアクセス、アーキテクチャ上の着想、コードの再利用、配布の許可は、それぞれ別個の問いとして扱います。 リポジトリを読めることは、その実装をコピーする許可にはなりません。

対象に応じてリバース分析スキルを組み合わせる

リリース済みアプリ、パッケージ、バイナリ、または実行時の動作を調査する場合は、 スキルの組み合わせをお読みください。 不足している根拠に応じて専門スキルを選び、その調査結果をこのワークフローに反映し、 現在の製品契約、仕組みの判断、エンジニアリング／受け入れの担当者を維持します。

個人のコレクションを利用できない場合は、公開されているスキルのルートを直接使用します。 許可された個人のお気に入り連携がある場合は、それを使って追加の仕組みやフレームワーク候補を探し、 採用前に実際のスキルソースを確認します。連携がなくても公開ルートの利用は妨げられません。 これは参照の組み合わせであり、サードパーティのスキルやエンジンをバンドルするものではなく、 インストール、MCP のセットアップ、対象の実行を許可するものでもありません。

3. 移行する内容を判断する

次のアクションに影響しうる仕組みごとに、以下を記録します。

判断材料	必要な回答
根拠	正確なソース／参照先と、確認された通常時・障害時・復旧時の挙動
ユーザーへのメリット	現在のどのユーザー向け成果がどのように改善されるか、またその主張をどのように反証できるか
既存の同等機能	アプリがすでに提供しているものと、その違い
適合性とコスト	契約、ライフサイクル、データ、デフォルト設定、依存関係、運用コスト
判断	採用、適応、却下、または要検証と、その決め手となる理由
次の根拠	残る不確実性を解消する最小限の検証またはユーザージャーニー

既存の不具合が実証されていなくても、肯定的な機会は残してください。 機会を正当化するために、不具合をでっち上げないでください。現在の契約に反する仕組みは却下し、有用な部分は残しながら、競合製品のアーキテクチャ、ビジネスモデル、またはより弱い保証を丸ごと持ち込まないでください。あるパラメーター群で失敗したからといって、無期限に試し続ける理由にはなりません。再試行を正当化する、構造的に新しい根拠を特定してください。

ユーザーがチームを依頼した場合は、ホストが実際に提供するコラボレーションツールと、範囲を限定した役割（必要に応じて、プロダクト適合性、実装／ライフサイクル、独立した異議検討）を使用してください。元の要件、正確な根拠、明確に分けた担当範囲、反証可能な検証方法を提示してください。実行担当者が根拠を確認するか検証を行うまでは、調査結果を仮説として扱ってください。そのような許可がない場合は、必要最小限の独立したレビューを行い、調査や評価を多数に展開しないでください。

調査可能な不確実性は自分で解消してください。ユーザーに尋ねるのは、好み、相互排他的な製品選択、または不足している許可であり、コードや読み取り専用の検証で確認できる事実ではありません。任意の調査領域が利用できなくても、独立して許可された作業を止める必要はありません。一方、根幹となる契約が不明な場合は、それに依存する変更を解決まで保留してください。

4. 最小限の有用な変更を実装する

編集または検証を開始する前に、実装と受け入れ基準を読んでください。 ドメインロールの依頼、または複数箇所にまたがる判断ポリシーについては、新しいコンポーネントを作成するか呼び出し元を移動するかを決める前に、ドメインロールの抽出に従ってください。

実装は、Skill Creator ではなく、リポジトリの実際のエンジニアリングワークフローとドメインオーナーに委ねてください。任意の Skill を利用できない場合は、アクセス可能なリポジトリの指示と、許可範囲内で適用可能なツールを使ってください。非公開の依存関係を自動でインストールしたり、実行していないチェックを実行したかのように装ったりしないでください。

ユーザーへのメリットと依存関係に基づいて作業の順序を決めてください。保護対象の挙動、ソースの来歴、永続化、ID、復旧経路を維持してください。製品契約上、必須処理の完了に影響させてはならない任意の処理は、必須のホットパスから外してください。その制限値は、このアプリのワークロードと測定結果に基づいて決めてください。無関係なアプリのタイムアウトやデバイスポリシーをコピーしないでください。

実装を依頼された場合は、依頼された実装と必要な検証を完了してください。計画や推奨だけで止めないでください。分析のみの依頼では、読み取り専用を維持してください。デプロイ、本番環境への書き込み、支出、公開、破壊的操作については、許可された範囲を守ってください。

5. 検証し、修正して、成果を届ける

想定される利用者の成果と、正常なケースが損なわれていないことを検証します。ソースチェック、合成テスト、実際のランタイムでの一連の操作、パッケージ化・インストール後の動作、本番環境の状態、人による採用状況を分けて確認します。あるレイヤーでの証拠は、別のレイヤーを証明するものではありません。成果が利用される箇所で読み返して確認します。

証拠が不十分な場合は、生のシグナルを調べ、反証を探し、根本原因または誤った判定基準を修正します。関連する入力または仮説が変わった後に限り、再試行します。新しいガードやチェックは、正常な入力と失敗する入力の両方で調整し、調査した項目を考慮したうえで、想定した不適切な動作が検出されることを示します。チェックをグリーンにするためだけに、製品の保証を弱めてはいけません。

確立された承認済みのワークフローを通じて、リポジトリへの成果の反映を完了します。既存の製品 SSOT では、変更された事実のみを更新します。依頼があれば、再利用可能な知見はそれを所有する Skill に残します。自動的な副産物として、メモリファイル、フック、新しいプロセスを作成してはいけません。

何を変更したか、なぜ適切なのか、どこに反映したか、ユーザーの成果を示すどの証拠を確認できたか、何が未検証なのかを報告します。宣言された成果がユーザーの判断に依存する場合は、人による承認を求めます。ユーザーに代わって承認済みとしてはいけません。承認された成果と必要な証拠がそろった時点で停止します。外部条件だけが残っている場合は、未完了の成果と、再開に必要な正確な条件を明示します。