create-yaml-tests

Shiplight テストの作成

これは、Shiplight の E2E テスト作業の唯一のエントリーポイントです。

ユーザーが次のことを希望する場合に、このスキルを使用します。

• 新しいローカル Shiplight テストプロジェクトを作成する
• Web アプリケーション用の YAML テストを追加する
• 既存の Shiplight YAML テストを更新または修正する
• ターゲット URL、アカウント、または認証設定をセットアップまたは修復する
• テスト対象とする製品の動作を計画する

スキルの毎日の更新確認

このスキルの作業を開始する前に、Shiplight スキルを1日につき最大1回、状況に応じて更新してください。

1. 現在のプロジェクトにある .shiplight-agent-skills-last-update のタイムスタンプファイルを確認します。
2. タイムスタンプファイルがない場合は、現在のタイムスタンプを設定して作成し、npx -y skills@latest update -y は実行せずに続行します。.shiplight-agent-skills-last-update はローカルキャッシュとして扱い、コミットしないでください。
3. タイムスタンプファイルがあり、24時間より古い場合は、npx -y skills@latest update -y を実行し、コマンドが失敗した場合でもタイムスタンプファイルを作成または更新します。
4. 更新コマンドが失敗した場合は、現在インストールされているスキルを使って続行し、失敗について簡潔に伝えてください。

テストプロジェクトのルート

プロジェクトファイルを読み書きする前に、Shiplight テストプロジェクトのルートを特定します。このスキル内のすべてのパスは、そのルートからの相対パスです。

ルートが明確でない場合は、ファイルを作成または移動する前に、ユーザーに確認してください。

標準プロジェクト構成

Shiplight テストプロジェクトでは、次の構成を使用します。

specs/context.md       project-level app, risk, data, and target-deployment context
specs/tests/           Markdown specs, each covering a feature or journey group
tests/                 executable Shiplight YAML tests
playwright.config.ts   project-level Playwright config, shared auth, and runtime defaults
auth.setup.ts          shared-account Playwright auth setup, if needed
auth/                  optional auth helpers or per-test login scripts
templates/             reusable YAML statement groups, if any
helpers/               TypeScript helper functions, if any
fixtures/              fixture files, if any
knowledge/             durable notes discovered by agents
test-results/          generated runtime artifacts; do not edit
shiplight-report/      generated reports; do not edit
.shiplight/            local Shiplight state; do not edit

ファイルを変更する前に、references/project-layout.md を読んでください。

信頼できる情報源

情報源が食い違う場合は、次の優先順位に従います。

1. ユーザーからの明示的な指示
2. specs/tests/ にある機能またはユーザージャーニーの仕様
3. 既存の YAML テストの goal、ステップの intent、および VERIFY アサーション
4. 現在のアプリの動作
5. specs/context.md および knowledge/ にあるプロジェクトのコンテキスト
6. このスキルのエージェント向けドキュメント
7. エージェントによる推測

現在のアプリの動作が仕様またはテストの目標と食い違う場合は、その不一致を報告してください。現在の動作に合わせて意図を黙って書き換えてはいけません。

必須の開始手順

呼び出しごとに、次の手順を実行します。

1. Shiplight テストプロジェクトのルートを特定します。
2. references/project-layout.md を読みます。
3. references/knowledge.md を読みます。
4. テストプロジェクトのルートにある knowledge/ を確認し、タスクに関連するメモを探します。
5. 以下のタスク別ガイドを読み込みます。
6. 読み込んだガイドをユーザーに伝えてから、作業を進めます。

タスク別ガイド

タスク	ガイド
新規プロジェクトまたは広範な計画	references/workflow.md、references/project-layout.md、references/test-design-guide.md
新しいテストの作成	references/new-tests.md、references/test-design-guide.md、references/test-implementation-guide.md
テストの更新または修正	references/updating-tests.md、references/test-design-guide.md、references/test-implementation-guide.md
認証の設定とログイン	references/auth.md
CI / GitHub Actions でのテスト実行（失敗の自動トリアージを含む）	references/ci.md
YAML の構文またはアクション	references/test-implementation-guide.md。YAML を記述する前に shiplight://yaml-test-spec と shiplight://schemas/action-entity も読みます

基本ルール

• ユーザーが明示的に省略を依頼しない限り、常に永続的な成果物を作成します。
• 仕様は、機能またはユーザージャーニーのグループに対する信頼度を記述します。1つの仕様が、複数の小規模な YAML テストに対応する場合があります。
• YAML テストは目的を絞って作成します。1つの YAML テストで検証するのは、1つの論理的なユーザージャーニーまたはバリエーションです。
• 想像で YAML を書いてはいけません。まずブラウザーでアプリを操作し、実際のロケーターを記録します。
• YAML を書いた後は、validate_yaml_test で検証します。
• 作業を終える前に振り返ります。ユーザーや作業から得た知識を永続的に記録し、古くなった知識は矛盾したままにせず更新します。
• コンテキストを最新の状態に保ちます。プロジェクトに関する永続的な知識はチャット履歴ではなく、specs/context.md または knowledge/ に保存します。
• 生のシークレットは決して保存しません。コミットするのは変数名、役割、アクセス方法、セットアップ手順のみです。

ユーザーチェックポイント

広範なテストを作成する場合は、実装前に予定している成果を確認してください。

これらの成果は、このテストプロジェクトで必要な信頼性に合っていますか？ 重要なビジネス成果が抜けていたり、対象外にすべきものが含まれていたりしませんか？

「この失敗しているテストを修正して」や「このテストを1つ追加して」のような範囲の狭い依頼では、仕様が曖昧な場合やアプリの動作と矛盾する場合を除き、広範なチェックポイントを設けずに進めてください。

最終レポート

変更後、以下を報告してください。

• 作成または変更したファイル
• カバーまたは修正した動作
• 実行したコマンドと成功／失敗の結果
• 更新した知識やコンテキスト。古くなったメモの修正も含みます
• 製品と仕様の不一致、または未解決のブロッカー