ワンクリックで
test-plan-format
Test plan structure, naming conventions, edge case generation rules, and file saving conventions for QA test plans.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Test plan structure, naming conventions, edge case generation rules, and file saving conventions for QA test plans.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Backend testing patterns — API request construction, response verification, database state checks, error handling testing, and adaptive tool detection.
Frontend testing patterns using Playwright — navigation, interaction, assertions, screenshots on failure, and common UI testing scenarios.
Test report format with QA-XXX issue IDs compatible with code-review plugin. Defines report structure, severity levels, issue format with canonical fields, and detailed results.
Enforces AppVerk Swift coding standards across all code.
Structured concurrency and thread safety patterns in modern Swift.
Data persistence patterns for Swift apps using SwiftData, CoreData, UserDefaults, and Keychain.
| name | test-plan-format |
| description | Test plan structure, naming conventions, edge case generation rules, and file saving conventions for QA test plans. |
| activation | Load when creating or formatting QA test plans |
docs/testing/plans/YYYY-MM-DD-<topic>-test-plan.md where <topic> is a slugified summary (lowercase, hyphens, no spaces)mkdir -p docs/testing/plansEvery test plan MUST follow this exact structure:
# Test Plan: <title>
## Source
- Type: <PR #N / branch <name> / last N commits / staged changes>
- Base: <main/master>
- Date: <YYYY-MM-DD>
## Changes Summary
<Brief description of what changed and what needs testing. List affected areas.>
## Detected Tools
- Playwright: <available/unavailable>
- HTTP client: <curl/httpie/unavailable>
- Database access: <psql/sqlite3/mysql/unavailable>
## FE Test Scenarios
### FE-01: <scenario name>
- **Area:** <component/page>
- **Preconditions:** <what must be true before test>
- **Steps:**
1. <action>
2. <action>
3. <verification>
- **Expected:** <expected result>
- **Edge cases:**
- <edge case 1>
- <edge case 2>
## BE Test Scenarios
### BE-01: <scenario name>
- **Area:** <endpoint/service>
- **Method:** <HTTP method> <path>
- **Headers:** <required headers, e.g. Authorization: Bearer TOKEN>
- **Payload:** `<JSON body>`
- **Expected:** <status code>, <response body description>
- **DB Check:** `<SQL query>` — <expected state>
- **Edge cases:**
- <edge case with expected response>
FE-01, FE-02, ... FE-NN (zero-padded two digits)BE-01, BE-02, ... BE-NN (zero-padded two digits)For EVERY scenario, consider and include relevant edge cases from:
## BE Test Scenarios section entirely## FE Test Scenarios section entirely## Detected Tools and mark dependent scenarios with (skip — <tool> unavailable) in the scenario nameBefore saving the plan, verify: