jpskill.com
🛠️ 開発・MCP コミュニティ

create-handover-test

Playwright E2Eテストスイートにおいて、チケット番号を基に命名された引き継ぎテストを、適切なディレクトリに配置し、プロモーションライフサイクルに沿って作成するSkill。

📜 元の英語説明(参考)

Creates a ticket-driven handover test for a Playwright E2E test suite. Names the test with the ticket prefix, places it in the handover test directory, and follows the promotion lifecycle. Use when asked to write a handover test, ticket test, functional test, or test for a specific ticket number.

🇯🇵 日本人クリエイター向け解説

一言でいうと

Playwright E2Eテストスイートにおいて、チケット番号を基に命名された引き継ぎテストを、適切なディレクトリに配置し、プロモーションライフサイクルに沿って作成するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o create-handover-test.zip https://jpskill.com/download/10196.zip && unzip -o create-handover-test.zip && rm create-handover-test.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/10196.zip -OutFile "$d\create-handover-test.zip"; Expand-Archive "$d\create-handover-test.zip" -DestinationPath $d -Force; ri "$d\create-handover-test.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して create-handover-test.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → create-handover-test フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

ハンドオーバーテストの作成

特定の受け入れ基準を検証する、チケット駆動型のハンドオーバーテストを生成します。


ワークフロー

  1. ユーザーのリクエストからチケットキーと説明を解析します(例:PROJ-456 bulk export)。
  2. e2e/poms/ 内のテスト対象ページにPOMが存在するかどうかを確認します。
    • 存在する場合、それを読み込み、このチケットの受け入れ基準に必要な新しいメソッドを追加します。
    • 存在しない場合、最初に create-pom スキルを使用して作成します。
  3. テストデータが存在するかどうかを確認します。必要に応じて作成または更新します。
  4. e2e/tests/handover/スペックファイルを作成します。
  5. テストを実行して、合格することを確認します。
    npx playwright test --project="chromium:handover" {TICKET}-{description}.spec.ts

命名規則

ファイル名

{TICKET}-{short-description}.spec.ts
  • {TICKET} — チケットトラッカーに表示されるとおりの正確なチケットキー(例:PROJ-456MANT-123
  • {short-description} — 簡単なケバブケースの要約(チケットの完全なタイトルではありません)

例:

  • PROJ-456-bulk-export.spec.ts
  • MANT-123-vault-bulk-delete.spec.ts
  • FEAT-789-user-avatar-upload.spec.ts

test.describe ブロック

外側の test.describe には、追跡可能性のために必ずチケットキーを含める必要があります。

test.describe('PROJ-456: Bulk Export', () => {

スペックの構造

import { test } from '../../fixtures/base';
import { getAuthFilePath } from '../../helpers/env-config';
import { FeaturePage } from '../../poms/feature.page';

const authFile = getAuthFilePath();

test.describe('PROJ-456: Bulk Export', () => {
    test.beforeAll(async ({ browser }) => {
        const context = await browser.newContext({
            storageState: authFile,
        });
        const page = await context.newPage();
        const pom = new FeaturePage(page);
        await pom.setUp();
        await page.close();
        await context.close();
    });

    test('should export selected items as CSV', async ({ page, testData }) => {
        const pom = new FeaturePage(page);
        const items = testData.feature.items;

        await pom.navigateToPage();
        // ... チケットからの受け入れ基準を検証
    });

    test('should show error when no items selected', async ({ page }) => {
        const pom = new FeaturePage(page);

        await pom.navigateToPage();
        // ... エラー処理の基準を検証
    });
});

完全なテンプレートについては、references/handover-spec-template.md を参照してください。


POMのルール

ハンドオーバーテストは、回帰/スモークテストとすべて同じPOMのルールに従います。

  • テスト対象ページに既存のPOMを使用します。
  • チケットが新しいインタラクションを必要とする場合は、既存のPOMにメソッドを追加します。同じページに対して2番目のPOMを作成しないでください。
  • チケットが完全に新しいページを導入する場合にのみ、新しいPOMを作成します。
  • すべての新しいPOMメソッドには、Stepsと@paramタグを含む完全なJSDocが必要です。

すべての標準ルールが適用されます

  • @playwright/test からではなく、カスタムフィクスチャから test をインポートします。
  • スペックに生の page 呼び出しはありません。すべてのインタラクションはPOMを介して行われます。
  • すべてのテストは独立しています。独自のデータを作成し、独立してナビゲートします。
  • ハードコードされたテストデータはありません。testDataフィクスチャを介して外部JSONを使用します。
  • beforeAllは、クリーンアップのためにstorageStateを持つ手動ブラウザコンテキストを使用します。

プロモーションライフサイクル

ハンドオーバーテストは、設計上、一時的なものです。チケットが完了した後:

アクション いつ
回帰テストに昇格 機能が永続的であり、すべてのビルドで実行する必要がある場合
スモークテストに昇格 機能がクリティカルパス上にある場合
削除 既存のテストですでにカバーされている場合、または機能が元に戻された場合

昇格の準備ができたら、promote-handover-test スキルを使用します。

陳腐化ポリシー

  • すべてのスプリント/リリースの後に tests/handover/ を確認します。
  • チケットが完了/クローズされたスペックは、昇格または削除する必要があります。
  • ハンドオーバーテストを無期限に実行したままにしないでください。

ファイルチェックリスト

  • [ ] e2e/poms/{feature}.page.ts — POMが新しいメソッドで更新されました(または新しいPOMが作成されました)
  • [ ] e2e/test-data/{feature}.json — テストデータ(作成または更新)
  • [ ] e2e/tests/handover/{TICKET}-{description}.spec.ts — スペックファイル
  • [ ] ファイル名にチケットキーのプレフィックスが含まれています
  • [ ] test.describe にチケットキーが含まれています
  • [ ] すべてのPOMメソッドにJSDocがあります
  • [ ] テストに合格します: npx playwright test --project="chromium:handover" {TICKET}-{description}.spec.ts
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Create Handover Test

Generate a ticket-driven handover test that validates specific acceptance criteria.


Workflow

  1. Parse the ticket key and description from the user's request (e.g., PROJ-456 bulk export)
  2. Check if a POM exists for the page under test in e2e/poms/
    • If yes, read it and add any new methods needed for this ticket's acceptance criteria
    • If no, create one first using the create-pom skill
  3. Check if test data exists — create or update as needed
  4. Create the spec file in e2e/tests/handover/
  5. Run the test to verify it passes:
    npx playwright test --project="chromium:handover" {TICKET}-{description}.spec.ts

Naming Convention

Filename

{TICKET}-{short-description}.spec.ts
  • {TICKET} — The ticket key exactly as it appears in the tracker (e.g., PROJ-456, MANT-123)
  • {short-description} — Brief kebab-case summary (NOT the full ticket title)

Examples:

  • PROJ-456-bulk-export.spec.ts
  • MANT-123-vault-bulk-delete.spec.ts
  • FEAT-789-user-avatar-upload.spec.ts

test.describe Block

The outer test.describe must include the ticket key for traceability:

test.describe('PROJ-456: Bulk Export', () => {

Spec Structure

import { test } from '../../fixtures/base';
import { getAuthFilePath } from '../../helpers/env-config';
import { FeaturePage } from '../../poms/feature.page';

const authFile = getAuthFilePath();

test.describe('PROJ-456: Bulk Export', () => {
    test.beforeAll(async ({ browser }) => {
        const context = await browser.newContext({
            storageState: authFile,
        });
        const page = await context.newPage();
        const pom = new FeaturePage(page);
        await pom.setUp();
        await page.close();
        await context.close();
    });

    test('should export selected items as CSV', async ({ page, testData }) => {
        const pom = new FeaturePage(page);
        const items = testData.feature.items;

        await pom.navigateToPage();
        // ... validate acceptance criteria from ticket
    });

    test('should show error when no items selected', async ({ page }) => {
        const pom = new FeaturePage(page);

        await pom.navigateToPage();
        // ... validate error handling criteria
    });
});

See references/handover-spec-template.md for the full template.


POM Rules

Handover tests follow all the same POM rules as regression/smoke tests:

  • Use the existing POM for the page under test
  • If the ticket requires new interactions, add methods to the existing POM — do NOT create a second POM for the same page
  • Only create a new POM if the ticket introduces an entirely new page
  • All new POM methods must have full JSDoc with Steps and @param tags

All Standard Rules Apply

  • Import test from custom fixtures, not from @playwright/test
  • No raw page calls in specs — all interaction through POMs
  • Every test is independent — creates its own data, navigates independently
  • No hardcoded test data — use external JSON via the testData fixture
  • beforeAll uses manual browser context with storageState for cleanup

Promotion Lifecycle

Handover tests are temporary by design. After the ticket is Done:

Action When
Promote to regression Feature is permanent, should run on every build
Promote to smoke Feature is on the critical path
Delete Already covered by existing tests, or feature was reverted

Use the promote-handover-test skill when ready to promote.

Staleness Policy

  • Review tests/handover/ after every sprint/release
  • Any spec whose ticket is Done/Closed should be promoted or deleted
  • Never leave handover tests running indefinitely

File Checklist

  • [ ] e2e/poms/{feature}.page.ts — POM updated with new methods (or new POM created)
  • [ ] e2e/test-data/{feature}.json — Test data (created or updated)
  • [ ] e2e/tests/handover/{TICKET}-{description}.spec.ts — Spec file
  • [ ] Filename includes ticket key prefix
  • [ ] test.describe includes ticket key
  • [ ] All POM methods have JSDoc
  • [ ] Tests pass: npx playwright test --project="chromium:handover" {TICKET}-{description}.spec.ts