just-use-it

まず使う

まず使う。ソースを読むのは最後です。

ソースにアクセスできるライブラリ、フレームワーク、CLI、または開発者向けツールを1つ選び、使用優先の監査を実施します。ユーザーが利用するインターフェースを通じて機能サーフェスを実際に操作し、その後、ソースを調べて公開機能と、実地検証で見落とした、リポジトリ内で実行可能な関連環境を見つけます。

監査では、利用体験、カバレッジの根拠、指摘パケットを扱います。根拠の適格性評価とアクションの推奨（不足している事実によって推奨が変わる可能性がある場合の、範囲を限定した調査を含む）には、assess-findingsを使用してください。investigate-with-evidence依存関係とともにインストールしてください。いずれかを利用できない場合は、可能な範囲で使用を続け、不足している依存関係を明記して未評価の指摘パケットを保持します。評価は保留のままです。製品の修正とトラッカーへの記録には、別途承認が必要です。同時に稼働する$yak-shaving-triageは、設定された権限の範囲でトラッカーの整合と作業記録の作成を担います。正式なトラッカーへの公開には、別途承認が必要です。

作業はスライス優先で進めます。各実行エージェントは、割り当てられた機能グループ内で、ユーザーの成果につながる機能ジャーニーを1つ、その識別に役立つバリエーション、および該当する探索を完了します。以下の委任ワークフローを通じて、独立したスライスを並行して進めてもかまいません。エントリーポイントやコンテナーを開いて確認できるのは、そのエントリーポイントだけです。その内部の機能まで確認したことにはなりません。

1. 範囲を定めて切り分ける

対象、想定ユーザー、ユーザー向けドキュメント、および実地検証に必要な環境を特定します。依頼内容とワークスペースからこれらを推定し、実質的に異なる対象が複数残る場合に限り、質問してください。

成果の範囲を定める

ユーザーが明示した範囲を使用します。作業を続ける場合は、次の作業を選ぶ前に、選択済みのバッチとその進捗を確認してください。通常の利用依頼では、プロジェクトの構造または機能別に整理した、実質的な機能グループからなる有限のバッチを選びます。各グループには、ユーザーの成果につながるジャーニーを含めます。実施済みの主要ワークフロー、記録された深度、未カバーの領域、関連する指摘をもとに、有意義な作業がある場合は複数のグループを選びます。固定数に合わせたり、グループを不自然に分割したりせず、有用なバッチを選んでください。明示的に全サーフェス監査を求められた場合は、全サーフェスを範囲とします。より狭い依頼では、Exploreとの併用も含め、その依頼の境界を維持します。

ドキュメント、使用、ソースとの照合、評価を通じてバッチの範囲を維持します。結論を変える可能性がある場合、ブロッカーを説明する場合、または根拠を無効にする場合は、新たな確認を追加します。独立して有用な新しい成果は、将来のバックログに記録します。共有コンポーネントだけでは、範囲の拡大や確認済み作業の再実施を正当化できません。完了の説明は宣言したバッチを対象とし、製品全体が完了したと主張せずに、より広い範囲のカバレッジマップを保持します。

ユーザーの指示で範囲が変更されても、それまでのカバレッジとソース／トラッカーの確認状況は維持します。魅力的なアイデアを見つけた場合や、難しい障害に直面した場合でも、バッチを暗黙に縮小してはいけません。

成果物と開始フェーズを定める

開始時または再開時に監査成果物を選択、作成する前に、根拠の鮮度と対象の選定を適用し、ソース、実行した成果物、元のアップストリームを確認します。これは新規監査にも、記録済みの作業の再開にも適用されます。無関係なインストール済みリリースではなく、選択した対象のドキュメントに記載されたビルドを使用します。挙動の根拠として採用する前に、利用可能な起動メタデータまたは識別メタデータを通じて、実際に有効な実行可能ファイル、インポートされたパッケージ、またはデプロイメントを確認してください。観察結果は実際に実行されたものの範囲に限定します。ソースとの対応関係が不明な場合、ソースへの帰属は制限されますが、直接観察した事実は制限されません。ソースまたは履歴へのアクセスが制限されている場合は、許可された識別メタデータを確認し、実装の比較は保留して、不確実性と再開条件を記録します。 日々の継続監査では、経路を選ぶ前に、記録の契約に従って設定された関連する作業記録を確認します。保留中の結果、変更された挙動、関連する証拠を使って実際の利用を優先し、新たな観察の余地も残します。過去の Verified 結果は、記録された成果物についての証拠であり、現行バージョンについての証拠ではありません。継続の文脈がない状態で新たに監査を行う場合は、公開されているユーザータスクから始めます。ユーザーが独立した体験を求めている場合は、監査ゲートまで過去の指摘本文、要約、トラッカーの調査を保留します。設定の確認だけで指摘が明らかになるとは限りません。履歴をすでに把握している場合は、新たに独立した監査を行っていると主張せず、その制約を開示します。これらの選択によって変わるのは証拠の由来と経路の順序であり、宣言された結果の範囲ではありません。

パスを計画する前に、開始フェーズを定めます。継続監査または既知の問題の再検証では、既存のカバレッジ、証拠の由来、評価担当者、ソース／トラッカーへのアクセス状態を確認します。未完了のゲートを引き継ぎ、依頼された範囲に関係する証拠のみを更新します。その状態を使用状況、Assess、Yak の各ワーカーと共有します。新しいワーカーと一時プロジェクトにも、この証拠の由来を引き継ぎます。以下のフェーズ開始手順は、各ゲートが未完了の間に適用されます。すでに開始済みのソース調査と照合は、残りの使用状況確認と並行して進めてもかまいません。実際の公開利用から、引き続き挙動の証拠を得ます。

初回のソース非参照監査では、最初の2つのパスの間、挙動に関わる実装ソースと対象プロジェクトのイシュートラッカーを参照しないでください。リポジトリの指示に従い、ツールを起動するために必要な公開ドキュメントとエントリーポイントのメタデータを確認します。ドキュメントに記載された起動方法で失敗した場合は、その結果を記録してから、運用メタデータを使って対象を実行可能な状態にします。ソースパスに入るまでは、実装を参照しません。

ソース非参照とは、挙動の把握を避けることであり、安全性の確認まで避けることではありません。実行が安全かどうかを判断するために必要な最小限のインストールフック、起動スクリプト、権限、外部への影響を確認します。ただし、それらから製品の挙動を推測してはいけません。安全な実行により広範なソース確認が必要な場合は、ソース非参照の順序を維持できないことを開示し、その手順で使用状況優先監査を行ったと主張しないでください。

CLI、公開 API、パッケージを利用する場合は、利用者側のセットアップ、インストール、初回呼び出しの前に、ヘルプやバージョンの確認も含め、references/programmatic-experience.mdを読んでください。

自動選択されるプロジェクト、ワークスペース、設定ソース、またはワークロードの規模や処理範囲が評価に影響するジャーニーでは、実行前にコンテキストとワークロードの確認を読んでください。

必要なランタイム、コンパイラツールチェーン、SDK、システムパッケージ、コンテナーランタイム、または同様の前提条件が不足している場合は、インストールや該当機能の断念を決める前に、references/prerequisites.mdを読んでください。

コストのかかる実行や不確かなワークロードの前に、リソース制御を読んでください。直接の作業、ワーカー、子プロセスにまたがる総予算を適用してください。ファイルシステムの分離ではメモリを制限できません。

破棄可能な状態を優先してください。

• ユーザーがブラウザーまたはタブを明示的に開き、使用を依頼した場合は、新たに作成する前にその既存のセッションを選択します。
• 対象のチェックアウトで追跡対象になっているファイルを変更しないでください。状況に応じて、既存の安全な実行インスタンス、破棄可能なコピーまたはワークツリー、あるいは対象の外部にある利用者用ワークスペースを使用します。
• 監査で作成した一時パス、プロセス、サーバー、ブラウザーコンテキストをすべて記録し、完了、失敗、中断時に正確に後片付けできるようにします。
• 外部への影響は、破棄可能なプロジェクト、テストデータ、またはサンドボックス内に限定します。既存の認可チェックポイントをすべて維持し、安全に実行できない機能には Blocked と記録します。 完了条件： 成果のスコープと対象外事項、対象とその実行環境との対応関係または不確実性、公開されている出発点の資料、開始フェーズと引き継がれるゲート、ブラウザーの選択、分離境界、クリーンアップ対象、既知の前提条件に関するすべての判断が明確になっていること。

2. 文書化された機能範囲を把握する

初回監査では、動作の実装ソースを読まずに公開ドキュメントから Capability Surface を構築し、対象範囲内の文書化されたすべての機能に Not Exercised の状態を割り当てます。対象範囲外であることが判明している機能は、成果のスコープに対象外事項として残します。継続監査では、依頼されたスコープと更新が必要な証拠について、既存の Coverage Ledger を更新します。

Capability Group は、プロジェクトの構造または機能ごとに整理します。各グループでは、必要なコンポーネント境界をすべてまたぐ、ユーザーの成果に至る一連の手順に沿って進めます。選択したグループは、製品の主要タスクと関連する記録済みのカバレッジに基づいて順序付けします。既知の各 Capability Group、目標とする成果、インターフェースとモード、現在の状態、次のアクションを含む簡潔な Coverage Ledger を作成します。

初期ゲートが閉じている間は、実装ソースと対象の課題トラッカーを閉じたままにします。ソースを閉じた状態とは、動作に関する情報を得ない状態を意味します。安全な起動に必要な公開ドキュメントとエントリーポイントのメタデータは、引き続き利用できます。

完了条件： 対象範囲内のすべての機能がユーザーの成果に基づくグループに属し、維持中または保留中のカバレッジが明確で、次の Vertical Capability Slice が特定されていること。

3. 垂直スライスを完了する

各スライスの開始前に、限定されたコンテキストで独立して作業を進められるか、リソースの状態を制御できるか、委任によるメリットが引き継ぎや統合にかかるコストに見合うかに基づいて、実行担当者を選択します。密接に関連する調査は現在の担当者が続け、独立したコンテキストによって割り当て作業の効果が高まる場合は、新しいワーカーを使用します。境界が不明確な場合は、明確になるまで現在の担当者が作業を続けます。作業を割り当てる前、スライスを並行実行する前、または担当者を変更する前に、実行の調整 を読んでください。メインエージェントが実行する場合も、同じ一連の手順と証拠要件に従います。

割り当てられたワーカーは、自身のスライス内でこのスキルに従います。監査全体を最初からやり直したり、さらに委任したりはしません。初期のソースを見ないパスでは、すべてのエージェントが実装ソースと対象の課題トラッカーを閉じたままにします。後続の割り当てでは、監査で確立されたソース／トラッカーのフェーズと出所情報を引き継ぎ、ソースを見ない手順を最初からやり直しません。各 Capability Group について、次の手順に従います。

グループでインタラクティブ UI を使用する場合は、操作する前に references/ui-experience.md を読んでください。スライスに終端状態を割り当てる前に、その UI Journey Gate を完了します。このリファレンスでは、必要な観察事項と、対象外および Blocked の経路を定義しています。

1. 文書化された機能ジャーニーに正確に従い、公開インターフェースを通じて、ユーザーにとって観察可能な結果が得られるまで実行します。
2. 入力、状態、モード、または復旧条件のいずれか1つを変更し、観察可能な結果が異なるはずの識別力のあるバリエーションを1つ試します。その機能に実質的なバリエーションがない場合は、明示的に除外を記録します。
3. references/exploration-lenses.mdを読み、アクティブな機能グループ内で自由に探索します。機能の形に沿った小規模なマトリックスを作成します。実際の結果と実質的なバリエーションに証拠があり、具体的な所見について、その判断に十分な調査が行われているか、未解決の依存関係が明示され、次に調べるべき不確実性または除外を説明できる状態になったら、グループの作業を完了します。バグを見つけること、または見つからないことは完了基準ではありません。根本原因の完全な特定が必要なのは、それによって分類、対処、担当、または範囲が変わる場合に限られます。
4. 新たに見つかった公開機能を機能サーフェスに追加します。アクティブな結果に役立つ機能は現在のスライスに残し、独立して有用な結果は結果の範囲に従って分類します。対象範囲内のものは新しいNot Exercisedグループとして追加し、それ以外は除外として記録します。
5. 最初のVerified状態を割り当てる前に、references/verification-traces.mdを読みます。完全な検証トレースがある場合に限り、機能をVerifiedにできます。動作が所見に該当する可能性が生じたら、すぐにreferences/finding-packets.mdを読み、証拠を保全して、早期評価のためコーディネーターに回します。アセッサーが現在のソース／トラッカーのフェーズに基づいてパケットをレビューしている間も、使用を続けます。
6. スライス内のすべての機能に終端状態を割り当て、証拠を記録します。委任された実行者は、その結果をメインエージェントに返します。メインエージェントは証拠を確認し、カバレッジ台帳を更新してから、同じ実行基準に基づいて次の割り当てを選択します。Verified、Finding、Observed、Blockedは使用に関する終端状態です。Observedはジャーニーを実行したものの、その問題または改善に関する判断が保留中であることを意味します。評価の状態は使用完了とは別に管理します。Not Exercisedは未完了のままです。

完了した各グループの調査深度と証拠を保存したら、既存の許可の範囲内で、次に選択されたグループへ自動的に進みます。バッチ内の既知の機能に実行可能なものが残っている間は、完了したスライスをまたいで続行します。進捗報告にはスライスの区切りを使います。部分監査は未完了のカバレッジを示すものであり、タスクを終了する理由ではありません。ユーザーが停止または範囲の縮小を求めた場合、あるいは利用できない前提条件、アクセス権、またはユーザー入力なしでは対象範囲内で意味のある進捗をこれ以上見込めない場合に、未完了の監査を終了します。ある機能がBlockedでも、実行可能な他の作業は続けます。終了時には、残っているカバレッジと再開条件を保持します。初回のトラッカー照合前の一時停止では、そのゲートを閉じたままにします。すでに開いているゲートは開いたままにします。既知の対象範囲内の機能がNot Exercisedのまま中断によって実行を終了する場合は、現在のスライスと次のアクションを保持し、完了した所見パケットを凍結して、部分監査として報告します。別個にアクティブな記録ワークフローでは、凍結したパケットを照合できます。その後の監査では、再開後を含むトラッカーの履歴を読み込むため、挙動を事前に知らない状態ではなく、トラッカーの情報を踏まえて実施します。

実装が文書化されていない修正によって動作する場合でも、ドキュメントの誤りは所見です。運用メタデータやソースに関する知識を使って、文書化されたジャーニーを暗黙に救済してはいけません。 完了条件： 対象範囲内の機能のうち、ソースを参照せずに発見できるものすべてに最終状態が設定されていること、実質的に適用可能な探索視点すべてについて、実行済みの経路または明示的な除外があること、すべての Verified 機能に Verification Trace があること、そして選択した各グループが上記の深度基準を満たしていることです。独立した今後のグループは、この完了宣言の対象外です。

4. ソースと照合する

実装ソースがまだ閉じられている場合、必要なハンズオンのスライスが証拠の整理まで含めて完了し、先行する利用完了条件も満たされた後に、メインエージェントがソースを開きます。この移行を評価担当ワーカーに通知してください。トラッカーの履歴は、それ自体のゲートが開くまで閉じたままにします。可能な場合は、ソースを実際に操作した成果物と照合し、別リビジョンから得た手掛かりは、それぞれの成果物で実際に確認するまで条件付きのものとして扱います。

成果の対象範囲に関係する公開エクスポート、ルート、コマンド、フラグ、機能登録、例、テスト、および必要な依存関係を調べ、カバレッジに含まれていない、リリース済みの公開機能を探します。新たに見つかった独立した成果は、同じ対象範囲の境界に従って分類します。内部用、テスト専用、または未リリースと明記されていない限り、リリース済みのエクスポート、実行ファイル、ルート、ブラウザーグローバルは公開されたものとして扱います。ヘルプ項目が非表示であることだけでは、非公開であるとは判断できません。未解決の公開意図は明示的に報告してください。

追加の機能経路、コンポーネント状態、または統合を利用できる、実行可能なリポジトリ環境を特定するため、references/repository-environments.md を読んでください。こうした環境は、それ自体がエンドユーザー向けリリースでなくても、有用な実体験を提供することがあります。環境自体の証拠と、それが表す製品経路の証拠は、対象範囲を分けて管理してください。

ソースから発見した機能と関連環境を、既存のカバレッジ、妥当な除外、または新たに割り当てた利用確認に対応付けます。新しいスライスの実行担当者は、同じ実行基準に従って選び、ソースから発見した経緯を記録してください。ソースの調査で得られるのは手掛かりであり、実際の実行によって利用の証拠が得られます。調査結果やソースの証拠から以前のカバレッジの限界が明らかになった場合は、関連するカバレッジを再検討してください。評価担当ワーカーはこの時点から、割り当てられた推奨事項の対象範囲内でソースに依存する質問を調査できます。その間も、独立した利用確認は継続します。

対象範囲内でソースにより確認された公開エントリーポイントと関連環境のすべてについて、利用確認または明示的な除外による整理が済んだら、独立して観察されたパケットを凍結し、監査照合ゲートを開きます。同時進行の記録ワークフローを使ってバッチを照合し、割り当てられた評価担当者に証拠を返すことができます。Yak を使わない場合、評価担当者は手法で許可された範囲内で、読み取り専用のトラッカーチェックを実施できます。トラッカーの履歴を読むと、その後の作業はトラッカー情報を踏まえたものとして扱われます。新しいワーカーに切り替えても、先入観のない来歴には戻りません。

カバレッジの最終調整として、ゲート通過後に公開されているイシュー履歴をサンプリングしてもかまいません。関連する公開経路を再度実行してください。そこで初めて遭遇した挙動は、独立した発見ではなく、既知のイシューの再現として扱います。

完了条件： ソースから発見したカバレッジが整理されていること、すべての利用スライスに最終状態があること、パケットの来歴と照合の適格性が明確であることです。評価は、名前を挙げた前提条件が満たされるまで保留のままでもかまいません。利用フェーズの移行を妨げることはありません。

5. レポートとクリーンアップ

finding handoff を使用して、最終レポートの前に評価結果を収集します。会話形式の監査レポートには、次の内容を含めます。

• 意図した対象、実際に検証したアーティファクトまたはインスタンス、および環境。
• 宣言された成果の対象範囲、その除外事項、および対象範囲内の各機能の状態を記載した Coverage Ledger。
• Verified の各機能に対する簡潔な Verification Trace。
• 評価済みの所見、改善の機会、未解決の観察事項、および除外した主張。それぞれの根拠と、区別した対応の推奨事項。
• Blocked の機能、および部分実行の場合は Not Exercised の機能。
• 別途有効化された記録ワークフローから返された、再利用済みレコードまたは正常に公開された変更のトラッカーリンクまたは識別子。
• クリーンアップの結果。

対象範囲内の機能に Not Exercised のものが残っている場合は、その結果を 部分監査 と呼びます。完了した垂直機能スライスと、残っている作業を明記してください。それ以外の場合は、除外事項を明示したうえで、宣言された対象範囲の完了を報告します。機能サーフェス全体の完了を主張できるのは、サーフェス全体を対象とした監査のみです。

ユーザーがリポジトリアーティファクトを明示的に求めない限り、会話形式のレポートにします。保存を求められた場合は、指定された保存先とリポジトリの規約を厳守します。正式なトラッカーへの公開は、このスキルの対象外です。許可された作業レコードの更新では、完全な監査レポートのアーティファクトを作成しなくても、共有レコード契約を通じてパケットと評価を保持できます。保存先がない場合は、その永続化が明示的に保留中であることを示します。履歴へのアクセスが許可される前に観察事項を書き込む場合も含め、ID の照合中は独立監査のゲートを維持してください。

監査を終了する前に、すべての監査ワーカーを停止または終了し、そのリソース状態を収集します。破棄可能な状態を削除する前に、必要な証拠を会話、依頼されたレポート、または独立して許可された記録ワークフローに移します。部分的な進捗やリソースによって中断された進捗も含め、共有レコード契約に基づいて対象範囲の深度と次のアクションを保持します。そのうえで、この監査用に作成した正確な一時パスのみを削除し、この監査用に起動したプロセス、サーバー、タブ、またはブラウザーコンテキストのみを停止します。ユーザー所有のブラウザー状態は保持してください。クリーンアップに失敗した場合は、残存するパスまたは実行中のリソースを添えて、すべて報告します。

完了条件： レポートの対象範囲に関する主張が台帳と一致し、すべてのパケットに評価または証拠不足もしくは依存関係に関する明示的な制約があり、すべての破棄可能なパスと実行中のリソースが削除済み、または残存状態として報告されていること。